Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Hi Bronslav - keeping to the technical as per hixi'e request you wrote: both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that matters is what is in browsers. Not exactly true, the semantics of HTML and the rules on how implemented (or yet to be implemented) features are to be used within the constraints of their implementation is not down to the browser vendors, the rules on how HTML is to be used has an important effect upon the accessibility of authored content. Also there are there are other classes of software such as conformance checkers for which HTML/HTML5 provide normative requirements and advice. And as it happens this is one of the areas where the 2 specs diverge: In the HTML5 spec [5] there are currently only 2 cases (soon there may only be 1 [1]) where lack of alt on an attribute is considered conforming: A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies: •The img element is in a figure element that satisfies the conditions described above. •The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string generator. (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.) While in HTML living standard there are 3 [2] the one missing from HTML5 is The title attribute is present and has a non-empty value The reasons why the HTML5 specification does not have the same requirement as HTML the living standard is well documented [3] So conformance checkers have to make a decision about which set of rules to implement. I would strongly suggest that one of the major validation tools [4] will implement the rules in the W3C HTML spec, not HTML living standard. [1] http://www.w3.org/html/wg/wiki/ChangeProposals/Issue31cMetaGeneratorUpdated [2] http://www.whatwg.org/specs/web-apps/current-work/multipage//embedded-content-1.html#guidance-for-conformance-checkers [3] http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2 [4] http://validator.w3.org/ [5] http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-conformance-checkers On 25.7.2012 16:55, Steve Faulkner wrote: hi Bronislav you wrote: I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. I am sure the same can be said from the other viewpoint, The W3C HTML working group will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the WHATWG group doesn't demonstrate any serious lapses in judgement. Which is why the 2 specs have diverged on author conformance requirements and advice as each group considers the other to have made lapses in judgement. Hi Steve, True, no doubt about that, but that is matter of relevancy of opinion. Mine and yours are irrelevant. W3C and WHATWG as organizations are irrelevant - neither actually have any authority, both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that maters is what is in browsers. Bronislav Klucka -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Hi Steve, you are trying to keep it technical by picking one example. But I guess you are missing a point, this is not technical issue here, this is not about choosing, this is about market. I do understand, that HTML is more than a set of tags and rules to use them, there are a lot of different issues here involved (conformance, nonconformance, legacy content, error fixing, parsing, accessibility. etc.), but again, this is not technical issue, it's marketing, and frankly I think this is exactly what you are missing. Let's assume, the browser is the most important device to consume HTML (I do not know about search engines crawlers, due to their speed, number and reach, they may be dominant, but they usually go for different thinks then validity, conformity, accessibility and most likely even semantics in general). I do not have any numbers/research to support that, but it's not unreasonable to assume this. Let's say we have 2 specs.: spec A and spec. B, Let's say, that majority of browsers (vendors) pick specification A. 1/ web developers will look into A for guidance, because of the browser support of HTML and HTML related technologies (it's one package developers are working with - HTML, CSS, JS) 2/ web developers will not use validators checking against B (because of 1/, why would they?) 3/ most validators will use A as a frame to check against 4/ due to our assumption, due to 1/, if crawlers will look for any validity specific issues, they will use specification A 5/ due to our assumption, due to 1/, assistant devices (e.g. readers for blind) will use specification A 6/ specification B becomes marginal 7/ because all of this, any other future device consuming HTML (even browser, browser versions) will choose spec. A And that won't change until browser switch from spec. A to other This is not about just pick one of those specifications, no vendor of any device/sw, who does want to become a player in this field of any significance will go with the flow. Due to Hixie's intervention here (this is technical forum), if you wishes to discuss this issue further, why do I think that living standard approach is better than specification circle (the technical differences are minor issues here). You can write me directly. Brona On 26.7.2012 13:38, Steve Faulkner wrote: Hi Bronslav - keeping to the technical as per hixi'e request you wrote: both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that matters is what is in browsers. Not exactly true, the semantics of HTML and the rules on how implemented (or yet to be implemented) features are to be used within the constraints of their implementation is not down to the browser vendors, the rules on how HTML is to be used has an important effect upon the accessibility of authored content. Also there are there are other classes of software such as conformance checkers for which HTML/HTML5 provide normative requirements and advice. And as it happens this is one of the areas where the 2 specs diverge: In the HTML5 spec [5] there are currently only 2 cases (soon there may only be 1 [1]) where lack of alt on an attribute is considered conforming: A conformance checker must report the lack of an alt attribute as an error unless one of the conditions listed below applies: •The img element is in a figure element that satisfies the conditions described above. •The document has a meta element with a name attribute whose value is an ASCII case-insensitive match for the string generator. (This case does not represent a case where the document is conforming, only that the generator could not determine appropriate alternative text — validators are required to not show an error in this case to discourage markup generators from including bogus alternative text purely in an attempt to silence validators.) While in HTML living standard there are 3 [2] the one missing from HTML5 is The title attribute is present and has a non-empty value The reasons why the HTML5 specification does not have the same requirement as HTML the living standard is well documented [3] So conformance checkers have to make a decision about which set of rules to implement. I would strongly suggest that one of the major validation tools [4] will implement the rules in the W3C HTML spec, not HTML living standard. [1] http://www.w3.org/html/wg/wiki/ChangeProposals/Issue31cMetaGeneratorUpdated [2] http://www.whatwg.org/specs/web-apps/current-work/multipage//embedded-content-1.html#guidance-for-conformance-checkers [3] http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2 [4] http://validator.w3.org/ [5] http://dev.w3.org/html5/spec/the-img-element.html#guidance-for-conformance-checkers On 25.7.2012 16:55, Steve Faulkner wrote: hi Bronislav you wrote: I was just looking
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 20 July 2012 14:38, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Hixie, I believe you have made some spurious claims, one of them being; The WHATWG effort is focused on developing the canonical description of HTML and related technologies The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification. I do not consider this to be wholly that case, in particular in regards to author level conformance requirements and advice, where the HTML standard has no special claim to authority, it is not the domain of browser vendors to decide what is good authoring practise and any authoring requirements that go beyond implementation realities. The HTML living standard is not a canonical description of HTML, if it was there would be no need for the existence of specifications such as HTML to Platform Accessibility APIs Implementation Guidehttp://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html, this document is in existence and is being developed because neither the HTML5 specification nor the HTML living standard contains anything bearing a resemblance of what could be considered and adequate description of how user agents can implement accessibility support for HTML features in an interoperable way. Neither HTML5 in its current form or HTML the living standard can claim to be a canonical description of author conformance requirements for the provision of text alternatives, as there is another document in existence also published by the W3C that provides normative requirements for the subject:http://dev.w3.org/html5/alt-techniques/ The HTML standard contradicts the HTML5 specification (or vice versa) on a number of author conformance requirements and advisory techniques, including use of tables, use of ARIA and use of the title attribute. In respect to those author related requirements mentioned above the HTML5 specification can currently claim to be contain a more accurate set of requirements and advice, that takes into account current implementation realities, thus providing author with more practical advice and thus end users with a better experience. All in all I do not agree with your claim of the HTML living standard being canonical. It is unfortunately the case that we now have at least 2 specifications; HTML5 and the living standard neither of which can claim to be canonical description of HTML for stakeholders other than browser vendors. There's been some commentary about this in blogosphere e.g. http://www.xmltoday.org/content/inevitable-forking-html Is it accurate to say that html5 is being 'forked', or would that be an overstatement? -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 20.7.2012 14:38, Steve Faulkner wrote: Hi Hixie, I believe you have made some spurious claims, one of them being; The WHATWG effort is focused on developing the canonical description of HTML and related technologies The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification In respect to those author related requirements mentioned above the HTML5 specification can currently claim to be contain a more accurate set of requirements and advice, that takes into account current implementation realities, thus providing author with more practical advice and thus end users with a better experience. Canonical means neither correct nor accurate, those words have no meaning in this case, you cannot apply them on set of rules (you first have to have set of rules, to claim, whether something is accurate or correct within the boundaries of those rules), canonical means, that those set of rules are valid, that those rules apply. The question is, who will follow those set of rules. Both HTML5 and HTML TLS can claim to be canonical, both can be valid for different groups. Let's just hope all major vendors will chose the same... Brona
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Le 25/07/2012 13:45, Bronislav Klučka a écrit : On 20.7.2012 14:38, Steve Faulkner wrote: Hi Hixie, I believe you have made some spurious claims, one of them being; The WHATWG effort is focused on developing the canonical description of HTML and related technologies The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification In respect to those author related requirements mentioned above the HTML5 specification can currently claim to be contain a more accurate set of requirements and advice, that takes into account current implementation realities, thus providing author with more practical advice and thus end users with a better experience. Canonical means neither correct nor accurate, those words have no meaning in this case, you cannot apply them on set of rules (you first have to have set of rules, to claim, whether something is accurate or correct within the boundaries of those rules), canonical means, that those set of rules are valid, that those rules apply. The question is, who will follow those set of rules. Both HTML5 and HTML TLS can claim to be canonical, both can be valid for different groups. Who are those different groups? As far as I know, the major producer of HTML content is a group usually refered as web developers. I have a genuine question which is: does what any other group think about HTML matters? Let's just hope all major vendors will chose the same... This statement seems very upside down to me. Some people thinks standards follow this path: 1) a spec is written 2) some folks (browser vendors) implement it 3) some other folks (web devs) build on top of that. I don't know how to say that, but this model is plain wrong. Maybe it works in some industry. Maybe it works for some languages, but it's not the case for web technologies (HTML included). Reality is that implementors implement and for the most part, the spec codifies *afterwards* what has been implemented. The biggest part of HTML5 has been exactly that. And sometimes between the first implementation and the standard, other implement the same thing. Sometimes with bug, sometimes they get the initial implementors to fix a bug before copying it, sometimes no one care about what has been implemented and it's removed. In the end, all majors vendors will keep doing what they have always been doing and for most part, since they all have the constraint to properly render at least what others render properly, there will be at worst a de facto standard if the standard either doesn't cover this case or is not properly describing what is actually implemented. Who writes the spec, what is in the spec is at no point the most important piece of the puzzle, because if no one follows the spec, it's just a useless piece of document. My good news for you is the following: all relevant specs will codify what all major vendors choose to do. David
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Canonical means neither correct nor accurate, those words have no meaning in this case, you cannot apply them on set of rules (you first have to have set of rules, to claim, whether something is accurate or correct within the boundaries of those rules), canonical means, that those set of rules are valid, that those rules apply. The question is, who will follow those set of rules. Both HTML5 and HTML TLS can claim to be canonical, both can be valid for different groups. Who are those different groups? As far as I know, the major producer of HTML content is a group usually refered as web developers. I have a genuine question which is: does what any other group think about HTML matters? I was describing general meaning of rules. The difference between validity of rules and correctness of statement. And different groups? We already had the situation, where some vendors were implementing WHATWG and W3C was producing XHTML2 (some 5 years ago). WHATWG was valid for (some) vendors, W3C for W3C... the outcome is history (and very pleasing for me). Let's just hope all major vendors will chose the same... This statement seems very upside down to me. Some people thinks standards follow this path: 1) a spec is written 2) some folks (browser vendors) implement it 3) some other folks (web devs) build on top of that. I don't know how to say that, but this model is plain wrong. Maybe it works in some industry. Maybe it works for some languages, but it's not the case for web technologies (HTML included). Reality is that implementors implement and for the most part, the spec codifies *afterwards* what has been implemented. The biggest part of HTML5 has been exactly that. And sometimes between the first implementation and the standard, other implement the same thing. Sometimes with bug, sometimes they get the initial implementors to fix a bug before copying it, sometimes no one care about what has been implemented and it's removed. In the end, all majors vendors will keep doing what they have always been doing and for most part, since they all have the constraint to properly render at least what others render properly, there will be at worst a de facto standard if the standard either doesn't cover this case or is not properly describing what is actually implemented. Who writes the spec, what is in the spec is at no point the most important piece of the puzzle, because if no one follows the spec, it's just a useless piece of document. My good news for you is the following: all relevant specs will codify what all major vendors choose to do. David I completely agree... again, we live trough that (Netscape and MS box model vs. W3C box model; W3C burial of HTML vs. pretty much everybody else minus XML zealots; W3C XHMTL2 vs. no-one because no-one cared...). I agree with your description of HTML progress. It worked in browser wars (W3C codified what actually already worked - what was in spec. should actually work) and now without the war but through cooperation the progress can be as quick as 15 years ago but much less painfull. Only by extensive using of some version of draft can that draft be fully tested and, if necessary, udated. And the specification process round trip is counterproductive. And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? (Thou I do not think it actually will happen). To put it simply, it does not matter, what either W3C or WHATWG codify, what matter is, what browsers implement - it was always about vendors... W3C forgot that. Brona
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Le 25/07/2012 15:32, Bronislav Klučka a écrit : And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? Interesting question... (Thou I do not think it actually will happen). To put it simply, it does not matter, what either W3C or WHATWG codify, what matter is, what browsers implement - it was always about vendors... ... which you answer yourself to. If the WHATWG continue to work in ways that we know (including codifying de facto standards to preserve content backward compatibility), then no matter what browsers will to do (follow one spec or several or none), the end result is that the WHATWG will codify what works. As an example, they spec'ed innerHTML which was first implemented in IE (and followed by all others) which isn't part of the WHATWG. There are probably dozens of these examples. W3C forgot that. Who did? I mean, the actual people. Who should we be talking to to convince them that web standards are more the consequence of an implementation rather than the opposite (regardless of whether this is a good situation or not)? David
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Le 25/07/2012 15:32, Bronislav Klučka a écrit : And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? A last point I forgot. Since there is one web, since urls (usually) refer to the same content, all web browsers are tied together to all render the content, no matter what their standards belonging/non-belonging/preference is. From the implementor perspective, what's important isn't standards by themselves, but supporting this existing (and hopefully upcoming) content. There is still a need to shift the perception of what a standard actually means in the context of the web. It is my understanding that when Hixie shifted to the living standard model, one of the goal was to start this shift of perception. There is still a long way to go. David
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 25.7.2012 16:04, David Bruant wrote: Le 25/07/2012 15:32, Bronislav Klučka a écrit : And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? Interesting question... (Thou I do not think it actually will happen). To put it simply, it does not matter, what either W3C or WHATWG codify, what matter is, what browsers implement - it was always about vendors... ... which you answer yourself to. If the WHATWG continue to work in ways that we know (including codifying de facto standards to preserve content backward compatibility), then no matter what browsers will to do (follow one spec or several or none), the end result is that the WHATWG will codify what works. As an example, they spec'ed innerHTML which was first implemented in IE (and followed by all others) which isn't part of the WHATWG. There are probably dozens of these examples. This goes to my Interesting question, I do understand the advantage of codifying supported convention, but in case of differences... And it's already happening (on vendor level... maybe not differences at the same task, but different approaches on similar tasks, decisions not to implement some parts of WebApp - but I guess it's inevitable). W3C forgot that. Who did? I mean, the actual people. Who should we be talking to to convince them that web standards are more the consequence of an implementation rather than the opposite (regardless of whether this is a good situation or not)? David I do not know who actually decided, that W3C will be inventor instead of codifier... It's like 14 years ago :). And I'm not in either group. Just remembering those times :) You should ask the people that were behind creation of WHATWG (there must have been a reason why some vendors, part of WG working on web tech, decided to leave and start their own project - there must have been someone opposing the idea of fast progress of HTML, there must have been someone trying to push XHTML2 at all costs, there must have been someone who though, that vendors opinion is irrelevant, or less important). I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. B.
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Le 25/07/2012 16:36, Bronislav Klučka a écrit : On 25.7.2012 16:04, David Bruant wrote: Le 25/07/2012 15:32, Bronislav Klučka a écrit : And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? Interesting question... (Thou I do not think it actually will happen). To put it simply, it does not matter, what either W3C or WHATWG codify, what matter is, what browsers implement - it was always about vendors... ... which you answer yourself to. If the WHATWG continue to work in ways that we know (including codifying de facto standards to preserve content backward compatibility), then no matter what browsers will to do (follow one spec or several or none), the end result is that the WHATWG will codify what works. As an example, they spec'ed innerHTML which was first implemented in IE (and followed by all others) which isn't part of the WHATWG. There are probably dozens of these examples. This goes to my Interesting question, I do understand the advantage of codifying supported convention, but in case of differences... And it's already happening (on vendor level... maybe not differences at the same task, but different approaches on similar tasks, decisions not to implement some parts of WebApp - but I guess it's inevitable). In case of differences, often, if some content is found to behave differently, some browsers will fix to align with the others after discussion (usually in standards mailing-lists, because that's what they are really here for). If at some point all content decide to follow what some browser say, the others will follow creating a de facto standard. You seem to be worried about what browsers will implement, but in the long term, there is no reason. In the long term, they will all align on parts of the spec that matter (that people cover by writing actual content for it). I admit short term is a bit more chaotic, though. David
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
hi Bronislav you wrote: I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. I am sure the same can be said from the other viewpoint, The W3C HTML working group will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the WHATWG group doesn't demonstrate any serious lapses in judgement. Which is why the 2 specs have diverged on author conformance requirements and advice as each group considers the other to have made lapses in judgement. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 25.7.2012 16:52, David Bruant wrote: Le 25/07/2012 16:36, Bronislav Klučka a écrit : On 25.7.2012 16:04, David Bruant wrote: Le 25/07/2012 15:32, Bronislav Klučka a écrit : And my last remark: I hope major browser vendors will chose to follow the same path, the same implementation of tasks, but not all major vendors are part of WHATWG (as far as I know), and if some choose to follow W3C and some different WHATWG drafts of the same task, what would happen? Interesting question... (Thou I do not think it actually will happen). To put it simply, it does not matter, what either W3C or WHATWG codify, what matter is, what browsers implement - it was always about vendors... ... which you answer yourself to. If the WHATWG continue to work in ways that we know (including codifying de facto standards to preserve content backward compatibility), then no matter what browsers will to do (follow one spec or several or none), the end result is that the WHATWG will codify what works. As an example, they spec'ed innerHTML which was first implemented in IE (and followed by all others) which isn't part of the WHATWG. There are probably dozens of these examples. This goes to my Interesting question, I do understand the advantage of codifying supported convention, but in case of differences... And it's already happening (on vendor level... maybe not differences at the same task, but different approaches on similar tasks, decisions not to implement some parts of WebApp - but I guess it's inevitable). In case of differences, often, if some content is found to behave differently, some browsers will fix to align with the others after discussion (usually in standards mailing-lists, because that's what they are really here for). If at some point all content decide to follow what some browser say, the others will follow creating a de facto standard. Let me just give you few examples: WebSql, FileSystem - most likely dead, thou codified and supported by some; saving blob on disk without server round trip (there are 3 different ways to do that, in MSIE, in Chrome, in FF), audio/video codecs... There's another part of your If statement: If they don not decide to follow, you end up with solution for some browser, with another (if any) solution in other browser. With one WHATWG document some vendors will ignore, or with several competing WHATWG documents, or with no WHATWG documentation at all. You seem to be worried about what browsers will implement, but in the long term, there is no reason. In the long term, they will all align on parts of the spec that matter (that people cover by writing actual content for it). I admit short term is a bit more chaotic, though. David I'm actually not worried at all, after 15 years of web devel, what could be worst than developing for NN4 and IE3 simultaneously :). My original post was about the canonical and other about the irrelevance of W3C against browser vendors and more satisfying approach by WHATWG, but that can crush also... The fact, that current state is little annoying (see my examples above) is most likely inevitable. It's a tax we have to pay for working in this industry. We can either have all cool stable everything (like cca between 2002-2007), but actually time stood still in those times. Or we can have bit chaotic progress (not just in a short term... yes, 3 years from now, all current cool stuff will be peachy, but there will new stuff) Brona
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 25.7.2012 16:55, Steve Faulkner wrote: hi Bronislav you wrote: I was just looking at WHATWG wiki and there is nice sentence: In general the WHATWG will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the W3C group doesn't demonstrate any serious lapses in judgement. I am sure the same can be said from the other viewpoint, The W3C HTML working group will ensure that the normative content of the specifications (the requirements on authors and implementors) remains the same so long as the WHATWG group doesn't demonstrate any serious lapses in judgement. Which is why the 2 specs have diverged on author conformance requirements and advice as each group considers the other to have made lapses in judgement. Hi Steve, True, no doubt about that, but that is matter of relevancy of opinion. Mine and yours are irrelevant. W3C and WHATWG as organizations are irrelevant - neither actually have any authority, both derives their authority from browser vendors - specification not supported by majority of browsers is irrelevant, developers can only work with what is in the browser (plugins are becoming obsolete, as it would seems). The only thing, that maters is what is in browsers. Bronislav Klucka
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Le 25 juil. 2012 à 10:04, David Bruant a écrit : W3C forgot that. Who did? I mean, the actual people. Nobody forgot. The discussions are not about WHATWG vs W3C. This is nonsense. There W3C is not a monolithic bloc either. Most of the browser engineers working on whatwg lists, IRC channels, are also part of the W3C groups. There is productive work done at different places. There are issues with _some_ groups. One group which has been difficult lately in terms of agreeing on how to work is the W3C HTML WG. (I'm not taking side). The W3C has an history of broader public and diversity in terms of opinions, ideas on Web architecture, etc. which indeed makes the consensus more difficult to reach, hence the (sometimes too) heavy process (when engineers just want to have fun solving concrete use cases). Let's not forget that the W3C Web Apps WG is working quite well. But it is a smaller group with more likely minded people. http://www.w3.org/2008/webapps/ http://lists.w3.org/Archives/Public/public-webapps/ http://lists.w3.org/Archives/Public/www-dom/ List of documents being worked on http://www.w3.org/TR/tr-groups-all#tr_Web_Applications_Working_Group -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
To reiterate the statement I made in the original post on this thread: If you have any questions, I encourage you to e-mail me privately or ask on the IRC channel (#whatwg on Freenode); process-related discussion is discouraged on this mailing list so that we can maintain a high technical signal to noise ratio. You can also cc an archive mailing list, e.g. the www-arch...@w3.org mailing list, or cc me on a public post on a system such as Google+ or e-mail me a link to your blog post. Answers to any frequent questions about process issues will be added to the FAQ (something that you can do directly or which you can wait for someone else such as me to do). This mailing list (wha...@whatwg.org) is specifically for technical discussions and not for process discussions. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On 25 July 2012 18:12, Ian Hickson i...@hixie.ch wrote: To reiterate the statement I made in the original post on this thread: If you have any questions, I encourage you to e-mail me privately or ask on the IRC channel (#whatwg on Freenode); process-related discussion is discouraged on this mailing list so that we can maintain a high technical signal to noise ratio. You can also cc an archive mailing list, e.g. the www-arch...@w3.org mailing list, or cc me on a public post on a system such as Google+ or e-mail me a link to your blog post. Answers to any frequent questions about process issues will be added to the FAQ (something that you can do directly or which you can wait for someone else such as me to do). This mailing list (wha...@whatwg.org) is specifically for technical discussions and not for process discussions. Thank you for the response, and the guidance. I presume that naming is still a technical matter. Just so that it's possible to understand how to name the two new branches correctly, can you confirm that the W3C branch is now called HTML5 and the WHATWG branch is named 'HTML Living Standard'. Is this the long term project name, or just a working title? Just thinking out loud, is that wise given that the acronym (T)LS (The) Living Standard, (which someone has used already) is also used often used as 'Transport Layer Security'? Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On Wed, 25 Jul 2012, Melvin Carvalho wrote: Just so that it's possible to understand how to name the two new branches correctly, can you confirm that the W3C branch is now called HTML5 and the WHATWG branch is named 'HTML Living Standard'. Is this the long term project name, or just a working title? The WHATWG spec is just called HTML, Living Standard is what it is. As we've gone through half a dozen names already for this spec (XForms Basic, Web Forms 2.0, Web Applications 1.0, HTML 5, HTML5, Web Applications 1.0 again, and now HTML), I don't intend to change it again, but who knows. :-) As of the last time the W3C equivalent spec was updated, it was titled HTML5, but you'd have to ask the W3C what their plans are. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
2012-07-25 20:40, Ian Hickson wrote: On Wed, 25 Jul 2012, Melvin Carvalho wrote: Just so that it's possible to understand how to name the two new branches correctly, can you confirm that the W3C branch is now called HTML5 and the WHATWG branch is named 'HTML Living Standard'. Is this the long term project name, or just a working title? The WHATWG spec is just called HTML, Living Standard is what it is. As we've gone through half a dozen names already for this spec (XForms Basic, Web Forms 2.0, Web Applications 1.0, HTML 5, HTML5, Web Applications 1.0 again, and now HTML), I don't intend to change it again, but who knows. :-) The practical problem with names is that we need to communicate what we are referring to, in an understandable manner. HTML is far too broad, and Living Standard doesn't even say this is about HTML. HTML Living Standard would do I guess, even though it sounds more like a credo than a technical reference. I suppose WHATWG HTML might be used as a fairly neutral expression. As of the last time the W3C equivalent spec was updated, it was titled HTML5, but you'd have to ask the W3C what their plans are. HTML5 has become a rather loose expression, so we may need to use a phrase like W3C HTML5, or maybe W3C HTML5 draft(s), in contexts where the difference between W3C HTML5 and WHATWG HTML might matter. Yucca
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
Hi Hixie, I believe you have made some spurious claims, one of them being; The WHATWG effort is focused on developing the canonical description of HTML and related technologies The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification. I do not consider this to be wholly that case, in particular in regards to author level conformance requirements and advice, where the HTML standard has no special claim to authority, it is not the domain of browser vendors to decide what is good authoring practise and any authoring requirements that go beyond implementation realities. The HTML living standard is not a canonical description of HTML, if it was there would be no need for the existence of specifications such as HTML to Platform Accessibility APIs Implementation Guidehttp://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html, this document is in existence and is being developed because neither the HTML5 specification nor the HTML living standard contains anything bearing a resemblance of what could be considered and adequate description of how user agents can implement accessibility support for HTML features in an interoperable way. Neither HTML5 in its current form or HTML the living standard can claim to be a canonical description of author conformance requirements for the provision of text alternatives, as there is another document in existence also published by the W3C that provides normative requirements for the subject:http://dev.w3.org/html5/alt-techniques/ The HTML standard contradicts the HTML5 specification (or vice versa) on a number of author conformance requirements and advisory techniques, including use of tables, use of ARIA and use of the title attribute. In respect to those author related requirements mentioned above the HTML5 specification can currently claim to be contain a more accurate set of requirements and advice, that takes into account current implementation realities, thus providing author with more practical advice and thus end users with a better experience. All in all I do not agree with your claim of the HTML living standard being canonical. It is unfortunately the case that we now have at least 2 specifications; HTML5 and the living standard neither of which can claim to be canonical description of HTML for stakeholders other than browser vendors. -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
[whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
If you've been happily ignoring the W3C's involvement with HTML these past few years, you can stop reading now. If you got a bunch of bugmail recently and want to know why, the explanation is below. A few years ago (around 2007), we started working with the W3C on what we were then unofficially calling HTML5, and officially calling Web Applications 1.0. We renamed the specification HTML5, and the W3C began publishing a copy of it as well. Not long after, the W3C side of this effort decided to split their version of the spec into subspecs (e.g. splitting out the 2D canvas API, server-sent events, postMessage, etc), and for a while we tried to match that on the WHATWG side. The result was an increasing confusion of versions of the spec, so we eventually went back to just having a single spec on the WHATWG side which contains everything I work on, which we now call the HTML Living Standard. Over the years, this document and the various documents on the W3C side have slowly slightly forked, as documented at the top of the WHATWG spec. More recently, the goals of the W3C and the WHATWG on the HTML front have diverged a bit as well. The WHATWG effort is focused on developing the canonical description of HTML and related technologies, meaning fixing bugs as we find them [1], adding new features as they become necessary and viable, and generally tracking implementations. The W3C effort, meanwhile, is now focused on creating a snapshot developed according to the venerable W3C process. This led to the chairs of the W3C HTML working group and myself deciding to split the work into two, with a different person responsible for editing the W3C HTML5, canvas, and microdata specifications than is editing the WHATWG specification (me). [2] As part of working with the W3C, we have been using the W3C Bugzilla system to track bugs filed using the widget at the bottom right of the WHATWG specification. The W3C has kindly agreed to continue hosting the bugs filed on WHATWG specifications. Previously, however, since there was just one editor working on the W3C and WHATWG specs, we just had one set of bugs for both specs, and I processed them as if there was just one spec. With the fork, this is no longer tenable. Therefore, we have taken all the bugs that were previously filed in the W3C Bugzilla system on the HTML specs, and cloned them: one copy for the W3C, and one copy for the WHATWG. I will be going through the WHATWG bugs, and the new editor(s) for the W3C will be going through the W3C bugs. If you recently got a bunch of bugmail mentioning operation convergence, that's what it was about. For more details on what exactly happened, see later in this e-mail. How does this affect you? * If you want to send feedback on the WHATWG specification: the easiest way is just to e-mail this mailing list (wha...@whatwg.org). * If you want to file a bug on the WHATWG specification: Use the tool in the WHATWG specification, and it will use the right component for you. * If you want to use the W3C Bugzilla directly to file bugs or search for bugs on the WHATWG specification: Use the WHATWG product in Bugzilla. The component is HTML for the specification I edit; the product also has components for a few other specifications edited by, e.g., Anne. * If you want to comment on a bug in Bugzilla in such a way that I see your comment: make sure you comment on the bug that's assigned to me. If the bug is in the HTML WG product, not the WHATWG product, it will be assigned to the HTML WG's editor and so I might not see it. (I'll be doing my best to track changes made on the W3C side, but I likely won't be tracking it down to the level of individual bug comments.) This is a link to the currently open bugs on the WHATWG HTML spec: https://www.w3.org/Bugs/Public/buglist.cgi?product=WHATWGcomponent=HTMLresolution To track how much feedback is pending, I use this graph: http://www.whatwg.org/issues/data.html Details on operation convergence: The bugs used to be in two buckets: those filed on the W3C spec (in various components like HTML5 spec) and those filed on the WHATWG spec (in the other Hixie drafts component). They were mostly all assigned to me, and I used to ignore the component [3]. I ran a pair of scripts recently in conjunction with W3C staff that cloned all these bugs. The first script took those bugs that used to be in the HTML5 spec components, made a new clone in the WHATWG product assigned to me, and reassigned the original bug to nobody. The second script took the bugs that were in the other Hixie drafts component, moved them to the WHATWG product, and cloned them into bugs in the HTML5 spec component, assigned to nobody. The bugs that are assigned to nobody today will in due course presumably be reassigned to whoever becomes the editor of the W3C's HTML5 specifications. This effort does not affect bugs filed in the future; I am still working with the chairs of the
[whatwg] Administrivia
Last year the W3C introduced a new framework for people developing specifications, which they call Community Groups (CGs). Since then we have moved a few parts of the HTML standard under CGs, most notably Aryeh's HTML Editing APIs specification [1], which replaced the old execCommand() spec in the HTML standard. The main advantage of doing this is that it means we have a clear patent policy. Historically, we've relied on the W3C HTML working group for this, but as the W3C has focused on stablising their HTML5 snapshot, newer features have not enjoyed the same coverage. To address this, today I have started the process of forming a community group for the rest of the WHATWG work. This will basically have no effect on how the WHATWG operates, except that when we make use of the W3C Community Group Final Specification Agreement (FSA) mechanism, anyone who wishes to co-sign the agreement [2] will be invited to do so. [1] http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [2] http://www.w3.org/community/about/agreements/final/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: new member in the oversight committee
Ian Hickson wrote: On Sun, 30 Mar 2008, Dan Brickley wrote: Ian Hickson wrote: FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Does the committee have a mailing list? Where do they discuss things? Any papertrail? There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. W3C staff report through a variety of documented means to their stakeholders (including at regular events, Web Conference, TPs etc), they have named and documented roles grounded in the W3C Process, a class of document for airing their proposals to the wider community (Team notes) as well as strong internal-transparency via extensive internal email, cvs and irc logging so that new team-members can have access to previous discussions. Is this the equivalence you have in mind? W3C staff as a group culture (nothing personal here; I was one myself years) also have a tendency to be a little over-secretive, insular, and too often slip into thinking of themselves as having to heroically figure out what to do internally before presenting an external opinion. Get a tight-knit, smart and distributed group of people together with a sense of mission, and that's a hard trait to avoid. I hope you'll lean towards the public accountability side of things here. See also: http://www.whatwg.org/charter Thanks, interesting. Is a version history and change-log available, beyond what can be discerned from http://web.archive.org/web/*/http://www.whatwg.org/charter ? From the outside it is hard to understand how the charter has evolved over time. cheers, Dan -- http://danbri.org/
Re: [whatwg] Administrivia: new member in the oversight committee
On Mon, 31 Mar 2008, Dan Brickley wrote: There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. W3C staff report through a variety of documented means to their stakeholders (including at regular events, Web Conference, TPs etc), they have named and documented roles grounded in the W3C Process, a class of document for airing their proposals to the wider community (Team notes) as well as strong internal-transparency via extensive internal email, cvs and irc logging so that new team-members can have access to previous discussions. Everything that the WHATWG members do and decide is conveyed to the [EMAIL PROTECTED] mailing list. In the past two years, all they have done is agreed to invite Anne to their group, which was immediately conveyed to the list. See also: http://www.whatwg.org/charter Thanks, interesting. Is a version history and change-log available, beyond what can be discerned from http://web.archive.org/web/*/http://www.whatwg.org/charter ? From the outside it is hard to understand how the charter has evolved over time. The document was created in early 2004 with the announcement of the WHATWG. Dean Edwards was invited in June 2004. Anne was added a few days ago. That's all. (The other changes were to the markup of the header, or adding links to translations, etc.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: new member in the oversight committee
Hi Ian, Ian Hickson wrote: FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Does the committee have a mailing list? Where do they discuss things? Any papertrail? cheers, Dan -- http://danbri.org/
Re: [whatwg] Administrivia: new member in the oversight committee
On Sun, 30 Mar 2008, Dan Brickley wrote: Ian Hickson wrote: FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Does the committee have a mailing list? Where do they discuss things? Any papertrail? There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. See also: http://www.whatwg.org/charter -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: new member in the oversight committee
Le 31 mars 2008 à 10:43, Ian Hickson a écrit : There's no public accountability for this group, no. It's roughly equivalent to W3C staff, except that it is not a paid position. If you really want your metaphor flies… You could have said it's roughly equivalent to W3C Members of Advisory Committee, or Members of Advisory Board. That's all. W3C staff is tied by a work contract and a process. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
[whatwg] Administrivia: new member in the oversight committee
FYI, Anne van Kesteren was just invited to join the WHATWG membership (as defined by our charter, basically that's the small group of people whom I have to answer to in my role as editor). He was invited due to his long involvement in the WHATWG. This oversight group doesn't do much and this won't really change anything; basically the group is there to make sure I don't become evil and biased somehow, and to help direct the group should we decide to take on some new project. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
