Bug 20151

Summary: REGRESSION: CSS not formatting the same as Safari 3.1
Product: WebKit Reporter: Ross Gibson <RossGGG>
Component: CSSAssignee: Dave Hyatt <hyatt>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: ahmad.saleem792, ap, bfulgham, ian, mitz, rniwa, simon.fraser, webkit
Priority: P1 Keywords: HasReduction, InRadar
Version: 528+ (Nightly build)   
Hardware: Mac (PowerPC)   
OS: OS X 10.5   
URL: http://runningfromtherainbow.blogspot.com
Attachments:
Description Flags
Reduction. none

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.