[Bug 9659] Initial U+0000 should not set frameset-ok to "not ok"

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9659

--- Comment #27 from Henri Sivonen <hsivonen@iki.fi> 2010-10-14 09:36:19 UTC ---
(In reply to comment #26)
> Oh, ok. That one wasn't CDATA-specific, it was a general problem.
> 
> To fix the CDATA-in-HTML-in-SVG issue, a test before the tree constructor is no
> good. We'd have to add a test right in the tokenizer to look at the current
> element in the stack of open elements, as far as I can tell.

Indeed, that's what the spec now says. However, Gecko didn't do it when I fixed
http://html5.org/tools/web-apps-tracker?from=5296&to=5297

> In fact it seems
> orthogonal to whether we use a state in the tree constructor. Am I missing
> something here? Maybe I don't really understand what you had in mind when you
> say you want a test higher up rather than an insertion mode. Could you
> elaborate?

So, for deciding what to do about <![ we have to at minimum examine the
namespace of the current element on the tree builder stack. (And to be clear,
such feedback from tree buider to the tokenizer isn't *at all* a problem for
Gecko, because the whole setup (aka. "architecture" I guess) has been designed
to deal with this kind of feedback.)

Now, the in the tree builder when processing tag tokens, the spec has this "in
foreign content" insertion mode *concept*. This concept is supposed to be an
*optimization* that saves us from inspecting the namespace of the current node
whenever we process a tag token. However, *conceptually*, we want to run the
tag token steps that are now placed in the "in foreign content" mode whenever
the current node is not in the HTML namespace. Furthermore, I believe there
have been multiple (I think at least 4 but maybe even 9) spec bugs that have
been caused by the presence of the "in foreign content" spec-level optimization
and that wouldn't have been caused if the spec had been used the concept of
checking the namespace of the current node first when starting to process a tag
token.

The conclusion I draw from this is that the optimization in the spec has caused
actual harm to the conceptual correctness of the spec. This harm would be
avoided by getting rid of the optimization on the spec level and letting
implementors add optimization on the implementation level if simply
implementing the simpler conceptual model really leads to bad perf. At least
I'm pretty annoyed at having to chase--late in the Firefox 4 cycle--the spec
fixes for the spec bugs that have been caused by the "in foreign content"
optimization.

What I'd like to see is spec that looks like this code:

startTag(...) {
  if (current node not in HTML namespace) {
    if (not token that breaks out) {
       process as a foreign element
       return;
    }
    break out of foreign
  }
  process according to the insertion mode 
}

endTag(...) {
  while (current node not in the HTML namespace) {
    node = pop();
    if (node has the same lowercased name as the current token) {
      return;
    }
  }
  process according to the insertion mode 
}

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 14 October 2010 09:36:21 UTC