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

Hi, Maciej-

Maciej Stachowiak wrote (on 8/23/09 4:07 AM):
>
> 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.

Why?  Surely for interoperability, it's easier to come to a single group 
of people dedicated to that very purpose, than to force authors and 
users to file multiple feature requests with multiple browsers.  I've 
heard quite a few people say recently that they don't have time to 
participate in the standards/interop process, and that they feel 
underrepresented.  I am trying to represent their interests here.

Are you simply worried about the precedent this would set?  I don't 
think that's a serious concern, many specs suggest behavior, and I'm 
sure I could find such mention in HTML5 if I scoured it.  Is this 
specification solely for the benefit of implementers, or are the 
interests of authors to be represented as well?


> On behalf of Apple: Apple is very likely not willing to follow such a UI
> requirement in Safari or MobileSafari.

In the proposal I made, it would be a MAY, or at most a SHOULD, in which 
case Apple is free to make that decision not to support it.


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

Possibly, though that argument was probably applicable in the 1990s... I 
think most users are far more sophisticated than that now.  It could 
appear only on sequential pages (those with prev/next links), could be a 
floating translucent set of buttons over the content area, small arrows 
in the bottom-right of the status bar, or have any number of other 
distinguishing characteristics.


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

Then use some other way to do it.  On the iPhone, a flick of the phone 
to the left or right could trigger it, for example.  Or mouse gestures 
on desktop browsers, or any other mechanism that the user prefers.


> 3) There's no room for this additional UI complexity in the iPhone
> version of Safari.

Then don't do it.


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

Less and less so as more authors use it.  And I don't think authors are 
that easily confused... they adapt to each Webapp, with its 
idiosyncratic controls, pretty well.  And if done in a way that makes 
this clear that it is content-driven (like all the new <input> UI 
features implemented in Opera and elsewhere), then users wouldn't have 
cause for any confusion, and authors would be rewarded for using it.


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

Then don't do it.  It would be a recommendation, not a strict requirement.

I don't agree it's marginal.  A vast amount of existing content would be 
enhanced by this, and even more in the future as people start using 
@rel="next | prev" systematically, given the reinforcement of browser 
behavior.


> In other words, we disagree with you that prev/next support in the
> browser chrome would be user-friendly.

I clearly stated it would not have to be in the chrome, but could be 
provided any number of ways.


> We tend to think the opposite.

The use of the word "tend" implies that you haven't done any market UX 
research.  If you haven't done so, I'd ask that you look into it more 
closely before dismissing it.


> Apparently most other browser vendors have concluded likewise, and I
> believe this is a considered decision, not due to ignorance.

Do you have any evidence to support that?  In general, there does seem 
to be support for this idea [1][2], especially among users.  I haven't 
seen any other browser vendor outright reject it.

I'd be interested in the results of a poll on this subject.


>We believe
> strongly in content interoperability, but we're not up for having our
> browser's UI designed by committee.

Fair enough.  You wouldn't have to implement this feature.  I'm not 
asking for the group to mandate support for it, merely to describe it in 
the specification.  In the order of constituencies, users and authors 
come before browsers, and I've not seen any evidence that this would be 
bad for users and authors, and plenty of evidence saying they want it.

A final thought... before tabbed browsers, nobody was clamoring for 
browser tabs, but once they were introduced, people loved them (I 
actually switch from Netscape to NetCaptor for that very feature).  Now, 
many people can't live without them.  While I don't think this is as 
profound a shift, I do think that many people would find this feature 
extremely useful, and those that do wouldn't have to use it.  I don't 
think that it would negatively impact anyone's experience, and it would 
enhance others'.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=57399
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2800

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 23 August 2009 17:34:52 UTC