Bug 20151 - REGRESSION: CSS not formatting the same as Safari 3.1
Summary: REGRESSION: CSS not formatting the same as Safari 3.1
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac (PowerPC) OS X 10.5
: P1 Normal
Assignee: Dave Hyatt
URL: http://runningfromtherainbow.blogspot...
Keywords: HasReduction, InRadar
Depends on:
Blocks:
 
Reported: 2008-07-23 21:36 PDT by Ross Gibson
Modified: 2022-07-22 21:38 PDT (History)
8 users (show)

See Also:


Attachments
Reduction. (65 bytes, text/html)
2008-07-29 15:19 PDT, Dave Hyatt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ross Gibson 2008-07-23 21:36:12 PDT
In Safari 3.1, and other non-nightly-webkit-build browsers, the all blog entries are color-coded based on two span classes ("Michelle" and "Ross") and corresponding assignments in the CSS template (.Michelle and .Ross).  In at least the last several nightly webkit builds, however, this behavior has changed.  The first several posts on the blog appear in black text as if the span tags or the css are/is being ignored.  The source code still appears correct when choosing "view source" from the view menu in either browser.
Comment 1 Mark Rowe (bdash) 2008-07-24 23:30:08 PDT
<rdar://problem/6101675>
Comment 2 Deirdre Saoirse Moen 2008-07-29 15:08:14 PDT
Could you please post a reduced test case?
Comment 3 Dave Hyatt 2008-07-29 15:15:27 PDT
I am pretty sure this was caused by:

http://trac.webkit.org/changeset/34507

cc'ing Dan.
Comment 4 Dave Hyatt 2008-07-29 15:17:35 PDT
This works in Firefox 3.
Comment 5 Dave Hyatt 2008-07-29 15:19:02 PDT
Created attachment 22543 [details]
Reduction.
Comment 6 Ian 'Hixie' Hickson 2008-07-29 15:42:02 PDT
It's not that simple. Consider for example the rendering of:

<style>p { border: solid; }</style>
<p>a<span>b<div>c<p>d</p>e</div>f</span>g</p>

Right now Webkit (and HTML5) matches IE, but Firefox doesn't, and Opera wouldn't if they actually rendered their DOM (they have hacks in place to fake the rendering in a non-CSS-compliant fashion).

This is a quagmire of an issue, and there's really no good way to get the behaviour IE has reliably without either a non-tree approach or a hidden-data approach, both of which are IMHO really bad. What HTML5 does isn't a perfect match, but it's closer than anything else I have tried so far for most cases.

Maybe we should make <span> into a "formatting element" (with residual style processing)? That seems dangerous if people try to use <span>s from scripts and suddenly find their elements get duplicated all over the place...
Comment 7 Ahmad Saleem 2022-07-22 09:01:36 PDT
I am unable to reproduce this bug in Safari 15.6 on macOS 12.5 based on attached test case, where the text is rendered in 'black' and it matches with other browsers (Chrome Canary 105 and Firefox Nightly 104). I am not sure, whether the web-spec dictates the text to be shown in different color (i.e. purple) but since all browsers are matching, I think this can be considered as "RESOLVED" and can be closed off. Thanks!
Comment 8 Ryosuke Niwa 2022-07-22 21:38:38 PDT
This is expected per HTML5 parsing algorithm.