On Sun, 29 Jan 2006, Henri Sivonen wrote:
> >
> > I understood your system to be:
> >
> >[TOKENISER] --> [PREPROCESSOR] --> [PARSER]
> >
> > ...where the preprocessor rearranges tokens, and the parser creates
> > the DOM. How does your system handle the cases above without blocking
> > in
I did some testing in Internet Explorer with Ruby markup using the Live DOM
Viewer. Here are the results:
element
This element is closed by and . This element is required as a
container. Otherwise the following elements have no "rendering semantics". Much
like with the element.
Internet Expl
Simon Pieters wrote:
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
As far as I can tell both of these DOCTYPEs are considered conformant,
but shouldn't the first be an easy parse error?
Why? Both trigger standards mode as far as I can tell. :-)
It did in the browsers I tested too, but
Hi,
From: Lachlan Hunt <[EMAIL PROTECTED]>
As far as I can tell both of these DOCTYPEs are considered conformant, but
shouldn't the first be an easy parse error?
Why? Both trigger standards mode as far as I can tell. :-)
* Why is it marked as being error at that stage? It doesn't se
On Jan 27, 2006, at 09:16, Ian Hickson wrote:
In that case I don't understand your proposal.
We need something that, given this:
X
...results in this DOM:
BODY
EM
P
...and given this:
X
...results in this DOM:
BODY
EM
P
EM
Given that "X" can be a
