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

Re: Please Specify Behavior for @rel="next | prev"

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 3 Sep 2009 22:48:11 +0000 (UTC)
To: James Graham <jgraham@opera.com>
Cc: Doug Schepers <schepers@w3.org>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0909032240180.10423@hixie.dreamhostps.com>
On Thu, 3 Sep 2009, James Graham wrote:
> > >
> > > For these reasons, if there are other places where HTML 5 recommends 
> > > particular UI without solid grounding in an interoperability or 
> > > security requirement, I suggest removing those recommendations as 
> > > well.
> > 
> > I don't understand how what HTML5 says about <link> here is any 
> > different than what it says about <a href=""> later. ("Interactive 
> > user agents should allow users to follow hyperlinks created using the 
> > a element.")
> 
> It's not. As far as I can see the later text is also out of place. The 
> fact that hyperlinks created using the <a> element respond to click 
> events causing the browser to follow the hyperlink is already specified 
> under "The activation behavior of a elements…".

Good point. I've changed that text around to be less redundant.

A better example then might be <video controls>, which the spec says 
should result in UI being exposed to the user.


> > It's not saying what the UI should be, just that there may be one, and 
> > what the UI should take into account if it exists.
> 
> In general the "may" level conditions I can live with (although I would 
> prefer we didn't have them); they are mostly just fluff text anyway 
> since they merely explicitly allow things that are already implicitly 
> allowed. "Should"-level conditions, however, seem like an abuse of the 
> keyword since there is no interoperability or security requirement on 
> all browsers having the same UI features.

If one browser doesn't show controls for <video controls> and another 
does, then I think that authors would argue that there is a material loss 
of interoperability that would lead them to not consider the feature 
useful enough.

Why does the same not apply to <link>?


> In the case of the <link> element, the combination of a "may" level 
> requirement on providing some UI feature at all with "should" level 
> requirements on what ought to be present in the UI seems nonsensical; it 
> suggests that it is considered better to not have the feature at all 
> than to have the feature and not include all of the listed data. As with 
> other UI issues the problem of what information to present to the user 
> for <link> elements should be up to individual UAs.

Fair enough; so changed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 3 September 2009 22:45:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT