Skip to content

[css-lists] counter scopes should be based on box tree, not element tree #674

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.

Sign up for GitHub

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

Jump to bottom
Open
upsuper opened this issue Nov 3, 2016 · 8 comments
Open

[css-lists] counter scopes should be based on box tree, not element tree #674

upsuper opened this issue Nov 3, 2016 · 8 comments
Labels
css-lists-3 Current Work topic: shadow

Comments

@upsuper
Copy link
Member

upsuper commented Nov 3, 2016

CSS Lists and Counters spec says:

An element that does not generate a box ... cannot set, reset, or increment a counter. The counter properties are still valid on such an element, but they must have no effect.

While there is an issue listed in CSS Display spec says:

ISSUE 1 contents currently only has an effect on box generation and layout. Other things that care about the document tree are unaffected, like counter scopes. Is this what we want?

I'm not sure if there is any normative text in CSS Display spec leads to that issue, but given that the issue exists, there might be some disagreement between the two specs we may want to resolve.
@upsuper upsuper added css-display-3 Current Work css-lists-3 Current Work labels Nov 3, 2016
@fantasai
Copy link
Collaborator

fantasai commented Jan 3, 2017

The issue is currently open because no one presented use cases or implementation constraints that would indicate which definition is the better one to have... Would be good to have Mats or bz comment on this!

@fantasai fantasai removed the css-display-3 Current Work label Jan 24, 2017
@fantasai fantasai changed the title [css-lists][css-display] The two specs may disagree on whether element with "display: contents" should create counter scope [css-lists] counter scopes should be based on box tree, not element tree Jan 24, 2017
@fantasai
Copy link
Collaborator

CSSWG concluded in Seattle that counters should be operating on the box tree. I've removed the issue in CSS Display; CSS Lists will need an update, though, so re-assigning.

@lilles
Copy link
Member

lilles commented Oct 2, 2017 •
edited
Loading

Ran into counter issues in the display:contents implementation in Blink.

So, by box tree, do you mean that the ::before counters below should both be displaying 1 (anonymous table-row around the cell)?:

<!DOCTYPE html>
<style>
  div > div::before { content: counter(x); }
</style>
<div style="display:table">
  <div style="display:table-cell; counter-increment: x 1">X</div>
  <div style="display:table-row;  counter-increment: x 1">Y</div>
</div>

Also, box tree means that you'll get "1X" and "2Y" below:

<!DOCTYPE html>
<style>
  .count { counter-increment: x 1 }
  .count::before { content: counter(x); }
</style>
<div style="display:contents">
  <div class="count">X</div>
</div>
<div class="count">Y</div>

For Shadow DOM and distribution I think box tree (or flat tree) makes sense.

Blink currently uses light tree traversal, but uses flat tree traversal for style containment for counters.

@jonjohnjohnson
Copy link

Just wanted to offer a set of testcases...

...for which safari still has an open ticket/bug that kind of relates https://bugs.webkit.org/show_bug.cgi?id=187718

@jonjohnjohnson
Copy link

@fantasai when you say...

CSSWG concluded in Seattle that counters should be operating on the box tree. I've removed the issue in CSS Display; CSS Lists will need an update, though, so re-assigning.

Does this mean the working group already made a decision here? And that decision makes geckos and blinks implementations not aligned with the impending specification edits? And that the behavior in webkit will be considered correct?

See this test case between those three vendors -> http://jsfiddle.net/5rcjk9gv/4

I ask, because aside from this reduced test case, I have run into wanting geckos/blinks behavior a few times, while never having a use for webkits.

@dbaron
Copy link
Member

dbaron commented Jun 2, 2019

@jonjohnjohnson - could you briefly explain the cases where you ran into wanting the gecko/blink behavior?

@w3c w3c deleted a comment from css-meeting-bot Jun 5, 2019
@jonjohnjohnson
Copy link

@dbaron Currently, if you view both:

  1. http://jsfiddle.net/5rcjk9gv/3
  2. http://jsfiddle.net/5rcjk9gv/4

Their only difference is css line 5, changing the counter-increment from targeting an element that has no box, because of display:contents, to an element that is the descendant of an element that has no box. The first case is consistent and seems desirable across vendors. The second case only seems desirable in gecko/blink. In gecko/blink, sharing the incrementing through the display:content "layer" has allowed me better semantics and more portable/component styling. In webkit, the second case doesn't allow the same shared incrementing through the display:content ancestor, only incrementing once for each inner most element that outputs the counter.

Case 2 - Gecko/Blink

Screen-Shot-2019-06-05-at-1 02 37-PM

Case 2 - Webkit

Screen Shot 2019-06-05 at 1 02 19 PM

For all I really know, what I'm asking about is supported by the current box tree defined state of the spec, but I just haven't understood the answers to me question yet related to the cases I've linked here for the third time. :/

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed counter scopes should be based on box tree, not element tree.

The full IRC log of that discussion <dael> Topic: counter scopes should be based on box tree, not element tree
<dael> github:
<dael> github: https://github.com//issues/674
<dael> TabAtkins: fantasai added the agenda. I'm curious why. There's a person asking about implications but don't know what to discuss
<dael> fantasai: I don't remember
<dael> astearns: We have a comment with different cases
<dael> TabAtkins: I need to look through his HTML cases to figure out what they're trying to favor. I think we have to defer for now
<dael> astearns: My reading is here are the cases that show a difference. not sure they're picking a side

@astearns astearns removed the Agenda+ label Jun 19, 2019
@css-meeting-bot css-meeting-bot mentioned this issue Jun 19, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-lists-3 Current Work topic: shadow
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@jonjohnjohnson @dbaron @upsuper @fantasai @lilles @astearns @annevk @css-meeting-bot