Re: HTML5 Profiles - First Editors Draft

Toby Inkster, Tue, 25 May 2010 10:48:11 +0100:
> On Mon, 24 May 2010 22:11:30 -0400
> Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
>> It's the latter. That's a good summary of the situation. I don't quite
>> understand the reasoning behind XMDP where the first profile overrules
>> all other profiles in the attribute. Anyone on here know the reasoning
>> behind that decision? It seems backwards.
> 
> It's because the HTML 4 rec states that only the first profile in the
> list is significant, the others being ignored. XMDP revises this to say
> that the first is most significant, and others are listed in decreasing
> significance.
> 
> Why does HTML 4 make it a whitespace separated list of URIs, if all but
> the first should be ignored? Because they recognised the possible
> future need for multiple profiles, and wanted to make sure that any
> consuming tools were equipped to split the list on spaces.

I agree. I have previously said that the prose of HTML4 allows multiple 
profile URIs. But I have later started to think that it may be more 
correct that HTML4 tried to discern between authoring requirements and 
processing requirements. Hence, the real error was to express the 
authoring requirement in the DTD. 

And if this is so, then it may not be 100% correct to say that the 
allowance of multiple URIs inside the profile attribute is an _errata_ 
to HTML4. Rather, it is an "fulfillment" of HTML4 - or a correction of 
a misjudged way of expressing the authoring requirements.

Speaking of which: while HTML5 Profiles allows multiple URIs, it 
currently only shows as examples @profile attributes with a single URI 
present. Question: When @profile is permitted on each element, does it 
then make sense to allow multiple URIs inside each @profile? Perhaps 
that should be a special permission for head@profile? Isn't HTML4’s 
vision of multiple URIs a consequence of the fact that profile URIs 
could only appear one place - in the head element? 

To the extent that multiple profile URIs in the same @profile will be 
permitted, the spec should show examples of how it can be done and how 
it can be interpreted/what it means to do so.

Further, we could also say more about the history, I think: Does HTML4 
allow @class to be part of a HTML profile? It seems like the only 
attributes for which HTML4 allows am HTML profile to change the 
semantics, are those attributes that may appear inside the head 
element. The only reach it has outside <head>, is to those attributes 
that may appear both inside and outside <head>. As we know, HTML5 makes 
@class global. From that perspective, it makes sense that profile URIs 
also defines the semantics of class. Based on this, I think that it is 
possible to say something about the special role of head@profile and it 
might be useful and correct to do so. (I have no concrete spec text 
yet.) Thus, I think that we can interpret Microformats' extension of 
the HTML profiles concept to also cover @class as more as an 
anticipation of @class as a global attribute than an extension of the 
profile concept.

We could also say something about what a HTML profile is. HTML4 
operates with a default profile. And says that e.g. <META> elements 
must be defined via profiles. The HTML5 idea about having a Wiki page 
or some such, which defines the default profile for @rel, <meta> and 
perhaps more, is thus not a bad idea - it can be interpreted as a live 
management of the default profile of HTML5.
-- 
leif halvard silli

Received on Tuesday, 25 May 2010 10:57:45 UTC