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

Re: Distributed Extensibility

From: Thomas Broyer <t.broyer@gmail.com>
Date: Thu, 2 Aug 2007 18:08:02 +0200
Message-ID: <a9699fd20708020908q6f503db7td4c0a32195e3b789@mail.gmail.com>
To: public-html@w3.org

2007/8/2, Sam Ruby:
>      * Empty element syntax (self closing tags with a trailing soludus)
> are popular enough to merit special consideration.  HTML5 allows such
> syntax for elements like br, but not for script.  Allowing arbitrary
> extension elements to be empty would address this perceived user need.
> But consider the case of an extension element in a head section of a
> HTML page.  Subsequent elements would be considered to be enclosed in
> that element by a non-namespace aware user agent.  A narrower change
> that would capture the majority of the usage would be to allow empty
> extension elements but only if the immediate parent was also an
> extension element.

It wouldn't work when the nested extension elements have the same name:
    <x:foo><x:foo /></x:foo>
The </x:foo> end tag closes the nested x:foo element, not the outermost one.

Given that it only causes problems in the document's HEAD, I'd rather
propose the <body> start tag is required as soon as the HEAD contains
an extension element.

I'm not sure however that trying to parse <x:foo /> as a void element
is worth it.

Another (already proposed) alternative to your proposal would be to
extend <script> to contain XML if its @type attribute is specified and
with an XML Media Type value. UAs would then parse the <script>
content as XML (yes, XML) and if all goes well (XML is wellformed)
display it as if it has been an <object> with the given XML resource
referenced with the @data attribute. If the XML is not wellformed,
nothing would be displayed.

In other words:
<script type="application/mathml+xml"><math xmlns="...">...</math></script>
would be barely equivalent to:
<object data="data:application/mathml+xml,&lt;math

Finally, there's also Internet Explorer's <xml> element.

You'll note whichever the proposal, there never is a "fallback content".
After all, maybe we should stick with <object>, eventually using data:
URIs if we don't want external resources (hopefully, HTML editors
would handle the conversion for us and provide means for easy editing
(more than just "choose a file and I'll embed it as an <object> with a
data: URI)

Just some thoughts before I go in vacations (tomorrow evening, UTC)

Thomas Broyer
Received on Thursday, 2 August 2007 16:08:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC