User login
Username: *
Password: *
Browse archives
November 2014
Reinventing HTML
Reinventing HTML
Making standards is hard work.
Its hard because it involves listening to other people
and figuring out what they mean, which means figuring out where they are coming from, how they are using words, and so on.
There is the age-old tradeoff for any group as to whether to
zoom along happily, in relative isolation, putting off the day
when they ask for reviews, or whether to get lots of people
involved early on, so a wider community gets on board earlier, with
all the time that costs.
That's a trade-off which won't go away.
The solutions tend to be different for each case, each working group.
Some have lots of reviewers and some few, some have lots of time, some
urgent deadlines.
A particular case is HTML.
HTML has the potential interest of millions of people: anyone who has designed a web page may have useful views on new HTML features.
It is the earliest spec of W3C, a battleground of the browser wars,
and now the most widespread spec.
The perceived accountability of the HTML group has been an issue. Sometimes this was a departure from the W3C process, sometimes a sticking to it in principle, but not actually providing assurances to commenters. An issue was the formation of the breakaway WHAT WG, which attracted reviewers though it did not have a process or specific accountability measures itself.
There has been discussion in blogs where Daniel Glazman, Bj?rn H?rmann,
Molly Holzschlag, Eric Meyer, and Jeffrey Zeldman and others have shared
concerns about W3C works particularly in the HTML area.
The validator and other subjects cropped up too, but let's focus on HTML now.
We had a W3C retreat in which we discussed what to do about these things.
Some things are very clear. It is really important to have real developers on the ground involved with the development of HTML.
It is also really important to have browser makers intimately involved and committed.
And also all the other stakeholders, including users and user companies and makers of related products.
Some things are clearer with hindsight of several years.
It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work.
The large HTML-generating public did not move, largely because the browsers didn't complain.
Some large communities did shift and are enjoying the fruits of well-formed systems, but not all.
It is important to maintain HTML incrementally, as well as continuing
a transition to well-formed world, and developing more power in that world.
The plan is to charter a completely new HTML group.
Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact.
It will work on HTML and xHTML together.
We have strong support for this group, from many people we have talked to, including browser makers.
There will also be work on forms.
This is a complex area, as existing HTML forms and XForms are both form languages. HTML forms are ubiquitously deployed, and there are many implementations and users of XForms.
Meanwhile, the Webforms submission has suggested sensible extensions to HTML forms.
The plan is, informed by Webforms, to extend HTML forms. At the same time, there is a work item to look at how HTML forms (existing and extended) can be thought of as XForm equivalents, to allow an easy escalation path. A goal would be to have an HTML forms language which is a superset of the existing HTML language, and a subset of a XForms language wit added HTML compatibility.
We will see to what extend this is possible.
There will be a new Forms group, and a common task force between it and the HTML group.
There is also a plan for a separate group to work on the XHTML2 work which the old "HTML working group" was working on.
There will be no dependency of HTML work on the XHTML2 work.
As well as a new HTML work, there are other things
want to change. The validator I think is a really valuable tool both for users and in helping standards deployment. I'd like it to check (even) more stuff, be (even) more helpful, and prioritize carefully its errors, warning and mild chidings.
I'd like it to link to an explanations of why things should be a certain way. We have, by the way, just ordered some new server hardware, paid for by the Supporters program -- thank you!
This is going to be hard work.
I'd like everyone to go into this realizing this. I'll be asking these groups to be very accountable, to have powerful issue tracking systems on the w3.org web site, and to be responsive in spirit as well as in letter to public comments.
As always, we will be insisting on working implementations and test suites. Now we are going to be asking for things like talking with validator developers, maybe providing validator modules and validator test suites. (That's like a language test suite but backwards, in a way).
I'm going to ask commenters to be respectful of the groups, as always.
Try to check whether the comment has been made before, suggest alternative text, one item per message, etc, and add to technical perception social awareness.
This is going to be a very major collaboration on a very important spec, one of the crown jewels of web technology.
Even though hundreds of people will be involved, we are evolving the technology which millions going on billions will use in the future.
There won't seem like enough thankyous to go around some days.
But we will be maintaining something very important and creating something even better.
p.s. comments are disabled here in breadcrumbs, the DIG research blog, but they are welcome .