| Summary: | REGRESSION: Doctype is not parsed unless it's at the very beginning of the document (font-size didn't inherit from body to table elements) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Rafa Barbera <rbarberac> | ||||
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED WONTFIX | ||||||
| Severity: | Normal | CC: | ap, mitz | ||||
| Priority: | P1 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Mac (Intel) | ||||||
| OS: | OS X 10.5 | ||||||
| Attachments: |
|
||||||
Created attachment 21724 [details]
Case reduction
All the text in this page should present the same size. It works fine in Safari 3.1.1
From quirks.css:
/* Tables reset both line-height and white-space in quirks mode. */
/* Compatible with WinIE. Note that font-family is *not* reset. */
table {
white-space: normal;
line-height: normal;
font-weight: normal;
font-size: medium;
font-variant: normal;
font-style: normal;
color: -webkit-text;
text-align: -webkit-auto
}
I don't understand the quirks mode issue. The sample is declared as HTML 4.01 strict. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Regards (In reply to comment #3) > I don't understand the quirks mode issue. The sample is declared as HTML 4.01 > strict. The DOCTYPE is not parsed. Looking at the source, I see that it begins with *two* UTF-8-encoded BOMs (EF BB BF repeated twice), and I believe the second one throws the parser off. Safari 3.1.1 is OK even with text garbage before the DOCTYPE (just as Firefox is), so this change is not just something caused by BOM handling changes. Looks like entering quirks mode and ignoring the DOCTYPE is the right thing to do according to <http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#the-initial>. ...and IE agrees with TOT: attachment 21724 [details] is rendered the same in IE. Removing one BOM changes the rendering (so that the table text is the same size as body text) in IE and in TOT.
After a discussion in #webkit, the consensus appears to be that we want to match IE, Opera and HTML5, not Firefox. According to HTML5, only whitespace and comments are allowed before DOCTYPE (and implicitly, a single BOM as the very first character). Ok, I'm with you in that the correct way to handle this case is to go into quirks mode. But are there any way to know that the browser is working in quirks mode? All the <DOCTYPE> related conditions are easy to spot looking at the HTML source. But the BOM one is not, because it's an invisible-no-breaking-space character, so you need to use a hexeditor to see them. In my case, there are two developers working on a django project, one is working with TextMate in OS X and other with a windows editor (notepad+). This last one is putting a UTF-8 BOM. After that the Django development server is adding other UTF-8 BOM. But looking at the sources of the HTML with a text editor, I can't see nothing before the <DOCTYPE>. This will be a hard to spot "feature-working-as-a-bug" (In reply to comment #9) > But are there any way to know that the browser is working in > quirks mode? There is always alert(document.compatMode), although it is admittedly only helpful when you already suspect something like that. > But the BOM one is not, because it's an invisible-no-breaking-space character, > so you need to use a hexeditor to see them. This is very true. In some similar cases, this can even lead to security bugs, so it is particularly important to handle invisible characters to the letter of the spec, so that all browsers and security filters agree on the same behavior. >There is always alert(document.compatMode), although it is admittedly only >helpful when you already suspect something like that. Well, after this incident I'll always suspect something like that ;-). >In some similar cases, this can even lead to security bugs, >so it is particularly important to handle invisible characters to the letter of >the spec, so that all browsers and security filters agree on the same behavior. Yes, it seems the way to go. |
When using body { font-size:20px; } the table elements didn't show at this size.