[whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

[Henri Sivonen]

On Fri, Jan 11, 2013 at 10:00 PM, Ian Hickson <ian at 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
hsivonen at iki.fi
http://hsivonen.iki.fi/