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 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
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'