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

Hi, Maciej-

Maciej Stachowiak wrote (on 8/24/09 4:23 AM):
>
> On Aug 23, 2009, at 10:34 AM, Doug Schepers wrote:
>
>>
>>> 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.
>
> I'd be fine with a MAY-level option to make some UI use of prev/next.
> But isn't it the case implicitly that browsers MAY provide whatever UI
> affordances they want for various <link rel> values, since the spec does
> not restrict UI requirements? For example, most browsers nowadays do
> have built-in UI for rel="feed". So what difference would it make to
> specifically call out prev/next?
>
> That being said, based on the example of rel="feed" and the example you
> cited of tabbed browsing, it seems like the way to popularize particular
> browser UI changes is to bring your case direct to the browser vendors.
> Believe me that we are all highly susceptible to user feedback,
> especially when a competing product (Opera in this case) already has the
> feature. I can also tell you that at Apple, we have not heard customers
> clamoring for prev/next in the way that they did for tabbed browsing or
> built-in feed support. I bet customer demand will make a much bigger
> difference than a MAY requirement in the spec to the teams that work on
> Safari, IE, Firefox and Chrome.

Fair enough.  I suppose my view of specs may be a bit different than 
many browser implementers... having spent so many years as a developer 
and author, I see specs as targeting those folks almost as much as 
vendors.  So, in that sense, specs can provide rationales for authors 
and users to file bug reports... at least in Mozilla's bugzilla, I have 
seen comments from the implementers to the effect of "justify your 
feature request by pointing to the spec for it", and I have seen bugs 
fixed on account of pointing to someplace in a spec.

So, in other words, I don't see it as an either/or... I see direct 
feature requests to browser vendors and suggestions in W3C specs as 
complementary.  If users see something they like in a spec, which 
browser vendors haven't yet implemented widely, they can rally around 
that point and push browser vendors to implement it, and the wording in 
the spec can help promote interoperability in some of its details (for 
example, in this case, that the first relevant link with an appropriate 
@rel value is selected).

My point about tabbed browsing was not to suggest that next/prev links 
would be as popular and obvious... it was that until someone innovated 
with browser tabs, nobody was asking for the feature.  Once it was 
implemented, and people caught wind of it, they started asking for it. 
I suspect that once next/prev shortcuts are implemented in a way that 
doesn't require users to take extraordinary steps to use them, it will 
be popular.

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

Received on Monday, 24 August 2009 19:42:23 UTC