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

> In response to @emilio's comment -- I don't quite follow the 
concerns, although it's not clear to me that the concern would be 
worse with one approach than the other (rather than the old 
display:inline, which has other serious problems). Though if you still
 think this is problematic, I'd be interested to understand better why
 it is.

Before anything else, I think it is definitely less problematic than 
the other alternatives, I just said that it was less easy than what 
initially thought :)

For replaced elements, which are [defined by a 
spec](https://html.spec.whatwg.org/multipage/rendering.html#replaced-elements),
 I think this is totally ok.

I was thinking more about the other kind of elements that right now 
ignore display: contents in Gecko, such as `<details>` and the famous 
form controls, etc. In particular, I was concerned about elements 
which may create a custom frame in Gecko but not in Blink, or vice 
versa, and thus one engine would respect `display: contents` but the 
other wouldn't, causing interop problems.

I assume that the plan is that this resolution also affects those 
elements? If so, we should clearly define which elements are them and 
which aren't (though that's mostly #1024).

Also, the fact that display: contents is ignored in pseudo-elements 
(`::before { display: contents; content: "foo"; }` renders normally in
 Gecko) feels inconsistent with this resolution, and probably we 
should change the spec to specify that pseudo-elements with `display: 
contents` don't render? (Fine either way from an implementation point 
of view though)

But let me re-instate that I _don't_ think this resolution is by any 
means more problematic than the alternatives :)

-- 
GitHub Notification of comment by emilio
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/540#issuecomment-283438243 
using your GitHub account

Received on Wednesday, 1 March 2017 19:10:24 UTC