New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-display] Should anonymous boxes always inherit through the box tree? #1118

Closed
Loirooriol opened this Issue Mar 22, 2017 · 33 comments

Comments

Projects
None yet
10 participants
@Loirooriol
Contributor

Loirooriol commented Mar 22, 2017

CSS Display says

anonymous boxes (which only exist in the box tree) inherit through their box tree parentage

I think this implies an anonymous box doesn't inherit from its parent element if the parent has display: contents, because that means

The element itself does not generate any boxes

For example,

<section>
  <div>Foo</div>
</section>
section {
  color: red;
}
div {
  color: green;
  display: contents;
}

Foo is wrapped inside an anonymous inline box, so according to the quote above, it should inherit the red color from its parent box, which is the box of the section, because the div does not generate boxes.

But this seems wrong, because if we had

<section>
  <div><span>Foo</span></div>
</section>

then the span would inherit the green color from the div through the element tree.

In Firefox and Chromium the text in the first example is green as expected, I think it's just that the spec is confusing.

@Loirooriol Loirooriol changed the title from [css-display] Should anonymous boxes really inherit through the box tree? to [css-display] Should anonymous boxes always inherit through the box tree? Mar 23, 2017

@fantasai fantasai added the Agenda+ label Apr 7, 2017

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Apr 12, 2017

Contributor

Can we add a test case here?

Contributor

FremyCompany commented Apr 12, 2017

Can we add a test case here?

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Apr 12, 2017

Member

Yeah, I think that terminology is wrong now. We should probably define, for each anonymous box, what its "originating element" is, same as pseudo-elements have, which determines what it inherits from.

Member

tabatkins commented Apr 12, 2017

Yeah, I think that terminology is wrong now. We should probably define, for each anonymous box, what its "originating element" is, same as pseudo-elements have, which determines what it inherits from.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Apr 19, 2017

Member

The CSS Working Group just discussed Should anonymous boxes always inherit through the box tree?.

The full IRC log of that discussion
<astearns> topic: Should anonymous boxes always inherit through the box tree?
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1118
<myles> fantasai: There are anonymous boxes in the box tree. We defined an anonymous box in the box tree has initial values except for the ones which are inherited (from its parent box in the box tree). But! When we have display:contents, if the parent of the anonymous box, then the element's parent is really its grandparent!
<myles> TabAtkins: "parent box" is reasonably well-defined now, but with display:contents, not so much
<myles> fantasai: what I expect is that we look at the parent box in the box tree and we look at the element which generated that box
<myles> fantasai: However, implementations don't look at the box tree, they look at the parent element and its properties.
<myles> fantasai: sooooooo this is busted
<TabAtkins> (Specifically, "parent box" is simple enough, in a pre-display:contents world, that we don't have to worry much about the fact that it's weakly defined. With display:contents, tho, the full box tree starts being more relevant, adn the weak definition si more troublesome.)
<myles> fantasai: so are these bugs? Or should we update the spec?
<myles> TabAtkins: we should do the latter. Inheritance doesn't pay attention to the box tree. The fact that this uses the box tree was hand-wavey
<myles> TabAtkins: <gives obscure example>
<fantasai> <section> <div>Foo</div>
<fantasai> </section>
<fantasai> <section> <div><span>Foo</span></div>
<fantasai> </section>
<fantasai> section { color: red;
<fantasai> }
<fantasai> div { color: green; display: contents;
<fantasai> }
<myles> TabAtkins: explains the example
<myles> dbaron: there are 2 different distinctions to make (but one may not be observable)
<myles> dbaron: gecko recently changed how how anonymous boxes inherit (but only for nested anonymous boxes). Previously, if you have 2 nested ones, one would inherit from the other. Now, all nested boxes inherit from the closest real element.
<myles> Florian: is there an observable difference?
<myles> dbaron: not to regular users
<dbaron> xidorn: what about a writing-mode change on an element with display:contents and text inside it?
<myles> astearns: we need to change the spec to match the implementations
<myles> fantasai: if you have an inline element and its the child of a block, then it's the child of the root inline of that block. If you remove that inline element, then the contents of that inline element (the text) becomes a child of the block's root inline. There's no intervening box belonging specifically to the text. Now, if we make that box go away, there's nothing that is holding the properties that apply to the text other than the root inline. The root inline'
<myles> properties apply tot he text because there's nothing between there.
<myles> fantasai: if you put an inline in between the text and the root inline, give it a property, then pull it away with display:contents, then it's not in the formatting tree. How is it contributing a color when it's gone?
<myles> TabAtkins: inheritance always follow the element tree
<myles> TabAtkins: text doesn't have properties, but it does know things like color
<myles> fantasai: we have to invent this idea of a text frame, and say that it has properties, and it's an anonymous object which you can't get rid of
<myles> TabAtkins: we kind of had to do that with selectors already.
<myles> TabAtkins: we say that clicking on raw text correctly triggers, even when there are intervening shadows & etc.
<myles> fantasai: it is already a thing, but it doesn't have properties. Now we are saying that it has its own properties.
<myles> TabAtkins: yes, to achieve what all implementations do and what makes sense
<myles> TabAtkins: display:contents shouldn't change inheritance
<myles> fantasai: background color doesn't go away when you take away the box
<myles> TabAtkins: in the example in the issue, do you think in the first bit that text should be red?
<myles> TabAtkins: where red is assigned to <section> and green is assigned to <div>
<myles> fantasai: reads really hard
<myles> fantasai: i expected div of to take the color of the section, and div span foo to take the color of the div.
<myles> TabAtkins: i disagree.
<myles> TabAtkins: i agree with the originator and what implementations do
<myles> TabAtkins: we can work through the implementations to make things well-defined
<myles> astearns: this will be difficult to specify.
<myles> fantasai: it requires inventing a new type of box in the inline layout model which we don't' have yet.
<myles> TabAtkins: putting the span in there changes how inheritance works, which changes what users see, and this is unreasonable. The present of an element shouldn't make the color jump over the div.
<myles> Florian: the consequences that a non-styled span changes things is scary.
<myles> astearns: let's table this.
<myles> fantasai: If we make a new box, it belongs in the inline layout module, not this module
<myles> TabAtkins: let's put all the boxes in display:
<myles> fantasai: but you can't create it with display:
<myles> fantasai: TabAtkins: <tries to figure out which modules this should go in>
<myles> astearns: please stop
Member

css-meeting-bot commented Apr 19, 2017

The CSS Working Group just discussed Should anonymous boxes always inherit through the box tree?.

The full IRC log of that discussion
<astearns> topic: Should anonymous boxes always inherit through the box tree?
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1118
<myles> fantasai: There are anonymous boxes in the box tree. We defined an anonymous box in the box tree has initial values except for the ones which are inherited (from its parent box in the box tree). But! When we have display:contents, if the parent of the anonymous box, then the element's parent is really its grandparent!
<myles> TabAtkins: "parent box" is reasonably well-defined now, but with display:contents, not so much
<myles> fantasai: what I expect is that we look at the parent box in the box tree and we look at the element which generated that box
<myles> fantasai: However, implementations don't look at the box tree, they look at the parent element and its properties.
<myles> fantasai: sooooooo this is busted
<TabAtkins> (Specifically, "parent box" is simple enough, in a pre-display:contents world, that we don't have to worry much about the fact that it's weakly defined. With display:contents, tho, the full box tree starts being more relevant, adn the weak definition si more troublesome.)
<myles> fantasai: so are these bugs? Or should we update the spec?
<myles> TabAtkins: we should do the latter. Inheritance doesn't pay attention to the box tree. The fact that this uses the box tree was hand-wavey
<myles> TabAtkins: <gives obscure example>
<fantasai> <section> <div>Foo</div>
<fantasai> </section>
<fantasai> <section> <div><span>Foo</span></div>
<fantasai> </section>
<fantasai> section { color: red;
<fantasai> }
<fantasai> div { color: green; display: contents;
<fantasai> }
<myles> TabAtkins: explains the example
<myles> dbaron: there are 2 different distinctions to make (but one may not be observable)
<myles> dbaron: gecko recently changed how how anonymous boxes inherit (but only for nested anonymous boxes). Previously, if you have 2 nested ones, one would inherit from the other. Now, all nested boxes inherit from the closest real element.
<myles> Florian: is there an observable difference?
<myles> dbaron: not to regular users
<dbaron> xidorn: what about a writing-mode change on an element with display:contents and text inside it?
<myles> astearns: we need to change the spec to match the implementations
<myles> fantasai: if you have an inline element and its the child of a block, then it's the child of the root inline of that block. If you remove that inline element, then the contents of that inline element (the text) becomes a child of the block's root inline. There's no intervening box belonging specifically to the text. Now, if we make that box go away, there's nothing that is holding the properties that apply to the text other than the root inline. The root inline'
<myles> properties apply tot he text because there's nothing between there.
<myles> fantasai: if you put an inline in between the text and the root inline, give it a property, then pull it away with display:contents, then it's not in the formatting tree. How is it contributing a color when it's gone?
<myles> TabAtkins: inheritance always follow the element tree
<myles> TabAtkins: text doesn't have properties, but it does know things like color
<myles> fantasai: we have to invent this idea of a text frame, and say that it has properties, and it's an anonymous object which you can't get rid of
<myles> TabAtkins: we kind of had to do that with selectors already.
<myles> TabAtkins: we say that clicking on raw text correctly triggers, even when there are intervening shadows & etc.
<myles> fantasai: it is already a thing, but it doesn't have properties. Now we are saying that it has its own properties.
<myles> TabAtkins: yes, to achieve what all implementations do and what makes sense
<myles> TabAtkins: display:contents shouldn't change inheritance
<myles> fantasai: background color doesn't go away when you take away the box
<myles> TabAtkins: in the example in the issue, do you think in the first bit that text should be red?
<myles> TabAtkins: where red is assigned to <section> and green is assigned to <div>
<myles> fantasai: reads really hard
<myles> fantasai: i expected div of to take the color of the section, and div span foo to take the color of the div.
<myles> TabAtkins: i disagree.
<myles> TabAtkins: i agree with the originator and what implementations do
<myles> TabAtkins: we can work through the implementations to make things well-defined
<myles> astearns: this will be difficult to specify.
<myles> fantasai: it requires inventing a new type of box in the inline layout model which we don't' have yet.
<myles> TabAtkins: putting the span in there changes how inheritance works, which changes what users see, and this is unreasonable. The present of an element shouldn't make the color jump over the div.
<myles> Florian: the consequences that a non-styled span changes things is scary.
<myles> astearns: let's table this.
<myles> fantasai: If we make a new box, it belongs in the inline layout module, not this module
<myles> TabAtkins: let's put all the boxes in display:
<myles> fantasai: but you can't create it with display:
<myles> fantasai: TabAtkins: <tries to figure out which modules this should go in>
<myles> astearns: please stop
@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Apr 19, 2017

Member

fantasai and I seem to disagree on the behavior - she think the first example should have red text; i find it vaguely horrifying that inserting a non-styled span should have dramatic effects on inheritance in this sole instance.

Assuming we go with "everything should be green", doing this rigorously seems to require us to define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly. I'm down with this.

(Alternately, we can do some handwavey "the element that would generate the text's parent box, if it wasn't display:contents". But that's handwavey and nasty; I'd much prefer to get a better, more rigorous description of text in the CSS model.)

Member

tabatkins commented Apr 19, 2017

fantasai and I seem to disagree on the behavior - she think the first example should have red text; i find it vaguely horrifying that inserting a non-styled span should have dramatic effects on inheritance in this sole instance.

Assuming we go with "everything should be green", doing this rigorously seems to require us to define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly. I'm down with this.

(Alternately, we can do some handwavey "the element that would generate the text's parent box, if it wasn't display:contents". But that's handwavey and nasty; I'd much prefer to get a better, more rigorous description of text in the CSS model.)

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Apr 19, 2017

Contributor

Wouldn't it be unfortunate if

<hgroup>
  <h1>Introduction</h1>
  <p>...
</hgroup>
h1::before { content: "Chapter " counter(h1) ": "; }

would result in "Chapter 1: " and "Introduction" having different colors?

Contributor

FremyCompany commented Apr 19, 2017

Wouldn't it be unfortunate if

<hgroup>
  <h1>Introduction</h1>
  <p>...
</hgroup>
h1::before { content: "Chapter " counter(h1) ": "; }

would result in "Chapter 1: " and "Introduction" having different colors?

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Apr 19, 2017

Collaborator

define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly

For what it's worth, this is what Gecko does anyway. I can't speak for other implementations.

Collaborator

bzbarsky commented Apr 19, 2017

define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly

For what it's worth, this is what Gecko does anyway. I can't speak for other implementations.

@Loirooriol

This comment has been minimized.

Show comment
Hide comment
@Loirooriol

Loirooriol Apr 20, 2017

Contributor

Introducing text boxes would need to rewrite inline layout algorithm in order to take them into account. As I said in #1249 (comment), I think it would be easier (both conceptually and to spec) to handle this by wrapping each contiguous run of text that is directly contained inside an element into an anonymous inline box, which would inherit from the element. In practice it should almost be the same. Thoughts?

Contributor

Loirooriol commented Apr 20, 2017

Introducing text boxes would need to rewrite inline layout algorithm in order to take them into account. As I said in #1249 (comment), I think it would be easier (both conceptually and to spec) to handle this by wrapping each contiguous run of text that is directly contained inside an element into an anonymous inline box, which would inherit from the element. In practice it should almost be the same. Thoughts?

@astearns

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns May 2, 2017

Member

I believe the next step is for @tabatkins to come up with a proposal, so I'm removing the agenda+ waiting for that.

Member

astearns commented May 2, 2017

I believe the next step is for @tabatkins to come up with a proposal, so I'm removing the agenda+ waiting for that.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 15, 2017

Member

Proposed changes:

  • Display - Define that the element tree contains text as well as elements.

  • Cascade - Define how inheritance works over text

  • Scoping - Rigorously define how text moves around due to shadows

  • Text - Maybe some minor changes to rigorously talk about text?

  • Text Decor - clarify whether the magic decoration inheritance is thru the box tree or element tree

  • maybe more?

@fantasai and I are gonna explore what the actual edits need to be before we present this to the WG.

Member

tabatkins commented May 15, 2017

Proposed changes:

  • Display - Define that the element tree contains text as well as elements.

  • Cascade - Define how inheritance works over text

  • Scoping - Rigorously define how text moves around due to shadows

  • Text - Maybe some minor changes to rigorously talk about text?

  • Text Decor - clarify whether the magic decoration inheritance is thru the box tree or element tree

  • maybe more?

@fantasai and I are gonna explore what the actual edits need to be before we present this to the WG.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai May 16, 2017

Contributor

#1281 makes it clear that whatever construct we create to handle the properties of text, it shouldn't be a CSS box.

Contributor

fantasai commented May 16, 2017

#1281 makes it clear that whatever construct we create to handle the properties of text, it shouldn't be a CSS box.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 16, 2017

Member

Okay, we think this is the diff we need:

diff --git a/css-cascade/Overview.bs b/css-cascade/Overview.bs
index c72e6f1c5..f3ba84b99 100644
--- a/css-cascade/Overview.bs
+++ b/css-cascade/Overview.bs
@@ -45,14 +45,22 @@ Introduction</h2>
 <h3 id="placement">
 Module Interactions</h3>
 
+	<em>This section is normative.</em>
+
	<p>This module replaces and extends
 	the rules for assigning property values, cascading, and inheritance defined in [[!CSS21]] chapter 6.
 
	<p>Other CSS modules may expand the definitions of some of the syntax and features defined here.
 	For example, the Media Queries Level 4 specification,
 	when combined with this module, expands the definition of
 	the <<media-query>> value type as used in this specification.
 
+	For the purpose of this specification,
+	<a>text nodes</a> are treated as <a>element</a> children of their associated element,
+	and possess the full set of properties;
+	since they cannot be targetted by selectors
+	all of their computed values are assigned by <a href="#defaulting">defaulting</a>.
+
 <h2 id="at-import">
 Importing Style Sheets: the ''@import'' rule</h2>
 
diff --git a/css-display/Overview.bs b/css-display/Overview.bs
index b101c6eeb..661556484 100644
--- a/css-display/Overview.bs
+++ b/css-display/Overview.bs
@@ -34,21 +34,25 @@ Introduction</h2>
 
 	<p><em>This section is normative.</em>
 
-	CSS takes a source document, organized as a tree of <dfn lt="element|element tree">elements</dfn>,
+	CSS takes a source document, organized as a tree of <dfn lt="element|element tree">elements</dfn> and <dfn>text nodes</dfn>,
 	and renders it onto a <a href="https://www.w3.org/TR/CSS2/intro.html#canvas">canvas</a> (such as your screen, a piece of paper, or an audio stream).
 	To do this, it generates an intermediary structure,
 	the <dfn export>box tree</dfn>,
 	which represents the formatting structure of the rendered document.
-	Each <dfn export>box</dfn> represents its corresponding <a>element</a> (or <a>pseudo-element</a>)
-	in space and/or time on the canvas.
+	Each <dfn export>box</dfn> in the <a>box tree</a>
+	represents its corresponding <a>element</a> (or <a>pseudo-element</a>)
+	in space and/or time on the canvas,
+	while each <dfn export>text run</dfn> in the <a>box tree</a>
+	likewise represents the contents of its corresponding <a>text nodes</a>.
 
 	To create the <a>box tree</a>,
 	CSS first uses <a href="https://www.w3.org/TR/css-cascade/">cascading and inheritance</a>,
 	to assign a <a>computed value</a> for each CSS property
-	to each element in the source tree.
+	to each <a>element</a> and <a>text node</a> in the source tree.
 	(See [[!CSS3-CASCADE]].)
 
-	Then, for each element, it generates zero or more boxes
+	Then, for each element,
+	CSS generates zero or more boxes
 	as specified by that element's 'display' property.
 	Typically, an element generates a single <a>box</a>.
 	However, some 'display' values
@@ -62,6 +66,9 @@ Introduction</h2>
 	They're often referred to by their 'display' type--
 	e.g. a <a>box</a> generated by an element with ''display: block'' is called a “block box” or just a “block”.
 
+	Similarly, each contiguous sequence of sibling <a>text nodes</a> generates a <a>text run</a>,
+	which is assigned the same styles as the generating <a>text nodes</a>.
+
 	An <dfn lt="anonymous|anonymous box" export>anonymous box</dfn> is is a box that is not associated with any element.
 	<a>Anonymous boxes</a> are generated in certain circumstances
 	to fix up the <a>box tree</a> when it requires a particular nested structure
@@ -76,10 +83,11 @@ Introduction</h2>
 	<a href="https://www.w3.org/TR/css-cascade/#inheriting">inherit</a> through their <a>box tree</a> parentage.
 
 	In the course of layout,
-	a <a>box</a> may be broken into multiple <a>fragments</a>.
-	This happens, for example, when an inline box is broken across lines,
+	<a>boxes</a> and <a>text runs</a> can be broken into multiple <a>fragments</a>.
+	This happens, for example, when an inline box and/or text run is broken across lines,
 	or when a block box is broken across pages or columns.
-	A <a>box</a> therefore consists of one or more <a>box fragments</a>.
+	A <a>box</a> therefore consists of one or more <a>box fragments</a>,
+	and a <a>text run</a> consists of one or more <a>text fragments</a>.
 	See [[CSS3-BREAK]] for more information on <a>fragmentation</a>.
 
 	Note: Many of the CSS specs were written before this terminology was ironed out,
@@ -127,16 +135,18 @@ Box Layout Modes: the 'display' property</h2>
 	Media: all
 	</pre>
 
	The 'display' property defines box's <dfn export>display type</dfn>,
 	which consists of the two basic qualities of how an element generates boxes:
 
 	* the <dfn export local-lt="inner">inner display type</dfn>,
		which defines (if it a <a href="https://www.w3.org/TR/CSS2/conform.html#replaced-element">non-replaced element</a>) the kind of <a>formatting context</a> it generates,
 		dictating how its descendant boxes are laid out.
 		(The inner display of a <a href="https://www.w3.org/TR/CSS2/conform.html#replaced-element">replaced element</a> is outside the scope of CSS.)
 	* the <dfn export local-lt="outer">outer display type</dfn>,
 		which dictates how the box participates in its parent formatting context.
 
+	<a>Text runs</a> have no <a>display type</a>.
+
 	Some 'display' values have additional side-effects:
 	such as ''list-item'', which also generates a ''::marker'' pseudo-element,
 	and ''display/none'', which causes the element's entire subtree to be left out of the box tree.
@@ -498,7 +508,7 @@ Box Generation: the ''display/none'' and ''display/contents'' keywords</h3>
 		<dt><dfn>contents</dfn>
 		<dd>
 			The element itself does not generate any boxes,
-			but its children and pseudo-elements still generate boxes as normal.
+			but its children and pseudo-elements still generate box-tree nodes as normal.
 			For the purposes of box generation and layout,
 			the element must be treated as if it had been replaced in the [=element tree=]
 			by its contents
@@ -525,7 +535,10 @@ Box Generation: the ''display/none'' and ''display/contents'' keywords</h3>
 
 		<dt><dfn>none</dfn>
 		<dd>
-			The element and its descendants generate no boxes.
+			The <a>element</a> and its descendants generate no <a>boxes</a> or <a>text runs</a>.
+
+			Similarly, if a <a>text node</a> is defined to behave as ''display: none'',
+			it generates no <a>text runs</a>.
 	</dl>
 
 	Elements with either of these values do not have <a>inner</a> or <a>outer display types</a>,
diff --git a/css-flexbox/Overview.bs b/css-flexbox/Overview.bs
index 6fabce55e..ec53d00c1 100644
--- a/css-flexbox/Overview.bs
+++ b/css-flexbox/Overview.bs
@@ -561,12 +561,12 @@ Flex Items</h2>
 
 	Each in-flow child of a <a>flex container</a>
 	becomes a <a>flex item</a>,
-	and each contiguous run of text that is directly contained inside a <a>flex container</a>
-	is wrapped in an anonymous <a>flex item</a>.
-	However, an anonymous flex item that contains only
+	and each contiguous sequence of child <a>text runs</a>
+	is wrapped in an <a>anonymous</a> <a>block container</a> <a>flex item</a>.
+	However, if the entire sequence of child <a>text runs</a> contains only
 	<a href="https://www.w3.org/TR/CSS2/text.html#white-space-prop">white space</a>
 	(i.e. characters that can be affected by the 'white-space' property)
-	is not rendered (just as if it were ''display:none'').
+	it is instead not rendered (just as if its <a>text node</a> were ''display:none'').
 
 	<div class="example">
 		<p>Examples of flex items:
diff --git a/css-grid/Overview.bs b/css-grid/Overview.bs
index 315f9d9cc..c2851ed59 100644
--- a/css-grid/Overview.bs
+++ b/css-grid/Overview.bs
@@ -963,15 +963,16 @@ Clamping Overly Large Grids</h3>
 Grid Items</h2>
 
 	Loosely speaking, the <dfn export id="grid-item" lt="grid item">grid items</dfn> of a <a>grid container</a>
-	are boxes representing its in-flow contents:
-	each in-flow child of a <a>grid container</a>
-	becomes a <a>grid item</a>.
+	are boxes representing its in-flow contents.
 
-	Each contiguous run of text that is directly contained inside a <a>grid container</a>
-	is wrapped in an anonymous <a>grid item</a>.
-	However, an anonymous grid item that contains only
-	<a href="https://www.w3.org/TR/css-text/#white-space-processing">white space</a>
-	is not rendered, as if it were ''display: none''.
+	Each in-flow child of a <a>grid container</a>
+	becomes a <a>grid item</a>,
+	and each contiguous sequence of child <a>text runs</a>
+	is wrapped in an <a>anonymous</a> <a>block container</a> <a>grid item</a>.
+	However, if the entire sequence of child <a>text runs</a> contains only
+	<a href="https://www.w3.org/TR/CSS2/text.html#white-space-prop">white space</a>
+	(i.e. characters that can be affected by the 'white-space' property)
+	it is instead not rendered (just as if its <a>text node</a> were ''display:none'').
 
 	<div class="example">
 		<p>Examples of grid items:

We reviewed a few other specs that talk about text, particularly Fonts and Writing Modes, and they use "text runs" or "runs of text" in ways that are handwavily-compatible with this "text run" term of art. They could use some cleaning up eventually, but we don't think their lack of precision is necessary to fix at this moment.

Member

tabatkins commented May 16, 2017

Okay, we think this is the diff we need:

diff --git a/css-cascade/Overview.bs b/css-cascade/Overview.bs
index c72e6f1c5..f3ba84b99 100644
--- a/css-cascade/Overview.bs
+++ b/css-cascade/Overview.bs
@@ -45,14 +45,22 @@ Introduction</h2>
 <h3 id="placement">
 Module Interactions</h3>
 
+	<em>This section is normative.</em>
+
	<p>This module replaces and extends
 	the rules for assigning property values, cascading, and inheritance defined in [[!CSS21]] chapter 6.
 
	<p>Other CSS modules may expand the definitions of some of the syntax and features defined here.
 	For example, the Media Queries Level 4 specification,
 	when combined with this module, expands the definition of
 	the <<media-query>> value type as used in this specification.
 
+	For the purpose of this specification,
+	<a>text nodes</a> are treated as <a>element</a> children of their associated element,
+	and possess the full set of properties;
+	since they cannot be targetted by selectors
+	all of their computed values are assigned by <a href="#defaulting">defaulting</a>.
+
 <h2 id="at-import">
 Importing Style Sheets: the ''@import'' rule</h2>
 
diff --git a/css-display/Overview.bs b/css-display/Overview.bs
index b101c6eeb..661556484 100644
--- a/css-display/Overview.bs
+++ b/css-display/Overview.bs
@@ -34,21 +34,25 @@ Introduction</h2>
 
 	<p><em>This section is normative.</em>
 
-	CSS takes a source document, organized as a tree of <dfn lt="element|element tree">elements</dfn>,
+	CSS takes a source document, organized as a tree of <dfn lt="element|element tree">elements</dfn> and <dfn>text nodes</dfn>,
 	and renders it onto a <a href="https://www.w3.org/TR/CSS2/intro.html#canvas">canvas</a> (such as your screen, a piece of paper, or an audio stream).
 	To do this, it generates an intermediary structure,
 	the <dfn export>box tree</dfn>,
 	which represents the formatting structure of the rendered document.
-	Each <dfn export>box</dfn> represents its corresponding <a>element</a> (or <a>pseudo-element</a>)
-	in space and/or time on the canvas.
+	Each <dfn export>box</dfn> in the <a>box tree</a>
+	represents its corresponding <a>element</a> (or <a>pseudo-element</a>)
+	in space and/or time on the canvas,
+	while each <dfn export>text run</dfn> in the <a>box tree</a>
+	likewise represents the contents of its corresponding <a>text nodes</a>.
 
 	To create the <a>box tree</a>,
 	CSS first uses <a href="https://www.w3.org/TR/css-cascade/">cascading and inheritance</a>,
 	to assign a <a>computed value</a> for each CSS property
-	to each element in the source tree.
+	to each <a>element</a> and <a>text node</a> in the source tree.
 	(See [[!CSS3-CASCADE]].)
 
-	Then, for each element, it generates zero or more boxes
+	Then, for each element,
+	CSS generates zero or more boxes
 	as specified by that element's 'display' property.
 	Typically, an element generates a single <a>box</a>.
 	However, some 'display' values
@@ -62,6 +66,9 @@ Introduction</h2>
 	They're often referred to by their 'display' type--
 	e.g. a <a>box</a> generated by an element with ''display: block'' is called a “block box” or just a “block”.
 
+	Similarly, each contiguous sequence of sibling <a>text nodes</a> generates a <a>text run</a>,
+	which is assigned the same styles as the generating <a>text nodes</a>.
+
 	An <dfn lt="anonymous|anonymous box" export>anonymous box</dfn> is is a box that is not associated with any element.
 	<a>Anonymous boxes</a> are generated in certain circumstances
 	to fix up the <a>box tree</a> when it requires a particular nested structure
@@ -76,10 +83,11 @@ Introduction</h2>
 	<a href="https://www.w3.org/TR/css-cascade/#inheriting">inherit</a> through their <a>box tree</a> parentage.
 
 	In the course of layout,
-	a <a>box</a> may be broken into multiple <a>fragments</a>.
-	This happens, for example, when an inline box is broken across lines,
+	<a>boxes</a> and <a>text runs</a> can be broken into multiple <a>fragments</a>.
+	This happens, for example, when an inline box and/or text run is broken across lines,
 	or when a block box is broken across pages or columns.
-	A <a>box</a> therefore consists of one or more <a>box fragments</a>.
+	A <a>box</a> therefore consists of one or more <a>box fragments</a>,
+	and a <a>text run</a> consists of one or more <a>text fragments</a>.
 	See [[CSS3-BREAK]] for more information on <a>fragmentation</a>.
 
 	Note: Many of the CSS specs were written before this terminology was ironed out,
@@ -127,16 +135,18 @@ Box Layout Modes: the 'display' property</h2>
 	Media: all
 	</pre>
 
	The 'display' property defines box's <dfn export>display type</dfn>,
 	which consists of the two basic qualities of how an element generates boxes:
 
 	* the <dfn export local-lt="inner">inner display type</dfn>,
		which defines (if it a <a href="https://www.w3.org/TR/CSS2/conform.html#replaced-element">non-replaced element</a>) the kind of <a>formatting context</a> it generates,
 		dictating how its descendant boxes are laid out.
 		(The inner display of a <a href="https://www.w3.org/TR/CSS2/conform.html#replaced-element">replaced element</a> is outside the scope of CSS.)
 	* the <dfn export local-lt="outer">outer display type</dfn>,
 		which dictates how the box participates in its parent formatting context.
 
+	<a>Text runs</a> have no <a>display type</a>.
+
 	Some 'display' values have additional side-effects:
 	such as ''list-item'', which also generates a ''::marker'' pseudo-element,
 	and ''display/none'', which causes the element's entire subtree to be left out of the box tree.
@@ -498,7 +508,7 @@ Box Generation: the ''display/none'' and ''display/contents'' keywords</h3>
 		<dt><dfn>contents</dfn>
 		<dd>
 			The element itself does not generate any boxes,
-			but its children and pseudo-elements still generate boxes as normal.
+			but its children and pseudo-elements still generate box-tree nodes as normal.
 			For the purposes of box generation and layout,
 			the element must be treated as if it had been replaced in the [=element tree=]
 			by its contents
@@ -525,7 +535,10 @@ Box Generation: the ''display/none'' and ''display/contents'' keywords</h3>
 
 		<dt><dfn>none</dfn>
 		<dd>
-			The element and its descendants generate no boxes.
+			The <a>element</a> and its descendants generate no <a>boxes</a> or <a>text runs</a>.
+
+			Similarly, if a <a>text node</a> is defined to behave as ''display: none'',
+			it generates no <a>text runs</a>.
 	</dl>
 
 	Elements with either of these values do not have <a>inner</a> or <a>outer display types</a>,
diff --git a/css-flexbox/Overview.bs b/css-flexbox/Overview.bs
index 6fabce55e..ec53d00c1 100644
--- a/css-flexbox/Overview.bs
+++ b/css-flexbox/Overview.bs
@@ -561,12 +561,12 @@ Flex Items</h2>
 
 	Each in-flow child of a <a>flex container</a>
 	becomes a <a>flex item</a>,
-	and each contiguous run of text that is directly contained inside a <a>flex container</a>
-	is wrapped in an anonymous <a>flex item</a>.
-	However, an anonymous flex item that contains only
+	and each contiguous sequence of child <a>text runs</a>
+	is wrapped in an <a>anonymous</a> <a>block container</a> <a>flex item</a>.
+	However, if the entire sequence of child <a>text runs</a> contains only
 	<a href="https://www.w3.org/TR/CSS2/text.html#white-space-prop">white space</a>
 	(i.e. characters that can be affected by the 'white-space' property)
-	is not rendered (just as if it were ''display:none'').
+	it is instead not rendered (just as if its <a>text node</a> were ''display:none'').
 
 	<div class="example">
 		<p>Examples of flex items:
diff --git a/css-grid/Overview.bs b/css-grid/Overview.bs
index 315f9d9cc..c2851ed59 100644
--- a/css-grid/Overview.bs
+++ b/css-grid/Overview.bs
@@ -963,15 +963,16 @@ Clamping Overly Large Grids</h3>
 Grid Items</h2>
 
 	Loosely speaking, the <dfn export id="grid-item" lt="grid item">grid items</dfn> of a <a>grid container</a>
-	are boxes representing its in-flow contents:
-	each in-flow child of a <a>grid container</a>
-	becomes a <a>grid item</a>.
+	are boxes representing its in-flow contents.
 
-	Each contiguous run of text that is directly contained inside a <a>grid container</a>
-	is wrapped in an anonymous <a>grid item</a>.
-	However, an anonymous grid item that contains only
-	<a href="https://www.w3.org/TR/css-text/#white-space-processing">white space</a>
-	is not rendered, as if it were ''display: none''.
+	Each in-flow child of a <a>grid container</a>
+	becomes a <a>grid item</a>,
+	and each contiguous sequence of child <a>text runs</a>
+	is wrapped in an <a>anonymous</a> <a>block container</a> <a>grid item</a>.
+	However, if the entire sequence of child <a>text runs</a> contains only
+	<a href="https://www.w3.org/TR/CSS2/text.html#white-space-prop">white space</a>
+	(i.e. characters that can be affected by the 'white-space' property)
+	it is instead not rendered (just as if its <a>text node</a> were ''display:none'').
 
 	<div class="example">
 		<p>Examples of grid items:

We reviewed a few other specs that talk about text, particularly Fonts and Writing Modes, and they use "text runs" or "runs of text" in ways that are handwavily-compatible with this "text run" term of art. They could use some cleaning up eventually, but we don't think their lack of precision is necessary to fix at this moment.

@tabatkins tabatkins added Agenda+ and removed Needs Data labels May 16, 2017

@Loirooriol

This comment has been minimized.

Show comment
Hide comment
@Loirooriol

Loirooriol May 17, 2017

Contributor
  • it is instead not rendered (just as if its text node were ''display:none'').

    I think it should be "text nodes" in plural.

  • each contiguous sequence of sibling text nodes generates a text run, which is assigned the same styles as the generating text nodes

    Should it be noted that this works because text nodes cannot be targeted by selectors, so they must have the same styles?

  • but its children and pseudo-elements still generate box-tree nodes as normal

    The introduction should define "box-tree node" as either a box or a text run.

Contributor

Loirooriol commented May 17, 2017

  • it is instead not rendered (just as if its text node were ''display:none'').

    I think it should be "text nodes" in plural.

  • each contiguous sequence of sibling text nodes generates a text run, which is assigned the same styles as the generating text nodes

    Should it be noted that this works because text nodes cannot be targeted by selectors, so they must have the same styles?

  • but its children and pseudo-elements still generate box-tree nodes as normal

    The introduction should define "box-tree node" as either a box or a text run.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky May 17, 2017

Collaborator

children of their associated element

I assume this is in some sense "before first-line and first-letter are applied"?

Collaborator

bzbarsky commented May 17, 2017

children of their associated element

I assume this is in some sense "before first-line and first-letter are applied"?

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai May 17, 2017

Contributor

@bzbarsky Yeah. The pseudo-elements spec needs to explain itself; currently it does that by pretending to be an element in the inheritance tree (which would effectively hijack the process described here), although there are some complications that need to be properly specced out, e.g. #1097.

Contributor

fantasai commented May 17, 2017

@bzbarsky Yeah. The pseudo-elements spec needs to explain itself; currently it does that by pretending to be an element in the inheritance tree (which would effectively hijack the process described here), although there are some complications that need to be properly specced out, e.g. #1097.

@emilio

This comment has been minimized.

Show comment
Hide comment
@emilio

emilio May 30, 2017

Collaborator

define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly

For what it's worth, this is what Gecko does anyway. I can't speak for other implementations.

Just for reference, this is what Blink does too. But it's not what WebKit does. WebKit doesn't store any style for the text nodes, and just assumes text style == parent box style in the relevant places. Fun :)

Collaborator

emilio commented May 30, 2017

define "text" as an object in the element tree that has properties (only set via inheritance), and which generates "text" in the box tree accordingly

For what it's worth, this is what Gecko does anyway. I can't speak for other implementations.

Just for reference, this is what Blink does too. But it's not what WebKit does. WebKit doesn't store any style for the text nodes, and just assumes text style == parent box style in the relevant places. Fun :)

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk May 31, 2017

@emilio Note that this is just an optimization and not something fundamental.

I'm not entirely convinced that we need all this additional complexity to solve the original case, or that there is even anything to solve. The current behavior where the text turns red is consistent and not difficult to explain.

anttijk commented May 31, 2017

@emilio Note that this is just an optimization and not something fundamental.

I'm not entirely convinced that we need all this additional complexity to solve the original case, or that there is even anything to solve. The current behavior where the text turns red is consistent and not difficult to explain.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky May 31, 2017

Collaborator

The current behavior where the text turns red

Current behavior in WebKit but not in Blink or Gecko, right?

Collaborator

bzbarsky commented May 31, 2017

The current behavior where the text turns red

Current behavior in WebKit but not in Blink or Gecko, right?

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk May 31, 2017

Current behavior in WebKit but not in Blink or Gecko, right?

Right. That is also the behavior you get from the current specs before the revisions suggested here. Introducing the entirely new concept of text node styles (with revisions to multiple specs) just to explain Blink/Gecko behavior here seems bit much.

anttijk commented May 31, 2017

Current behavior in WebKit but not in Blink or Gecko, right?

Right. That is also the behavior you get from the current specs before the revisions suggested here. Introducing the entirely new concept of text node styles (with revisions to multiple specs) just to explain Blink/Gecko behavior here seems bit much.

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk May 31, 2017

Note that I'm not worrying about implementation complexity, I think we could implement this in WebKit without much trouble.

anttijk commented May 31, 2017

Note that I'm not worrying about implementation complexity, I think we could implement this in WebKit without much trouble.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky May 31, 2017

Collaborator

I think it's pretty weird if wrapping a span with no styles applied to it around some text changes the styling of the text. Can you think of any other cases in CSS where that would happen?

In particular, if someone wants to make the text a link target by putting <span id="targetname"> around it, having that change the style of the text seems unfortunate.

Collaborator

bzbarsky commented May 31, 2017

I think it's pretty weird if wrapping a span with no styles applied to it around some text changes the styling of the text. Can you think of any other cases in CSS where that would happen?

In particular, if someone wants to make the text a link target by putting <span id="targetname"> around it, having that change the style of the text seems unfortunate.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot May 31, 2017

Member

The CSS Working Group just discussed [css-display] Should anonymous boxes always inherit through the box tree?, and agreed to the following resolutions:

  • RESOLVED: let's try it out, go forward with the diff
The full IRC log of that discussion <astearns> topic: [css-display] Should anonymous boxes always inherit through the box tree?
<tantek> astearns: and another box tree with anon boxes
<astearns> github bot: https://github.com/w3c/csswg-drafts/issues/1118
<tantek> TabAtkins: this is about inheritance, not normal inheritance
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1118
<tantek> TabAtkins: do they inherit through box tree or element tree
<tantek> TabAtkins: we have a diff in the thread there as a suggestion
<tantek> TabAtkins: aside from a few nits we don't have obj. well we have anti as disagreement
<tantek> TabAtkins: also says webkit could impl without much trouble
<tantek> TabAtkins: it touches several specs
<tantek> TabAtkins: the implication of it is that in the example, first post in the thread
<tantek> TabAtkins: using the code provided where section provides a color and div provies a color
<tantek> TabAtkins: but div is display contents, the text will still be green
<tantek> TabAtkins: it won't turn red just because there is display contents involved
<tantek> astearns: but if the div had an underline?
<tantek> TabAtkins: decorations are weird and should not impinge on this
<tantek> TabAtkins: this is just about normal inheritance
<tantek> TabAtkins: recall these two examples
<TabAtkins> <section color:red><div color:green display:contents>Foo</div></section>
<tantek> TabAtkins: first example, should text be green or red
<TabAtkins> <section color:red><div color:green display:contents><span>Foo</span></div></section>
<tantek> TabAtkins: second, example, there is an absolute correct answer, and no way to question it
<tantek> TabAtkins: 2nd ex span inherits from div in ordinary way, and then foo gets its color from span
<tantek> TabAtkins: just the 1st ex that we have q about
<tantek> TabAtkins: putting in an empty span like that shouldn't change how inheritance works
<tantek> TabAtkins: so the edit we put together, makes node text be stuff in the tree
<tantek> TabAtkins: we have text nodes in the element tree, text runs in the box tree
<tantek> TabAtkins: means inheritance works the same in both cases
<tantek> TabAtkins: (describes color and boxes)
<tantek> astearns: I have not reviewed the diff, but I like the concept as described, would like to go forward
<tantek> TabAtkins: if people feel they need more review that would be fine but if they are ok with it I would like to commit it
<tantek> fremy: for us I think it would be fine
<tantek> astearns: any obj to going fwd with diff?
<tantek> RESOLVED: let's try it out, go forward with the diff
<tantek> astearns: almost to the hour. that's it for today
Member

css-meeting-bot commented May 31, 2017

The CSS Working Group just discussed [css-display] Should anonymous boxes always inherit through the box tree?, and agreed to the following resolutions:

  • RESOLVED: let's try it out, go forward with the diff
The full IRC log of that discussion <astearns> topic: [css-display] Should anonymous boxes always inherit through the box tree?
<tantek> astearns: and another box tree with anon boxes
<astearns> github bot: https://github.com/w3c/csswg-drafts/issues/1118
<tantek> TabAtkins: this is about inheritance, not normal inheritance
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1118
<tantek> TabAtkins: do they inherit through box tree or element tree
<tantek> TabAtkins: we have a diff in the thread there as a suggestion
<tantek> TabAtkins: aside from a few nits we don't have obj. well we have anti as disagreement
<tantek> TabAtkins: also says webkit could impl without much trouble
<tantek> TabAtkins: it touches several specs
<tantek> TabAtkins: the implication of it is that in the example, first post in the thread
<tantek> TabAtkins: using the code provided where section provides a color and div provies a color
<tantek> TabAtkins: but div is display contents, the text will still be green
<tantek> TabAtkins: it won't turn red just because there is display contents involved
<tantek> astearns: but if the div had an underline?
<tantek> TabAtkins: decorations are weird and should not impinge on this
<tantek> TabAtkins: this is just about normal inheritance
<tantek> TabAtkins: recall these two examples
<TabAtkins> <section color:red><div color:green display:contents>Foo</div></section>
<tantek> TabAtkins: first example, should text be green or red
<TabAtkins> <section color:red><div color:green display:contents><span>Foo</span></div></section>
<tantek> TabAtkins: second, example, there is an absolute correct answer, and no way to question it
<tantek> TabAtkins: 2nd ex span inherits from div in ordinary way, and then foo gets its color from span
<tantek> TabAtkins: just the 1st ex that we have q about
<tantek> TabAtkins: putting in an empty span like that shouldn't change how inheritance works
<tantek> TabAtkins: so the edit we put together, makes node text be stuff in the tree
<tantek> TabAtkins: we have text nodes in the element tree, text runs in the box tree
<tantek> TabAtkins: means inheritance works the same in both cases
<tantek> TabAtkins: (describes color and boxes)
<tantek> astearns: I have not reviewed the diff, but I like the concept as described, would like to go forward
<tantek> TabAtkins: if people feel they need more review that would be fine but if they are ok with it I would like to commit it
<tantek> fremy: for us I think it would be fine
<tantek> astearns: any obj to going fwd with diff?
<tantek> RESOLVED: let's try it out, go forward with the diff
<tantek> astearns: almost to the hour. that's it for today
@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk Jun 1, 2017

I think it's pretty weird if wrapping a span with no styles applied to it around some text changes the styling of the text. Can you think of any other cases in CSS where that would happen?

In this case styles are being applied to the span via inheritance. I don't see a major difference between having explicit rules targeting the span vs targeting it's display:contents parent. The behavior is perfectly consistent.

anttijk commented Jun 1, 2017

I think it's pretty weird if wrapping a span with no styles applied to it around some text changes the styling of the text. Can you think of any other cases in CSS where that would happen?

In this case styles are being applied to the span via inheritance. I don't see a major difference between having explicit rules targeting the span vs targeting it's display:contents parent. The behavior is perfectly consistent.

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Jun 1, 2017

Collaborator

In this case styles are being applied to the span via inheritance

Sure.

I don't see a major difference between having explicit rules targeting the span vs targeting it's display:contents parent.

Again, sure, but in your proposed behavior there's a difference: the former would affect the text while the latter would not.

Collaborator

bzbarsky commented Jun 1, 2017

In this case styles are being applied to the span via inheritance

Sure.

I don't see a major difference between having explicit rules targeting the span vs targeting it's display:contents parent.

Again, sure, but in your proposed behavior there's a difference: the former would affect the text while the latter would not.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jun 1, 2017

Member

Right.

Without this "text node"/"text run" concept (just relying on "text is styled according to its enclosing box" concept), the first example in the OP gives red text, because the anonymous inline box that gets generated around the text has to inherit from its parent box, which is generated by the section; while in the second example, it gets green text, because it inherits from the span's generated box, and the span is able to inherit from the div in the element tree.

With this concept, the text node inherits from the div or span in the element tree, getting color:green in both cases.

Member

tabatkins commented Jun 1, 2017

Right.

Without this "text node"/"text run" concept (just relying on "text is styled according to its enclosing box" concept), the first example in the OP gives red text, because the anonymous inline box that gets generated around the text has to inherit from its parent box, which is generated by the section; while in the second example, it gets green text, because it inherits from the span's generated box, and the span is able to inherit from the div in the element tree.

With this concept, the text node inherits from the div or span in the element tree, getting color:green in both cases.

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk Jun 2, 2017

Again, sure, but in your proposed behavior there's a difference: the former would affect the text while the latter would not.

As far as I can gather you are arguing it is strange and surprising that adding a <span> around the text changes its color here. Obviously it wouldn't be surprising at all if there were an explicit rule targeting the span and setting the color. I'm arguing that being styled via inheritance from a display:contents element is no more surprising and the resulting behavior does not necessarily warrant introducing the entirely new concept of "text node styles".

Occam's razor and all that.

anttijk commented Jun 2, 2017

Again, sure, but in your proposed behavior there's a difference: the former would affect the text while the latter would not.

As far as I can gather you are arguing it is strange and surprising that adding a <span> around the text changes its color here. Obviously it wouldn't be surprising at all if there were an explicit rule targeting the span and setting the color. I'm arguing that being styled via inheritance from a display:contents element is no more surprising and the resulting behavior does not necessarily warrant introducing the entirely new concept of "text node styles".

Occam's razor and all that.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jun 5, 2017

Member

Obviously it wouldn't be surprising at all if there were an explicit rule targeting the span and setting the color.

Yes, that would of course be normal and expected. As far as I can tell that's not germane to this issue, tho? Again, the issue is that, without something like what's described here, the inheritance behavior of text depends on whether or not its immediate parent element generates a box. This is inconsistent with how inheritance works for elements, thus the surprise.

I'm arguing that being styled via inheritance from a display:contents element is no more surprising and the resulting behavior does not necessarily warrant introducing the entirely new concept of "text node styles".

I'm very confused by this statement. You're correct that being styled via inheritance from a display:contents element isn't surprising. That's what we're trying to ensure will happen! Right now, as vaguely written, text won't inherit from a display:contents parent element; our concept of "text nodes" carrying styles ensures that it does, like normal elements do.


To help alleviate my confusion about what position you're advocating for, @anttijk, can you quickly say what color you expect the text to be in the two examples in the first comment?

Member

tabatkins commented Jun 5, 2017

Obviously it wouldn't be surprising at all if there were an explicit rule targeting the span and setting the color.

Yes, that would of course be normal and expected. As far as I can tell that's not germane to this issue, tho? Again, the issue is that, without something like what's described here, the inheritance behavior of text depends on whether or not its immediate parent element generates a box. This is inconsistent with how inheritance works for elements, thus the surprise.

I'm arguing that being styled via inheritance from a display:contents element is no more surprising and the resulting behavior does not necessarily warrant introducing the entirely new concept of "text node styles".

I'm very confused by this statement. You're correct that being styled via inheritance from a display:contents element isn't surprising. That's what we're trying to ensure will happen! Right now, as vaguely written, text won't inherit from a display:contents parent element; our concept of "text nodes" carrying styles ensures that it does, like normal elements do.


To help alleviate my confusion about what position you're advocating for, @anttijk, can you quickly say what color you expect the text to be in the two examples in the first comment?

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk Jun 6, 2017

This is inconsistent with how inheritance works for elements, thus the surprise.

We didn't have a case where you could have non-box-generating element with visible text children before display:contents. There is nothing to be inconsistent with; the case is new. It seem that the simplest solution would be that the text properties are defined by the parent box (which is also the specced behavior before the proposed changes here).

I'm very confused by this statement. You're correct that being styled via inheritance from a display:contents element isn't surprising. That's what we're trying to ensure will happen! Right now, as vaguely written, text won't inherit from a display:contents parent element; our concept of "text nodes" carrying styles ensures that it does, like normal elements do.

I don't find it particularly surprising that a non-box generating element doesn't affect child text node style. In fact that's what I would expect. The text node is behaving as if it was a direct child of the box-generating ancestor, something that is easily explained.

Perhaps there is some better example than has been presented here so far why this is a bad or inconsistent behavior? The argument in the original post is that it is surprising that an unstyled element is still being affected via inheritance. I was curious why people found it surprising.

anttijk commented Jun 6, 2017

This is inconsistent with how inheritance works for elements, thus the surprise.

We didn't have a case where you could have non-box-generating element with visible text children before display:contents. There is nothing to be inconsistent with; the case is new. It seem that the simplest solution would be that the text properties are defined by the parent box (which is also the specced behavior before the proposed changes here).

I'm very confused by this statement. You're correct that being styled via inheritance from a display:contents element isn't surprising. That's what we're trying to ensure will happen! Right now, as vaguely written, text won't inherit from a display:contents parent element; our concept of "text nodes" carrying styles ensures that it does, like normal elements do.

I don't find it particularly surprising that a non-box generating element doesn't affect child text node style. In fact that's what I would expect. The text node is behaving as if it was a direct child of the box-generating ancestor, something that is easily explained.

Perhaps there is some better example than has been presented here so far why this is a bad or inconsistent behavior? The argument in the original post is that it is surprising that an unstyled element is still being affected via inheritance. I was curious why people found it surprising.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jun 6, 2017

Member

We didn't have a case where you could have non-box-generating element with visible text children before display:contents. There is nothing to be inconsistent with; the case is new.

Of course the case is new. But before display:contents, "text nodes exists in the element tree, and inherit from their parent element" and "text exists in the box tree, and inherits from its parent box" were indistinguishable. Both behaviors had exactly the same effect (none of the box-tree manipulations that existed prior to display:contents changed the parent box of text in a way that would change the inheritance results).

Thus, you could pretend that inheritance always worked thru the element tree, for all styling. Now, we suddenly have a case that breaks the symmetry, and we have to decide whether we prefer "inheritance always goes thru the element tree" or "inheritance is thru the element tree for elements, and thru the box tree for text". The former is simpler overall, but requires introducing some new concepts to CSS; the latter requires no new spec concepts, but introduces an asymmetry and results that at least some people find surprising.

Neither way is particularly difficult for implementations, as far as I can tell, and thus I strongly prefer the one that doesn't produce a behavior asymmetry.

The argument in the original post is that it is surprising that an unstyled element is still being affected via inheritance. I was curious why people found it surprising.

No, you seem to be misunderstanding the example? It's pointing out the difference in the style of text; the span is used to introduce the styling difference, it's not the point of the example.

The argument in the example is that it would be surprising if the two target elements in the markup below ended up with different color values:

<parent color:red>
  <child display:contents color:green>
    <target />
  </child>
</parent>
<parent color:red>
  <child display:contents color:green>
    <wrapper>
      <target />
    </wrapper>
  </child>
</parent>

In both examples, target should have a computed color of green: in the first example, target directly inherits it from child; in the second example, target inherits from wrapper, but wrapper just inherits it from child, so it should be green as well. (This is standard, non-controversial CSS.)

It's weird, then, that if you replace <target /> with raw text, you'd get a different result - it would be red in the first example, and green in the second. What's the justification for raw text acting differently here? Why, if I add a meaningless wrapper element that doesn't interfere with inheritance at all (for scripting purposes, perhaps), do I get a dramatic difference in inherited value?

Our diff fixes the specs so that this all works consistently, whether it's an element or text.

Member

tabatkins commented Jun 6, 2017

We didn't have a case where you could have non-box-generating element with visible text children before display:contents. There is nothing to be inconsistent with; the case is new.

Of course the case is new. But before display:contents, "text nodes exists in the element tree, and inherit from their parent element" and "text exists in the box tree, and inherits from its parent box" were indistinguishable. Both behaviors had exactly the same effect (none of the box-tree manipulations that existed prior to display:contents changed the parent box of text in a way that would change the inheritance results).

Thus, you could pretend that inheritance always worked thru the element tree, for all styling. Now, we suddenly have a case that breaks the symmetry, and we have to decide whether we prefer "inheritance always goes thru the element tree" or "inheritance is thru the element tree for elements, and thru the box tree for text". The former is simpler overall, but requires introducing some new concepts to CSS; the latter requires no new spec concepts, but introduces an asymmetry and results that at least some people find surprising.

Neither way is particularly difficult for implementations, as far as I can tell, and thus I strongly prefer the one that doesn't produce a behavior asymmetry.

The argument in the original post is that it is surprising that an unstyled element is still being affected via inheritance. I was curious why people found it surprising.

No, you seem to be misunderstanding the example? It's pointing out the difference in the style of text; the span is used to introduce the styling difference, it's not the point of the example.

The argument in the example is that it would be surprising if the two target elements in the markup below ended up with different color values:

<parent color:red>
  <child display:contents color:green>
    <target />
  </child>
</parent>
<parent color:red>
  <child display:contents color:green>
    <wrapper>
      <target />
    </wrapper>
  </child>
</parent>

In both examples, target should have a computed color of green: in the first example, target directly inherits it from child; in the second example, target inherits from wrapper, but wrapper just inherits it from child, so it should be green as well. (This is standard, non-controversial CSS.)

It's weird, then, that if you replace <target /> with raw text, you'd get a different result - it would be red in the first example, and green in the second. What's the justification for raw text acting differently here? Why, if I add a meaningless wrapper element that doesn't interfere with inheritance at all (for scripting purposes, perhaps), do I get a dramatic difference in inherited value?

Our diff fixes the specs so that this all works consistently, whether it's an element or text.

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk Jun 8, 2017

@tabatkins Thank you for restating the basic facts of the case. The actual argument seems to boil down to a personal preference.

I don't think we should abandon the "only elements and pseudo-elements have style" invariant for this. It is valuable in explaining and understanding how CSS works. That this requires little or no spec changes is a bonus.

I'm opposed to making these changes. CSSWG should just clarify that text style is determined by the box tree (if it is currently unclear).

No, you seem to be misunderstanding the example?

I understand the example perfectly and already explained why I don't find the behavior surprising at all.

anttijk commented Jun 8, 2017

@tabatkins Thank you for restating the basic facts of the case. The actual argument seems to boil down to a personal preference.

I don't think we should abandon the "only elements and pseudo-elements have style" invariant for this. It is valuable in explaining and understanding how CSS works. That this requires little or no spec changes is a bonus.

I'm opposed to making these changes. CSSWG should just clarify that text style is determined by the box tree (if it is currently unclear).

No, you seem to be misunderstanding the example?

I understand the example perfectly and already explained why I don't find the behavior surprising at all.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 8, 2017

Contributor

I don't think we should abandon the "only elements and pseudo-elements have style" invariant for this.

This seems less important than the "adding a non styled span in the middle inline content has no effect on rendering" invariant. If we could keep both, that'd be great. But as it seems we cannot, this one seems more important to preserve.

Contributor

frivoal commented Jun 8, 2017

I don't think we should abandon the "only elements and pseudo-elements have style" invariant for this.

This seems less important than the "adding a non styled span in the middle inline content has no effect on rendering" invariant. If we could keep both, that'd be great. But as it seems we cannot, this one seems more important to preserve.

@anttijk

This comment has been minimized.

Show comment
Hide comment
@anttijk

anttijk Jun 8, 2017

@frivoal There is no such thing as "non-styled span" in a rendered document. In this case the span is getting styled via inheritance which I find no more surprising than being styled by explicit "span { color:green }".

anttijk commented Jun 8, 2017

@frivoal There is no such thing as "non-styled span" in a rendered document. In this case the span is getting styled via inheritance which I find no more surprising than being styled by explicit "span { color:green }".

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 8, 2017

Contributor

@anttijk I meant a span on which there is no specified styles.

Contributor

frivoal commented Jun 8, 2017

@anttijk I meant a span on which there is no specified styles.

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jul 5, 2017

Contributor

@anttijk It is a general principle here that a bit of text and a <span>bit</span> of text, where <span> has no style rule applying to it, render identically. This invariant is more important than any intuition about how things should work.

Contributor

fantasai commented Jul 5, 2017

@anttijk It is a general principle here that a bit of text and a <span>bit</span> of text, where <span> has no style rule applying to it, render identically. This invariant is more important than any intuition about how things should work.

@tabatkins tabatkins closed this in dbb7042 Jul 5, 2017

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue Jul 6, 2017

[css-display] 各種更新
Commits on Jul 6, 2017

Note that 'display: contents' does not affect property inheritance.
Fixes w3c/csswg-drafts#1473
w3c/csswg-drafts@356b329
d005a73bfc9

Normatively define what was in the previous note: that run-in fixup
occurs before first line determination.
w3c/csswg-drafts@37c01a4
31f8898ed4d

Move computed value bullet before box generation bullet.
w3c/csswg-drafts@5d10db8
88236d37ccb

Clarify that run-in fixup occurs before block/inline fixup.
w3c/csswg-drafts@6f6913e
9c01e8b2186

Expand out informal definitions of BFC.
Also fixes w3c/csswg-drafts#1471 .
w3c/csswg-drafts@388b1fb
a10787c9121

Refer to 'flow layout' directly, rather than just mentioning the types
of boxes that flow layout can produce.
Fixes w3c/csswg-drafts#1470 .
w3c/csswg-drafts@09212af
e3fdcd86e06

Make the run-in recursion explicit, so it's clear the second step
doesn't recurse.
Fixes w3c/csswg-drafts#1460 .
w3c/csswg-drafts@c9f1bb1
52eeff5abf1

Be a little looser about what counts as abspos, because css-lists
defines as out-of-flow.
Fixes w3c/csswg-drafts#1458
w3c/csswg-drafts@f7ff606
ba04f13a2f8

Remove the w3c/csswg-drafts#1390 inline issue.
w3c/csswg-drafts@4514b3e
90fc2def209

Add note about the two categories of box-tree fixup, and their relative
ordering.
Fixes w3c/csswg-drafts#1355 .
w3c/csswg-drafts@f5b79e9
0bc69b90786

Apply diff, per resolution.
Fixes w3c/csswg-drafts#1118 .
w3c/csswg-drafts@dbb7042
f338d8ad944

hubot pushed a commit to WebKit/webkit that referenced this issue Oct 17, 2017

antti@apple.com
Text nodes with display:contents parent should render as if they were…
… wrapped in an unstyled <span>

https://bugs.webkit.org/show_bug.cgi?id=178332

Reviewed by Ryosuke Niwa.

Source/WebCore:

According to w3c/csswg-drafts#1118

    <div style="display:contents;color:green">text</div>

must result in green text even though div doesn't generate a box.

This patch implements the behavior by wrapping text renderers with display:contents parent element
in an anonymous inline box that receives its style by inheriting from the parent element.

* dom/Document.cpp:
(WebCore::Document::updateTextRenderer):
* rendering/RenderElement.cpp:
(WebCore::RenderElement::computeFirstLineStyle const):

    Synthesize the first line style in display:contents parent case.

* rendering/RenderObject.cpp:
(WebCore::findDestroyRootIncludingAnonymous):

    Factor into a function.

(WebCore::RenderObject::removeFromParentAndDestroyCleaningUpAnonymousWrappers):

    Get rid of the anonymous wrapper if it exists.

* rendering/RenderText.cpp:
(WebCore::inlineWrapperForDisplayContentsMap):
(WebCore::RenderText::RenderText):
(WebCore::RenderText::willBeDestroyed):
(WebCore::RenderText::inlineWrapperForDisplayContents):
(WebCore::RenderText::setInlineWrapperForDisplayContents):

    Add a weak member (implemented as a rare data map) for holding the wrapper pointer.

(WebCore::RenderText::findByDisplayContentsInlineWrapperCandidate):

    Helper to get the text renderer for a wrapper.

* rendering/RenderText.h:
* style/RenderTreeUpdater.cpp:
(WebCore::createTextRenderer):
(WebCore::RenderTreeUpdater::updateTextRenderer):

    Create the wrapper if needed.

* style/StyleTreeResolver.cpp:
(WebCore::Style::TreeResolver::resolveComposedTree):

    Compute the wrapper style by inheriting from the display:contents parent.

* style/StyleUpdate.h:
(WebCore::Style::TextUpdate::TextUpdate):

LayoutTests:

* TestExpectations: 10 more display:contents tests pass.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@223514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment