Consider the following simple markup:
!doctype html/br
If I run it through my parser, which is implemented after the html5
algorithm, the resulting dom is as follows:
html
head
body
The br end tag is a bit special, and should be handled as if it was a br
start tag. What happens here
Anne van Kesteren wrote:
On Thu, 04 Dec 2008 11:51:05 +0100, timeless [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 12:34 PM, Tommy Thorsen [EMAIL PROTECTED]
wrote:
This matches Internet Explorer and Opera, but not Firefox and
Safari. Then
again, it looks like Firefox and Safari ignore all
Ian Hickson wrote:
On Wed, 12 Nov 2008, Tommy Thorsen wrote:
Consider the following markup:
pobjectpX/p/p
The html5 parsing algorithm produces the following tree:
htmlhead/headbodypobjectpX/pp/p/object/p/body/html
whereas Firefox and Opera both produce:
htmlhead/headbodypobjectpX
Consider the following markup:
pobjectpX/p/p
The html5 parsing algorithm produces the following tree:
htmlhead/headbodypobjectpX/pp/p/object/p/body/html
whereas Firefox and Opera both produce:
htmlhead/headbodypobjectpX/p/object/p/body/html
and IE produces:
Ian Hickson wrote:
On Mon, 10 Nov 2008, Tommy Thorsen wrote:
FWIW: In our implementation, I've changed the handling of base and
title in in body to:
Process the token using the rules for the after head insertion
mode.
instead of processing them with the rules for in head
Henri Sivonen wrote:
On Nov 11, 2008, at 13:27, Tommy Thorsen wrote:
The assertion that the current node is still the head element pointer
does not seem correct, as we push a script element onto the stack of
open elements in the A start tag whose tag name is 'script' section
of the in head
Ian Hickson wrote:
On Mon, 10 Nov 2008, Tommy Thorsen wrote:
From an implementors point of view, it's good to have clearly defined
boundaries between modules. An implementation would typically have one
module that tokenises and parses html and one module that renders the
resulting dom
This one is kinda complex, but I'll try to explain the problem. The
algorithm for handling script start tags in the after head insertion
mode requires us to push the head element pointer onto the stack of open
elements, then process the token using the rules for the in head
insertion mode.
Simon Pieters wrote:
The description of the title element in the spec (4.2.2 The title
element) says:
Contexts in which this element may be used:
In a head element containing no other title elements.
I don't care very strongly about whether or not title elements are
allowed
I noticed that, according to the html5 algorithm, when the parser sees a
title start tag when in the in body insertion mode, it's not
supposed to relocate it to the head element. Opera matches this
behaviour, but Firefox moves any title tag it finds into the head element.
The description of
In the handler for 'A start tag whose tag name is li' in in body,
the algorithm says jump to the last step in a couple of places. Is
the last step step 5, or is it the final unnumbered step which says,
Finally, insert an HTML element for the token?
I suggest, to make this clearer, that we
we've had to deviate
from the specification in order to tackle problems discovered by our
testers, and if any of you are interested in this kind of feedback, I'll
dig them out and post them on this list.
Best regards
Tommy Thorsen
, ignore the token.
The Otherwise does not really make sense in this context, does it?
Should that last sentence just be erased?
Regards,
Tommy Thorsen
13 matches
Mail list logo
