Re: Distributed Extensibility

Thomas Broyer wrote:
> 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.

Agreed.  This is should be fixable.

> 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 yet convinced that it only causes problem in HEAD, nor would I 
want to prematurely preclude extensions from being in HEAD.  I'd rather 
require that empty elements not match the name of either the outermost 
containing extension element.  I'd also be happy with stronger 
restriction that elements

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

The first time I saw the problem was with taking svg from inkscape and 
trying to embed it in an HTML page, using scripts:

http://intertwingly.net/blog/2006/12/05/HOWTO-Embed-MathML-and-SVG-into-HTML4

The problem is that inkscape tends to emit an empty <defs/> element and 
then follow it with vector graphics.  Vector graphics inside a defs 
element aren't rendered, they are merely available for reuse.

Take a look at the number of empty FBML elements.

I think users will find this to be will be very problematic.

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

I guess I missed this.  URL to prior discussion (archives?  wiki?)

I personally don't care much for the requirement that this imposes for 
an XML parser, and the implicit attitude of robust parsing is only for 
features that we approve of, everything else must be handled in a 
draconian fashion.

> 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
> xmlns=&quot;...&quot;&gt;...&lt;/math&gt;"></object>
> 
> Finally, there's also Internet Explorer's <xml> element.

I recall that being generously described as "undocumented".  Has that 
changed?

> 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)

If fallback is a requirement, then perhaps there should be a <fallback> 
element.

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

Thanks!  For the record, I don't insist that my specific proposal be 
adopted unmodified.  It has been my experience that proposals of this 
nature that aren't fleshed out to this level tend not to go very far. 
But that doesn't say that any other proposal (such as <xml>) that 
satisfies this use case wouldn't be equally acceptable to me.

- Sam Ruby

Received on Thursday, 2 August 2007 16:41:43 UTC