- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 19 Jun 2007 00:49:59 +0000 (UTC)
On Sun, 24 Dec 2006, Anne van Kesteren wrote: > > On Sat, 23 Dec 2006 11:06:33 +0100, Anne van Kesteren <annevk at opera.com> > wrote: > > So we pass "<p><b><i><u></p><p>X" but not <p><b><i><u></p> <p>X" it seems. > > Found the problem. The "in body" insertion mode says to "reconstruct the > active formatting elements" for any character token. That should > probably only happen for non space characters. When I made that change I > passed the testcase given and didn't regress any other testcase. > > I should note though that Firefox handles a newline differently from a > space. See: > > http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cp%3E%3Cu%3E%3C/p%3E%0A%3Cp%3EX > > http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cp%3E%3Cu%3E%3C/p%3E%20%3Cp%3EX > > In case of a space it seems the active formatting elements are > reconstructed. Safari treats them all the same (and does reopen the formatting tags)... Given that the algorithm in the spec matches Safari's, and is relatively inexpensive when doing aggressive reopening, do we want to just keep what's in the spec? Did html5lib have to change for compatibility to handle this case or...? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 18 June 2007 17:49:59 UTC