Summary: | Unclosed CSS block causes incorrect handling of rest of stylesheet | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Elliott Sprehn <esprehn> | ||||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED CONFIGURATION CHANGED | ||||||||
Severity: | Normal | CC: | ap, bfulgham | ||||||
Priority: | P2 | ||||||||
Version: | 523.x (Safari 3) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
Elliott Sprehn
2007-06-05 16:14:06 PDT
Created attachment 14871 [details]
Unclosed block followed by non-type selector.
The text in the examples should be colored the same as the color for each word.
Created attachment 14872 [details]
Unclosed Block Followed By Type Selector
Text should be colored the same as word specifies.
Apparently the handling seems to differ based on if there's a type or non-type selector after the unclosed block. Both behaviors are wrong as per the spec and behavior of FireFox and IE. If there's a type selector Webkit ignores the entire rest of the sheet and the rules in the unclosed block. If there's no type selector Webkit closes the block at the next rule, ignores the that rule, but doesn't ignore the rest of the stylesheet or the rule that was missing the close brace. Behavior as per the spec and the what other browsers do is to make the whole rest of the sheet into "invalid rules" and ignore them, but to respect the rules in the unclosed block that happened before the next rule was encountered. Confirmed with a local debug build of WebKit r21976 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135). Both examples work in Firefox 2.0.0.4 and Opera 9.10. Is this the same bug as 12558? I'm not sure if this can be closed as a duplicate - but it's closely related for sure. Safari, Chrome, and Firefox produce the same output for both test cases. I don't believe any compatibility issues remain for this bug. |