Quoting Ian Hickson [EMAIL PROTECTED]:
Another problem (which I just noticed on CNN.com) is that if we say that
noframes creates nodes, browsers will be creating nodes for img
elements that previously they were not creating, which will cause a
different set of images to be fetched from the
On Fri, 27 Jan 2006 13:36:46 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
2. With the described algorithm it's possible to build DOM with, for
example, two TITLE nodes, which is invalid. At what point should it be
handled?
Not sure what you are asking. The title parsing is fully defined in
On Fri, 27 Jan 2006, Alexey Feldgendler wrote:
Sadly, that's not compatible with the Web.
UAs that support frames treat noframes as CDATA. That mea, e.g.,
that script tags inside noframes don't get executed, and that
input elements inside noscript don't get added to forms. We can't
Ian Hickson wrote:
On Sat, 28 Jan 2006, Lachlan Hunt wrote:
Why can't it just be defined that noframes and noscript content gets
parsed exactly as regular markup
Because there are a _lot_ of side-effects of parsing as regular markup.
e.g.
noframes
style.../style
i Foo
On Sat, 28 Jan 2006, Lachlan Hunt wrote:
Ok, I think the noframes case can be handled something like this and the
noscript can probably be handled in a similar way.
link and style
Moved to the document head (just like normal erroneous link element
in the body).
If frames are
On Fri, 27 Jan 2006 08:08:49 +0600, Ian Hickson [EMAIL PROTECTED] wrote:
Ok, I specced out what I think is a workable algorithm that works a lot
better than what we had before.
It still only supports p and em elements inside body for now, but
at least it does so in a way compatible with
On Fri, 27 Jan 2006, Alexey Feldgendler wrote:
1. What happens with the following: script src=1.jsscript
src=2.js (without closing tags)?
Nothing yet, I haven't specced out the script start tag.
I plan to say that it would be treated as script src=1.js, with the
element containing the
