W3C home > Mailing lists > Public > www-style@w3.org > April 2015

Re: [css3-ui] directional nav error handling

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 14 Apr 2015 15:56:25 -0700
Message-ID: <CAAWBYDDMMs3NBvS-qKJARXWae7Dk3GvEDG5D++UfWPjyAryGqA@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>
On Fri, Apr 10, 2015 at 8:36 AM, Florian Rivoal <florian@rivoal.net> wrote:
> I found something that needs clarification in the directional navigation
> section.
>   The <target-name> parameter indicates the target frame for the focus
>   navigation. It is a <string> and it cannot start with the underscore
>   "_" character. If the specified target frame does not exist, the
>   parameter will be treated as the keyword current.
> It cannot start with an underscore character, but what happens if it does is
> unclear. I think we should explicitely pick one of these:
> a - This is an author level requirement, so using it is invalid, but the
>     behavior is defined, and if there is a frame by that name that doesn't
>     conflict with one of the reserved keywords (although that's a spec
>     violation), the UA must navigate to it anyway.
> b - Same as a, but in addition, "_parent" and "_top" navigate to the parent
>     and root frame, respectively.
> c - This is an author level requirement, so using it is invalid, and the
>     behavior is undefined.
> d - treat as the current frame (same behavior as for non existing frame
>     names)
> e - Parse error
> Presto does a.
> The Samsung chromium implementation does b.
> e sounds like handling this at the wrong layer.
> I think I prefer b. It is invalid, but having interoperable error
> handling is good, and the author intent is clear.
> If we want to prioritize spec advancement over interop, we could do c in
> level 3, and go for b in level 4.

E is the correct behavior.  It's not a layering violation;
<target-name> is just defined as "a <string> that doesn't start with
an underscore".  Nothing wrong with that.

Both A and B are wrong, and violate the spirit of the spec.  The
entire *point* of the restriction is to avoid allowing directional nav
to invoke the special _foo target behaviors.

The behavior *should* be clarified, though, by making it more explicit
that it's invalid.

Received on Tuesday, 14 April 2015 22:57:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC