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

Two comments.

In a personal capacity: I think it's inappropriate for the spec to  
mandate UI outside the content area. Behavior of the browser chrome is  
not an interoperability requirement, and has traditionally been the  
province of the browser developers themselves, to experiment and  
compete. If there is a browser UI feature you really truly want, then  
the right way to pursue that would be to submit feature requests to  
your favorite browsers.

On behalf of Apple:  Apple is very likely not willing to follow such a  
UI requirement in Safari or MobileSafari. Here's some concerns we  
would have:

1) Any button or menu item UI for prev/next would likely be too easily  
confused with back/forward.
2) Arrow keys with almost all reasonable combinations of modifiers are  
already taken, for back/forward, tab switching, scrolling and other  
features, and in any case we're not really interested in adding secret  
keyboard-only features..
3) There's no room for this additional UI complexity in the iPhone  
version of Safari.
4) Given the extremely spotty usage of prev/next, giving them full- 
time presence in the UI would likely be inappropriate. But UI that  
appears and disappears can be confusing to users.
5) In general, we try to keep our UI simple and streamlined, and we're  
not interested in dedicating UI real-estate to marginal features.

In other words, we disagree with you that prev/next support in the  
browser chrome would be user-friendly. We tend to think the opposite.  
Apparently most other browser vendors have concluded likewise, and I  
believe this is a considered decision, not due to ignorance. We  
believe strongly in content interoperability, but we're not up for  
having our browser's UI designed by committee.


On Aug 23, 2009, at 12:01 AM, Doug Schepers wrote:

> Hi, HTML WG-
> I was pleased to see that the sequential structure represented in  
> many kinds of sites (galleries, forums, search results, tutorials,  
> articles, etc.) is touched on in the HTML5 spec. [1]
> However, the 'next' [2] and 'prev' [3] keywords have been around for  
> around 15 years, and while they are used in quite a lot of content,  
> browsers still don't do anything with them. [4]
> I'd like to see wording that recommends (MAY, possibly even SHOULD)  
> that browsers expose this to users, in a UA-dependent manner; this  
> might be pressing the left/right arrows (possibly in combination  
> with some meta key), and/or a menu or UA option or button  
> (obviously, the UA could allow the user to customize this, but  
> should have a sensible default).
> Activating the next/prev link should trigger the browser to navigate  
> to that page.  The first instance of each would be the one  
> followed.  This would allow users a consistent way to follow  
> sequential links without having to hunt around on the page for the  
> next/previous link, and by specifying it in HTML5 (finally), we  
> could get interop.
> This would apply to both <link rel="next | prev" href="..."> and  <a  
> rel="next | prev" href="...">.  In my opinion, the latter is  
> probably the more obvious approach, since it would not require  
> duplicating the link, just marking existing links up appropriately  
> (which many sites already do).  I believe that many sites also use  
> the <link> version, possibly related to accessibility.  Choosing the  
> first <a> or <link> that defines @rel as each of the next/previous  
> would mean that both cases are covered.
> I know the spec generally steers away from making UI requirements  
> (though there are exceptions [5]), but this is clearly something  
> that people want.  There have been several bugs filed on this with  
> Mozilla, and probably on other browsers.  Authors have continued to  
> create content that uses this even though it doesn't have a tangible  
> effect.
> I think this is one of those obvious bits of user-friendliness that  
> has just fallen through the cracks, though it would be easy to  
> implement. Specifying it now would enhance all that existing content  
> in a way that was obviously intended by the authors, and would make  
> it clear to authors how to enable this for future content.
> [1]
> [2]
> [3]
> [4]
> [5]
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 23 August 2009 08:08:13 UTC