This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See https://bugzilla.mozilla.org/show_bug.cgi?id=588357 and http://software.hixie.ch/utilities/js/live-dom-viewer/saved/597 Pre-HTML5 Gecko, pre-HTML5 WebKit and Opera 9.60 (but no longer Opera 10.61) allow the </div> close the object. Note that the joystiq page uses conditional comments to serve different markup to IE.
Conditional comments are evil. It's like UA detection in the parser.
I strongly desire to not change this. Is the joystiq page the only one that we have run into that breaks with this? Would three major browsers soon shipping with this change have any impact in terms of getting them to fix their obviously broken markup? Especially since they've recently updated it specifically for HTML5 (it uses <video>)?
(In reply to comment #2) > I strongly desire to not change this. I sympathize. Can you elaborate why, though? > Is the joystiq page the only one that we > have run into that breaks with this? It's the only one I've seen. > Would three major browsers soon shipping > with this change have any impact in terms of getting them to fix their > obviously broken markup? Maybe. > Especially since they've recently updated it > specifically for HTML5 (it uses <video>)? Aside: The site uses <object> and <video> the wrong way round--presumably to cater to iOS but not caring about HTML5 on desktop.
(In reply to comment #3) > > I strongly desire to not change this. > > I sympathize. Can you elaborate why, though? It's just an especially brittle part of the parser, and changing it tends to result in more bugs. Do we know what IE8 does here? (It's hard to test earlier IEs due to IE's crazy parsing behaviour with <object>, but IIRC IE8 isn't as bad so might be testable.)
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I'm rejecting this on the premise that joystiq is actively maintained and might be responsive to advocacy here. Please reopen the bug (with information on what IE does) if it turns out that there are more pages affected by this or if joystiq is not responsive to the information that a big chunk of their users are about to be upgraded to browsers that don't render their site correctly due to a bug on their site.
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.
The spec is trying to match IE's old parser, not WebKit's. WebKit's old parser had nowhere near the same level of deployment. In particular, the scoping behaviour is trying to emulate IE's scoping behaviour, not WebKit's. <button> was a special case that we changed due to a compat issue where IE's old behaviour was less compatible than what the spec now says. The joystiq case is special because they're using conditional comments to send IE different markup. What was the other site that the problem was seen on?
(In reply to comment #7) > What was the other site that the problem was seen on? The sidebar on http://johneepixels7.tumblr.com/post/1343104367
Firefox trunk, Chrome trunk, Opera, and IE8 all render it the same. The only browsers I could find that renders that page as intended are old builds of Firefox and Safari. I count that as a win for the spec, personally. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The spec improves interop here.