- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 25 May 2010 12:57:10 +0200
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, HTMLWG WG <public-html@w3.org>
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