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

On Mon, 31 Aug 2009, James Graham wrote:
> Ian Hickson wrote:
> > On Sun, 23 Aug 2009, Doug Schepers wrote:
> > > I'd like to see wording that recommends (MAY, possibly even SHOULD) that
> > > browsers expose [rel=next/prev] to users, in a UA-dependent manner
> > 
> >
> This section appears to try and influence browser UI in a way that 
> doesn't make sense for a technical spec. A MAY level requirement for UI 
> is meaningless because browser makers are already free to implement 
> whatever UI makes sense for their product. Following it by a SHOULD 
> requirement for details of things to be implemented if this UI is 
> implemented at all appears to just be an attempt to micromanage browser 
> UI without any basis in creating interoperability. As such, I suggest 
> dropping the whole #linkui section.
> In general, I believe format specs should steer clear of UI issues 
> except where there are particular considerations that must be made for 
> security reasons. Vendors should be given free reign to compete on the 
> basis of their UI design. They should not be expected to implement 
> certain features because they are deemed desirable by the rather biased 
> sample of users that make up the working group for the underlying 
> document formats. Instead members of the working group should use the 
> same feedback channels avaliable to other members of the population if 
> they want to influence browser UI design. I note that the converse is 
> not true; that is that if UI experts tell us a feature cannot be given a 
> good UI that should certainly be taken into account when considering the 
> design, or indeed existence, of the feature.
> It should also be noted that, in practice, the effect of UI requirements 
> in the spec is limited by the fact that people who design browser UI 
> care much more about user studies, HIG specs and intuition than what 
> some technical spec, typically written by people who are not UI experts, 
> says. Therefore UI requirements are unlikely to gain significant 
> implementation traction merely by being in the HTML spec. However the 
> presence in the spec of a particular UI recommendation increases the 
> chance of an incoming stream of bug reports from power users suggesting 
> that a browser "must" implement a given UI feature because some spec or 
> the other suggests it.  This is simply a waste of time for everyone 
> concerned.
> 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 saying what the UI should be, just that there may be one, and 
what the UI should take into account if it exists.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 3 September 2009 11:56:01 UTC