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

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

From: James Graham <jgraham@opera.com>
Date: Mon, 31 Aug 2009 13:13:12 +0200
Message-ID: <4A9BB048.1080908@opera.com>
To: Ian Hickson <ian@hixie.ch>
CC: Doug Schepers <schepers@w3.org>, "public-html@w3.org" <public-html@w3.org>
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
> 
> http://www.whatwg.org/specs/web-apps/current-work/#linkui
> 

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.
Received on Monday, 31 August 2009 11:13:46 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC