- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 14 Apr 2015 15:56:25 -0700
- 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. ~TJ
Received on Tuesday, 14 April 2015 22:57:13 UTC