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

Ian Hickson wrote:
> 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
>>> 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.
> 
> 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…". The additional 
requirement I deduce from "Interactive user agents should allow users to 
follow hyperlinks created using the a element." is that UAs ought to 
provide a mechanism to follow hyperlinks even when users are not able to 
dispatch click or DOMActivate events to them. For example, assuming no 
non-UA stylesheets, a requirement that the user be able to follow the 
hyperlink created by the <a> element in the following fragment:

<section hidden>
<a href="foo">Next</a>
</section>

This implies a requirement on the browser chrome to have something like 
a list of all links on the page (or, arguably, a user stylesheets 
feature so that they can reveal display:none content). It is this 
"should" level requirement on browser UI that is problematic.

> 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. 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.

Received on Thursday, 3 September 2009 16:06:41 UTC