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

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

From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
Date: Thu, 23 Feb 2017 00:31:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-281851371-1487809904-sysbot+gh@w3.org>
> Problem with making it "behaves as" is that there are plenty of 
other properties that care about the box that the element will 
generate; it's generally very significant whether something generates 
an inline, block, or no box at all. So we can't just push this to 
used-value with the "behaves as" language; this is fundamentally a 
computed-value issue.

While I see your point, knowing both Blink's and Gecko's 
implementation, this is sort of complex to implement at computed value
 time. All the logic to decide whether an element generates a box 
resides on the actual box construction step, with the notable 
exception of `display: none`. Gecko is rewriting the style engine to 
run ahead of box construction (not at the same time). Blink is doing 
[a similar 
 on its engine.

This will mean having to keep track of whether an element generates a 
box when its specified value is `contents` in two different places: at
 style resolution time, and at layout tree construction time, which 
requires significant changes in both engines as far as I can tell 
(specially in Gecko, for the way style sharing works there I think).

How painful or difficult those changes are I don't know ahead of time,

> So impls either need to bite the bullet and allow this computed 
value to depend on form-control-ness (as, according to François, 
Firefox already does?).

Firefox doesn't. For a quick example, the following logs `contents`. 
The work in progress Blink implementation doesn't either (except for 
SVG elements, which I need to clean up depending on this resolution).

<!doctype html>
<button style="display: contents">Foo</button>

> or shoot for a simpler resolution, like making display:contents 
suppress the box like normal (and, as a side-effect of being a form 
control, and thus half-replaced, also suppress its children's boxes, 
like display:none).

This is definitely simpler to implement, though I'm not sure all the 
people would be on board with this. @MatsPalmgren or @rune-opera may 
have opinions here?

GitHub Notification of comment by emilio
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 23 February 2017 00:31:53 UTC

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