Bug 19573

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: DOMAssignee: 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:
Description Flags
Case reduction none

Rafa Barbera
Reported 2008-06-16 02:57:21 PDT
When using body { font-size:20px; } the table elements didn't show at this size.
Attachments
Case reduction (2.25 KB, text/html)
2008-06-16 02:59 PDT, Rafa Barbera 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Rafa Barbera
Comment 1 2008-06-16 02:59:18 PDT
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
mitz
Comment 2 2008-06-16 09:54:21 PDT
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 }
Rafa Barbera
Comment 3 2008-06-16 10:44:29 PDT
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
mitz
Comment 4 2008-06-16 10:54:50 PDT
(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.
Alexey Proskuryakov
Comment 5 2008-06-16 13:08:33 PDT
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.
mitz
Comment 6 2008-06-16 22:30:22 PDT
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>.
mitz
Comment 7 2008-06-16 22:40:33 PDT
...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.
Alexey Proskuryakov
Comment 8 2008-06-16 22:55:08 PDT
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).
Rafa Barbera
Comment 9 2008-06-16 23:33:23 PDT
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"
Alexey Proskuryakov
Comment 10 2008-06-17 00:09:09 PDT
(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.
Rafa Barbera
Comment 11 2008-06-17 00:15:31 PDT
>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.
Note You need to log in before you can comment on or make changes to this bug.