- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 05 Feb 2009 05:49:25 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Larry Masinter <masinter@adobe.com>, HTML WG <public-html@w3.org>
Maciej Stachowiak 2009-02-05 02.36: > On Feb 4, 2009, at 4:20 PM, Larry Masinter wrote: >> In particular, whether *attributes and features* > - 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. -- leif halvard silli
Received on Thursday, 5 February 2009 04:50:10 UTC