Re: ISSUE-41/ACTION-97 decentralized-extensibility

On Oct 23, 2009, at 5:05 PM, Tony Ross wrote:

> On Thursday, October 22, 2009 at 4:06 PM, Maciej Stachowiak wrote:
>>
>> - For purely private extensions, I think allowing custom attributes  
>> is
>> reasonable, but allowing custom elements could be problematic. The
>> reason is as follows. Let's say two vendors define different custom
>> attributes with the same effect, perhaps using some sort of prefix.
>> It's practical to put both on an element. If a similar feature is  
>> ever
>> standardized, you can include that too, without conflict. CSS vendor
>> extensions work the same way - you can specify multiple prefixed
>> properties without a problem. For elements, it's not so simple.
>> Unknown elements (unlike unknown attributes) already have some
>> behavior in HTML. Writing two different custom elements nested, or
>> next to each other, won't necessarily give the results you want. So
>> differences like that have to be patched over by script or by serving
>> different content to different user agents.
>
> I can see the problem if such elements have custom parser handling  
> or fix-up, but that shouldn't be allowed. Only user agents would be  
> able to put such a restriction in place anyway.
>
> Other differences could be styling and rendering or additional APIs  
> exposed on the element instance, but this could just as easily be  
> triggered based on an attribute. In the end I'm not quite sure how  
> this becomes a problem specific to elements.
>
> Can you elaborate?

Here's a specific example. Let's say I invent a <-webkit-rotating- 
sphere> element that places every child element on the surface of a 3D  
sphere and rotates it. In real life we wouldn't introduce such a  
specific element, though it is possible to do that with our 3D CSS  
transforms and animations. So here's what the markup might look like:

<-webkit-rotating-sphere>
     <img src="image1.png">
     <p>Some text</p>
     <img src="image2.jpg">
     <video src="video.mp4">
</-webkit-rotating-sphere>

This would make a sphere with 4 rotating panels on its surface. Now  
let's say that Mozilla wants to introduce a similar element, but they  
don't want to step on our extension namespace. An author wants to make  
content that works in both. What do they do?

<-moz-rotating-sphere>
     <-webkit-rotating-sphere>
         <img src="image1.png">
         <p>Some text</p>
         <img src="image2.jpg">
         <video src="video.mp4">
     </-webkit-rotating-sphere>
</-moz-rotating-sphere>

That doesn't work though - in Mozilla it will make a rotating sphere  
with just one panel. How about this:

<-moz-rotating-sphere>
     <img src="image1.png">
     <p>Some text</p>
      <img src="image2.jpg">
     <video src="video.mp4">
</-moz-rotating-sphere>
<-webkit-rotating-sphere>
     <img src="image1.png">
     <p>Some text</p>
     <img src="image2.jpg">
     <video src="video.mp4">
</-webkit-rotating-sphere>

But now the content appears twice, both flat and in the sphere (plus  
the author has to repeat it twice). You have to use script or UA- 
specific content to get it right and use only the proper element. But  
let's say we used a div with a magic attribute instead:

<div -webkit-rotating-sphere -moz-rotating-sphere>
     <img src="image1.png">
     <p>Some text</p>
      <img src="image2.jpg">
     <video src="video.mp4">
</div>

Hey, no problem! We get one rotating sphere with four panels in the  
browsers that support it, and (presumably) graceful fallback in  
browsers that don't. Just as for CSS properties.

The upshot is this: for custom prefixed attributes, browsers can  
independently have their own prefixed versions of the implementation  
and authors can use both (as well as an eventual standard version in  
tandem). For elements, though, you basically have to copy the full  
vendor-specific name

Note: the lack of a blessed vendor extension mechanism for HTML  
attributes has led us to make some things be CSS properties in WebKit  
when they really should have been attributes. For example, -webkit- 
user-drag and -webkit-user-modify should really not be CSS properties,  
because they alter behavior, not presentation. But the norm for CSS is  
more forgiving of prefixed vendor extensions (even though content that  
uses them does not, technically, validate). On some occasions, we have  
introduce HTML attributes with no prefix, such as "placeholder", but I  
think we would feel more comfortable with using a recommended  
prefixing mechanism.

We have very rarely introduced new elements, and at this point would  
be extremely reluctant to do so without going to a standards body well  
before shipping. We had a pretty bad experience with <canvas>, where  
some design mistakes in our initial version had to be fixed when it  
got standardized, and as a result we had a dilemma between  
compatibility with existing <canvas>-using content and following the  
standard. In the end we went with the superior standard behavior but  
we had to do some unpleasant compatibility hacks to do so. I think in  
this case, a prefix mechanism would not have helped.


>> Nonstandard extensions
>> have a notable tendency to eventually be standardized, and sometimes
>> changed in the process, even if they were originally considered
>> totally proprietary. So we need to think about such considerations.
>
> Agreed. I think this is the advantage of a standardized extension  
> mechanism. Should an extension be rolled into HTML with behavioral  
> changes, element and attribute names can be altered so existing  
> content relying on the original behavior can continue to function.  
> Then implementers can migrate to the new standard without fear of  
> breaking the web. Authors can also utilize both the standard and  
> legacy markup until such time that the standard is broadly enough  
> adopted. This matches closely with how CSS vendor prefixes work today.
>
> I think we should also recognize that many of these extensions will  
> never be standardized, especially when their purpose is more domain- 
> specific. I expect the number of extension authors to be much  
> greater than the number of user agent vendors, increasing this gap.  
> This is also what makes me more concerned about the potential for  
> name collisions.

For both these reasons, I think a prefixing scheme is sensible. But  
let me note, we have a lot of vendor-specific extensions to HTML, and  
a lot of effective extensions via JS libraries, and we don't seem to  
have a problem in practice with name collisions. I do not have reason  
to beliee the problem would be much greater than in the future.

>
>> When considering the possibility of eventually folding in custom
>> markup extensions into standards, I think custom elements are
>> considerably more problematic than custom attributes.
>
> Why do you think custom elements are more problematic?

See above.

>
>> I also can't
>> think of a lot of use cases for custom elements that couldn't be
>> served by a standard element with custom attributes, or a special
>> "class" value, or perhaps special RDFa or Microdata markup. Thus, I
>> would prefer we only cater to custom attributes.
>
> I think the primary use case is the readability of the source. I  
> find something like <my-calendar> a bit easier to follow than <div  
> class="my-calendar"> or <div data-my-type="calendar">.

I place a lower priority on readability of the source in such cases,  
than on the concerns I outlined above.

>
>> Note though: CSS
>> doesn't make vendor-prefixed properties valid, it just defines their
>> form and promises that the standard won't conflict with a properly
>> vendor-prefixed property. I think this is an impractical choice, and
>> we should make prefixed attributes valid.
>
> Agreed, though I would also want validators to inform authors when  
> HTML documents contain extensions.

Giving a warning for use of properly identified extensions might  
strike a reasonable balance. I think that might be the sensible route  
for CSS as well. But I can see arguments either way.

Regards,
Maciej

Received on Saturday, 24 October 2009 01:02:16 UTC