w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire ISSUE-41: Decentralized-extensibility - Straw Poll for Objections
The results of this questionnaire are available to anybody.
This questionnaire was open from 2010-09-23 to 2010-10-07.
11 answers have been received.
Jump to results for question:
- Objections to the Change Proposal to generalize the mechanism used for SVG and MathML
- Objections to the Zero-edit Change Proposal for ISSUE-41
1. Objections to the Change Proposal to generalize the mechanism used for SVG and MathML
We have a Change Proposal to generalize the mechanism used for SVG and MathML. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Change Proposal to generalize the mechanism used for SVG and MathML |
|---|---|
| Aryeh Gregor | I have two major objections to this change proposal, after initial inspection. I don't think either was addressed at all in the rationale or any other part of the proposal. 1) It refers to HTML that contains arbitrary, potentially proprietary extensions as "valid extended HTML". Arbitrary documents could easily be constructed that consist entirely of proprietary markup, but would still be called "valid" by a W3C-approved validator. This defeats the point of reporting validity status to begin with. (You can already do this to some extent by using <object> or such, but we shouldn't exacerbate the problem -- it would be better if we moved in the other direction, and marked pages containing Flash and such as invalid.) Instead, all unrecognized markup should be invalid. Validators should be written to recognize markup corresponding to known open standards, the same way the HTML5 validator recognizes SVG and MathML. Since the standardization process is inherently centralized and invariably slow, this is completely practical. And while it's fine for some vendor extensions that are not yet part of an open standard to exist, they should not be reported as valid. This point is essential. The goal of the W3C is to promote open standards, and it must not endorse unrecognized extensions as having any validity. 2) Authors should not ever have to explicitly type out namespaces in text/html. Namespaces are almost impossible to remember and very awkward to type. Instead, UAs that support the markup should infer the namespace, and those that don't will put it in the HTML namespace. This is harmless at worst -- it doesn't do anything, why does it matter what namespace it's in? -- and is actually useful at best, since it allows easy feature-detection from CSS: e.g., @namespace math url(http://www.w3.org/1998/Math/MathML); math { display: none } math|math { display: block } math|math + img.math-fallback { display: none } When considering the possibility of implementing MathML-in-text/html in MediaWiki, I found this namespace trick to be the best available method for hiding element contents from old browsers (although there might be better ones I don't know about). A point-by-point rebuttal of the "Positive Effects" section: * Future extensions can be added to HTML in the same way that SVG and MathML were integrated in the past SVG and MathML were integrated before this change proposal existed, so it's fairly clear that this was already possible, and you can't count it in favor of the proposal. * Provides guidelines for spec authors to help them write specs that work well with HTML Work well with HTML in what way? Why is there any reason to think that this way of writing specs will work better than other ways (e.g., simply writing an extension spec as is already permitted)? I saw no reference elsewhere in the change proposal to this positive effect, or any supporting evidence for it. * Helps user agents know what to expect from documents that use unknown extensions, and how to handle such documents gracefully This behavior is already well-defined -- HTML5 specifies exactly how to handle unrecognized elements and attributes. This specification makes no changes to that behavior that I can see, except that it changes the element's namespace in some cases, which is bad (see point 2). * Extensions can be merged into a future version of HTML without the need for document to continue to support a previous syntax * Existing XML markup can be pasted directly into HTML, without having to worry about prefixes * A document can use extensions and parse correctly in both HTML and XML * Since "xmlns" only has meaning when the extension attribute is set, parsing behaviour is unchanged for pre-existing documents * Copy/paste problems with prefixes go away, since prefixed attributes have a fixed meaning. All of these are a feature of the existing system (un-namespaced extensions and implicitly-namespaced extensions) too, as evidenced by MathML and SVG. Overall, this proposal doesn't adequately explain what's wrong with the status quo and why it's better. Almost everything in the Rationale and Positive Effects sections could equally be said to apply to the zero-edit proposal. On the other hand, there are at least two actively harmful aspects to it, compared to the extremely similar existing extension mechanisms. It isn't as egregiously bad as some of the other proposals that have been put forward, and avoids some of their pitfalls -- but it still fundamentally fails to address any actual problem with the language, and creates new ones. |
| Henri Sivonen | The polling system rejected my response, so I sent it to www-archive per previous instructions from the Team Contact. Please consider the objections in http://lists.w3.org/Archives/Public/www-archive/2010Sep/0054.html as if they were fully stated herein. |
| Julian Reschke | |
| David Singer | - This proposal adds significant implementation complexity and involves untested changes to the parsing algorithm. - We are at a late stage of developing HTML5. While additional extensibility features may be useful, adding a significant new one so close to Last Call would be unwise. It would be better to move forward with what is already in HTML5, and consider additional extensibility features in a future version. In particular, HTML5 already has extensibility features to address many of the same use cases, and it would be valuable to learn how they work out in practice. - Namespace features involving explicit namespace URIs have been unfriendly to authors in the past. Memorizing or copy/pasting namespace URIs is unpleasant and makes markup more verbose. Authors also tend to get confused about the importance of the namespace prefix as opposed to the namespace URI. |
| James Graham | This proposal assumes that having elements in namespaces is a desirable feature, despite acknowledging that users find multiple-namespace documents harder to work with than single-namespace documents. Adding such complexity for authors when a simple alternative – to forgo the use of namespaces – is available requires extraordinary justification, but none such is given. The change proposal also fails to cite any real use cases in the form of specifications that would like to integrate with HTML in the prescribed manner. This suggests that, at worst, rejecting the change proposal is harmless since the idea can be revisited in the future when there is an actual extension specification that wants to integrate into HTML and has some justification for not using the HTML namespace. Working from a real need rather than an abstract idea makes it more likely that any solution will actually address the requirements. |
| Tony Ross | I previously stated Microsoft's position on ISSUE-41 here: http://lists.w3.org/Archives/Public/public-html/2010Aug/0116.html We agree with David Singer that HTML5's existing extensibility mechanisms address many of the same use cases. Consequently we don't think additional methods of extensibility are important enough to make changes to this version of HTML this close to Last Call. |
| Anne van Kesteren | I strongly oppose this proposal. Platform and language extensions so far have not happened in a silo and there is no reason to expect they will in the future. They can, are and should be a coordinated public effort between users, authors, and vendors. Vendor extensions have happened in private and will do so again in the future. I agree that we should give advice on how user agents should go about this. Typical user agent extensions are however not whole new vocabularies but rather new attributes or values, or a single new element. Long term experience with vendor extensions to CSS and the DOM show that a simple prefix is sufficient to avoid clashing. The draft as it is today already addresses this need sufficiently. There is also strong indication that namespaces are too complex: http://wiki.whatwg.org/wiki/Namespace_confusion |
| Norman Walsh | |
| Jonas Sicking | I object to this proposal for a few reasons. First of all it doesn't seem to be needed, at least according to the rationale provided. The proposal gives the following three rationales (defined in detail in the proposal): * "platform extensions" * "language extensions" * "vendor-specific experimental extensions" It is provably the case that the first two rationales don't need this extension mechanism. SVG, MathML and RDFa have all already been integrated into HTML without the use of the proposed mechanism. The last rationale doesn't seem to need the proposed mechanism either as the spec already defines a mechanism which vendors like Webkit and Mozilla can use. Second, while the proposal does take some steps to reduce the complexity involved with prefixing mechanisms such as xmlns, it still leaves a fair amount in there. It still requires that authors type long namespace names which are generally hard to remember. I more often than not have to look up the namespace even for XHTML, and I definitely have to do it every time I use XSLT or XUL. And not only does the proposal result in that people will have to type long namespaces in the markup. It also forces people to use the awkward namespace integration that exists in the DOM, for example using the *NS functions. This requires passing twice as much information through any code that deal with node names. It also makes it very easy to make mistakes in case there are local-name name collisions with HTML elements if the non-namespaced methods in the DOM are used. Also, as a result of reducing complexity in prefix usage, it requires a registry to be set up. This means that in some sense it has the worst of two worlds as it both requires excessive typing, *and* requires the use of a central registry with all the complexities involved with that. Consider for example the link registry which has received extensive controversy, and the HTTP header registry which is woefully under used. Third, for extension of any of the types listed in the rationale, I think we should strongly encourage language authors to avoid local-name name collisions. It already introduces complexity that SVG and HTML collides in a few instances, despite the fact that the colliding elements are generally semantically identical. For example if a <script> element is currently moved from inside a <svg> to outside it, it is unlikely to still work due to differences in parsing behavior. There are also the risks mentioned above due to the limitations in the DOM APIs, such as people calling getElementsByTagName instead of getElementsByTagNameNS. The way HTML5 currently integrates other specs like SVG and MathML discourages these types of collisions. Fourth, using the proposed mechanism alone wouldn't actually allow extensions such as SVG and MathML. Both these languages need to be able to contain HTML as well. This is currently done by letting the parser switch out of "foreign content" mode when certain elements are parsed, for example a SVG <foreignObject> element or MathML <mtext> element. This functionality could not be done with the proposed mechanism. |
| Sam Ruby | [comment from Leif Halvard Silli] http://www.malform.no/messages/issue-41-poll-reply |
| Leif Halvard Silli |
2. Objections to the Zero-edit Change Proposal for ISSUE-41
We have a Zero-edit Change Proposal for ISSUE-41. If you have strong objections to adopting this Change Proposal, please state your objections below.
Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.
Details
| Responder | Objections to the Zero-edit Change Proposal for ISSUE-41 |
|---|---|
| Aryeh Gregor | |
| Henri Sivonen | |
| Julian Reschke | A few observations: - this Change Proposal cites spec text which in the meantime has been changed (for instance, with respect to Microdata) - under "Platform Extensions": "Such extensions should be coordinated among browser vendors within this working group." -- (a) why just the browser vendors, (b) what if the WG doesn't exist anymore? - under "Vendor-specific Experimental Extensions": "The spec already provides for this with the vendor--feature="" pattern for vendor-specific attributes" -- ...as something that makes documents non-conforming. Not sure what "provides for" means when it can't be used in conforming document. People willing to publish non-conforming documents already can add whatever they want and doesn't break parsing. |
| David Singer | |
| James Graham | |
| Tony Ross | |
| Anne van Kesteren | |
| Norman Walsh | I don't find the arguments about current extension mechanisms sufficient. Limiting my extensions to class attributes, which have no namespacing mechanism and may be even further overloaded, data-* attributes, and a few other places seems too limiting for a language that will be deployed as widely and pervasively as HTML. I'd much prefer a solution where there is some mechanism for extensions, where CSS can style those extensions, and where they appear in the object model identifiably as extensions. |
| Jonas Sicking | |
| Sam Ruby | |
| Leif Halvard Silli | http://www.malform.no/messages/issue-41-poll-reply |
More details on responses
- Aryeh Gregor: last responded on 26, September 2010 at 22:03 (UTC)
- Henri Sivonen: last responded on 29, September 2010 at 13:33 (UTC)
- Julian Reschke: last responded on 5, October 2010 at 11:54 (UTC)
- David Singer: last responded on 5, October 2010 at 18:13 (UTC)
- James Graham: last responded on 6, October 2010 at 21:38 (UTC)
- Tony Ross: last responded on 6, October 2010 at 21:51 (UTC)
- Anne van Kesteren: last responded on 7, October 2010 at 10:31 (UTC)
- Norman Walsh: last responded on 7, October 2010 at 17:22 (UTC)
- Jonas Sicking: last responded on 8, October 2010 at 02:45 (UTC)
- Sam Ruby: last responded on 8, October 2010 at 09:50 (UTC)
- Leif Halvard Silli: last responded on 8, October 2010 at 11:13 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project