Re: [whatwg] Allowing in attribute values
On 24 Jun 2010, at 14:11, Benjamin M. Schwartz wrote: Why would it simplify parsing? It greatly simplifies parsing when you just want to extract entire tags, without immediately parsing the attributes. If you mean parsing with regular expressions, then I think that's a bad practice and shouldn't be encouraged. A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of the body element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then . But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. In my opinion, the gain of allowing is so poor regarding to the troubles it makes, that it should be forbidden in both XML and HTML (any version). Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. Allowing it in the spec and how the browser should behave if it is anyway are two different things. Regards, Skrol29
Re: [whatwg] Allowing in attribute values
I disagree, there are so many other things you need to take account of if you were (for example) getting all the text out of an HTML document. Text and markup in comment nodes would just through a spanner in the works for starters. It all boils down to the fact that the only thing disallowing in attribute values does is simplify regex scanning of HTML (which *isn't* parsing). Seeing as regex parsing of HTML is wrong in so many ways, and isn't something that should be (IMO) encouraged in the slightest, I don't see any reason to change the allowance for characters in attributes. David W. On 25 June 2010 10:46, Skrol29 skrol29forum+wha...@gmail.comskrol29forum%2bwha...@gmail.com wrote: On 24 Jun 2010, at 14:11, Benjamin M. Schwartz wrote: Why would it simplify parsing? It greatly simplifies parsing when you just want to extract entire tags, without immediately parsing the attributes. If you mean parsing with regular expressions, then I think that's a bad practice and shouldn't be encouraged. A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of the body element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then . But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. In my opinion, the gain of allowing is so poor regarding to the troubles it makes, that it should be forbidden in both XML and HTML (any version). Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. Allowing it in the spec and how the browser should behave if it is anyway are two different things. Regards, Skrol29
[whatwg] Technical Parity with W3C HTML Spec
Hi, WHATWG folks- As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. I'm not trying to be political about this, but since W3C and WHATWG are meant to be collaborating, there has to be a certain amount of of flexibility from both sides, for the good of the standard itself, and for readers of the spec. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. Options 1 and 2 are obviously both unreasonable. Option 3 results in the problem we have now (though having an explanation for each difference would be an improvement; I don't know of any such wording now). This leaves option 4. W3C has a relatively clear method for resolving conflicts: first, the group tries to settle the issue on the merit of the technical arguments; failing that, the group may hold a poll (with each individual or organization given a single voice); if there is no consensus, the chairs of the group can make a ruling based on the reasoning at hand; if there are still Formal Objections to the results of that poll, the group can escalate the issue up to the Domain Lead, and ultimately all the way up to the W3C Director (who is normally Tim Berners-Lee). Obviously, the strong preference is not to get to the poll stage at all. I don't know of any W3C method for dealing with conflicts between different standards bodies, like W3C and WHATWG, so I think we're in the air here; W3C obviously has no authority over decisions made in WHATWG, but we need to find a way to resolve these conflicts. As I understand it, the editor seems to have final decision-making power in WHATWG, and I don't know of any process for appealing those decisions (assuming you would want to); for the purposes of arbitration between groups, how can we proceed? For the record, here's my suggestion: a) Both WHATWG and W3C should maintain a single definitive HTML5 specification, that is a feature-for-feature match between groups b) For the longer-term WHATWG work, including sections that were once part of the HTML5 spec but were split off into separate specs (Canvas API) or removed (datagrid), there is another Master Spec that includes whatever the editor feels is needed in that spec, so long as it doesn't conflict with the HTML5 or related specs c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. Maybe the answer is to have a spokesperson or liaison role, someone respected in the WHATWG community with a reputation for reasonable neutrality? Both Hixie and Maciej have conflicts of interest, as editor and W3C co-chair respectively. Maybe Håkon or David, since they were instrumental in forming WHATWG in the first place? (Sorry I won't be very responsive on this list, I'm actually on vacation and only have sporadic net access.) Regards- -Doug
Re: [whatwg] Allowing in attribute values
On 2010-06-25 11:46, Skrol29 wrote: A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of thebody element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then. But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. You seem to be conflating document conformance requirements with parsing requirements. Even if '' was disallowed in attribute values for document conformance, parsers would still be required to handle it if it were present. If your parser doesn't handle it because it just assumes that '' is the end of the tag name, then your paser is broken. Changing the parsing requirements such that '' is treated as the end of a tag, in places where it's currently treated as part of an attribute value, would break backwards compatibility. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Allowing in attribute values
A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. You just need two extra states in the parser (toggled on or '). I wouldn't call that very costly. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of the body element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then . But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. Conversion of HTML to text is more complicated than that - e.g. you shouldn't turn foobrbar into foobar, but you have to keep foobbar as foobar. Implied body is allowed, you should extract img alt, you have to decode entities, etc. I think check for a single character is just a drop in the ocean in such code. And if you're not concerned about accuracy of conversion, you can ignore the fact that is allowed too. It's just going to be yet another tradeoff among many other, much bigger ones. Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. Allowing it in the spec and how the browser should behave if it is anyway are two different things. If you're parsing markup from the web, you have to support invalid markup that browsers accept, not merely pure markup that spec allows. There are reasons to disallow , but I'm not convinced that parsing performance is one of them. -- regards, Kornel
Re: [whatwg] Allowing in attribute values
On Fri, 2010-06-25 at 13:28 +0100, Kornel Lesinski wrote: A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. You just need two extra states in the parser (toggled on or '). I wouldn't call that very costly. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of the body element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then . But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. Conversion of HTML to text is more complicated than that - e.g. you shouldn't turn foobrbar into foobar, but you have to keep foobbar as foobar. Implied body is allowed, you should extract img alt, you have to decode entities, etc. I think check for a single character is just a drop in the ocean in such code. And if you're not concerned about accuracy of conversion, you can ignore the fact that is allowed too. It's just going to be yet another tradeoff among many other, much bigger ones. Also take into consideration that even if was forbidden in the spec, it wouldn't mean it doesn't happen in the wild. Since it works in browsers, you'd still have to support it if you wanted to parse markup from the web. Allowing it in the spec and how the browser should behave if it is anyway are two different things. If you're parsing markup from the web, you have to support invalid markup that browsers accept, not merely pure markup that spec allows. There are reasons to disallow , but I'm not convinced that parsing performance is one of them. I think maybe the best reason for disallowing it I've seen is where attributes aren't correctly quoted: foo bar=foobar Which could potentially break everything. At the moment, most browsers deal with this as a missing quote, but allowing in the value, they should include content after the . Parsing-wise, I don't see it being any more difficult except for very basic parsing methods, and any time difference should be negligible. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Technical Parity with W3C HTML Spec
On Jun 25, 2010, at 5:13 AM, Doug Schepers wrote: There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. 5) W3C could go away
Re: [whatwg] Allowing in attribute values
On Thu, Jun 24, 2010 at 2:34 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: [...] HTML5 is about making a spec that matches common practice, right? In practice, no one puts in attribute values. The data disagrees: http://philip.html5.org/data/gt-in-attribute.txt -- Philip Taylor exc...@gmail.com
Re: [whatwg] Technical Parity with W3C HTML Spec
How is that productive? I realize that it's meant as a joke but it does nothing but add to the impression that some in the WHATWG community just don't care about civility, respect, and cooperation. The best thing to counteract that impression is to prove it wrong. On Jun 25, 2010, at 8:51 AM, Perry Smith wrote: On Jun 25, 2010, at 5:13 AM, Doug Schepers wrote: There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. 5) W3C could go away
Re: [whatwg] Allowing in attribute values
-Message d'origine- De : Lachln Hunt [mailto:lachlan.h...@lachy.id.au] Envoyé : vendredi 25 juin 2010 14:18 À : Skrol29 Cc : 'WHAT Working Group'; b...@alum.mit.edu Objet : Re: [whatwg] Allowing in attribute values On 2010-06-25 11:46, Skrol29 wrote: A agree disallowing chars in attributes greatly simplifies parsing. Not only with regular expressions, but any parsing. If are allowed, it means that in order to found the end of the element you do have to read all attributes before. This is very costy. Just an example but they are many others: let's image you'd like to convert an HTML document into flat text. To simplify you're algorithm you've chosen to retrieve the content of thebody element and then to delete all elements in it. This is very fast if are not allowed in attributes because you're able found elements bounds just by searching and then. But if are allowed, the operation gets much more complicated, and you spend much more time to scan all elements. You seem to be conflating document conformance requirements with parsing requirements. Even if '' was disallowed in attribute values for document conformance, parsers would still be required to handle it if it were present. If your parser doesn't handle it because it just assumes that '' is the end of the tag name, then your paser is broken. Changing the parsing requirements such that '' is treated as the end of a tag, in places where it's currently treated as part of an attribute value, would break backwards compatibility. If the only purpose of an HTML contents was to be displayed by a browser, I would agree with you. We have to consider that XML contents, and therefore HTML contents, has many finalities in the world including in the industry. It is an evidence for XML, but it is also true for HTML. In the industry, parsing the content is essential, whatever the method is. I understand that for the browser finality, the tolerance to the specification must be large in order to display something even if the webmaster has made mistakes in the source. You also don't mind to be obliged to parse all attributes because quite all of them have an impact for the browser. In another hand, in the industry the tolerance to the spec is often very low in order build simple, fast and robust processes. They are also many parsing purposes that care about some elements and don't care about others. I can give examples if needed, but we can foresee this is true. Allowing in attributes is a small gift of tolerance for webmasters, but implies major complications for the industry. Disallowing falls within the purpose of simplifying the grammar, like when XHTML disallowed the uppercase for element and attribute names, like when XHTML disallowed attribute values without quotes PS: Of course my previous example is not a realistic one. That was a technical illustration of the issue. Regards, Skrol29
Re: [whatwg] Technical Parity with W3C HTML Spec
Appreciate the informations on what's currently hurting the specs... On Fri, Jun 25, 2010 at 12:13 PM, Doug Schepers d...@schepers.cc wrote: Hi, WHATWG folks- As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. I'm not trying to be political about this, but since W3C and WHATWG are meant to be collaborating, there has to be a certain amount of of flexibility from both sides, for the good of the standard itself, and for readers of the spec. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. Options 1 and 2 are obviously both unreasonable. One of the unreasonable ways will do fine for the real end users. I couldn't tell myself which of them but whatever other option will just lead to confusion (as it is now). I think it is clear to all that specifications should be driven for the benefit of all, unfortunately we all have a hard time putting that in real practice. Option 3 results in the problem we have now (though having an explanation for each difference would be an improvement; I don't know of any such wording now). This is what should be avoided, not one more option. This leaves option 4. W3C has a relatively clear method for resolving conflicts: first, the group tries to settle the issue on the merit of the technical arguments; failing that, the group may hold a poll (with each individual or organization given a single voice); if there is no consensus, the chairs of the group can make a ruling based on the reasoning at hand; if there are still Formal Objections to the results of that poll, the group can escalate the issue up to the Domain Lead, and ultimately all the way up to the W3C Director (who is normally Tim Berners-Lee). Obviously, the strong preference is not to get to the poll stage at all. I don't know of any W3C method for dealing with conflicts between different standards bodies, like W3C and WHATWG, so I think we're in the air here; W3C obviously has no authority over decisions made in WHATWG, but we need to find a way to resolve these conflicts. As I understand it, the editor seems to have final decision-making power in WHATWG, and I don't know of any process for appealing those decisions (assuming you would want to); for the purposes of arbitration between groups, how can we proceed? For the record, here's my suggestion: a) Both WHATWG and W3C should maintain a single definitive HTML5 specification, that is a feature-for-feature match between groups b) For the longer-term WHATWG work, including sections that were once part of the HTML5 spec but were split off into separate specs (Canvas API) or removed (datagrid), there is another Master Spec that includes whatever the editor feels is needed in that spec, so long as it doesn't conflict with the HTML5 or related specs c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. Maybe the answer is to have a spokesperson or liaison role, someone respected in the WHATWG community with a reputation for reasonable neutrality? Both Hixie and Maciej have conflicts of interest, as editor and W3C co-chair respectively. Maybe Håkon or David, since they were instrumental in forming WHATWG in the first place? With all respect for both suggested persons (I would vote for one of them too), I believe neutrality is a term we shouldn't use to describe willingness of a role person to help achieving the objective of both W3C and WHATWG and that should be what the users expect: one standard body pushing one specification. (Sorry I won't be very responsive on this list, I'm actually on vacation and only have sporadic net access.) Regards- -Doug Hope
Re: [whatwg] Allowing in attribute values
On 25.06.2010 15:52, Skrol29 wrote: ... Allowing in attributes is a small gift of tolerance for webmasters, but implies major complications for the industry. Disallowing falls within the purpose of simplifying the grammar, like when XHTML disallowed the uppercase for element and attribute names, like when XHTML disallowed attribute values without quotes ... XHTML uses XML. XML allows . I really don't see what needs to be discussed. Do you want to change XML? Best regards, Julian
Re: [whatwg] Allowing in attribute values
On 6/25/10 9:52 AM, Skrol29 wrote: In another hand, in the industry the tolerance to the spec is often very low in order build simple, fast and robust processes. They are also many parsing purposes that care about some elements and don't care about others. As I see it, there are two possibilities here: 1) You have control over your input. If so, you can impose whatever restrictions on it will make your parsing easier, above and beyond what the spec defines. 2) You do not have control over your input. If so, you need to be able to parse things correctly which for HTML in practice ends up meaning like browsers do it. Am I missing something? It seems like what you want here is for browsers to parse as they do now, but a particular subset of browser-accepted syntax to be enshrined so that when defining your restrictions over content you control you can just say follow the spec instead of follow the spec and don't put '' in attribute values, right? -Boris
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:13 AM, Doug Schepers d...@schepers.cc wrote: Hi, WHATWG folks- As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. I'm not trying to be political about this, but since W3C and WHATWG are meant to be collaborating, there has to be a certain amount of of flexibility from both sides, for the good of the standard itself, and for readers of the spec. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. Options 1 and 2 are obviously both unreasonable. I'm not sure why. The two-group development that HTML has is very weird, and most of the conflict wouldn't exist if one group or another did everything. Option 3 results in the problem we have now (though having an explanation for each difference would be an improvement; I don't know of any such wording now). Look in the introduction of the WHATWG spec. It lists every difference between it and the W3C spec, along with a short explanation as to why the difference exists. This leaves option 4. W3C has a relatively clear method for resolving conflicts: first, the group tries to settle the issue on the merit of the technical arguments; failing that, the group may hold a poll (with each individual or organization given a single voice); if there is no consensus, the chairs of the group can make a ruling based on the reasoning at hand; if there are still Formal Objections to the results of that poll, the group can escalate the issue up to the Domain Lead, and ultimately all the way up to the W3C Director (who is normally Tim Berners-Lee). Obviously, the strong preference is not to get to the poll stage at all. I don't know of any W3C method for dealing with conflicts between different standards bodies, like W3C and WHATWG, so I think we're in the air here; W3C obviously has no authority over decisions made in WHATWG, but we need to find a way to resolve these conflicts. As I understand it, the editor seems to have final decision-making power in WHATWG, and I don't know of any process for appealing those decisions (assuming you would want to); for the purposes of arbitration between groups, how can we proceed? The WHATWG has a steering council made up of browser developers. Officially, they can override Ian's decisions or make him step down as editor. They've never had to exercise this power yet, though. For the record, here's my suggestion: a) Both WHATWG and W3C should maintain a single definitive HTML5 specification, that is a feature-for-feature match between groups This begs the question. At the moment, the WHATWG version is a pure superset of the W3C version. This may not be the case in the future. Should the two-group spec be the intersection of the two individual specs? The union? Something else? Reconciling the two specs is *precisely* what the problem here is that we're trying to solve. b) For the longer-term WHATWG work, including sections that were once part of the HTML5 spec but were split off into separate specs (Canvas API) or removed (datagrid), there is another Master Spec that includes whatever the editor feels is needed in that spec, so long as it doesn't conflict with the HTML5 or related specs Yeah, that's the Complete spec here at WHATWG - http://www.whatwg.org/specs/web-apps/current-work/complete/. c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. Again, begging the question. Where there have been conflicts, the WHATWG has decided definitely how to resolve them for itself - that is, Ian decided, and the steering committee didn't disagree sufficiently to override him. What else can be done here? Maybe the
Re: [whatwg] Technical Parity with W3C HTML Spec
On 25.06.2010 18:11, Tab Atkins Jr. wrote: ... Alternately, we could continue work solely in the HTMLWG. This would not be possible unless we change the way the HTMLWG works somewhat, though. There's a *reason* that almost no technical discussion happens within the HTMLWG. If we were to pursue this option and ... So what's the reason for that? Any opinion? Don't say too much process discussions, because those are *caused* by the two groups not getting along too well. Best regards, Julian
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 9:23 AM, Julian Reschke julian.resc...@gmx.de wrote: On 25.06.2010 18:11, Tab Atkins Jr. wrote: ... Alternately, we could continue work solely in the HTMLWG. This would not be possible unless we change the way the HTMLWG works somewhat, though. There's a *reason* that almost no technical discussion happens within the HTMLWG. If we were to pursue this option and ... So what's the reason for that? Any opinion? Don't say too much process discussions, because those are *caused* by the two groups not getting along too well. To sum it up simply: too much process discussion. ^_^ Less glibly: Most W3C groups have one editor (or a very small number of editors, but without loss of generality I'll just presume a single editor) for each spec. That one editor processes all feedback, makes all decisions, and writes all text. There are then a relatively small number of other WG members who vet those decisions, and if enough of them disagree, they can override them. I have direct experience with the CSSWG working this way, and my limited experience with other groups suggests that my generalization is correct for them as well. The WHATWG is also structured in this way. Ian processes all feedback, makes all decisions, and writes all text. The steering committee, a relatively small group of interested browser vendors, vets his decisions and can override him if enough of them agree. The HTMLWG is different. It wanted to match the WHATWG's commitment to openness and community participation, but it went about it wrong. In most public W3C groups and the WHATWG, the community (that is, everyone who's not an editor or otherwise an official member of the group) can participate by sending comments, suggestions, and bug reports. The editor is still the one in charge of making decisions. In the HTMLWG, the community is part of the decision-making process. They can not only file bugs against things they think are wrong, they can actually attempt to override the editor themselves. Further, the way the decision process is structured, it appears to be *actually* consensus-driven, not technical-merit driven. This produces all the traditional downsides of design-by-committee development. Every disagreement produces something that satisfies no one, and most of them are far too minor to justify the time spent on them in the first place. There are additional confounding factors that make the design-by-committee process of the HTMLWG even worse. For one, the chairs of the group do not seem willing to actually moderate the group and remove poisonous personalities. Anyone who has successfully handled public input knows that poisonous people aren't worth whatever useful technical feedback they might provide, as they depress everyone else's desire to contribute and tend to drive away the most useful members of the community. I know Tantek could chime in on this, for example, as he has significant experience moderating the Microformats community. In addition to the effects on the community itself, these poisonous personalities have the ability to manipulate the decision-making process itself due to the way the HTMLWG operates. For two, the WHATWG benefits from being driven by a group of people with similar goals and overall ideas for what the web should be, and who have a direct interest in ensuring the group makes good decisions, as they have to implement them. While one must always be on guard against groupthink and should treasure dissenting voices for their critical viewpoint, general agreement amongst the decision-making group allows things to proceed fairly smoothly and productively. Since the dissolution of the XHTML2WG, though, the HTMLWG has gained a number of vocal members who have fundamental disagreements with the direction that HTML is taking the web. Due to the way HTMLWG process works, each shard of thought has equal input into the decisions of the group, we run into too many cooks issues, where we lose an overarching vision binding the document together and end up with a patchwork of decisions and rationalizations. ~TJ
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 9:23 AM, Julian Reschke julian.resc...@gmx.de wrote: On 25.06.2010 18:11, Tab Atkins Jr. wrote: ... Alternately, we could continue work solely in the HTMLWG. This would not be possible unless we change the way the HTMLWG works somewhat, though. There's a *reason* that almost no technical discussion happens within the HTMLWG. If we were to pursue this option and ... So what's the reason for that? Any opinion? Don't say too much process discussions, because those are *caused* by the two groups not getting along too well. It's a negative spiral. The more epic threads about having epic threads, the more technically oriented folks tune out, the less technical discussion takes place, the more noise fills the room. To try to counter this downward spiral, I've been trying to direct my technical feedback to public-html, with mixed success. I think what's actually going on is that the spec is (for most intents and purposes) done. There isn't that much more technically to discuss, which is why this list is much quieter now than it was a year ago. The W3C HTML WG still has a lot of angst that it needs to work out, but that's much more smoke than fire. IMHO, it's about time we shipped HTML5 and focused on HTML-next. Adam
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, 25 Jun 2010 06:13:13 -0400, Doug Schepers d...@schepers.cc wrote: Hi, WHATWG folks- As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. I'm not trying to be political about this, but since W3C and WHATWG are meant to be collaborating, there has to be a certain amount of of flexibility from both sides, for the good of the standard itself, and for readers of the spec. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG That sounds great to me. I'm fine with the whatwg process, Ian's decisions based on our feedback and the whatwg version of the spec (it's the one I reference and give feedback on). I don't even look at the w3c version, so I don't know how much different it is or why it's different or even how it could be better than the whatwg spec. (Not only that, but the spec isn't easy enough for me to find at http://www.w3.org/ like it is on whatwg.org, but that's a minor front page navigation issue at w3c.org). I do follow public-html, but my message list is full of a bunch of messages with subjects like isssue N or change proposal n or bug n - part of the subject ..., which don't make any sense until I drift off to the bts and have disconnected discussions. At some point, almost all technical discussions were shifted to a bug tracking system, which is just too annoying, so I don't know what's going on anymore and I don't see any technical discussions in the list like there used to be. Yes, the spec is more mature now, but judging by all the issue n messages etc. it looks like lots of technical discussion is happening elsewhere, away from the list. Here on whatwg, things happen on the list and I can tell what's going on better and therefore trust the whatwg.org spec way more. All public-html is lately is working/arguing on process, procedure and what looks like (to me at least), bullying the editor. Before the beginning of last year, things were much more whatwg-like on public-html, which was awesome. In addition, my understanding of the W3C helping out with HTML5 was to make it seem more official to the general public and provide some patent stuff to ease adoption. I still consider the whatwg the authority here, if there has to be one. But, it's not like public-html is secondary or anything. Ian takes all feedback into account. So, my stance is that the whatwg has a better process and therefore a potential for a better version of the spec, and I think the w3c version should be as good. I also don't have a problem with the whatwg complete version having some future things the w3c version supposedly doesn't and I'm not fond of the nitpicking going on about the text describing the differences between the specs. -- Michael
Re: [whatwg] Technical Parity with W3C HTML Spec
On 25.06.2010 20:33, Michael A. Puls II wrote: ... I do follow public-html, but my message list is full of a bunch of messages with subjects like isssue N or change proposal n or bug n - part of the subject ..., which don't make any sense until I drift off to the bts and have disconnected discussions. At some point, almost all technical discussions were shifted to a bug tracking system, which is just too annoying, so I don't know what's going on anymore and I don't see any technical discussions in the list like there used to be. Yes, the spec is more mature now, but judging by all the issue n messages etc. it looks like lots of technical discussion is happening elsewhere, away from the list. ... For the record: that discussions moved from the mailing list to Bugzilla, and the Issue Tracker is indeed a problem. I'd prefer if we could have these discussions back on the mailing list. Best regards, Julian
Re: [whatwg] Technical Parity with W3C HTML Spec
I would like to encourage peopel participating in this thread to focus exclusively on coordination with the W3C. In particular, this is not the right forum to discuss the W3C HTML WG public-html mailing list, the W3C HTML WG's decision policies, or other W3C matters. We don't have the authority in this mailing list to do anything about the W3C's internal matters, so discussing them here is not productive. What we _can_ make progress on is to find a way to coordinate with the W3C and resolve any differences of opinion between the two groups. On Fri, 25 Jun 2010, Doug Schepers wrote: As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. The WHATWG doesn't actually work on HTML5, it works on an unversioned specification for HTML that is to be continually maintained. HTML.next, if you will (though the spec's title is still HTML5 by request from advocates -- apparently the word HTML5 is a good buzzword at the moment and it helps advocates if the spec has that name in the title). The differences between this draft and the W3C HTML5 draft all fall into two categories: - editorial differences with no normative impact (e.g. different style sheet, different introduction section, different license, additional examples in the WHATWG version, more implementation advice in the WHATWG version). - sections that are absent from the W3C version (e.g. device). These are, by definition, part of HTML.next rather than HTML5. Could you clarify which of the two categories of differences, and within those categories, which specific differences, you think are problematic? In my opinion, the specific technical details of any given feature [...] is of lesser importance than there being a single definitive version that is consistent between both organizations. The goal is to get interoperability between implementations while advancing the Web. It doesn't really matter how many versions of the spec exist (it could be zero, one, two, ten), so long as we get interop. The WHATWG itself has four versions of the spec: HTML, HTML as a multipage document, complete, and complete as a multipage document. In the past we've also had other versions, e.g. HTML5 (as distinct from the HTML spec which has the newer features), Web Forms 2, etc. 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each Option 3 results in the problem we have now (though having an explanation for each difference would be an improvement; I don't know of any such wording now). The differences are detailed in the WHATWG spec's introduction. To have the changes listed in the W3C spec's introduction I encourage you to approach the W3C HTML WG. As I understand it, the editor seems to have final decision-making power in WHATWG, and I don't know of any process for appealing those decisions (assuming you would want to) Others have explained the process, but just for the record, it is indeed as they described: much as in the HTML WG, the editor makes the first proposals, and if the editor is making bad decisions he can be overridden or replaced by the charter members. for the purposes of arbitration between groups, how can we proceed? For the record, here's my suggestion: a) Both WHATWG and W3C should maintain a single definitive HTML5 specification, that is a feature-for-feature match between groups We had this for a while (a year or so, IIRC), but it turned out to be a waste of time: nobody read the WHATWG HTML5 version, they all read the WHATWG HTML version with the new features. Maintaining a version of the W3C subset of the HTML specification on the WHATWG site just for the purpose of saying we have a version with identical text seems like it would be exclusively work for politics' sake, which isn't very interesting. Having said that, the WHATWG spec is licensed under a very liberal license, so if anyone wants to maintain such a version of the spec they are welcome to do so. b) For the longer-term WHATWG work, including sections that were once part of the HTML5 spec but were split off into separate specs (Canvas API) or removed (datagrid), there is another Master Spec that includes whatever the editor feels is needed in that spec, so long as it doesn't conflict with the HTML5 or related specs That's the status quo. c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. Maybe the answer is to have a spokesperson
Re: [whatwg] Allowing in attribute values
On 06/25/2010 11:50 AM, Boris Zbarsky wrote: It seems like what you want here is for browsers to parse as they do now, but a particular subset of browser-accepted syntax to be enshrined so that when defining your restrictions over content you control you can just say follow the spec instead of follow the spec and don't put '' in attribute values, right? That's more or less how I feel. The spec places requirements on how user agents, data mining tools, and conformance checkers must handle non-conforming input, but there are many other things in the world that process HTML. In other applications, it may be acceptable to have undefined behavior on non-conforming input, like in ISO C. HTML5 has a very clear specification of conformance, and a validator is widely available. If I build a tool that guarantees correct behavior only on conforming inputs, then users can easily check their documents for conformance before using my tool. If my tool has additional restrictions, then I need to write my own validator, and answer a lot of questions. I was inspired to suggest this restriction after using mod_layout for Apache, which inserts a banner at the top of a page. It works by doing a wildcard search for body*. There are a number of obvious ways to break this [1]; one of them is by having in an attribute value. I'm sure there are many thousands of such programs around the world. It sounds like most experts here would prefer to allow in attribute values in conforming documents, and that's fine. I don't fully understand the advantage, but I won't argue against consensus. --Ben [1] A javascript line like widthbodywidth heightbodyheight would also break it, as would an appropriately constructed comment. It might be possible to construct a regexp for this that functions correctly on all conformant HTML5 documents. Such a regexp would be considerably simpler if were disallowed in attribute values. signature.asc Description: OpenPGP digital signature
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: Maybe the answer is to have a spokesperson or liaison role, someone respected in the WHATWG community with a reputation for reasonable neutrality? Both Hixie and Maciej have conflicts of interest, as editor and W3C co-chair respectively. Maybe Hakon or David, since they were instrumental in forming WHATWG in the first place? Maybe an alternative would be: Where there are technical or political conflicts, W3C should decide how to resolve those internally, and how to represent the W3C point of view in the WHATWG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with WHATWG. I don't have a good answer here, because I think it's up to the W3C to decide their own processes, but I hope we agree that we need improvements to how we liaison. First can we work on improving communications so that we can work on differences before they become conflicts? We recently had a change proposal made by Lachlan: http://lists.w3.org/Archives/Public/public-html/2010Apr/1107.html Absolutely nobody in the W3C WG indicated any issues with this proposal: http://lists.w3.org/Archives/Public/public-html/2010Jun/0562.html Recently you said that you value convergence: http://lists.w3.org/Archives/Public/public-html/2010Jun/0525.html Yet, when you made the change, you did it in a way that made the WHATWG version not a proper superset. You also characterized the change in a way that I don't believe is accurate: http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/004270.html I'm having trouble reconciling all of the above. You clearly continue to be a member of the W3C Working Group. You state that you value convergence. You were given ample opportunity to state an objection. And you clearly have an issue with Lanlan's suggestion. How can we improve communications to prevent misunderstandings such as this one from occurring in the future? What's the best way to address the mischaracterization of the difference as it is currently described in the WHATWG draft? Most importantly, how can we deescalate tensions rather that continuing in this manner? - Sam Ruby
Re: [whatwg] Allowing in attribute values
One advantage is almost the same as your footnote: JavaScript source is permitted in the values of many attributes, and can certainly contain the operator. On Jun 25, 2010 12:34 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 06/25/2010 11:50 AM, Boris Zbarsky wrote: It seems like what you want here is for browsers to parse as they do now, but a particular subset of browser-accepted syntax to be enshrined so that when defining your restrictions over content you control you can just say follow the spec instead of follow the spec and don't put '' in attribute values, right? That's more or less how I feel. The spec places requirements on how user agents, data mining tools, and conformance checkers must handle non-conforming input, but there are many other things in the world that process HTML. In other applications, it may be acceptable to have undefined behavior on non-conforming input, like in ISO C. HTML5 has a very clear specification of conformance, and a validator is widely available. If I build a tool that guarantees correct behavior only on conforming inputs, then users can easily check their documents for conformance before using my tool. If my tool has additional restrictions, then I need to write my own validator, and answer a lot of questions. I was inspired to suggest this restriction after using mod_layout for Apache, which inserts a banner at the top of a page. It works by doing a wildcard search for body*. There are a number of obvious ways to break this [1]; one of them is by having in an attribute value. I'm sure there are many thousands of such programs around the world. It sounds like most experts here would prefer to allow in attribute values in conforming documents, and that's fine. I don't fully understand the advantage, but I won't argue against consensus. --Ben [1] A javascript line like widthbodywidth heightbodyheight would also break it, as would an appropriately constructed comment. It might be possible to construct a regexp for this that functions correctly on all conformant HTML5 documents. Such a regexp would be considerably simpler if were disallowed in attribute values.
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 4:03 PM, Sam Ruby ru...@intertwingly.net wrote: Yet, when you made the change, you did it in a way that made the WHATWG version not a proper superset. On closer reading, it turns out that I was incorrect here. It still, however, remains a divergence, it still is mis-characterized, and I am still can't reconcile your statement concerning valuing convergence with this action. - Sam Ruby
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, 25 Jun 2010, Sam Ruby wrote: We recently had a change proposal made by Lachlan: http://lists.w3.org/Archives/Public/public-html/2010Apr/1107.html Absolutely nobody in the W3C WG indicated any issues with this proposal: http://lists.w3.org/Archives/Public/public-html/2010Jun/0562.html Recently you said that you value convergence: http://lists.w3.org/Archives/Public/public-html/2010Jun/0525.html Again, I would like to request that participants on this thread avoid discussing W3C process and discussions on this list. This list is for technical discussion of Web technologies and, where absolutely necessary, issues of immediate concern to the WHATWG community. Discussing the ins and outs of W3C mailing lists is not appropriate on this list, as we do not have the authority to effect change at the W3C on this list. You also characterized the change in a way that I don't believe is accurate: http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/004270.html What's the best way to address the mischaracterization of the difference as it is currently described in the WHATWG draft? In what sense is the difference mischaracterised? If I misunderstood why the example was considered inappropriate by the HTML working group, please let me know, on the HTML working group mailing list or privately, so that I can correct the mistake. On Fri, 25 Jun 2010, Sam Ruby wrote: On closer reading, it turns out that I was incorrect here. It still, however, remains a divergence, it still is mis-characterized, and I am still can't reconcile your statement concerning valuing convergence with this action. I value technical merit even higher than convergence. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=location proposals
On Thu, Jun 24, 2010 at 8:55 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think it's quite a fringe case. What about things that are more used: * type=number - a browser could aid input with some sort of spinner type=number has been in the spec for years.
Re: [whatwg] input type=location proposals
On Thu, Jun 24, 2010 at 5:55 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think it's quite a fringe case. What about things that are more used: type=number - a browser could aid input with some sort of spinner type=price - a browser could use the locale to select a monetary format, or at least display the amount in the locale format specified by the document itself I think that most users are able to input a number or price without much difficulty. Asking a user to input their latitude and longitude is a great way to bounce them entirely, since none of them are going to have any idea how to find it out. Mike
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 9:11 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The WHATWG has a steering council made up of browser developers. Officially, they can override Ian's decisions or make him step down as editor. They've never had to exercise this power yet, though. Could you elaborate on this? That *anyone* can override Ian's decisions or make him step down as editor is news to me, and I suspect that the organization I represent is counted among the developers you list. Who is on the steering council of browser developers? How does one appeal a decision to them, and how do they determine what to do (unanimity, majority vote, rotating single-person veto, five-card draw)? Mike
Re: [whatwg] input type=location proposals
On Fri, 2010-06-25 at 17:09 -0400, Aryeh Gregor wrote: On Thu, Jun 24, 2010 at 8:55 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: I think it's quite a fringe case. What about things that are more used: * type=number - a browser could aid input with some sort of spinner type=number has been in the spec for years. Do you have a link to this to verify? Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson i...@hixie.ch wrote: I value technical merit even higher than convergence. How is technical merit assessed? Removing Theora from the specification, for example, seems like it was for political rather than technical reasons, if I understand how you use the terms. How can one learn of the technical motivations of decisions such as the change to require ImageData for Canvas, or participate in their evaluation prior to them gaining the incumbent's advantage of being present in the specification text? Mike
Re: [whatwg] input type=location proposals
On Fri, Jun 25, 2010 at 2:45 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-25 at 17:09 -0400, Aryeh Gregor wrote: type=number has been in the spec for years. Do you have a link to this to verify? http://dev.w3.org/html5/markup/input.number.html is the fourth hit for type=number in Google for me, but your search engine results results may vary. It's also under the input element, type values, number part of the WHATWG's HTML5 draft, a document with which you may have some familiarity. Mike
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 2:45 PM, Mike Shaver mike.sha...@gmail.com wrote: On Fri, Jun 25, 2010 at 9:11 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: The WHATWG has a steering council made up of browser developers. Officially, they can override Ian's decisions or make him step down as editor. They've never had to exercise this power yet, though. Could you elaborate on this? That *anyone* can override Ian's decisions or make him step down as editor is news to me, and I suspect that the organization I represent is counted among the developers you list. Who is on the steering council of browser developers? How does one appeal a decision to them, and how do they determine what to do (unanimity, majority vote, rotating single-person veto, five-card draw)? Bottom of the charter: http://www.whatwg.org/charter I believe the decision process is knife fight to first blood. ~TJ
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Bottom of the charter: http://www.whatwg.org/charter I believe the decision process is knife fight to first blood. Editors should reflect the consensus opinion of the working group when writing their specifications, but it is the document editor's responsibility to break deadlocks when the working group cannot come to an agreement on an issue doesn't sound like the working group can override anything, and only goes as far as should. It turns out that two of the Members are in the same building as me, though, so I'll go see what they think the model is. I think they may be surprised to discover that they could have overridden Ian on anything! Mike
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 2:48 PM, Mike Shaver mike.sha...@gmail.com wrote: On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson i...@hixie.ch wrote: I value technical merit even higher than convergence. How is technical merit assessed? Removing Theora from the specification, for example, seems like it was for political rather than technical reasons, if I understand how you use the terms. Not quite. The technical motivation was that there was no clear path to that requirement getting interop. The reasons for that were political/legal, but their effect was technical. How can one learn of the technical motivations of decisions such as the change to require ImageData for Canvas, On the WHATWG wiki a Rationale page is being assembled by a volunteer (don't know their name, but they go by 'variable' in #whatwg) to document the reasoning behind various decisions that come up in questions. Beyond that, mailing-list diving. or participate in their evaluation prior to them gaining the incumbent's advantage of being present in the specification text? Depends on the feature and where it originated. WHATWG operates on commit-then-review, so as soon as Hixie hits something in his email dive and thinks it's sufficiently good, he writes it up. There can sometimes be a significant delay between something being proposed and this happening, though, so within that timespan things can be discussed without the incumbent advantage you talk about. That advantage isn't worth much, though, at least not until somebody starts shipping something. ~TJ
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:06 PM, Mike Shaver mike.sha...@gmail.com wrote: On Fri, Jun 25, 2010 at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Bottom of the charter: http://www.whatwg.org/charter I believe the decision process is knife fight to first blood. Editors should reflect the consensus opinion of the working group when writing their specifications, but it is the document editor's responsibility to break deadlocks when the working group cannot come to an agreement on an issue doesn't sound like the working group can override anything, and only goes as far as should. It turns out that two of the Members are in the same building as me, though, so I'll go see what they think the model is. I think they may be surprised to discover that they could have overridden Ian on anything! I wasn't precise in my language - don't read too much into my exact wording. ~TJ
Re: [whatwg] input type=location proposals
On Thu, Jun 24, 2010 at 1:45 PM, Jeremy Keith jer...@adactio.com wrote: Michelango wrote: ... 3. Maps data are often non-free and non-open, reliable maps data are always non-free and non-open. The second clause of point 3 is demonstrably false. Said demonstration is http://www.openstreetmap.org/ which in many cases (e.g. the town I live in) has better, more up-to-date reliable data than its non-free, non-open counterparts. See also: Wikipedia, blogs, and much of the World Wide Web The Wikimedia California Chapter initial funding proposal has some interactive map work in it, if people are interested. I've been trying to raise money for it but it's been going pretty slow. Anyone who cares can find it on line. It needs $150,000 plus management salary to get going as a viable concern. The point here is that even free things take time and/or money to get right and and get open right. Locations should have security considerations similar to contacts. It seems reasonable to assume that people are going to want to download them more than upload them, unless they have a very tightly controlled assumption about of the list of recipients, and some assurance that their assumptions are correct. Also locations share a lot in common with the user's contacts, of course, including the fact that at least one is associated with the user. (Telepresence is an interesting example of a situation where a person may be associated with multiple locations, but those are so rare that example seems contrived.) Regards, James Salsman
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:07 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: How can one learn of the technical motivations of decisions such as the change to require ImageData for Canvas, On the WHATWG wiki a Rationale page is being assembled by a volunteer (don't know their name, but they go by 'variable' in #whatwg) to document the reasoning behind various decisions that come up in questions. Beyond that, mailing-list diving. In the case of the ImageData change, I can't find any proposal made to the list prior to the spec being altered, but I will dive anew. There can sometimes be a significant delay between something being proposed and this happening, though, so within that timespan things can be discussed without the incumbent advantage you talk about. That only works if changes are proposed via the mailing list, and it relies on meaningful delay. If my recollection of the original additions of SQL databases and web workers is correct, there was very little such delay, certainly relative to the scale of content. Are you describing how you think the WHATWG has committed to work, how it does work, or how you think it should work? Mike
[whatwg] WHATWG decision process (Was: Technical Parity with W3C HTML Spec)
On Fri, 25 Jun 2010, Mike Shaver wrote: On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson i...@hixie.ch wrote: I value technical merit even higher than convergence. How is technical merit assessed? I read all the e-mails (and other feedback) sent on a topic, and try to take everything into account and determine the best course of action. Removing Theora from the specification, for example, seems like it was for political rather than technical reasons, if I understand how you use the terms. It was removed because some significant implementors (in this case mainly Apple) did not want to implement it, the same reason as the SQL Database section was removed (in that particular case, mainly Mozilla). How can one learn of the technical motivations of decisions such as the change to require ImageData for Canvas, or participate in their evaluation prior to them gaining the incumbent's advantage of being present in the specification text? Take part in this mailing list. :-) I should note that for various reasons I haven't been able to respond to feedback in the past few months (since about March), so I'm somewhat behind in dealing with input from the WHATWG mailing list. I am now ramping back up and should resume responding to feedback shortly. (I'm working on the timed track stuff for video at the moment, a topic on which there are many e-mails that I must read and evaluate carefully.) You can see the current progress on feedback here (give it a few moments to load, there's a lot of data): http://www.whatwg.org/issues/data.html The list of current pending e-mails is here: http://www.whatwg.org/issues/ Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I wasn't precise in my language - don't read too much into my exact wording. No, certainly; I'm much more interested in the spirit here than the wording, since it doesn't match my experience or understanding. I'll take on my education burden myself, though! Mike
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 6:13 AM, Doug Schepers d...@schepers.cc wrote: As you are probably aware, some differences have arisen between the W3C draft of the HTML5 spec and the larger WHATWG version. In my opinion, the specific technical details of any given feature (which, let's be fair, are often more-or-less arbitrary) is of lesser importance than there being a single definitive version that is consistent between both organizations. The whole point of an open technical standard is to promote interoperability between implementations, and having conflicting or ambiguous specs will not result in that goal. The specs do not conflict. The WHATWG spec is a superset of the W3C one as far as all requirements go. The parts that are in both differ only in non-normative things like examples and implementers may do X. There are a few possible ways to handle this: 1) W3C could match the WHATWG version in all details, with all decisions made by WHATWG 2) WHATWG could match the W3C version in all details, with all decisions made by W3C 3) WHATWG and W3C could maintain different specs with different details, and list the differences with an explanation for each 4) WHATWG and W3C could adopt decisions made in each group, and where there is conflict, decide upon some method of settling the difference of opinion. Options 1 and 2 are obviously both unreasonable. I think those are the only two reasonable options. One body should make the decisions. It would be totally fine if that were the HTMLWG, as long as the current insanely bureaucratic structure were scrapped and replaced with a typical one, where the editor makes most decisions and can be overruled only by a few members (who would be implementers in our case). But Ian doesn't want us discussing that here, so I won't elaborate further here. c) Where there are technical or political conflicts, WHATWG should decide how to resolve those internally, and how to represent the WHATWG point of view in the W3C HTML WG. I would expect that people differ, so I would expect those different opinions to be represented in liaisons with W3C. I don't have a good answer here, because I think it's up to the WHATWG to decide their own processes, but I hope we agree that we need improvements to how we liaison. I think the problem is that the groups are structured so differently, particularly that the WHATWG is controlled entirely by implementers while the HTMLWG gives a great deal of say to anyone who wants to sign up and voice an opinion. Communication isn't the problem. On Fri, Jun 25, 2010 at 6:06 PM, Mike Shaver mike.sha...@gmail.com wrote: Editors should reflect the consensus opinion of the working group when writing their specifications, but it is the document editor's responsibility to break deadlocks when the working group cannot come to an agreement on an issue doesn't sound like the working group can override anything, and only goes as far as should. It turns out that two of the Members are in the same building as me, though, so I'll go see what they think the model is. I think they may be surprised to discover that they could have overridden Ian on anything! I'm pretty sure they won't be. Any significant implementer has always had veto power over the spec. For example, Mozilla vetoed Web Databases, and Apple vetoed Theora requirements, by just saying they wouldn't implement them. Ian has always made it clear that he'll spec whatever the implementers are happy with. For instance, a few days ago in #whatwg (lots of lines deleted for readability): [100622 17:18:08] ap Hixie: we shipped something that matched the draft spec, is there a good reason for it to change under us? this seems like a completely arbitrary change [100622 17:19:58] Hixie but the reason for this change was a discussion on public-webapps which had people from webkit, mozilla, and opera and which decided that we should consistently use lowercase attribute names so as to not make authors go crazy trying to work out what was lowercase and what was uppercase [100622 17:25:06] Hixie I was on the side of going all uppercase, but that had a higher cost than going all lowercase except Document [100622 17:27:35] Hixie ap: if you want to change the decision, convince opera and mozilla to go the other way. [100622 17:30:32] Hixie ap: i'm not the one you have to convince [100622 17:32:07] ap Hixie: who should I convince? [100622 17:32:22] Hixie reopen the thread on public-webapps and get the participants to agree to implement the opposite This is common. Since Hixie never knowingly specs anything that implementers aren't all willing to implement, and since basically everyone else on the steering committee is an implementer, they've never had to explicitly cite their authority as the steering committee to overrule him.
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: While I agree that it is helpful for us to cooperate, I should point out that the WHATWG was never formally approached by the W3C about this With whom (and where?) would such a formal discussion take place? I would prefer that such a discussion happen on a publicly archived mailing list. - Sam Ruby
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor simetrical+...@gmail.com wrote: I'm pretty sure they won't be. Any significant implementer has always had veto power over the spec. I fear that simply refusing to implement is indeed the WHATWG's equivalent of how Tab described FO-threats in the W3C environment: a much more efficient way to influence the direction of the document than sharing technical reasoning during the design of a capability. For example, Mozilla vetoed Web Databases, and Apple vetoed Theora requirements, by just saying they wouldn't implement them. Web Databases was removed from the specification before we were even certain within Mozilla that we wouldn't implement them, so I don't think that's quite right. It's true that we don't think it's a good technology direction for the web, and that we didn't believe it belonged in HTML5 proper, but I don't think that's quite the same thing. (To the extent that Mozilla has unanimity on such things in the first place.) Ian has always made it clear that he'll spec whatever the implementers are happy with. That is not my recollection of what happened with offline, for what it's worth. Mozilla and Google had a relatively small set of deviations between approaches (ours developed on the whatwg list and Google's developed behind closed doors prior to the Gears announcement) and Ian specified an entirely different model, over the objections of both Mozilla and Google. I welcome corrections to the timeline and details here, but apparently the behaviour that we *should* have exhibited was simply refusing to implement, rather than changing late in our development cycle to the new specification that Ian constructed, for which there was no implementation or deployment experience. Is that really how we want the group to operate? It seems to reward silent refusal with greater influence than transparent reasoning. We saw similarly (IMO) offensive behaviour when IBM voted against the ES5 specification at ECMA General Assembly, simply because their pet feature hadn't been included (though there was ample technical justification for its omission, both in closed-door membership meetings and in the public list). Happily, in that case it simply made IBM look manipulative and petty, and didn't prevent the specification from reaching ratification. If I were to be in charge of an organization building a platform that competed with the web, I would certainly consider it worth my time to implement a browser and then refuse to implement pieces of the specification that competed with my line of business. Certainly if I were running an organization that made a browser and had a line of business threatened by a piece of the specification, it would be very clear how to mitigate that threat, since no specifics need be provided in support of a refusal veto. Mike
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, 25 Jun 2010, Sam Ruby wrote: On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: While I agree that it is helpful for us to cooperate, I should point out that the WHATWG was never formally approached by the W3C about this With whom (and where?) would such a formal discussion take place? I would prefer that such a discussion happen on a publicly archived mailing list. Best thing to do is probably to e-mail the people listed in the charter as being the members (e-mail addresses below), and cc the www-arch...@w3.org mailing list for archival purposes. ann...@opera.com, bren...@mozilla.com, dba...@mozilla.com, hy...@apple.com, dean.edwa...@gmail.com, howc...@opera.com, j...@mozilla.com, m...@apple.com, i...@hixie.ch HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver mike.sha...@gmail.com wrote: On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor simetrical+...@gmail.com wrote: I'm pretty sure they won't be. Any significant implementer has always had veto power over the spec. I fear that simply refusing to implement is indeed the WHATWG's equivalent of how Tab described FO-threats in the W3C environment: a much more efficient way to influence the direction of the document than sharing technical reasoning during the design of a capability. It's possible to use it like that, sure. It makes you look like a jackass, but it would work. However, its efficacy isn't something that the WHATWG or anyone else can change - if someone with significant market share refuses to implement something, *web authors can't use it*. End of story. No amount of moaning or complaining about the unfairness of gaming-possibility will change that, because it's simply how reality works. There's no sense speccing something that can't be used, because a significant chunk of an author's visitors won't ever have it. Better to spend time speccing things that everyone *will* implement. Is that really how we want the group to operate? It seems to reward silent refusal with greater influence than transparent reasoning. We saw similarly (IMO) offensive behaviour when IBM voted against the ES5 specification at ECMA General Assembly, simply because their pet feature hadn't been included (though there was ample technical justification for its omission, both in closed-door membership meetings and in the public list). Happily, in that case it simply made IBM look manipulative and petty, and didn't prevent the specification from reaching ratification. Like I said above, it's not our choice. Removing something from the spec when a significant browser refuses to implement it is simply making the spec match reality, because authors won't be able to use that feature. If I were to be in charge of an organization building a platform that competed with the web, I would certainly consider it worth my time to implement a browser and then refuse to implement pieces of the specification that competed with my line of business. Certainly if I were running an organization that made a browser and had a line of business threatened by a piece of the specification, it would be very clear how to mitigate that threat, since no specifics need be provided in support of a refusal veto. Note that has a browser isn't enough to give a company veto power. You need has a browser with sufficient market share (where sufficient is somewhere around 1%, based on previous remarks from Ian). This is due to the reasons stated above - the veto isn't a power that we grant browsers, it's a right that they earn on their own by virtue of having users. ~TJ
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, 2010-06-25 at 16:11 -0700, Tab Atkins Jr. wrote: On Fri, Jun 25, 2010 at 4:00 PM, Mike Shaver mike.sha...@gmail.com wrote: On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor simetrical+...@gmail.com wrote: I'm pretty sure they won't be. Any significant implementer has always had veto power over the spec. I fear that simply refusing to implement is indeed the WHATWG's equivalent of how Tab described FO-threats in the W3C environment: a much more efficient way to influence the direction of the document than sharing technical reasoning during the design of a capability. It's possible to use it like that, sure. It makes you look like a jackass, but it would work. However, its efficacy isn't something that the WHATWG or anyone else can change - if someone with significant market share refuses to implement something, *web authors can't use it*. End of story. No amount of moaning or complaining about the unfairness of gaming-possibility will change that, because it's simply how reality works. There's no sense speccing something that can't be used, because a significant chunk of an author's visitors won't ever have it. Better to spend time speccing things that everyone *will* implement. Is that really how we want the group to operate? It seems to reward silent refusal with greater influence than transparent reasoning. We saw similarly (IMO) offensive behaviour when IBM voted against the ES5 specification at ECMA General Assembly, simply because their pet feature hadn't been included (though there was ample technical justification for its omission, both in closed-door membership meetings and in the public list). Happily, in that case it simply made IBM look manipulative and petty, and didn't prevent the specification from reaching ratification. Like I said above, it's not our choice. Removing something from the spec when a significant browser refuses to implement it is simply making the spec match reality, because authors won't be able to use that feature. If I were to be in charge of an organization building a platform that competed with the web, I would certainly consider it worth my time to implement a browser and then refuse to implement pieces of the specification that competed with my line of business. Certainly if I were running an organization that made a browser and had a line of business threatened by a piece of the specification, it would be very clear how to mitigate that threat, since no specifics need be provided in support of a refusal veto. Note that has a browser isn't enough to give a company veto power. You need has a browser with sufficient market share (where sufficient is somewhere around 1%, based on previous remarks from Ian). This is due to the reasons stated above - the veto isn't a power that we grant browsers, it's a right that they earn on their own by virtue of having users. ~TJ If we all subscribed to that point of view though, everyone would still be stuck using IE5. As it is, there's a push by developers to use features that IE has always been slow to implement but other browsers have, and IE being the most popular browser is a pretty major player. Just because they've refused to support things countless times hasn't stopped the progression of standards; standards that other browsers adhere to for the most part. I'm quite thankful that standards weren't dropped because this 'major player' refused to participate in the same sport as everyone else. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Technical Parity with W3C HTML Spec
On Jun 25, 2010, at 3:17 PM, Mike Shaver wrote: On Fri, Jun 25, 2010 at 3:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I wasn't precise in my language - don't read too much into my exact wording. No, certainly; I'm much more interested in the spirit here than the wording, since it doesn't match my experience or understanding. I'll take on my education burden myself, though! As one of the Charter Members or Steering Committee, I believe that in principle we have the power to remove or replace the editor, and I believe we have at the very least persuasive authority to overrule decisions, at least if acting by consensus. However, so far the set of charter members has never tried to overrule or replace the editor. Indeed, this group of people has taken very few collective actions of any kind. Most of what has been discussed, in the rather infrequent discussions, have been political or legal matters, and sometimes these conversations have involved other people from the companies that the nominal charter members work for (such as the W3C AC reps of those companies, or attorneys for legal matters). Since the process of trying to overrule the editor has never been exercised, it's hard to say definitively how it would go if it ever was. Regards, Maciej
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 7:02 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 25 Jun 2010, Sam Ruby wrote: On Fri, Jun 25, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote: While I agree that it is helpful for us to cooperate, I should point out that the WHATWG was never formally approached by the W3C about this With whom (and where?) would such a formal discussion take place? I would prefer that such a discussion happen on a publicly archived mailing list. Best thing to do is probably to e-mail the people listed in the charter as being the members (e-mail addresses below), and cc the www-arch...@w3.org mailing list for archival purposes. ann...@opera.com, bren...@mozilla.com, dba...@mozilla.com, hy...@apple.com, dean.edwa...@gmail.com, howc...@opera.com, j...@mozilla.com, m...@apple.com, i...@hixie.ch HTH, Done: http://lists.w3.org/Archives/Public/www-archive/2010Jun/0054.html -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' - Sam Ruby
Re: [whatwg] Technical Parity with W3C HTML Spec
On Sat, Jun 26, 2010 at 11:00 AM, Mike Shaver mike.sha...@gmail.com wrote: That is not my recollection of what happened with offline, for what it's worth. Mozilla and Google had a relatively small set of deviations between approaches (ours developed on the whatwg list and Google's developed behind closed doors prior to the Gears announcement) and Ian specified an entirely different model, over the objections of both Mozilla and Google. Who from Mozilla objected? I didn't object, because I thought Ian's approach (manifests) was better than ours (JAR files). And I thought ours was quite different from Gears' (which used manifests, IIRC). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Technical Parity with W3C HTML Spec
On Fri, Jun 25, 2010 at 6:50 PM, Robert O'Callahan rob...@ocallahan.org wrote: Who from Mozilla objected? I didn't object, because I thought Ian's approach (manifests) was better than ours (JAR files). And I thought ours was quite different from Gears' (which used manifests, IIRC). There were two revision periods, I think, one as you describe that got us off JAR files (thank the stars), and then another later on, which is the one to which I am referring. I could be grotesquely misremembering, though, so I'll retract my comment rather than try to find records of the conversations! Mike
