Bug 19573 - 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)
Summary: REGRESSION: Doctype is not parsed unless it's at the very beginning of the do...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (Intel) OS X 10.5
: P1 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-16 02:57 PDT by Rafa Barbera
Modified: 2008-06-17 00:15 PDT (History)
2 users (show)

See Also:


Attachments
Case reduction (2.25 KB, text/html)
2008-06-16 02:59 PDT, Rafa Barbera
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rafa Barbera 2008-06-16 02:57:21 PDT
When using 

body { font-size:20px; }

the table elements didn't show at this size.
Comment 1 Rafa Barbera 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
Comment 2 mitz 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
}
Comment 3 Rafa Barbera 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
Comment 4 mitz 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.
Comment 5 Alexey Proskuryakov 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.
Comment 6 mitz 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>.
Comment 7 mitz 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.
Comment 8 Alexey Proskuryakov 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).
Comment 9 Rafa Barbera 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"
Comment 10 Alexey Proskuryakov 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.
Comment 11 Rafa Barbera 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.