Re: head@profile: another dropped attribute

Hi Leif,

On Feb 4, 2009, at 10:49 PM, Leif Halvard Silli wrote:

>
> Maciej Stachowiak 2009-02-05 02.36:
>> On Feb 4, 2009, at 4:20 PM, Larry Masinter wrote:
>
>>> In particular, whether *attributes and features*

First, I want to applaud Larry's suggestion of establishing broader  
abstract guidelines to shape the document conformance criteria (such  
as when attributes or elements should be deprecated, removed, or  
maintained). Such overarching guides in the spec authoring process can  
make the reading of the spec that much easier. Without such steps, the  
confusion and disagreements within the WG will most certainly spill  
over into those who try to read, interpret, implement, and author  
documents conforming to the specification.

>>>
>
>> - What is the purpose of this *feature*? What use cases does it  
>> serve?
>> - If the *feature* is already deployed, then how well is it serving  
>> its use cases? Is it used at all? When used, does it serve the  
>> intended purpose?
>> - Does the *feature* cause harm, for example by fostering bad  
>> practices, either directly or indirectly (by being error-prone, or  
>> easy to abuse)?
>> - Does the harm of the *feature* outweigh the benefit?
>
> Maciej, I note that Larry said "attributes and features".
>
> In that regard, @profile is not the feature here. Linking to a  
> profile and getting the UA to make use of that profile, *that* is  
> the feature. And profiles do exist "in the wild".
>
> The problem is that the draft doesn't whether talk about the profile  
> concept or about the profile attribute or about using <link> to link  
> to profiles. (Despite Ian's advocacy for <link>, he has't added any  
> Link Type for linking to profiles via <link>.)
>
> Thus, as it seems to be very little resistance (am I wrong?) against  
> the very profile /concept/, the feature issue with regard to the  
> profile /attribute/, has to do with compatibility with existing  
> specs, produces, consumers and author knowledge.
>
> However, coming back to the very profile /concept/, when are we  
> going to discus /that/? Because, the existing profiles have been  
> "digged out" - or literally dedused - from the very thin info that  
> the HTML 4 spec has. E.g. see the XHTML Meta Data Profiles page:
>
> http://Gmpg.org/xmdp/description
>
> Thus, regardless of @profile or <link> or both, HTML 5 has, IMHO, to  
> define how one is supposed to set up profiles and what HTML 5 means  
> by profiles.
>
> HTML 4 spesificly says that it does not define any profile format.  
> However, history has shown that such a defintion is needed. History  
> has also shown that profiles are popular.
>
> And in that regard, HTML 4 says about the <META> element that "the  
> permitted values" for the @name, @content, @scheme and @http-equiv   
> "are profile dependent". The real life profile for many  of these  
> attributes seems to be Google ...
>
>> From the implementation point of view, there is no cost to <head  
>> profile=""> being conforming. We must support the  
>> HTMLHeadElement.profile property in any case for compatibility. I  
>> would guess the developers of other browsers are similarly agnostic  
>> on this one. I believe the decision to drop profile was made based  
>> on considering the needs of authors, although that assessment may  
>> have been incorrect.
>
> It is your mention of authors that had me start thinking about the  
> above ... Authors needs the profiles concept. Do they also need  
> @profile? Would it be a problem for them to use <link> instead?  
> Would it be a benefit to use <link> instead? The one benefit I could  
> think of would be that using <link> is probably more well known.
>
> Assuming that there were benefit in going for <link>, could we  
> include both @profile and <link> for ultimate compatibilty? Of  
> course, that could be confusing. But what about this:
>
> <head profile="html5-default-profile-URI">
> <link rel="profile" href="realProfileURI" >
>
> Explanation:
> In HTML 4 the profile attribute is implied. Thus, there is always a  
> profile - namely the default profile of HTML 4. Thus, at least per  
> the letter, we could have said that the default profile for HTML 5  
> has moved the profile linking to the <link> element. Hence, we could  
> have said that @profile was implied, but that, for compatibility, it  
> was also permitted to insert the default profile of HTML 5 via  
> profile="" and a specified URI. We could then limit the conforming  
> content of @profile to just one single URI, namely the "super- 
> profile-URI" of HTML 5.
>
> Here also we are touching on the /concept/ of profile ... It would  
> be beneficial to define what the default profile for HTML 5 is -  
> that is: what it covers. I think we should at least say that it  
> covers the HTML 5 link relations. But also other things.

This sounds like a reasonable approach. Is there any reason we could  
have both the HTML 4 and the HTML5 profiles unified into one profile  
(different versions of the same profile, but where everything included  
in the profile before continues to have the same meaning but with more  
options) In this way the attribute would continue to exist, but would  
have a specific URI assigned to it (conceptually speaking since no one  
would actually have to enter that URI ever into a document for that  
profile to be assumed).

For most authors the default HTML profile would be suitable and only  
in exceptional cases would anyone need to change the profile to  
something else. I also think this suggestion eliminates the need for a  
special 'profile' rel value.

Take care,
Rob

Received on Thursday, 5 February 2009 05:53:43 UTC