Re: several messages about New Vocabularies in text/html

Ian Hickson wrote:
> The key to avoiding the problem is the variant on Simon's idea, which is 
> to hard-code all the HTML element names and cause them to automatically 
> close the "namespaced" scope.
> 
> So e.g.:
> 
>    <math><b>
> 
> ...is treated as:
> 
>    <math></math><b>

That may work for MathML and SVG vs HTML5 as of today, but makes future 
changes extremely hard, because of potential name clashes.

>> As such, I don't believe that this meets the stated requirement of 
>> "Ability for an author to unilaterally extend the language to address 
>> problems we are currently unaware of and that therefore are not covered 
>> by existing functionality".
> 
> Actually this proposal isn't at all intended for use as an author-level 
> extension syntax. HTML has long used the class="" attribute for this, and 

HTML has also allowed adding new element names, and people have been 
relying on that as well (doing things with script after the page has 
loaded, such as inserting fragments into the page).

> I propose to continue using this, along with a new set of attributes for 
> name-value pairs using the data- prefix (and some corresponding DOM 
> infrastructure). For an example of this, please see:
> 
>    http://wiki.whatwg.org/wiki/CustomData
> 
> In practice for most HTML Web application authors this ends up being more 
> useful, and certainly easier to make accessible, than having the authors 
> mix in entirely arbitrary private vocabularies into their markup.

What exactly do you mean by "more accessible" here?

>> triggering transitions based on an attribute named xmlns would go a long 
>> way towards addressing this requirement.
> 
> As I've mentioned several times, I don't see any way we can do this on the 
> Web given the ridiculous numbers of elements of all kinds already in 
> text/html content on the Web that have xmlns="" attributes with various 
> values. I agree that in an ideal world it would be a great idea. But we're 
> not in an ideal world. Reality must be dealt with on its terms, not ours.

I still don't buy that. It would be interesting to get solid data from 
Opera about the experimental changes they tried.

Anyway, if "xmlns" really can't be used, there's nothing stopping us 
minting a new attribute name that has the same effect.

>> Simply specing that this "in namespace" state is case sensitive
> 
> Actually it turns out to make things really complicated. For example, 
> consider these four cases:
> 
>   1 <math><B>
>   2 <math><FOO>
>   3 <math><mtext><B>
>   3 <math><mtext><FOO>
>   4 <math><mtext><mglyph>
> 
> In case 1, we need to recognise that the B element is a known HTML 
> element, but we need to put the FOO element into the MathML namespace. In 
> the second case, we want <B> and <FOO> to become lowercase HTML elements, 
> but we still want the <mglyph> to end up in the MathML namespace. If we 
> were case-sensitive, then we'd want to recognise <B> as <b> but not 
> <MGLYPH> as <mglyph>. It ends up being far simpler to just support the 
> element names case-insensitively and fix them up afterwards.

Out of curiosity: where does the requirement to include HTML (not XHTML) 
into MathML come from?

BR, Julian

Received on Friday, 4 April 2008 08:04:32 UTC