Since we published the Working on HTML5.1 post, we’ve made progress. We’ve closed more issues than we have open, we now have a working rhythm for the specification that is getting up to the speed we want, and we have a spec we think is a big improvement on HTML5.

Now it’s time to publish something serious.

We’ve just posted a Call For Consensus (CFC) to publish the current HTML5.1 Working Draft as a Candidate Recommendation (CR). This means we’re going into feature freeze on HTML5.1, allowing the W3C Patent Policy to come into play and ensure HTML5.1 can be freely implemented and used.

While HTML5.1 is in CR we may make some editorial tweaks to the spec – for instance we will be checking for names that have been left out of the Acknowledgements section. There will also be some features marked “at risk”, which means they will be removed from HTML5.1 if we find during CR that they do not work in at least two shipping browsers.

Beyond this, the path of getting from CR to W3C Recommendation is an administrative one. We hope the Web Platform WG agrees that HTML5.1 is better than HTML5, and that it would benefit the web community if we updated the “gold standard” – the W3C Recommendation. Then we need W3C’s membership, and finally W3C Director Tim Berners Lee to agree too.

The goal is for HTML5.1 to be a W3C Recommendation in September, and to achieve that we have to put the specification into feature freeze now. But what happens between now and September? Are we really going to sit around for a few months crossing legal t’s and dotting administrative i’s? No way!

We have pending changes that reflect features we believe will be shipped over the next few months. And of course there are always bugs to fix, and editorial improvements to make HTML at W3C more reliable and usable by the web community.

In the next couple of weeks we will propose a First Public Working Draft of HTML5.2. This will probably include some new features, some features that were not interoperable and so not included in HTML5.1, and some more bug fixes. This will kick off a programme of regular Working Draft releases until HTML5.2 is ready to be moved to W3C Recommendation sometime in the next year or so

As always please join in, whether by following @HTMLWG on Twitter, filing issues, joining WP WG and writing bits of the specification, or just helping your colleagues stay up to date on HTML…

… on behalf of the chairs and editors, thanks!

Source: Web Design

A draft of a new article, Ruby Markup is out for wide review. We are looking for comments by 5 May.

The article describes how to mark up HTML for ruby support. (It will later be followed by a similar article describing how to style ruby.)

Please send any comments as github issues by clicking on the link “Leave a comment” at the bottom of the article. (This will add some useful information to your comment.)


Source: Web Design

HTML5 was released in 2014 as the result of a concerted effort by the W3C HTML Working
Group. The intention was then to begin publishing regular incremental updates to the HTML standard, but a few things meant that didn’t
happen as planned. Now the Web Platform Working Group (WP WG) is working towards an
HTML5.1 release within the next six months, and a general workflow that means we can release
a stable version of HTML as a W3C Recommendation about once per year.

Goals

The core goals for future HTML specifications are to match reality better, to make the specification as clear as possible to readers,
and of course to make it possible for all stakeholders to propose improvements, and understand what makes changes to HTML successful.

Timelines

The plan is to ship an HTML5.1 Recommendation in September 2016. This means we will need to have a Candidate Recommendation by the
middle of June, following a Call For Consensus based on the most recent Working Draft.

To make it easier for people to review changes, an updated Working Draft will be published approximately once a month. For
convenience, changes are noted within the specification itself.

Longer term we would like to “rinse and repeat”, making regular incremental updates to HTML a reality that is relatively
straightforward to implement. In the meantime you can track progress using Github
pulse
, or by following @HTML_commits or @HTMLWG on Twitter.

Working on the spec…

The specification is on Github, so anyone who can make a Pull Request can propose changes.
For simple changes such as grammar fixes, this is a very easy process to learn – and simple changes will generally be accepted by the
editors with no fuss.

If you find something in the specification that generally doesn’t work in shipping browsers, please file an issue, or better still file a Pull Request to fix it. We will
generally remove things that don’t have adequate support in at least two shipping browser engines, even if they are useful to have and
we hope they will achieve sufficient support in the future: in some cases, you can or we may propose the dropped feature as a future
extension – see below regarding “incubation”.

HTML is a very large specification. It is developed from a set of source files, which are processed with the Bikeshed
preprocessor
. This automates things like links between the various sections, such as to element definitions. Significant
changes, even editorial ones, are likely to require a basic knowledge of how Bikeshed works, and we will continue to improve the
documentation especially for beginners.

HTML is covered by the W3C Patent Policy, so many potential patent holders have already ensured that it can be implemented without
paying them any license fee. To keep this royalty-free licensing, any “substantive change” – one that actually changes conformance –
must be accompanied by the patent commitment that has already been made by all participants in the Web Platform Working Group. If you
make a Pull Request, this will automatically be checked, and the editors, chairs, or W3C staff will contact you to arrange the
details. Generally this is a fairly simple process.

For substantial new features we prefer a separate module to be developed, “incubated”, to ensure that there is real support from the
various kinds of implementers including browsers, authoring tools, producers of real content, and users, and when it is ready for
standardisation to be proposed as an extension specification for HTML. The Web Platform
Incubator Community Group (WICG)
was set up for this purpose, but of course when you develop a proposal, any venue is
reasonable. Again, we ask that you track technical contributions to the proposal (WICG will help do this for you), so we know when it
arrives that people who had a hand in it have also committed to W3C’s royalty-free patent licensing and developers can happily
implement it without a lot of worry about whether they will later be hit with a patent lawsuit.

Testing

W3C’s process for developing Recommendations requires a Working Group to convince the W3C Director, Tim Berners-Lee, that the
specification

“is sufficiently clear, complete, and relevant to
market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized”

This had to be done for HTML 5.0. When a change is proposed to HTML we expect it to have enough tests to demonstrate that it does
improve interoperability. Ideally these fit into an automatable testing system like the “Webapps
test harness
“. But in practice we plan to accept tests that demonstrate the necessary interoperability, whether they are readily
automated or not.

The benefit of this approach is that except where features are removed from browsers, which is comparatively rare, we will have a consistently
increasing level of interoperability as we accept changes, meaning that at any time a snapshot of the Editors’ draft
should be a stable basis for an improved version of HTML that can be published as an updated version of an HTML Recommendation.

Conclusions

We want HTML to be a specification that authors and implementors can use with ease and confidence. The goal isn’t perfection (which
is after all the enemy of good), but trather to make HTML 5.1 better than HTML 5.0 – the best HTML specification until we produce HTML
5.2…

And we want you to feel welcome to participate in improving HTML, for your own purposes and for the good of the Web.

Chaals, Léonie, Ade – chairs
Alex, Arron, Steve, Travis – editors

Source: Web Design

For twenty-five years the Internationalization & Unicode® Conference (IUC) has been the preeminent event highlighting the latest innovations and best practices of global and multilingual software providers. The 40th conference will be held this year on November 1-3, 2016 in Santa Clara, California.

The deadline for speaker submissions is Monday, 4 April, so don’t forget to send in an abstract if you want to speak at the conference.

The Program Committee will notify authors by Friday, May 13, 2016. Final presentation materials will be required from selected presenters by Friday, July 22, 2016.

Tutorial Presenters receive complimentary conference registration, and two nights lodging, while Session Presenters receive a fifty percent conference discount and two nights lodging.


Source: Web Design

This is an open invitation to all people in the free-software community for genuine person-to-person dialog with people in the W3C staff about DRM on the Web (and any other topics of importance to the Web we all have an interest in discussing).

We have a People of the W3C page that lists the names and e-mail addresses of all the W3C staff, and we always welcome you to contact us about the work we are doing together for the Web. Along with that we have a Contact page that includes more details about how to find us.

We believe this invitation from us to you for real person-to-person dialog is a much more constructive route to mutual understanding and change than approaches such as the recent campaign (under the apparent aegis of the Free Software Foundation) which you might have seen, that encourages you to instead go by a W3C office to just “take a protest selfie” in demonstration against “DRM in HTML”.

As the announcement about that campaign suggests, if you live near a W3C office, “you have a unique opportunity to make a difference”—but that opportunity is actually for much more than just snapping a selfie next to a W3C sign. Instead you have a chance to talk with real people who care a great deal about the Web and its future—just as you do—and to find out things we agree about with each other, and problems we can work on solving together.

We’re all real people. So let’s treat each other like real people, and don’t instead let someone else make you try to shoehorn yourself into any narrative they want to construct about fearless activists doing battle against some faceless uncaring entity.

So if you care enough yourself to make time to visit a W3C office in person, please consider not doing it only to take a selfie in front of a W3C sign and then leave. Instead, make it an opportunity to actually meet the people at your nearby W3C office who care deeply about a lot of same things you do, and chat with some of us person-to-person over a cup of coffee (or hey, maybe even some after-work drinks somewhere nearby).

The announcement about the “take a protest selfie” campaign claims to have “reliable advice” that it will be “very influential to the W3C’s leadership”. But I have a lot more reliable advice for you: The open invitation for real person-to-person conversation, that we as people are offering you right here, is an opportunity to be much more influential.


Related:

Source: Web Design

Since the end of last year the Web Platform Working Group has responsibility for W3C’s HTML spec, as well as many other core specifications. What have we been doing with HTML, and what is the plan?

The short story is that we are working toward an HTML 5.1 Recommendation later this year. The primary goals are to provide a specification that is a better match for reality, by incorporating things that are interoperable and removing things that aren’t.

We also want more people and organisations to get involved and make sure the development of HTML continues to reflect the needs and goals of the broad community.

As an important step down that path, the editors (Arron Eicholz, Steve Faulkner and Travis Leithead) have published the Editors’ Draft in github, and by using bikeshed to build it we have made it easier for people to propose an effective edit. Different kinds of edit require different levels of effort, of course…

Fixing a typo, or clarifying some text so it is easier to understand, are easy ways to start contributing, getting used to the spec source and github, and improving HTML. This level of edit will almost always be accepted with little discussion.

Meanwhile, we welcome suggestions – ideally as pull requests, but sometimes raising an issue is more appropriate – for features that should not be in a Recommendation yet, for example because they don’t work interoperably.

Naturally proposals for new features require the most work. Before we will accept a substantial feature proposal as part of an HTML recommendation, there needs to be an indication that it has real support from implementors – browsers, content producers, content authoring and management system vendors and framework developers are all key stakeholders. The Web Platform Incubator Community Group is specifically designed to provide a home for such incubation, although there is no obligation to do it there. Indeed, the picture element was developed in its own Community Group, and is a good example of how to do this right.

Finally, a lot of time last year was spent talking about modularisation of HTML. But that is much more than just breaking the spec into pieces – it requires a lot of deep refactoring work to provide any benefit. We want to start building new things that way, but we are mostly focused on improving quality for now.

The Working Group is now making steady progress on its goals for HTML, as well as its other work. An important part of W3C work is getting commitments to provide Royalty-Free patent licenses from organisations, and for some large companies with many patents that approval takes time. At the same time, Art Barstow who was for many years co-chair of Web Apps, and an initial co-chair of this group, has had to step down due to other responsibilities. While chaals continues as a co-chair from Web Apps, joined by new co-chairs Adrian Bateman and Léonie Watson, we still miss both Art’s invaluable contributions and Art himself.

So we have taken some time to get going, but we’re now confident that we are on track to deliver a Recommendation for HTML 5.1 this year, with a working approach that will make it possible to deliver a further improved HTML Recommendation (5.2? We’re not too worried about numbering yet…) in another year or so.

Source: Web Design

In addition to generally updating the information, the following changes were made:

  • rearranged most of the material and rewrote the majority to make it more readable
  • updated information about desktop browser settings
  • limited that section to just a representative sample of major browsers
  • removed ‘Finding and choosing custom tags’, since no longer relevant
  • added information about mobile devices

See the updated article.

See the github commit diffs.


Source: Web Design