- From: <bugzilla@jessica.w3.org>
- Date: Wed, 27 Oct 2010 13:34:03 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10427
Henri Sivonen <hsivonen@iki.fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|WONTFIX |
--- Comment #6 from Henri Sivonen <hsivonen@iki.fi> 2010-10-27 13:34:01 UTC ---
Reopening, since this problem was reported as a Firefox bug when seen on
another site.
It's not clear to me what exactly makes the legacy WebKit tree builder treat
these cases the same way:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/659
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/681
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/682
But this is different:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/680
These cases are more interesting and all the same:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/683
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/685
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/686
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/687
If we use the old WebKit tree builder as our guide (I think we should), the
first conclusion is that marquee and applet should become like button and
object should first become like button and then *maybe* we should add the
special case for object that explains the saved/680 difference above.
Looking at the old WebKit source code, it's clear that the "scoping" concept in
the old WebKit tree builder is about preventing <p> from autoclosing--not about
trying to blackhole end tags whose start tag is on the stack behind a scoping
element.
--
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 Wednesday, 27 October 2010 13:34:07 UTC