Why do WYSIWYG editors hate HTML5?

What happens when Web browser vendors design new HTML features but don't consult with other parties such as vendors of WYSIWYG editors? We end up with a markup language that's difficult to author and prone to the same misuse as previous versions of HTML.

Background

Much of the HTML that we use today was simply created by browser vendors to support their own invented elements. If these elements became popular, W3C incorporated them into subsequent HTML specifications. This process is repeating itself today as browser vendors are again the only ones determining the future direction of HTML, leaving authoring tool vendors out of the conversation.

When less is more

HTML 4 has too many elements. Each element, or in some cases the attribute of an element, requires a button or a list box on a WYSIWYG editor toolbar. The screen shot below shows an overcrowded authoring toolbar that does not even include all of the features of HTML 4.

Screen shot of a WYSIWYG editor with a toolbar that contains large number of buttons and controls.

Now, with HTML5 we have additional new elements that do the same thing as the <div> element, such as <section>, <nav>, <article>, <aside>, <header> and <footer>. They too will probably each require their own button on the toolbar of WYSIWYG editors. But how many more buttons can a toolbar sustain before it becomes ridiculous?

Sometimes it means this, and sometimes it means that... and only under certain conditions

WYSIWYG editors (in fact all GUI applications) need simple, invariable rules. Unfortunately, HTML5 is full of rules with exceptions, or rules too complex for authoring tools to implement. Take the <time> element as an example. The <time> element has 3 different meanings depending on how it is used.

First, if it is used without the pubdate attribute, it provides a machine-readable date. For example:

<time datetime="2009-11-16">November 16, 2009</time>

Second, if used with the pubdate attribute that is not inside an <article> element, it indicates the publication date of the entire document. For example:

<body>
...
<time datetime="2009-11-16" pubdate>November 16, 2009</time>
...
</body>

Third, if used with the pubdate attribute that is inside an <article> element, it indicates the publication date only of the article. For example:

<article>
...
<time datetime="2009-11-16" pubdate>November 16, 2009</time>
...
</article>

As a result, a WYSIWYG editor must somehow create a single user-friendly interface that makes the user understand the 3 possible usages of the <time> element. And if that is not enough, there are more rules for the <time> element that push the limits of user-interface design further.

For example, the pubdate attribute is always optional. The datetime attribute is sometimes optional and at other times it is required. The datetime attribute is required when the pubdate attribute is used and when the element does not contain a string in the valid date time format. For example:

<time datetime="2009-11-16" pubdate>Monday</time>

But the datetime attribute is optional when the <time> element does contain a valid date time format. For example:

<time>2009-11-16</time>
<time pubdate>2009-11-16</time>

The <time> element can also be empty. For example:

<time datetime="2009-11-16"></time>
<time datetime="2009-11-16" pubdate></time>

A further rule states that no more than one <time> element can be permitted directly within an <article> element, or no more than one <time> element outside the <article> element. It is unclear how WYSIWYG editors are supposed to allow users to use copy and paste without breaking this rule.

Solutions in search of problems

HTML 4 has a satisfactory way of dealing with alternate text for images. Images are used for either decoration or as content. The alt attribute is required. If the alt attribute is empty, the image is used for decoration. If the alt attribute is non-empty, it contains alternate text for the image. So a WYSIWYG editor can build an interface to ask the user if the image is decorative or not and can then, depending on the user's selection, make the alternate text field required or can disable it as shown in the screen shots below.

Screen shot of a WYSIWYG editor's Image properties dialog box with the control labeled 'Decorative image' set to No. The 'Alternate text' field is enabled and required.

Screen shot of a WYSIWYG editor's Image properties dialog box with the control labeled 'Decorative image' set to Yes. The 'Alternate text' field is blank and disabled.

But HTML5 makes the alt attribute optional, and the absence of the alt attribute means that the content author does not know what alternate text should be entered, if any. This leads inevitably to the assumption by users that alternate text is not important.

So how are WYSIWYG editors supposed to create a user-friendly interface that conveys the 3 possible states of alternate text for an image? Below is a screen mock-up that comes to mind:

A screen mock-up of a WYSIWYG editor's image properties dialog box with the control labeled 'Image type' set to: Don't know or don't care. The Alternate text field is disabled and the Description field is enabled.

But even an interface such as the one above is not that simple as it looks to implement, because HTML5 makes the alt attribute optional only if one of the following conditions are met:

if the title attribute has content
if the <img> element is inside a <figure> element that contains a non-empty <dt> element
if the <img> element is part of the only paragraph directly in its section, and is the only <img> element without an alt attribute in its section, and its section has an associated heading.

Going from bad to worse

Headings in HTML5 go from bad to worse. Headings are supposed to help readers navigate through long documents, to skip directly to sections of interest, and to break up long stretches of text. The mechanism for creating headings in HTML (<h1> to <h6>) has always been bad and practically no one is using headings correctly in HTML. Because headings are stand-alone elements, WYSIWYG editors cannot enforce their proper use and as a result content authors often use headings incorrectly as a way to format text or as a way to emphasize text so it jumps off the page.

Alas, HTML5 offers no solution. Indeed, the use of headings in HTML5 is so convoluted that after reading the spec several times and scouring third-party articles on the topic, I am not able to summarize the correct use of headings as per the HTML5 spec.

I did notice that there is a new heading element called <hgroup>, which must contain two or more <h1> to <h6> elements. I can only guess that this element is used to group two or more headings together, and then to hide one of these headings from the document outline. So you would use one heading element to create a kind of sub-heading and then use another element to hide the sub-heading. But why would you do that? Also, as a lead developer for a WYSIWYG editor, I cannot even imagine a user-friendly interface that we could build in order to let content authors apply the <hgroup> element as intended.

So how would a WYSIWYG editor vendor want to see headings implemented? Since headings don't make sense on their own, they should be part of a <section> element to form a compound construct, similar to <table>, <ol>, <ul> and <dl>. For example:

<section role="article">
<heading>...</heading>
<content>...</content>
</section>

A WYSIWYG editor could implement this feature with just a single toolbar button as shown in a screen mock-up below.

A screen mock-up of a WYSIWYG editor displaying two boxes. One box contains the words Heading and the other box contains the words Content.

And sections could be nested like this:

<section role="article">
<heading>...</heading>
<content>
<section>
<heading>...</heading>
<content>...</content>
</section>
<section>
<heading>...</heading>
<content>...</content>
</section>
</content>
</section>

WYSIWYG editors can make authoring the above markup idiot proof, whereas HTML5 headings are next to impossible to author correctly.

Don't blame the WYSIWYG vendors

Building good authoring tools starts with a good markup language. Unfortunately, HTML5 makes building WYSIWYG editors with user-friendly interfaces that comply with the rules of the language, impractical or next to impossible. It does not have to be so. To the Web browser vendors designing HTML5 I say let's work together to improve the Web.

Public comments

1. Posted by Gary Miller
on Monday 2009-11-16 at 12:17:51 PST

Hi Vlad,

Good article! I haven't even tried to get my head around HTML 5 yet...

Errr...did you ever stop to think that maybe, just maybe, HTML 5 was specifically designed to make us all go back to hand-coding? ;)

Gary Miller via AccessifyForum

2. Posted by Philip Jägenstedt
on Tuesday 2009-11-17 at 03:00:45 PST

Yes, let's work together. I'm sure Hixie will stumble on to this eventually, but it would also be nice if you joined the WHATWG and/or W3C HTMLWG to give more feedback of this type. I just recently sent feedback on some <time> issues, so now would be a good time to have a look at your issues to see if some kind of redesign of some parts is in order (the @pubdate construct is quite new). About your sectioning example, if you just replace <heading> with <h1> and drop <content> (everything not the heading is the content, right?) it should be fine, per my understanding of HTML5 anyway. Ask http://validator.nu/ to be sure.

3. Posted by Dave Smith
on Tuesday 2009-11-17 at 03:06:27 PST

Hi Vlad

Slightly aside from your point:
"HTML 4 has a satisfactory way of dealing with alternate text for images", true but I wish that it had never been limited as a singleton element (whether that was a browser or spec thing). As a normal element, alternate text or markup could be put inside. As a singleton it would be decorative by default.

all the best
Dave

4. Posted by David Smith
on Tuesday 2009-11-17 at 03:08:30 PST

It's for exactly this reason that you need to leave writing markup to professionals! It's complicated.

WYSIWYG editors allow any old sap to try and create markup and this is very dangerous. Why not just give up and force people to learn code? ;)

5. Posted by kl
on Tuesday 2009-11-17 at 03:22:32 PST

UI design is hard, let's go shopping!

Seriously, nobody tells you to build UI around HTML tags. Build UI around functionality and use tags to implement it. If your editor isn't managing pubdates, don't bother with time element. Instead of dozen buttons, add outline view or build it automatically from old-style headers.

6. Posted by DMC
on Tuesday 2009-11-17 at 03:33:13 PST

I have to agree with Gary and David here.
So WYSIWYG editor vendors haven't been involved in the development of html5.
Good.

WYSIWYG editors are for amateurs, and the day we allow amateurs into the conversation, is the day I leave this industry.

I don't allow WYSIWYG editors in my studio, and I wouldn't employ someone who can't hand code. Simple as that.

7. Posted by Robert Foxx
on Tuesday 2009-11-17 at 03:35:05 PST

Oh yeah, I'm *sure* the folks at Adobe are absolutely loathing the opportunity to release and sell another incremental version of Dreamweaver, full of all the old bloat, but with half-assed HTML5 support shoehorned into it as a must-have feature.

8. Posted by Konrad
on Tuesday 2009-11-17 at 04:19:28 PST

“But how many more buttons can a toolbar sustain before it becomes ridiculous?“

The toolbar in your screenshot is way beyond the point of ridiculous. That, by the way, is not at all related to the number of tags in HTML – rather, it’s due to the idiotic aspiration of the designer to create a 1:1 mapping between tags and buttons. A UI hell.

„WYSIWYG editors (in fact all GUI applications) need simple, invariable rules.“

That is a logical fallacy. GUI applications need to supply the user with exactly the set of functions they want, accessible in the simplest possible manner. First of all, no WYSIWYG editor needs to implement the whole of HTML5. Secondly, the status quo is not one you can build on: WYSIWYG editors (not only for HTML!) are crap as it is. Blaming a new technology for making it worse is like claiming that new deck chair cushions didn’t prevent the ship from sinking.

Was the impact on WYSIWYG editors considered in the design of HTML5? Probably not. Now, ask yourself why this might be the case. After all, impact on both browsers and users has been considered *extensively*. Might it not be that WYSIWYG editors simply appeared irrelevant?

If you want to change this, by all means – go ahead. But complaining now isn’t the right way, and your last section is back to front; it should read: Don’t blame the HTML5 designers. They did an excellent job at considering possible impacts of their design. In this vein, your complaint comes a little *late*.

9. Posted by kl
on Tuesday 2009-11-17 at 04:29:55 PST

Actually WYSIWYG editors have been taken into account when HTML5 was designed. They are specifically mentioned in several places. However HTML 5 folks hoped UI designers will be a bit more abitious with the UI rather than keep blindly copying failed Word UI that has since been scrapped.

10. Posted by AlastairC
on Tuesday 2009-11-17 at 04:47:34 PST

I thought WYSIWYG editors were involved at some stage, which is why the font tag was (almost?) retained?

Thanks for writing this, I've been frustrated by browser based editors for many years (http://alastairc.ac/category/wysiwyg-editors/), I need to go through it in more detail now.

In the meantime, there maybe assumptions in usage that mean many of the new elements don't affect an editor in standard use. For example, why implement a header element when the editor is only used to edit within an article?
I generally have to strip things out of a standard editor, they have too much for a site that uses CSS properly.

If an editor had a drop-down for block elements, a drop down for dynamically adding pre-defined classes, and button for inline elements, I would be very happy! (Bonus points for robust template insertion.)

Having said that, you have a good point about the section / headings aspect.

Could you take an approach a bit more like the WYSIWYM editor, showing the containing blocks?

11. Posted by Grumpy Smurf
on Tuesday 2009-11-17 at 05:18:26 PST

@Alastair : Do you mean something like www.wymeditor.org ?

WYSIWYG editors doesn't have to provide a full HTML5 support, because people who will use them to write (or worse : developper who will make their clients "able" to rewrite) entire web page are just mad !

If you think about real world use case, you'll see that there's no need for a time-tag support, nor heading/content.

Less is more ? That's right.
So just concentrates your work on providing a solid implementation of usefull features that produce W3C-valid HTML code. That's all we need.

12. Posted by Jay Gilmore
on Tuesday 2009-11-17 at 06:30:45 PST

WYSIWYG and RTE editors should be implemented to aid users in editing individual documents or parts of documents.

By your example, you would have the editor of a blog create the post title, date and other meta within the RTE but in actual fact all of these in a CMS or Blogging app should be handled by a variety of custom input fields and the output be handled by the templating system markup.

Done right RTEs like TinyMCE, CK, FCK and the like should be used only for a limited number of actions on text and images such as adding emphasis or weight to a selection or sub headings within a document. Document descriptors like date and main title should be fields only. Removing access to things like color, font and size is necessary as they should all be handled by css. You can add custom classes to most RTEs that allow users to apply specific class rules to selections that are within the scope of the document.

It takes a lot more planning and more design to streamline the document editing for the content types and limiting user markup but blaming the RTE for the fact that you handed the end user a box of tools and expect the tool box to control the way the user employs them is the wrong way around.

That said, RTEs need significant improvement and honestly some views on a website are just not going to be feasibly edited by anyone but an HTML editor.

13. Posted by Lars Gunther
on Tuesday 2009-11-17 at 10:29:40 PST

If an author wants to use HTML5 elements, he or she must learn when they are APPROPRIATE to use. Markup should be SEMANTIC. We need What You Mean Is What You Get (WYMISYG) rather than WYSIWYG.

If you've already learned the semantics of the elements, why not also learn the name and code by hand?

People that simply contribute content never need to mess with article, section, nav, time, canvas, etc. They need a SMALL and SENSIBLE subset of all elements, that hook into site styles. E.g. setting font-family in an editor usually mean style attributes inline. We have a problem already there!

For more complex data structures, like tables, guides are probably the best solution.

And yes, how would one use a WYSIWYG editor to develop for all form factors? Inline CSS is not exactly something that mixes well with @media rules....

14. Posted by Serge Bédard
on Tuesday 2009-11-17 at 11:39:26 PST

Response to David Smith

> It's for exactly this reason that you need to leave writing markup to
> professionals! It's complicated.

> WYSIWYG editors allow any old sap to try and create markup and this is very
> dangerous. Why not just give up and force people to learn code? ;)

David, you obviously never work in a content management system infrastructure dealing with 1000 of content providers.

This is why WYSIWYG exist.

15. Posted by Vlad Alexander
on Tuesday 2009-11-17 at 13:35:25 PST

Philip Jägenstedt wrote: "it would also be nice if you joined the WHATWG and/or W3C HTMLWG to give more feedback of this type"

Others have suggested this as well. In short, the markup issues I have raised in this article are symptoms of the problem. The real problem is that the stakeholders in the future of Web technology are not working collaboratively together. This problem cannot be addressed via the WHATWG/W3C issue tracking system.

Philip Jägenstedt wrote: "About your sectioning example, if you just replace <heading> with <h1> and drop <content> ... it should be fine, per my understanding of HTML5"

Yes, but how do you enforce this in a WYSIWYG environment? How do you prevent the following from being written by non-technical authors using a WYSIWYG editor when the spec actually permits it:

<section>
<p>text text text</p>
<h1>text text text</h1>
</section>

If you made section and heading into a compound structure like <table> or <dl> or <ol>, then WYSIWYG editors can enforce the correct use of headings.

Dave Smith wrote: "I wish that it [alt text for images] had never been limited as a singleton element."

Me too!

Konrad wrote: "Might it not be that WYSIWYG editors simply appeared irrelevant?"

Konrad, I don't have the numbers to back this up, but I would guess that the majority of new content added to the Web today is authored using WYSIWYG editors. Also, please see the comment by Serge Bédard.

AlastairC wrote: "thought WYSIWYG editors were involved at some stage"

WYSIWYG editor vendors have never had any influence over the spec or more importantly over the design principles.

Jay Gilmore wrote: "Done right RTEs like TinyMCE, CK, FCK and the like should be used only for a limited number of actions"

I am all for that. But if HTML permits more actions, there will be vendors who will pimp more features irrespective of the consequences. Maybe future Web technology should have a separate layout and content languages?

16. Posted by chaals
on Tuesday 2009-11-17 at 17:31:40 PST

Vlad, thanks for a thought-provoking and clear article.

A decade ago I went to work for W3C on providing guidance to authoring tool producers (where WYSIWYG editors are one of the clearly important target audiences) on how to make content that would be accessible (and make sure that their products were themselves accessible) to people with disabilities. The result, http://www.w3.org/TR/ATAG10 was far from perfect, but the process of developing it showed that the underlying issues you raise are indeed incredibly important, not just for people with disabilities but for how we build the web in general. (On the other hand, it was not entirely terrible. And authoring tools are a lot better, on average, than they were a decade or so ago when we began).

Now I work at Opera (like Philip), representing first and foremost a browser vendor. But we still want the web to work properly, and if WYSIWYG editors can't produce HTML 5 then we haven't got it right.

First, the nit-picking. My response to your reply to Philip is that nothing requires the WYSIWYG editors to merely follow the spec as the one and only source of truth. Editing tools guide authors in all sorts of ways, and there is no inherent reason a tool cannot go beyond the strict rules and provide warnings for what is not really clever. At the same time, I recognise that authoring tools are already dealing with a huge amount of complexity, and only the best will figure out how to simplify what matters when, and present that clearly to an author.

Second, the challenge. I too struggle to keep up with the flow of information in the Working Group (and consider that, for many reasons, more important than the effort in the WHAT-WG, although the WHAT-WG was a necessary step to getting the Working Group). Nonetheless, for something as important as HTML I think that the overall process at W3C does enable important concerns to be raised and force them to be addressed. So I would ask you to spend the amount of time it took to make this article in raising specific issues against the HTML5 spec, and finding champions (you need not champion them all personally- if they are real issues, there will be others who have noticed and can take some of the workload).

Third, and finally (because three is a agic number, and while 9 is more magic I don't have enough time to write that much and don't want to demand that much time for people to read it), the question. What would it take to ensure that WYSIWYG tool developers do have significant input to the development of HTML 5? In other words, if I *as an all-powerful representative of a *Browser Vendor* give you my magic wand, and you believe for a minute that it really works and isn't just a stick I found a few minutes ago, what would you do?

(For those who think that publishing on the web should be restricted to professional experts, I respectfully suggest that its succes is in large part based on the fact that it never has been, but instead has allowed freedom of expression, and that one of the major philosophical underpinnings of HTML 5 is that trying to restrict this freedom would be more futile than trying to turn back the tides - something king Knut used as an example to enlighten the foolish people who tried to tell him that everything was possible for him).

cheers

Chaals

17. Posted by Vlad Alexander
on Tuesday 2009-11-17 at 19:49:03 PST

Chaals wrote: "What would it take to ensure that WYSIWYG tool developers do have significant input to the development of HTML 5?"

I would use the magic wand to give all stakeholders in the future of Web technology a seat at the table, each with significant decision making power and influence over the future direction of Web technology.

Before I get into the details, let me describe how I, and many others, perceive the current process of developing HTML5 works. I am going to oversimplify for brevity and effect. You have a bunch of young men with no real world experience designing features that their employers are missing from their Web based apps. Occasionally you get "wouldn't it be cool" requests from the general public and these features are tossed into the kitchen sink that is HTML. The whole process is run by a benevolent dictator whose only interest is in serving the wants of the 5 browser vendors. The HTML5 group suffers from "not invented here" syndrome. The process of accepting feedback from the general public is chaotic with a free-for-all mailing list that has in the past been overwhelmed by the volume of emails. Features are added to the spec based on the likelihood of browser vendors implementing them in the short term. Browser vendors are shipping HTML5 features in release builds while these features are still up for discussion in the spec which actually cuts off any further debate on these features.

This is how I would change things:

W3C would appoint a person or two to represent the interests of each stakeholder group in the future of Web technology. The stakeholders include browser vendors, authoring tool vendors, screen reader vendors, application developers, search engine developers, Web page builders/content authors, users with special needs, general users of the Web, etc. The role of these people would be to champion the needs of their constituents, write the specification, and vote on which features are in or out of the spec.
No more ad hoc "wouldn't it be cool" feature requests. Features should be added to the spec only if they are necessary to solve a problem that is part of a use-case. A set of use-cases is developed to identify features the future Web must have and development of any spec is guided by the technology necessary to satisfy these use-cases. For example, a use-case can be as follows. A person while driving in a car verbally asks the car's computer to find him a reasonably priced restaurant that offers vegetarian black bean soup. The car's computer searches online and verbally responds back with the single recommendation along with the price and driving directions. The use-case would identify Web technology related features (i.e. semantic markup, embedding data into Web pages, changes to HTTP, etc.) that would need to be built in order for the use-case to be fulfilled.
Web technology would be developed with a long-term view in mind. Everything is on the table and up for discussion as long as it will help reach the goal of building the technology that satisfies the use-cases.

Chaals, as you know, as part of my job I have interacted with the dev/testing team at Opera. I think the world of them. And I have had similar contacts and have similar opinions of the other browser vendors. So I do think very highly of the engineers that work for the browser vendors. But it is an incontestable fact that the browser vendors have absolute power over the future of Web technology and you know the old adage about absolute power.

18. Posted by Joe
on Wednesday 2009-11-18 at 01:18:13 PST

@DMC

I do hope you're joking: "WYSIWYG editors are for amateurs, and the day we allow amateurs into the conversation, is the day I leave this industry."

Like it or not, people who cannot hand code are going to create web content, and making it possible for them to do so in as usable and accessible a way as possible is a noble goal.

Some wysiwyg are for amateurs, sure. These editors will have no understanding of the way correctly formatted HTML should be published, and will end up creating pages that fail miserably at conforming to standards. Dreamweaver, to name one, has decent HTML output however, and allows for rapid prototyping of web pages. Used with sufficient guidance it produces code that is fine for production use.

I would rather that amateurs were involved in this industry than developers who try and stifle progress by restricting web design to notepad coding purists only.

Interstingly, I note that your own page violates one of the basic tenets of accessible web design, that is conforming to the very standards set out by the World Wide Web Consortium (See W3C-WAI, WCAG2 for more info). By identifying your body links only using colour, you are potentially excluding colour blind users. I would pla

19. Posted by chaals
on Wednesday 2009-11-18 at 09:05:45 PST

Vlad,

I think a lot of people share your perception of the HTML process, and in particular as it was in the WHAT-WG. I think it is valuable to look at the current process at W3C, which I think offers something more.

There are three chairs, and two of them qualify as greybeards (I have never seen Maciej with a beard, although I doubt it would come out with any grey...) from large companies (IBM and Microsoft) whose record in the group and outside suggests they are extremely interested in the bigger picture.

To treat your three points in turn...

1. W3C process generally allows all members to be represented. There are W3C members whose primary interest is accessibility, as well as individuals within large companies in the same situation, as well as members whose major interest is authoring tools as well as members who have large authoring activities, and so on. Under the process it is not possible to appoint representatives of different stakeholders - in part because the work is done on a voluntary basis (in the sense that W3C cannot compel anyone to do the work). But it is trivially easy for any member to join any group representing an interest they think is not being well served.

The W3C process for HTML is somewhat unusual, which is caused in part by the editor demanding an extremely unusual degree of freedom of action, in part by the group allowing more or less anyone in the world to join, whether they are a W3C member or not.

The problem in part is that there is real work required, and that takes real time, which is not always readily available. There is no barrier I can see to people participating and following points which are important to them (as I do for a few accessibility things, but not much more).

2. In an open group it is pretty much impossible to tell people what they cannot say. However, the editor has always insisted on there being clear use cases for features (although people have argued that his application of this test has been somewhat uneven) - including retaining some existing features of HTML 4.

I believe that the current chairs have a reasonably effective process for not going overboard with feature requests. The change request process seems to be reasonable, both in ensuring that there is some sensible requirement before changes are considered, and that the editor is in fact bound by the Group rather than the other way around.

Note that W3C works on a range of technology, and many parts of it have nothing to do with HTML, or are developed in other working groups. Your use cases could be taken today from the Geolocation, Voice, and Multimodal working groups.

3. I think this is already the case. However, the devil is of course in the detail, an following the detail is a lot of extremely hard work. Really, a huge amount.

One of the reasons Hixie has such power is because he has been the only person who has demonstrated the ability and desire to be the editor - with all due respect, as far as I can tell he is effectively sole editor despite what the official story says. Likewise, browsers do indeed have power, but that comes in part from putting a large amount of effort into the development.

I would very much welcome more direct and active participation from Authoring Tool vendors, because I believe they are a critical part of the infrastructure. If you want to take the discussion offline I will happily spend a bit of time exploring practical ways to move forward on getting some more active scrutiny and clear feedback that gets acted on in the Working Group.

I don't promise to agree with you, but I do want to ensure that your points are clearly made and heard. It is important to me that HTML5 works for the Web as a whole, not just a handful of vendors. In part because I don't think it helps us as vendors to get it wrong...

Comments are closed for this article.

Rebuilding The Web