Re: Possible Compromise solution for namespaces in HTML5

>> Do you have specific instances where this has occurred that you can
>> provide so we can look at how this has happened in the past?
>
> In terms of multiple experimental versions of the same element,
> providing with distinct names?  No, this has never happened.  When new
> elements have been experimented with, browsers have just added them in
> directly; this has caused trouble, as you know, which is why we're
> trying to make this easier.
>

We are talking about two different things. Sorry if you all realized
it sooner than me.

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.

As you've stated, if a browser wanted to try a new element, it would
just add it. The Canvas element is the one that comes to mind,
first[1].  Apple came out with its Webkit version, followed by Firefox
with its, and then Opera with its. In the past, others have invented
elements, such as IE inventing the ActiveX control, and Netscape
proposing frames...after it had already implemented them[2].

What's happened with all of these is yes, there is a period of
confusion. Confusion, not only because not every browser would support
the element, such as Canvas, but not every browser implemented the
same variation of the element. Again, such as Canvas.

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.


> In terms of the general problem of multiple experimental
> implementations of a feature given different names, I've already
> provided an example.  CSS deals with this heavily, with a multitude of
> properties implemented in prefixed form by multiple browsers at once.
> CSS handles it properly, so that they play nicely with each other and
> the eventual standardized (and prefixless) version.  The properties of
> CSS that allow this should be obvious (though I can enumerate them if
> necessary), and it should be equally obvious that element names do
> *not* have analogous properties.
>

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.

>> Point taken, but to the web page author, to all intents and purposes,
>> people perceive that IE ignores the elements. There is no fallback, we
>> have to do something in the web page to make them work.
>
> This still has nothing to do with the problem I'm citing - it's an
> entirely different issue.
>

Yes, sorry, I see that now.

>> I think you're using an unlikely scenario. A typical namespaced
>> element in the future would probably be something like the creative
>> commons license, or Inkscape's elements within SVG: they won't require
>> anything from specific user agents.
>
> That's explicitly not the situations I'm talking about - I'm
> addressing the issue of multiple experimental implementations of a
> feature, leading to an eventual standardization of it.  This is a very
> likely scenario, as it is used and useful in CSS; HTML currently
> doesn't possess the correct characteristics to allow it to work
> properly, however.
>

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.

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.

>> To me, extensibility doesn't mean that all user agents will be equally
>> interested in the extended elements. But that there is a means to
>> record the extended elements in a web page, without causing other
>> elements to break, and to be available for those user agents that are
>> interested.
>>
>> If, for some reason, Mozilla, Opera, Apple, Google, and IE decide to
>> implement their own creative commons element, named cc, or some such
>> thing, then I don't think we'll see a proliferation of apple-cc:
>> moz-cc: and so on.
>
> No, what's feared is a <ms:cc> element, plus a <moz:cc> element, plus
> a <webkit:cc> element - all of them performing the same purpose and
> wanting to be used at the same time on the same data.  There are many
> bad ways to handle this - you could repeat the data multiple times,
> once in each element, and come up with some way (probably js-based) of
> hiding all but the correct element for each UA; you could hope that
> the content model for the elements are set up such that you can nest
> them and then just insert the data once, and hope that any problems
> caused by this can be smoothed out by CSS and js; you can connive to
> serve different pages to different UAs, each delivering a different
> element in that area.  There are no good ways to handle it currently.
> When the element gets standardized as <cc>, there's significant
> pressure not to update - you have to either pursue one of the above
> methods, or just write off legacy clients.
>
> This is not a good situation for authors.
>

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

>> The point I was making is that attributes do not always provide the
>> same capability. If they did, we wouldn't supposedly need article or
>> section, we could just create an article attribute or a section
>> attribute and attach to a div element.
>
> Of course, that would be silly.  Why would we use attributes when
> element names suffice?  The only reason we're even *considering* using
> attributes as a substitute for element names is because, in this
> particular situation, element names do not suffice, as I explained
> above.
>

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.

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?  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.

In some future HTML version, if cc is standardized, and defined to be
both flow and phrasing content, previous implementations of Mozilla's
variation of cc: will still work (because Mozilla will be committed to
ensuring they work), previous versions of Opera's cc will work
(because Opera will be committed to ensuring they work), and future
versions of the new non-prefixed cc will also work (because of
commitments by both Opera and Mozilla).

It seems to me that in the real world, web page authors would be more
worried about breakage but duplication. But, as you noted Tab, that's
not the real problem.

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. There are rules in SVG for unknown elements:
elements from other namespaces are parsed into the DOM, but otherwise
ignored. However, in HTML4/XHTML1:

* If a user agent encounters an element it does not recognize, it
should try to render the element's content.

* If a user agent encounters an attribute it does not recognize, it
should ignore the entire attribute specification (i.e., the attribute
and its value).

Of course, this works in our favor with our new elements: section,
article, and so on. Even though IE and the old Firefox don't recognize
the doctype, don't allow css styling, they do "attempt to render the
element contents". You just have to use the shim to make them pretty.

And it will work in the favor of browsers experimenting with new
elements in the future: other browsers will attempt to render the
contents, though only the browser that added the extended element will
do something magical with it. In the case of something like Canvas, no
biggie because technically, the only contents for the Canvas element
are the fallback contents that should render if Canvas is not
supported and/or JS is turned off.

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.

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?

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.

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

> ~TJ
>

Shelley

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].

[1] http://ln.hixie.ch/?start=1089635050&count=1
[2] http://www.oxfordu.net/web-design/office/proprietary.html
[3] http://en.wikipedia.org/wiki/Miracle_fruit

Received on Sunday, 22 November 2009 16:37:23 UTC