W3C home > Mailing lists > Public > public-css-archive@w3.org > March 2017

Re: [csswg-drafts] [css-display] Define interaction of display:contents and replaced elements

From: L. David Baron via GitHub <sysbot+gh@w3.org>
Date: Wed, 01 Mar 2017 01:34:02 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-283217421-1488332040-sysbot+gh@w3.org>
The reason that the concept of computed value is important is that the
 computed value concept is what inheritance operates on.  Inheritance 
happens as part of style computation.

Software architecture depends on being able to split software into 
pieces in useful ways.  Being able to separate parts of software 
allows both maintainability and the ability to make the pieces happen 
at different times.  While the divisions in different engines are 
somewhat different from each other, many performance optimizations 
that the Web depends on depend on separation between different parts 
of a software system in various ways.  Currently style computation is 
tied to the differences between elements only (I think) via the UA 
stylesheet and via the rules for mapping presentational attributes 
into CSS, which are both forms of specified values that are the normal
 input to the style computation process.  Likewise, style computation 
is separate from selector matching (which happens before it) and from 
box construction (which happens after it), which is in turn separate 
from intrinsic size calculation, which is separate from layout 
calculation, which is separate from painting and compositing.

Currently CSS computed values are a function of specified values 
(which include the UA style sheet, and are based on the results of 
selector matching), which pseudo-element the values are for 
(considering a regular element as a single type), and the computed 
values of the parent (i.e., what the element inherits from) and 
occasionally the grandparent.  We've designed large amounts of 
software around those assumptions.  While we might be willing to the 
substantial amounts of work to stop depending on these assumptions for
 a good reason, I don't want to change them for handling of an edge 
case that wasn't one of the actual use cases for which the feature was
 designed and implemented (and wasn't brought up until a year or so 


I'd also like to point out that there's a third option:  that for 
replaced elements, display:contents just removes the replaced-ness of 
the element and allows the children to display as though the replaced 
element weren't there.  (The previous two options were treating as 
none, and treating as inline.)  I think there's a decent argument that
 this might even be the most logical option.

GitHub Notification of comment by dbaron
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 1 March 2017 01:34:31 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:09 UTC