Re: Possible Compromise solution for namespaces in HTML5

On Sun, Nov 22, 2009 at 10:36 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> When I'm talking about extensibility, I'm talking about a general
> extensibility that isn't browser specific. You're talking about the
> browsers wanting to add new elements and attributes, which is a
> specific type of extensibility for a specific type of HTML user agent.

Yes, precisely.

> In my opinion, though, nothing we do in this group will ever change
> this. The Canvas element came out after HTML4 and XHTML 1 were
> released. There was a procedure in place, not only to ensure well
> formed markup, but extensible markup. That didn't stop Apple from
> extending, or Firefox from following suit. Again, in my opinion, no
> extensibility proposal, regardless of what is proposed, will ever
> change this. So I don't focus on what I know will never change.

I assume that the "procedure in place" was namespaces-in-xml?  That
would only work in xml, and as I've been saying, wouldn't have helped
in this instance anyway - namespaces are inherently unsuited for
providing fallback.

> Not just CSS: Mozilla implemented a new Canvas property,
> mozImageSmoothingEnabled that was released with Firefox 3.6. However,
> we have methods in JS for dealing with browser extensions such as
> these.

Yup, JS, being a full programming language, has a number of ways to
work around inconsistencies; a good thing, too, or the language would
have been unusable years ago.

> Yes, I agree with you, there is nothing in HTML now to allow for this.
> There really is no way of gracefully handling something like a
> <mozilla:canvas> and a <safari:canvas> in HTML. If people are willing
> to provide -moz-background-size and -o-background-size in CSS, or deal
> with proprietary object properties in the Canvas element, they aren't
> going to be willing to do:
>
> <moz:cc>something</moz:cc>
> <o:cc><p>something</p></o:cc>
>
> Or some variation of same. But that is a very different situation than
> what exists in web pages today.

It's a situation that has existed in the past and will exist in the
future, and that frankly I'd like to encourage.  Experimental
implementations are a good thing; it lets us authors toy around with
something and suss out problems before they solidify into a final
spec.

> Today, you can have a non-prefixed web page title, used to provide a
> title for the web page, but you can also <dc:title> within an SVG
> element, used to provide a descriptive title for just the element. Two
> elements with the same name, but different purposes, and most likely,
> of interest to different user agents. This is the type of
> extensibility that interests me. When I talk about extensibility, this
> is the type of extensibility I'm thinking of: not something specific
> only to browsers.

I recognize that; that's just not the type of extensibility I'm
talking about here.

> No, of course not. But again, you're looking at browser-specific HTML,
> and I'm looking at HTML from a broader perspective.

Yup, I'm a webpage/webapp author, so browsers are my target platform.
I joined this group to ensure that my interests are served as best as
possible.  I recognize that UAs beyond browsers exist, but they are
far from my primary concern.

> Sure, and I can see the interest in focusing on attribute
> extensibility when it comes to browser specific extensions. While it
> may be awkward to contemplate:
>
> <moz:cc>something</moz:cc>
> <o:cc><p>something</p></o:cc>
>
> Something like the following could be more palatable:
>
> <div moz:attr1="some value" o:attr1="othervalue>...</div>
>
> A little more palatable to authors, but just. Or, as has been used,
> something like -moz-binding. Frankly, there's no difference between
> -moz-binding and moz:binding following Rob's proposal (as long as
> Mozilla registers moz). If anything, Rob's proposal, and others in the
> past week like it, formalize -moz in HTML, as -moz has been formalized
> in CSS.

Yup.

> But let's return for a moment to that, which is too awful to contemplate:
>
> <moz:cc>something</moz:cc>
> <o:cc><p>something</p></o:cc>
>
> Is this worse than Mozilla creating a <cc> element with one behavior,
> and Apple a <cc> element with another behavior, with nothing more than
> a warning to the users that <cc> is proprietary to each vendor and the
> behavior for the element differs?
>
> Hypothetically, let's say Mozilla's cc element only accepts phrasing
> content, while Opera's can only contain flow content. How would we
> deal with that when there is only one undifferentiated element?

This is definitely still a problem.  Maciej's suggestion for handling
experimental elements greatly enhances the fallback potential in this
space, but does not make it perfect.  Gratuitously incompatible
requirements between experimental implementations will still cause a
lot of trouble.  Evidence suggests, though, that this doesn't happen
often (experimental implementations in CSS are usually just
implementations of draft standards, or else fully browser-internal
properties that aren't meant to be used on the wide web).  When it
does, there's always JS to fall back on.  It's not pretty, but
hiding/mutating content with JS-based feature-sniffing code will work,
and is used today to some extent.  At the limit, authors just have to
decide which of the implementations to support and which to drop.  We
can't solve every problem.

>  With
> Rob's suggestion, Mozilla could register a prefix of "moz:", Opera
> "o:" and then the browser companies could experiment with new elements
> and attributes without worries that web page authors will be confused
> about which browser supports what. More importantly, Opera could
> define cc to only contain flow content, while Mozilla define cc to
> only contain phrasing content, and if people wanted to support both,
> they could, without browser breakage.

Only if they were willing to accept one of the hacks I outlined
previously, or something similar.  They'd still be inserting multiple
elements into their document but only wanting to show one of them.

> Where the breakage occurs is that there are no rules within HTML about
> "unknown" elements.  If I use <dc:title> directly in HTML, the
> contents of dc:title will be printed out to the web page, even though
> I only want the value of this element to be available to specific
> metadata user agents.

Heh, no, we (now) have very strict rules about unknown elements - it's
all described in the spec.  ^_^  The behavior you describe is exactly
what's supposed to happen.

> It won't work, though, for <moz:cc> and <ie:cc> because we built
> failure for this type of extensibility into previous versions of
> XHTML/HTML.

Yes, to an extent.  We built in easy standardized extensibility -
SVG's method of extension (refuse to render unknown elements) makes it
more difficult to extend the language cleanly.  But it has its own
benefits.

> Tab, I understand your frustration with my responses. I apologize for
> covering ground you know, but it helps me to walk through the issues.
> From my understanding of your concerns, you're not concerned about
> prefix/namespaces per se, than but that there is no way to "hide" the
> different variations of element content from the different users.
> According to the rules, all browsers should attempt to parse, and
> render (the render part being the operative word here) the contents of
> all elements, regardless. Am I correct in my assumption?

Yes.  That's desirable behavior in general (as you noted, it worked in
our favor for adding <section>, etc. to the language), it's just not
ideal in this circumstance.

> Still, this isn't HTML4/XHTML1. We can differentiate between HTML5 and
> previous versions of both XHTML and HTML. We should consider whether
> now isn't the time to revisit these rules, and do so in a way that
> doesn't generate incompatibilities with past implementations.

I'd say that the way we handle things currently is the best solution
for HTML, and so no sweeping changes are necessary.  The vast majority
of elements in HTML are content elements, not metadata, thus it makes
sense to assume that unknown elements are just new content elements
which should be rendered.  The issue of experimental implementations
is a specific and small case that partially violates this expectation,
so it would be best to solve this discrepancy here rather than
restructuring the rest of the language into a solution around it.

> And the issue is separate from support for namespaces in both HTML and
> XHTML, including support in the DOM.

Yes.


> PS One can look at the SVG element in a whole new light in this
> discussion, not only as a way of implementing graphics, but also as a
> way of adding all sorts of namespaced elements we want added to the
> DOM but without rendering.
>
> SVG has become the equivalent of markup miracle fruit[3].

Your previous example use of <dc:title> as a pure metadata carrier
suggests that the correct solution is to change the way such things
are embedded, rather than changing the language around the way they
want to embed.  There are a number of ways to embed metadata into HTML
now that would be more than amenable to such things.

Misusing <svg> to allow metadata to be embedded as arbitrary elements
is a pretty gross abuse.

~TJ

Received on Sunday, 22 November 2009 18:19:01 UTC