- From: SelenIT via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Apr 2017 07:15:10 +0000
- To: public-css-archive@w3.org
@Loirooriol I can agree with any interpretation that would not require 'Foo' and 'Bar' in the example becoming separate flex items :). I believe that the ability to place content of different elements in the same 'run of text' (whatever that means) is one of the key advantages of `display:contents` (comparing to old values like `display:inline`), and I strongly disagree to remove it. The contents of the element with `display:contents` may be implemented as a separate text box, but this text box should never be 'blockified' etc. by itself. In my opinion, if the content of the element with `display:contents` ends up being a separate flex/grid item, it directly contradicts the requirement that 'the element creates no boxes'. I agree with @MatsPalmgren that the current implementations of Gecko and Blink match the intent of the spec. I believe that the spec should reflect this behavior and this behavior should not be changed. As I understand the [comment](https://github.com/w3c/csswg-drafts/issues/1118#issuecomment-295451992) by @bzbarsky, we already have the concept of styleable 'text', separate from 'anonymous inline box', in reality. May be we should specify it? > even if some character is not supported by the font and a fallback is used, its text box will still have the same specified font. display: contents allows adjacent text boxes to have different specified styles. I didn't suggest it's exactly the same, but I see many similarities between these situations from the rendering perspective. Different characters in the same run of text already can have different _actual values_ of `line-height` which affects the layout, and browsers are able to handle this. Maybe introducing something like 'text box' concept would be useful for both cases? -- GitHub Notification of comment by SelenIT Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1281#issuecomment-297631791 using your GitHub account
Received on Thursday, 27 April 2017 07:15:17 UTC