W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: Extensibility strategies

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 6 Aug 2008 13:50:36 +0300
Cc: Ian Hickson <ian@hixie.ch>, "'HTML WG'" <public-html@w3.org>, public-html-request@w3.org
Message-Id: <C8090B26-CAFD-45F2-94D2-CF68C47A93A6@iki.fi>
To: Sam Ruby <rubys@us.ibm.com>


On Aug 6, 2008, at 13:04, Sam Ruby wrote:

> Henri Sivonen wrote on 08/05/2008 08:03:01 AM:
> > With a colon in names, you can't have DOM consistency with all of
> > these at the same time:
> >   * text/html in existing shipped versions of Firefox, Safari and  
> Opera.
> >   * text/html in existing shipped versions of IE.
> >   * text/html in future HTML5-supporting browsers.
> >   * application/xhtml+xml in existing shipped versions of Firefox,
> > Safari and Opera.
>
> What you describe was certainly a factor in the ARIA discussions.
>
Yes, it was. Also, the assertion that there can't be DOM consistency  
with the colon is true regardless of what HTML5 specifies, because two  
immutable members of the set are enough to show an inconsistency:
  * text/html in existing shipped versions of Firefox, Safari and Opera.
  * application/xhtml+xml in existing shipped versions of Firefox,  
Safari and Opera.
> But, independent of whether a colon in element and attribute names  
> is a good idea or not, isn't it true that all HTML5 compliant  
> browsers will produce the same DOM for such elements and attributes?
>
Yes.
> Doesn't the "commented out" SVG proposal define attributes that  
> contain a colon?
>
Yes, and in that case, supporting the xlink:href syntax and DOM-level  
XLink namespacing even makes sense for copy-pasteability and renderer  
code reuse. The big difference is that when you have SVG elements,  
native renderer support for the elements is much bigger a deal than  
the colon: If a legacy browser doesn't render the elements as vector  
graphics, what happens with xlink attributes no longer matters.

However, if an extension is meant to be potentially script-sensitive  
without browser-native support being a prerequisite, DOM consistency  
matters more across old browsers and new browsers, because neither old  
nor new browsers have the browser-native support for the feature.
> Isn't it true that the <aside> element present in HTML5 produces  
> different DOMs with existing shipped versions of Firefox, Safari,  
> Opera, and IE?
>
Yes, for old enough values of existing.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Wednesday, 6 August 2008 10:51:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC