Closed Bug 638487 Opened 14 years ago Closed 10 years ago

buzzmachine.com + all default & Kubrick based WordPress themes - <div id="footer"> ends up outside <div id="page"> due to bad nesting in markup

Categories

(Web Compatibility :: Desktop, defect)

Product:
Web Compatibility
Component:
Desktop
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: richard, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase, Whiteboard: [due to html5 parser][see comments 4, 7, 12])

Attachments

(1 file, 1 obsolete file)

Testcase #2
(deleted), text/html
Details
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre On some Wordpress.com sites, the background of the center column stops before the center column content using Firefox 4.0.13pre but not Firefox 3.6.14. Reproducible: Always Steps to Reproduce: 1.Browse to http://buzzmachine.com 2.Scroll down 3. Actual Results: Center column background stops before the end of the center column content. Expected Results: Expect the site to render as it does on Firefox 3.6.14 with the center column background extending to the end of the center column content. Safari 5.0.3 (6533.19.4) renders the sample site the way Firefox 3.6.14 does (appears to be correct). Chrome 9.0.597.45 beta renders the sample site the way Firefox 4.0b13pre does (appears to be incorrect).
Correction. Buzzmachine.com appears to be an externally hosted Wordpress site, not a Wordpress.com site.
Confirmed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303030406 Using m-c... Last good nightly: 2010-05-06 First bad nightly: 2010-05-07 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=014349e11696&tochange=ca591da19a26 Using TM... Last good nightly: 2010-05-17 First bad nightly: 2010-05-18 Pushlog: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=e5ae28ee811b&tochange=955bfaadaebb The TM range being much after the m-c range presumably implies that the break happened on m-c, rather than TM, other than that I don't really have any clue what changeset might have caused the problem or if this is a case for tech evang? Errors from console: ------ Error: syntax error Source File: http://claimid.com/api/mylinks?id=jeffjarvis&limit=10 Line: 1 Source Code: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Security Error: Content at http://googleads.g.doubleclick.net/ may not load data from http://www.buzzmachine.com/. Error: syntax error Source File: http://www.publish2.com/search/links?newsgroup=jeff+jarvis+links&tag=wwgd&number_of_items=5&callback=jsonp1299184124137 Line: 1 Source Code: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ------ NB: This is broken for me in Chrome 11.0.686.1 dev as well. Ideas?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → general
Summary: Firefox 4.0b13pre renders some Wordpress Sites differently than 3.6.14 → buzzmachine.com styling broken as of 2010-05-07 nightly
Whiteboard: [TE?]
Version: unspecified → Trunk
Sorry, would appear I made a mistake in the m-c range. Even on the 'good' builds, you sometimes have to wait 2-3 seconds before the styling fully updates for the site (you can tell when it has, since the Google Ads will appear down the right hand side), which presumably on one of the last bisections caused me to think it was a bad, when in fact was a good. Corrected range... Last good nightly: 2010-05-03 First bad nightly: 2010-05-04 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519 HTML5 parser was enabled by default then, so tested latest nightly with html5.parser.enable set to false and http://buzzmachine.com/ displays fine. Suspect this may still be TE, but marking as blocking bug 373864 until someone can decide either way.
Blocks: html5-parsing
Component: General → HTML: Parser
QA Contact: general → parser
Summary: buzzmachine.com styling broken as of 2010-05-07 nightly → buzzmachine.com styling broken as of 2010-05-04 nightly
Whiteboard: [TE?] → [html5 parser; evang?]
The page is similarly broken in IE8. Browsers with HTML5 parsers (Firefox 4, Chrome 11, Opera Ragnarök) all render the page the same way as IE8. So does IE9. My conclusion is that the HTML5 parsing algorithm is more successful at modeling the parsing behaviors of IE8 (and older) than the old parsers in Firefox, Safari or Opera were. Hooray for interop. After already having spent too much time trying to pinpoint the problem, I give up. I think it's the site author's responsibility to debug this further and find the mismatched tags somewhere in there.
Assignee: nobody → english-us
Component: HTML: Parser → English US
Product: Core → Tech Evangelism
QA Contact: parser → english-us
Summary: buzzmachine.com styling broken as of 2010-05-04 nightly → buzzmachine.com, <div id="footer"> ends up outside <div id="page"> due to yet unidentified error in the HTML markup
Whiteboard: [html5 parser; evang?]
Version: Trunk → unspecified
Can't disagree with Henri that this isn't worth a lot of time, but I have seen this on a couple of other Wordpress sites as well, so I suspect it may be in the Wordpress theme. Buzzmachine appears to be using a custom theme named "buzzmachine", but I suspect that it's cloned from a stock theme. I'll send the folks at buzzmachine an email pointing out the problem and giving them a link to this bug.
(In reply to comment #5) > I suspect it may be in the Wordpress theme. > Buzzmachine appears to be using a custom theme named > "buzzmachine", but I suspect that it's cloned from a stock theme. Theme Name: BuzzMachine Theme URI: http://buzzmachine.com/ Description: BuzzMachine theme based on the famous <a href="http://binarybonsai.com/kubrick/">Kubrick</a>.
OK, I can confirm that this is a problem with some themes. I added the "Default" theme (also based on Kubrick), to a blog running the Atahualpa theme. It renders properly when Atahualpa is activated. If I switch to "Default" the same background problem we see with BuzzMachine appears. The bad news is that "Default" was the default WordPress theme until recently and is in use on thousands of sites. In the WordPress theme repository there are also about a dozen additional themes based on Kubrick and about two dozen based on "Default". The good news is that "TwentyTen", the current default theme shipped with WordPress, appears to work properly. I'll post a warning note in the WordPress Forums with a link to this bug. I'm guessing the right answer is mark this bug Won't Fix.
(In reply to comment #7) > I'll post a warning note in the WordPress Forums with a link to this bug. Spotted your post here: http://wordpress.org/support/topic/default-and-kubrick-based-themes-fail-on-new-browsers?replies=1 Awesome, thanks!
Attached file Testcase #1 (obsolete) (deleted) —
There's a difference in parsing <ul> <div> <li>
If anyone has a contact inside WordPress it might be a good idea to have them make that post a "sticky" in the themes forum before the FF4 release. (URL in comment 8)
Seems like I'm not really getting through to them on that support post. Not sure why we bothered!
Attached file Testcase #2 (deleted) —
The last test was correct, but my comment on it wasn't, the nesting is: <div id="sidebar"> <ul> <li> <div> <li></li> </div> AFAICT, we handle it according the HTML5 spec - the second <li> auto-closes the second <div> and first <li>, then the </div> auto-closes the <ul> and closes <div id="sidebar">, the rest ends up as siblings to "sidebar".
Attachment #517124 - Attachment is obsolete: true
Ed: I tried to whip up a little interest on the #WordPress irc channel on Freenode but didn't have any luck. Monday I'll see if Jane Finette has an email address for the VP of Marketing over there. He used to be at Mozilla. I'm sure he'll grok the problem.
Mats: Being a bear of very little brain, I've never really understood how the parsers work internally. Does this mean that all pages get parsed as HTML5 regardless of the contents of the DocType?
(In reply to comment #12) > The last test was correct, but my comment on it wasn't, the nesting is: > <div id="sidebar"> > <ul> > <li> > <div> > <li></li> > </div> Thanks. It looks like we build the tree the same way as IE6 and IE7 do as well (IE8 and IE9 were already mentioned). So indeed this is an interoperability success of the HTML5 parsing algorithm.
Whiteboard: [due to html5 parser]
Ed: Thanks for the help in the WordPress Themes Forum! They don't seem to grok the issue. I re=posted under the title "Theme Suddenly Stops Working" which should make it easier for non-techies to find when the avalanche hits.
Summary: buzzmachine.com, <div id="footer"> ends up outside <div id="page"> due to yet unidentified error in the HTML markup → buzzmachine.com + all default & Kubrick based WordPress themes - <div id="footer"> ends up outside <div id="page"> due to bad nesting in markup
Whiteboard: [due to html5 parser] → [due to html5 parser][see comments 4, 7, 12]
The theme has been changed it seems.
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Component: English US → Desktop
Resolution: --- → INVALID
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: