- From: James Graham <jgraham@opera.com>
- Date: Thu, 03 Sep 2009 18:06:15 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Doug Schepers <schepers@w3.org>, "public-html@w3.org" <public-html@w3.org>
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