W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: Implementation of head@profile

From: James Graham <jgraham@opera.com>
Date: Fri, 13 Feb 2009 15:39:54 +0100
Message-ID: <4995863A.60200@opera.com>
To: Larry Masinter <masinter@adobe.com>
CC: HTML WG <public-html@w3.org>

Larry Masinter wrote:
> I spoke too soon. In fact Dreamweaver supports the insertion of the 'profile' attribute and its value when the user uses dialogs to insert/edit the head tag and when code hinting. See
> 
> http://lists.w3.org/Archives/Public/www-archive/2009Feb/0032.html 
> for screen shots.

Looking at those screenshots, it is hard to imagine that the level of 
support in Dreamweaver goes beyond a table somewhere in the source code 
that lists it as an attribute that can appear on <head> and that takes a 
URI. Indeed the UI is misleading because it brings up a filepicker that 
has clearly been optimised for inserting images and hyperlinks.

If this is the extent of the support, I suggest that the example of 
Dreamweaver is not very convincing as "authoring tool support for 
@profile". Indeed it's an example of how hard it is to provide 
intuitive, helpful UI around the feature (because, for example, if a 
user types class="hCard" they probably, per spec, should have the 
relevant profile URI. But it is as easy for a client to detect something 
that looks like a microformat and process it without the profile as it 
is for the authoring tool to detect it and insert the profile. And if 
you fix it on the client you have the advantage of fixing it for all the 
cases where the author wasn't using an intelligent authoring tool. So 
you end up with the status quo which is that when @profile is present it 
is ignored).
Received on Friday, 13 February 2009 14:40:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC