Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen hsivo...@iki.fi wrote: Would it be terrible to make attempts to mutate the 'is' attribute throw thereby teaching authors who actually try to mutate it that it's not mutable? We already have several attributes that are immutable but don't throw or anything when they're changed. e.g. script src, html manifest. In the case of manifest, we omitted the IDL attribute to signal that it shouldn't be changed. As another example, input type was immutable in old IE and that made people think of it as immutable. -- Simon Pieters Opera Software
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Wed, 6 Mar 2013, Simon Pieters wrote: On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen hsivo...@iki.fi wrote: Would it be terrible to make attempts to mutate the 'is' attribute throw thereby teaching authors who actually try to mutate it that it's not mutable? We already have several attributes that are immutable but don't throw or anything when they're changed. e.g. script src, html manifest. In the case of manifest, we omitted the IDL attribute to signal that it shouldn't be changed. As another example, input type was immutable in old IE and that made people think of it as immutable. I think the content attributes should always be mutable, for consistency and to avoid unexpected crashes in code that just tries to set every attribute indiscriminately. (Much like how the DOM tree needs to be a real tree, not a graph, so that code can walk it without fear of loops.) It's ok to have attributes that set some other variable that is itself immutable, though. For example, html manifest sets the page's manifest URL, but you can't change the manifest URL, even though you _can_ change the element's attribute after the fact. In a sort of similar way, script src is mutable, it's just that it's only read at one point in the script processing model and it's the value at that point that matters. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Wed, 06 Mar 2013 18:55:27 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 6 Mar 2013, Simon Pieters wrote: On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen hsivo...@iki.fi wrote: Would it be terrible to make attempts to mutate the 'is' attribute throw thereby teaching authors who actually try to mutate it that it's not mutable? We already have several attributes that are immutable but don't throw or anything when they're changed. e.g. script src, html manifest. In the case of manifest, we omitted the IDL attribute to signal that it shouldn't be changed. As another example, input type was immutable in old IE and that made people think of it as immutable. I think the content attributes should always be mutable, for consistency and to avoid unexpected crashes in code that just tries to set every attribute indiscriminately. (Much like how the DOM tree needs to be a real tree, not a graph, so that code can walk it without fear of loops.) It's ok to have attributes that set some other variable that is itself immutable, though. I'm trying to say that we can do this with is=. For example, html manifest sets the page's manifest URL, but you can't change the manifest URL, even though you _can_ change the element's attribute after the fact. In a sort of similar way, script src is mutable, it's just that it's only read at one point in the script processing model and it's the value at that point that matters. -- Simon Pieters Opera Software
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Fri, Jan 11, 2013 at 10:00 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 11 Jan 2013, Henri Sivonen wrote: I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. When you say use XML, do you mean serving content using an XML content type? I'm talking about serving text/html but using XML machinery to generate it (with a text/html-aware serializer at the end of the process). Still, I think that as long as browsers to support XHTML, we'd be worse off with the DOM-and-above parts of the HTML and XML implementations diverging. Sure, but if on the long term, or even medium term, they don't continue to support XHTML, this is no longer a problem. But if they do continue to support XHTML, introducing divergence will be a problem and, moreover, a problem that may become unfixable. (That we were able to converge on the namespace was narrow enough a success. It broke Facebook!) Anyway, I'm not suggesting that they diverge beyond the syntax (which is already a lost cause). All I've concretely proposed is syntax for binding Web components in text/html; I haven't described how this should be represented in the DOM, for instance. If we define foo/bar as being a text/html syntactic shorthand for foo xml:component=bar, or foo xmlcomponent=bar, in much the same way as we say that svg is a shorthand for svg xmlns=http://www.w3.org/2000/svg;, then the DOM remains the same for both syntaxes, and (as far as I can tell) we're fine. I didn't realize you were suggesting that HTML parsers in browsers turned bar/foo into bar xml:component=foo in the DOM. How is xml:component=foo better than is=foo? Why not bar foo=, which is what bar/foo parses into now? (I can think of some reasons against, but I'd like to hear your reasons.) The idea to stick a slash into the local name of an element in order to bind Web Components is much worse. I don't propose to change the element's local name. select/map has tagName select in my proposal. Oh. That was not at all clear. Please, let's not make that mistake. What do you propose to resolve this problem then? Let's focus on the requirements before proposing solutions. Some of the constraints are: - The binding has to be done at element creation time - The binding has to be immutable during element lifetime - The syntax must not make authors think the binding is mutable (hence why the select is=map proposal was abandoned) “Was abandoned”? Already “abandoned”? Really? How does xml:component=map suggest mutability less than is=map? Would it be terrible to make attempts to mutate the 'is' attribute throw thereby teaching authors who actually try to mutate it that it's not mutable? - The syntax must be as terse as possible - The syntax has to convey the element's public semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders. - It must be possible to generate the syntax using a serializer that exposes (only) the SAX2 ContentHandler interface to an XML system and generates text/html in response to calls to the methods of the ContentHandler interface and the XML system may enforce the calls to ContentHandler representing a well-formed XML document (i.e. would produce a well-formed XML doc if fed into an XML serializer). The syntax must round-trip if the piece of software feeding the serializer is an HTML parser that produces SAX2 output in a way that's consistent with the way the parsing spec produces DOM output. (This is a concrete way to express “must be producable with Infoset-oriented systems without having a different Infoset mapping than the one implied by the DOM mapping in browsers”. As noted, dealing with template already bends this requirement but in a reasonably straightforward way.) - It must be possible to generate the syntax with XSLT. (Remember, we already have !DOCTYPE html SYSTEM about:legacy-compat, because this is important enough a case.) Adding these requirements to your list of requirements may make the union of requirements internally contradictory. However, I think we should have a proper discussion of how to reconcile contradictory requirements instead of just conveniently trimming the list of requirements to fit your proposed solution. (For example, it could be that one of my requirements turns out to be more important than one of yours.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
Hixie wrote in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c31 : I think it's fine for this not to work in XML, or require XML changes, or use an attribute like xml:component= in XML. It's not going to be used in XML much anyway in practice. I've already had browser vendors ask me how they can just drop XML support; I don't think we can, at least not currently, but that's the direction things are going in, not the opposite. This attitude bothers me. A lot. I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. (Rewriting Gecko's XML load code path has been on my to-do list since July 2010 and I even have written a design document for the rewrite, but actually implementing it is always of lower priority than something else.) Still, I think that as long as browsers to support XHTML, we'd be worse off with the DOM-and-above parts of the HTML and XML implementations diverging. Especially after we went through the trouble of making them converge by moving HTML nodes into the XHTML namespace. But I think it's wrong to just consider XML in browsers, observe that XML in browsers is a burden and then conclude that it's fine for stuff not to work in XML, to require XML changes or to have a different representation in XML. XML has always done better on the server side than on the browser side. I think it's an error to look only at the browser side and decide not to care about XML compatibility anymore. When designing Validator.nu, inspired by John Cowan’s TagSoup, I relied on the observation that XML and valid HTML shared the data model, so it was possible to write an HTML parser that exposed an API that looked like the API exposed by XML parsers and then build the rest of the application on top of XML tooling. In the process of writing the parser, in addition to supporting the XML API I needed for Validator.nu I also added support for a couple of other Java XML APIs to make it easy for others to drop the parser into their XML-oriented Java applications. Then I got my implementation experience documented in the spec as the infoset coercion section. I also advocated for the DOM Consistency design principle in the HTML Design Principles. (I also advocated this approach in the HTML–XML Task Force, and I believe that the feasibility of using an HTML parser to feed into an XML pipeline in addition to making good technical sense for real software has been useful in calming down concerns about HTML among XML-oriented people.) Interestingly, the first ideas that were conceived unaware of these efforts to make HTML parsing feed into an XML-compatible data model and that threatened the consistency of the approach came from the XML side: ARIA with colons (aria:foo instead of aria-foo) and RDFa with prefix mappings relying on the namespace declarations (xmlns:foo). We were successful at getting ARIA to change not to break the data model unification. Since then, RDFa has downplayed the use of xmlns:foo even though it hasn't completely eradicated it from the processing model. Now it seems that threats to DOM Consistency and Infoset compatibility come from the HTML side. The template element radically changes the data model and how the parser interacts with the data model by introducing wormholes. However, this is only browser-side radicalness and a complete non-issue for server-side processes that don't implement browser-like functionality and only need to be able to pass templates through or to modify them as if they were normal markup. These systems don't need to extend the data model with wormholes—they can simply insert the stuff that in browsers would go into the document fragment on the other side of the wormhole as children of the template element. The idea to stick a slash into the local name of an element in order to bind Web Components is much worse. Many people probably agree that the restrictions on what characters you can have in an XML name where a bad idea. In fact, even XML Core thought the restrictions were a bad idea to the extent they relaxed them for the fifth edition. But for better or worse, existing software can and does enforce the fourth edition NCNameness of local names. This isn't about whether the restrictions on XML Names were a good or bad idea in the first place. This isn't about whether it's okay to make changes to the HTML parsing algorithm. This isn't about whether the error handling policy of XML parsing is a bad idea and should be replaced with XML5/XML-ER. This is about how *existing* XML data model *implementations* behave. Sure, the reason why they behave the way they do is that they try to enforce the serializability of the data model as XML 1.0 (4th ed. or earlier) + Namespaces, but that's not the key point. The key point is that NCName enforcement exists out there in software that would be useful for people working with HTML on the server side as long as
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Fri, Jan 11, 2013 at 12:29:42PM +0200, Henri Sivonen wrote: I think it would be a mistake to change HTML in such a way that it would no longer fit into the XML data model *as implemented* and thereby limit the range of existing software that could be used outside browsers for working with HTML just because XML in browsers is no longer in vogue. Please, let's not make that mistake. Strongly agree with Henri that XML tools provide a lot of leverage on the web today, and you don't want to give that up. I once wrote a primitive web crawler in shell using NetBSD's 'ftp' utility for fetching web pages, Nhat Minh Lê's one-of-a-kind 'xmlgrep' utility to extract hrefs, and 'tidy' to convert from HTML or dodgy XHTML to well-formed XHTML. It wasn't a very sophisticated or full-featured crawler, but it was tiny, fast, transparent, easy to extend, and it would have been impossible to whip up in a couple of hours if I didn't have in my pocket an XML multitool that I could apply easily to web pages. It seems to me that app-specific annotations, such as you can add to XHTML with XML namespaces, are valuable both on the server and on the browser, where they are visible and usable by application JavaScript. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
On Fri, 11 Jan 2013, Henri Sivonen wrote: Hixie wrote in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c31 : I think it's fine for this not to work in XML, or require XML changes, or use an attribute like xml:component= in XML. It's not going to be used in XML much anyway in practice. I've already had browser vendors ask me how they can just drop XML support; I don't think we can, at least not currently, but that's the direction things are going in, not the opposite. This attitude bothers me. A lot. I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. Still, I think that as long as browsers to support XHTML, we'd be worse off with the DOM-and-above parts of the HTML and XML implementations diverging. Sure, but if on the long term, or even medium term, they don't continue to support XHTML, this is no longer a problem. Anyway, I'm not suggesting that they diverge beyond the syntax (which is already a lost cause). All I've concretely proposed is syntax for binding Web components in text/html; I haven't described how this should be represented in the DOM, for instance. If we define foo/bar as being a text/html syntactic shorthand for foo xml:component=bar, or foo xmlcomponent=bar, in much the same way as we say that svg is a shorthand for svg xmlns=http://www.w3.org/2000/svg;, then the DOM remains the same for both syntaxes, and (as far as I can tell) we're fine. The idea to stick a slash into the local name of an element in order to bind Web Components is much worse. I don't propose to change the element's local name. select/map has tagName select in my proposal. Please, let's not make that mistake. What do you propose to resolve this problem then? Some of the constraints are: - The binding has to be done at element creation time - The binding has to be immutable during element lifetime - The syntax must not make authors think the binding is mutable (hence why the select is=map proposal was abandoned) - The syntax must be as terse as possible - The syntax has to convey the element's public semantics (a specified HTML tag name) in the document markup, for legacy UAs and future non-supporting UAs like spiders. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
From: Ian Hickson [mailto:i...@hixie.ch] To: Henri Sivonen On Fri, 11 Jan 2013, Henri Sivonen wrote: Hixie wrote in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c31 : I think it's fine for this not to work in XML, or require XML changes, or use an attribute like xml:component= in XML. It's not going to be used in XML much anyway in practice. I've already had browser vendors ask me how they can just drop XML support; I don't think we can, at least not currently, but that's the direction things are going in, not the opposite. This attitude bothers me. A lot. I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. Still, I think that as long as browsers to support XHTML, we'd be worse off with the DOM-and-above parts of the HTML and XML implementations diverging. Sure, but if on the long term, or even medium term, they don't continue to support XHTML, this is no longer a problem. It's okay for authors who leave deploying content to publisher to stop with looking at html appearance from browser to users. Xhtml's fewer publishers maybe bonded abit over-tightly with it if their quantity is lesser considering how helpful transforms are. Repetitive content over-counted is more likelier for html than transformable xml serializations. The publisher may favour plug-ins for flash, jvm, Silverlight and whichever else. However, small publishers who are impacted by semantic significance of content grasped by search engine, oft deliver same data using link tag with rel=alternate attribute than difficult to index proprietary plug-in based formats. The alternate representation might be atom, rdf, ... using grddl xslt or some such html sibling spec, so xhtml may not be well-supported but vanilla support is another matter. For my personal interest, I'm looking forward to seamless iframes, though styled iframe does hide the frame appearance for javascript that breaks on main xhtml page, and place it in another page that's plain html. My point is, if the spec can be precise w. r. t. DOM to avoid usability breakage in xhtml, then the spec hopefully will be precise, leaving aside when xhtml should be considered dead to user-supporters at present.
Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus
Ian Hickson wrote: On Fri, 11 Jan 2013, Henri Sivonen wrote: Hixie wrote in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669#c31 : I think it's fine for this not to work in XML, or require XML changes, or use an attribute like xml:component= in XML. It's not going to be used in XML much anyway in practice. I've already had browser vendors ask me how they can just drop XML support; I don't think we can, at least not currently, but that's the direction things are going in, not the opposite. This attitude bothers me. A lot. I understand that supporting XML alongside HTML is mainly a burden for browser vendors and I understand that XML currently doesn't get much love from browser vendors. Not just browser vendors. Authors rarely if ever use XML for HTML either. I know. XHTML, along with DOM Level 2, are my favorite features to mention when talking about IE8 as a boat anchor, because both are more than 10 years old now! The lack of DOM Level 2 support is probably why jQuery 2.0 no longer supports IE8. -- View this message in context: http://old.nabble.com/We-should-not-throw-DOM-Consistency-and-Infoset-compatibility-under-the-bus-tp34887132p34890189.html Sent from the whatwg.org - whatwg mailing list archive at Nabble.com.
