Surfin' Safari

HTML Standards Process Returning from the Grave

Posted by Maciej Stachowiak on Wednesday, January 17th, 2007 at 9:57 pm

For a long time, the HTML standards process has been moribund; the W3C‘s HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice. The people working on the major browsers have largely abandoned the HTML Working Group. And competing efforts like WHATWG stepped in to fill the void of advancing HTML.

But now the W3C is proposing new charters for a new set of working groups that may allow useful HTML work to happen inside the W3C., and is actively trying to engage browser vendors. You may have seen some comments on this from Tim Berners-Lee, Director of the W3C. There have also been posts on the topic from Chris Wilson, the IE Platform Architect and Daniel Glazman (and some further comments from Daniel).

Here are the new charters themselves:

Our Response

Those of us on the Safari team have asked Apple’s AC Representative to submit feedback on these proposed charters. (The AC is the W3C’s Advisory Committee, the forum where member organizations vote on decisions of this sort). We believe the general direction of the HTML Working Group is good, but we also think that the charter as it stands has some problems that need to be resolved. Although such feedback is normally private, we have decided to post it publicly here.

On the new HTML Working Group Chart, we have voted to support it with minor changes, and plan to participate. Here are our proposed changes:

  • We request that instead of weekly teleconferences, the charter call for teleconferences as needed and requested, with normal operation to be done via the mailing list. This is to avoid leaving non-Member contributors out of the conversation.
  • We request that instead of 4 face-to-face meetings per year, the charter call for one face-to-face meeting per year, which is open not only to Working Group members but to all who are willing and able to attend. This is to avoid leaving non-Member contributors out of the conversation, and to avoid an unreasonable meeting load on the working engineers who will hopefully comprise much of the group membership.
  • We strongly object to the 10% market share threshold in the Success Criteria. Effectively, this gives Mozilla Firefox and Microsoft Internet Explorer veto power over the spec. In general historically there have only been two browsers at a time that have been above this market share threshold. Furthermore, we believe that even if all browsers besides IE conformed to the spec, it would still be a huge success and a huge benefit to web compatibility.
  • We would like the charter to clarify that new features such as editing support will be specified in a platform-neutral and device-independent way.
  • We believe the schedule milestones are completely unrealistic. Given that the charter is still under review in January 2007, it is unreasonable to expect a first working draft in February 2007. Given the scope of work to be done, it is unreasonable to expect Candidate Recommendation in less than a year. And finally, it is completely implausible to expect a thorough test suite, let alone two interoperable implementations, by December 2008. We request that the milestones be omitted entirely or set much further in the future.
  • We request that the charter call for a formal relationship with Web Hypertext Application Technology Working Group (WHATWG), even though the group itself is informal.
  • We request that the “Good Standing” requirements be waived for this working group, since much work will be done by email, and since no minimum time commitment is expected of members.
  • We request that there be no Member-only mailing list; such lists risk being abused for non-public decision making for what should be a public group.
  • We request that rather than the standard W3C WG decision process, the relevant spec editor or editors should be allowed to make initial decisions about the spec using their own best judgment, with any working group member allowed to appeal decisions to the full working group. In such cases, the vote should be taken by email to allow due consideration and participation by all.

On the XHTML2, Forms, and Hypertext Coordination Group charters, we abstained from commenting and do not plan to participate at this time.

UPDATE: Dan Connolly of the W3C posted a response to some of our charter feedback, and I posted a futher reply.

UPDATE #2: More from Chris Wilson on the controversy over him as initial chair of the group.

43 Responses to “HTML Standards Process Returning from the Grave”

  1. Nicholas Shanks Says:

    As TimBL states in his blog posing on this matter, the more people who can contribute, the slower things go.
    I believe it would be better to have a faster, more thorough proposal created by fewer people, which is then opened up for discussion, than to have everyone jumping in and making requests right at the start.

  2. squareman Says:

    Nicholas, I think the last bullet in the requests addresses your concern (at least partially).

  3. Dan Connolly Says:

    Thanks for your careful review of the charters, and for sharing your thoughts.

    The market share threshold is intended to address the risk of getting “highly incompatible with existing practice”. Do you have any suggestion to replace the 10% number?

    About milestones: I would think companies would want some estimate of how long they should expect their engineers to participate before the work is done. Is it that you have no use for such estimates? Or that you have no confidence in any estimates at this time? Schedules are not easy to maintain; if people don’t get value from them, clearly we shouldn’t bother. I usually find them worthwhile, but perhaps HTML is a special case.

    What you say about telcons and face to face meetings is pretty reasonable (and it has a natural consequence of making “good standing” mostly irrelevant). And about editors making initial decisions, that’s perfectly normal and doesn’t conflict with any “standard W3C WG decision process”. The W3C decision process is all about appeals: how to prevent them most of the time, and what happens when push comes to shove.

  4. maciej Says:

    @Dan Connolly

    “The market share threshold is intended to address the risk of getting “highly incompatible with existing practice”. Do you have any suggestion to replace the 10% number?”

    Some kind of threshold makes sense to avoid claiming success based on implementations that are not relevant in practice. But this must be balanced against the risk of giving individual vendors veto power. Two possibilities are to either set the threshold significantly lower, so that at least the four browsers usually considered to be the “major” ones can meet it, or to make it a collective threshold, “2 or more interoperable implementations with a total market share of over N%”.

    “About milestones: I would think companies would want some estimate of how long they should expect their engineers to participate before the work is done. Is it that you have no use for such estimates? Or that you have no confidence in any estimates at this time?”

    December, 2008 for REC seems wildly implausible, and it’s better to have no milestone than a clearly wrong one. But possibly more realistic would be 2-3 years for the bulk of writing the spec and responding to comments (start of process to CR) and then another 2-3 years for test suite writing and implementation (CR to REC).

    “And about editors making initial decisions, that’s perfectly normal and doesn’t conflict with any ‘standard W3C WG decision process’.”

    The decision process I have often seen in working groups is that public comments result in an issue tracker item which is voted on by the group as a whole. The “vote” is done over a telecon and usually amounts to uninformed but passionate discussion, followed by the chair declaring a resolution and giving people about 15 seconds to object before it is recorded. So it’s probably worth stating explicitly that this is not the plan.

  5. Michael(tm)Smith Says:

    Given that the browser core/engine (not the browser UI) is the part of the implementation that has relevance to the HTML WG’s work, perhaps Success Criteria evaluation of how “widely used” a particular implementation is should based on browser engines, not on browsers. And should not be evaluated based just on how widely use a particular engine is in desktop browsers.

  6. Nicholas Shanks Says:

    @Michael: We can call it The ‘iPhone’ Clause. :-)

  7. Brady J. Frey Says:

    Chris Wilson of the IE team? The W3 has not lost sight that we’re talking about standards discussion in one breath and IE in another:
    http://validator.w3.org/check?uri=http%3A%2F%2Fblogs.msdn.com%2Fcwilso%2Farchive%2F2007%2F01%2F11%2Fsigh.aspx

    So the chair mis-formed his own frameset driven site… and I did say frameset, and it is 2007. IE7 – the same browser that just caught up with the majority of it’s own bugs in 2007 and is still years behind Gecko and Safari. He can argue the logistics of managing an issue don’t require being a developer, but most of us understand how it is to work in a scenario where the lead doesn’t understand the knowledgeable worker; it misaligns priorities and drains focus. I’m not saying understanding the code has to be the lead focus, but it should be a priority or what was this meeting about again?

    If we’re arguing that his management prowess is based on the strength and validity of IE’s market share, that has little to do with the team skillset – I imagine he is an accomplished manager and they are an accomplished team, but IE gains dominance through other means.

    PR and Marketing alone: Microsoft, IE, or their employees regardless of experience, does not sit will as the poster child for the future of standards and the internet. We’re talking about .NET and years of missed promises from CSS to the Object tag – and the internet is a volume that doesn’t forget this history.

    I know you’ve covered much more important issues above, all of which I hold agreement in, but I can’t help but chuckle on the idea that the company considered enemy number 1 for web designers the world over (the good ones, and that holds true, not worth debate) now chairs the future of the web.

  8. glazou Says:

    Hello Maciej. I read your article with great interest for two reasons : first making those comments public was an excellent idea ; second, of course, because your comments are quite in line with the ones I made myself on the Charter.

    The weblog-to-weblog “discussion” I recently had with Chris Wilson focused too much on its chairmanship. But my concerns about the Charter itself still stand and I think none of the replies I got, from Chris or from others, are able to make me change my opinion. I still think the Charter as it is proposed for the vote is not enough to start safely that new HTML WG, and that we should have another round of DISCUSSIONS about it and another vote.

    About Microsoft having the chairmanship, and despite of all Chris Wilson’s good will, I still have the same opinion. I am a too old monkey in this Web Standards’ world, I know exactly how it goes, how the technical choices are influenced by the battle of wills. Each individual in a WG is at some point balanced between what he/she thinks is the best and the competitive advantage of his/her employer (unless of course the company just does not care about the work he/she does, and that happens from time to time…).

    Just a side note, I am delighted to see you mentioned “editing support” in your comments. Apple just became the very first big company thinking about the editing side BEFORE starting the standardization work. Thanks for that.

    I know the comments above are only the voting suggestions you made to your AC-Rep. I sincerely hope your AC-Rep is going to follow your advise here.

    Say hi to hyatt from me pls.

  9. maciej Says:

    @glazou

    I agree that it’s worth having another round of discussions and a fresh draft of the charter with a new vote. I hope this happens. Also, for the record, these are the exact comments Apple’s AC Rep submitted, not just a suggestion. We hope other W3C members will follow suit and be willing to post their comments publicly.

  10. asbjornu Says:

    I love this new “opennes” of the future HTML WG! I really hope the charter will incorporate all of your comments. About Chris Wilson being a chair; I find it more troublesome that he might not have the necessary technical knowledge than the fact that he’s a Microsoft employee. That he works in Microsoft is only a plus, in my humble opinion, since that may lead to faster adoption of the standard in IE than if Microsoft had been less involved and represented in the WG. At least, that’s what I’m hoping for.

  11. JKT Says:

    “We strongly object to the 10% market share threshold in the Success Criteria.”

    Wouldn’t a far better option for a threshold for Success Criteria be to set is as e.g. the rendering engines that implement correct display of, say, 95% of the current standards rather than some arbritary market share value? This would reward those browser developers who actually can be bothered to implement the standards at the expense of laggards like Microsoft who didn’t give a monkey’s for far, far too long.

  12. DNR Says:

    @JKT

    I think that’s an excellent idea. Not only does that encourage and reward the adoption of the standards, it also gives a voice to those who have the most success in actually implementing the standard.

  13. Pingback from Domain Name Diary » Blog Archive » News Wire: The Secret Origin of Ajax:

    [...] struggling to meet accessibility standards in real-world projects. (tags: accessibility) HTML Standards Process Returning from the Grave The Safari development team chimes in with detailed feedback on the [...]

  14. Pingback from SitePoint Blogs » News Wire: The Secret Origin of Ajax:

    [...] ggling to meet accessibility standards in real-world projects. (tags: accessibility) HTML Standards Process Returning from the Grave The Safari development team chimes in with detailed feedback on the [...]

  15. Pingback from Blog Posible » Blog Archive » Lo que está pasando con la futura versión de HTML:

    [...] titulado… (música tétrica de mucho miedo y apocalíptica): HTML Standards Process Returning from the Grave. Donde denuncia que en la práctica, sólo valen las decisiones de l [...]

  16. ianji Says:

    Why the decision not to participate in the XHTML2 Working Group?

    And while I am on the subject of XHTML, there has been a longstanding problem with Safari’s XHTML rendering engine whereby clicking on href URLs that contain an ampersand separator does not take you to the correct page, whereas the same href on an HTML page works fine. Here is my test page which illustrates the problem:

    http://www.zenatode.org.uk/test/amptest.html

  17. maciej Says:

    @inaji

    We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web. There is no need to break compatibility with HTML4.x/XHTML1.x, and the compatibility-breaking changes are not necessarily good ones from the point of view of semantics or authorability. Also, it moves HTML in a direction that is suitable for documents but not as much for applications. However, we abstained from voting instead of voting no because we don’t think they should be stopped from doing this work if they feel it isvaluable.

    As for your test, how does it compare to other browsers? How does it compare to what the spec says you should do? If it is wrong per spec, please file a bug report citing the relevant part of the spec. Just being different from HTML is not necessarily evidence, since the parsing rules are different.

  18. ianji Says:

    @maciej

    Thanks for response re XHTML2

    Regarding my test. I am not familiar enough with the spec to say with certainty whether Safari is following it, which is why I haven’t filed a bug report yet. Certainly it doesn’t do what I expect, whereas Firefox does. My test pages are valid according to W3C and I am at a loss as to how I might change the code to get the desired behaviour in the XHTML case. I was hoping someone more knowlegable than me might have a look at it. I don’t want to waste time by filing a bug which turns out not to be a bug, so a second opinion would be much appreciated. Can anyone help me, or does anyone know anyone who might?

  19. alexander Says:

    >There is no need to break compatibility with HTML4.x/XHTML1.x

    HTML4.x/XHTML1.x have a lot of faults. If a new spec is backwards compatible, the new spec perpetuates these faults into the future. I would argue that specs don’t need to be backwards compatible. Instead, the better solution would be that user-agents need to be backwards compatible by supporting multiple specs.

  20. David Smith Says:

    >Instead, the better solution would be that user-agents need to be backwards compatible by supporting multiple specs.

    Given the difficulty in getting even the current specs reliably implemented, adding radically new ones on top of the existing ones does not seem like a practical path, however nice it may be in theory. It’s also the case that all programs and all specifications have flaws; throwing out known issues for unknown ones only makes sense to my mind if the known issues are unfixable and cripplingly bad.

  21. alexander Says:

    > throwing out known issues for unknown ones only makes sense to my mind if the known issues are unfixable and cripplingly bad.

    Let me provide some examples where HTML 4.x constructs are unfixable, not beneficial and should not be perpetuated into future specs.

    1. Content headings are the most important constructs for making Web pages accessible. Yet virtually noone uses heading correctly because the h1 to h6 constructs are very difficult to visualize for most people and almost impossible to author *correctly* in WYSIWYG editors. h1 to h6 are linear constructs (sibling elements) that are used to organize data into a nested construct (child content). Both X/HTML 5 and XHTML 2 will continue to support h1 to h6 for backwards-compatibility. The h element in XHTML 2 is a much better replacement for numbered headings.

    2. I think everyone will agree that the font element is an unfixable construct. (X)HTML 5 will continue to support the font element if content is authored by a WYSIWYG editor. Incidentally, why would WYSIWYG editors get an exemption here?

    3. Just like the font element, small, b and i elements encourage authors to use markup incorrectly. (X)HTML 5 says that these elements are now semantic, which in my opinion actually breaks backwards compatibility with HTML 4.

    4. The embed element is an unfixable construct because it has no fallback mechanism. The object element is a much better construct to replace the embed element. Nonetheless, (X)HTML 5 will support embed.

    5. The iframe element poses great challenges for assistive technologies. Nonetheless, (X)HTML 5 will support iframe.

    There is absolutely no need for the next markup specification to be backwards compatible because user-agents will continue to support HTML 4 and earlier specs for a long time to come. If an author *really* needs to use the font element or they have a numbered heading fetish, they can still use HTML 4.x

  22. Pingback from Dracoblogicon » Blog Archive » More HTML Working Group Discussion:

    [...] eality Check More HTML Working Group Discussion I just discovered another post about the new HTML WG, this time on Apple’s Surfin’ Safari Blog. Apple is wiling to partici [...]

  23. David Smith Says:

    alex: 1, 2, 4, and 5 are all examples of old (and mostly deprecated) tags that you find objectionable. I consider “fundamental flaws” to be ones where the *supposedly correct* way of doing things is bad, not the old broken way. The correct way of styling things in HTML is CSS, regardless of the ability to use backwards compatibility tags like . As for 3… I’m not sure what you mean by “semantic” in this sense, sorry.

    Basically, it seems like your objection is not that backwards compatibility is maintained, but that backwards compatibility is maintained in a way that doesn’t force authors to pick between shiny new stuff and nasty old stuff.

  24. David Smith Says:

    heh, that’s supposed to be “…tags like .” rather than “…tags like .[bold stuff]“. *There* is a legitimate argument for nuking the bold tag… it makes commenting on blogs annoying ;)

  25. alexander Says:

    Hi David,

    Unfortunatly, numbered heading are not deprecated. Neither are small, b or i elements.

    David, this may be terminology but it’s an important distinction. Anything the spec defines is the “correct way” of doing things. It may not be best practice, but it’s correct according to the spec.

    >> (X)HTML 5 says that these elements [small, b and i] are now semantic, which in my opinion actually breaks backwards compatibility with HTML 4.

    >… I’m not sure what you mean by “semantic” in this sense

    In HTML 4.x/XHTML 1.x, small, b and i are presentational elements. The following is taken from HTML 4.1 spec:

    — start quote —
    I: Renders as italic text style.
    B: Renders as bold text style.
    SMALL: Renders text in a “small” font.
    — end quote —

    X/HTML 5 redefines the meaning of these elements. The following is taken from Web Applications 1.0 spec:

    — start quote —
    The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.

    The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.

    The small element represents small print (part of a document often describing legal restrictions, such as copyrights or other disadvantages), or other side comments.
    — end quote —

    By redefining what small, i and b elements mean, this breaks backwards compatibility to HTML 4.x. Backwards compatibility means that an HTML 5 user agent must interpret an HTML 4.x document with the same meaning as an HTML 4.x user agent. So if the construct was meaningless in HTML 4.x, it must be meaningless in HTML 5 if HTML 5 is to claim backwards compatibly.

    Basically what I am saying is two things. First, there is no need for HTML 5 to be backwards compatible. Second, HTML 5 is not really backwards compatible.

  26. maciej Says:

    I think the semantics proposed for b, i and small are based on their observed de facto semantics of these elements on the web. Surely it is better to “pave the cowpaths” of the semantics these elements are used for than to continue frowning on a very common use.

  27. alexander Says:

    I support changing the semantic meaning of some HTML 4.x/XHTML 1.x elements. I also support removing “less useful” elements from the spec. But when we do this, let’s not call X/HTML 5 backwards compatible because it won’t be.

  28. maciej Says:

    HTML5 primarily aims to be compatible with existing practice on the web, which more or less resembles HTML4 but is certainly not identical to it. XHTML2 wildly breaks compatibility with existing content and implementations.

  29. ianji Says:

    I must say that I am slightly disturbed by maciej’s somewhat unprofessional use of hyperbole. XHTML2 “wildly” breaks compatibility? The use of the term “wildly” is at best highly subjective. Existing XHTML 1.x documents will clearly continue to
    work in future browsers because they can just keep processing XHTML 1.x as they do now and much of XHTML2 works already in existing browsers. XForms and XML events in XHTML2 will require agents that understand that functionality, but adding such functionality is not rocket science. Of course it requires a will to do so. It has been more than seven years since the XHTML 1.0 spec was released as a W3C standard and Microsoft’s browser still can’t handle it – but then that is clearly not for technical reasons.

  30. David Smith Says:

    ianji: Maciej’s statement is quite accurate with almost any interpretation of the wording. The fact that backwards compatibility could be maintained by doing two separate implementations of XHTML has little relevance to the fact that XHTML2 is incompatible with XHTML1 (or anything else on the web). If you follow your logic to its conclusion, you’ll realize that you just claimed that Perl and Ruby are HTML compatible, since they could be processed in a program without breaking HTML support…

    XHTML2 is obviously more compatible with XHTML1 than Perl is, but the minor changes on meaning that alexander has been talking about are hardly even comparable to the much more drastic changes in XHTML2. Essentially, if you want to measure “how compatible” two specs are, consider what percentage of documents work in both. Perhaps more importantly, consider how much author knowledge translates effectively between the two specs (HTML is heavily taught by example, which is one of the critical factors leading to the amazing growth of the web). HTML5 is highly compatible with existing practice on the web by both measurements, and XHTML2 really isn’t, however nice it may be in other ways.

    One focus of HTML5 that I highly approve of has been the attempt to get reasonable fallback content when parts of it aren’t supported.

  31. alexander Says:

    Here is my take on what is good and bad about X/HTML 5 and XHTML 2.

    http://xhtml.com/en/future/x-html-5-versus-xhtml-2/

  32. maciej Says:

    @alexander

    Your document is not very informative, because it simply says things are “cool” or “uncool” without deep consideration of the pros and cons. For instance, it says the “iframe” element being removed is cool, due to unspecified problems with assistive technologies. But it does not consider the fact that (a) “iframe” is widely used to safely embed offsite content in a sandboxed way; and (b) “object” can be used in the same way, and because it has a looser semantic, surely will have at least as many problems with assistive technologies. The rest of your analysis seems to be similarly shallow.

  33. ianji Says:

    David: I was clearly not implying that XHTML 2 is compatible with current standards – it is not. However, it is obvious that one of the main goals was to keep the differences to a minimum, consistent with “fixing” a few things which were thought to be important (and as I understand it XHTML 1.0 was always intended only as a transitional step between HTML and a future XML based markup language, so nobody complain that these incompatibilities are/were unexpected). I was only arguing against the use of the word “wildly” and I certainly think maciej’s comment would have been much closer to the mark if he had simply omitted that word. Of course I can’t objectively justify this because “wildly” is a subjective term – and that was my main point.

    Personally I feel that W3C made a mistake back in 2000 by releasing an XHTML spec that tried to be fully compatible with HTML to the extent of being able to be rendered using existing HTML parsers. It certainly doesn’t seemed to have helped much in terms of adoption (though that is also Microsoft’s fault for not giving MSIE an XHTML parser). If the plan for the future was an incompatible XHTML then they might as well have made the break back then and saved us the current debate.

    Purely in terms of my own XHTML website, since it is buillt from Markdown source I could bring it up to date with any future incompatible XHTML spec simply by replacing the Markdown to XHTML translator with a new one and editing one simple temlate file – which I guess is why I can be afford to be blase about lack of compatibility:-)

  34. Pingback from the future of the web at jimmah ./write:

    [...] major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as [...]

  35. sebnewyork Says:

    This might be a naive question, however I would love to get an knowledgeable answer to it, I’ve kept wondering about it since I first started being a web-designer-developer:
    Why can’t any content be fetched to an html page the same way an image can?
    for example:
    img src=”image.jpg” …
    text src=”file.txt (or file.html, etc.) just like an include…
    for remote content
    text src=”http://example.com/page.html/” tagId=”someID”
    or by extension any
    content-type src=”url” …
    It seems to me that it would open enormous possibility

    Has it been thought out when HTML was conceived? If not why?

  36. Pingback from   HTML5, XHTML2, and the Future of the Web by .: Jnbn :.:

    [...] major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating: We declined to participate in the XHTML2 Working Group because we [...]

  37. Pingback from Toronto’s Leading Web Designers » News Archive » HTML5, XHTML2, and the Future of the Web:

    [...] major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating: We declined to participate in the XHTML2 Working Group because we [...]

  38. Pingback from Make a Dream to be true… » HTML5, XHTML2, and the Future of the Web:

    [...] major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating: We declined to participate in the XHTML2 Working Group because we [...]

  39. Pingback from urang a.k.a Saiful Adnan | HTML5, XHTML2, and the Future of the Web:

    [...] major browser vendors supports XHTML2, and Apple’s Maciej Stachowiak even went so far as stating: We declined to participate in the XHTML2 Working Group because we [...]

  40. W3EDGE Says:

    I’m sorry to take it back to the beginning of the discussion here, (speaking to what Nicholas Shanks said), but I’d really like to know if and how delegation could be used to compartmentalize the tasks involved in finalizing a specification. It seems to me that there are plenty of qualified and talented minds willing to contribute, but so far (and excuse my ignorance), I cannot seem to find more than open discussions which tend to get a bit off topic.

  41. Pingback from Hixie's Natural Log: The CSS working group is irrelevant:

    [...] At the time, we were just starting with the HTML working group, and the openness of the WHATWG over the past few years was just starting to be adopted by the HTML working group, after several months of pushing for it in the W3C (mostly in secret, though my own posts on the matter were all public, as were a few others). [...]

  42. v9designbuild Says:

    I agree that the the 10% market share threshold may be off balance but some level does need to be established. I agree that giving the two major vendors the power of veto will disallow other browsers to be considered is not in the best interests of the industry. But if you lower it too far there is going to be a loss of integrity. Where is the happy medium?

  43. Pingback from Is XHTML good enought? | HTML-Advisor:

    [...] of HTML 5 and have largely ignored the development of XHTML 2. The Safari development team has even opted to take no part in the XHTML 2 development [...]