- From: Florian Rivoal <florian@rivoal.net>
- Date: Wed, 15 Apr 2015 16:24:55 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>
> On 15 Apr 2015, at 00:56, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > > 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. I wasn't sure we were OK with dealing at the parser level with the content of a string rather that just parsing it as a string, and letting the next layer worry about it's semantics (or lack thereof). If we can, then yes, E is probably the right answer. The downside is that E is not what either of the existing implementations I am aware of do. I don't have easy access to the corpus of existing content to assess if we'd have a compat problem to do that. These properties are heavily used on TV sites, so there is legacy content to consider. Less interesting, but still worth thinking about is the question of spec advancement. To get to level 3 past CR quickly, it may make things easier to do the more lenient option C in level 3, and only tighten it up in level 4. - Florian
Received on Wednesday, 15 April 2015 14:25:21 UTC