[css-lists] Consider new value for counter-reset

[lcchueri]

Use case: To help solve issues #3746 and #5389 , which both needs counting sublevels of sub/super scripts for MATHML.

To use as many generic CSS properties for MathML as possible, I propose to use the list counters in a more generic way:

Considering also, from issue #1026, enabling the use of counter() inside calc() for property font-size, these counter may be used to control font-size and other styles.

Proposition A:
Consider parent as new value for counter-reset
<counter-name> parent value removes the innermost counter that originates from a sibling or its child, instantiating a counter of given name from parent element with the parent counter value.

for example, UA style for sup/sub element would be something like

sub, sup {
counter-reset: countSubLevel parent;
counter-increment: countSubLevel +1;
font-size: calc(20px-counter(countSubLevel));
}

Proposition B:
Or, instead of new value for counter-reset, may be a new property named counter-remove, as:

property: counter-remove
value: <counter-name>+ | none
inherited: no

counter-remove removes counters names from counter set of the element that comes from siblings and their child.

It happens after New Counters are instantiated and before counter values are incremented.

[faceless2]

This specific proposal doesn't look like it would solve the case for MathML font sizing. The algorithm makes reference to two constants from the OpenType MATH table when the internal script-level counter is 1 or 2, falling back to a power function (0.71 ^ level, IIRC) beyond that. You couldn't represent that with a calc() expression.

I'm also against counter-remove, solely because counter scoping rules are complicated enough already.

However, the concept of creating a new counter but copying its value from the parent - your "counter-reset: countSubLevel parent" - is pretty trivial to implement, for us anyway. It also feels like it somehow might be incredibly useful, I just can't quite put my finger on why. In your example you're effectively using it to count how deep your element is in the element tree. I wonder what other use-cases we could find for that?

[lcchueri]

The purpose of both propositions in this issue is to produce information about measure of depth (sub-level) of the structure.

The example above I gave: font-size: calc(20px-counter(countSubLevel)) was a dummy example, only to demonstrate consuming an information produced about depth of sub-level by counters.

For the remaining of the problem, creating new functions for calc, may help.
Ex.: power(n, m)
Or may be one to choose constants (or sub-expressions) like decode function from the Oracle-database-SQL for select by the sub-level value which expression to use. ex.: decode(countSubLevel, 1, constant 1, 2, constant 2, ..., default) .

Note: Propose these expressions power, or, decode for the complete solution is not in the scope of this issue. To have a way to expose depth by reusing list counters is the proposition.

[lcchueri]

Republishing A-proposition, hoping to do a better explanation.

The A-proposition counter-reset: <counter-name> parent, first copies all counters from sibling (or parent), as section 4.4.1, and changes how it operates in step 3 of algorithm of section 4.4.2, copying value from parent instead a given integer.

property: counter-reset
value: [ <counter-name> [ parent | <integer> ]? ]+ | none
inherited: no

Note: There is still a syntax problem, that would prohibit parent to be a counter name

 1. Let counters be element’s CSS counters set.

 2. Let innermost counter be the last counter in counters with the name name. If innermost counter’s originating element is element or a previous sibling of element, remove innermost counter from counters.

 3. Append a new counter to counters with name name, originating element element, and 
 
  1. If initial value is an integer initializes with this.

  2. Else if string **parent**, gets the initial value from parent element's counter with the same name.

[lcchueri]

Republishing B-proposition, with algorithm.

B) a new property counter-remove

property: counter-remove
value: <counter-name>+ | none
inherited: no

operation of counter-remove would precede counter-reset.

It removes named counters coming from the preceding sibling (if exists), so can be reused the named counters of the parent element (if they are in parent's counter set)

This way, each sibling will have the same start value coming from it's parent. So post operation counter-increment, will indicate the same level value for all siblings.

Section 4.4.1 algorithm for counter-remove. New steps 3 and 4 expands from original algorithm step 3.

1. Let _element counters_ be an initially empty CSS counters set representing element’s own CSS counters set.

2. If _element_ is the root of its document tree, return. (The element has an initially-empty counter map and inherits nothing.)

3. If the _element_ has a preceding sibling

  1. Let _counter source_ be the CSS counters set of _element_’s preceding sibling.

  2. Let _sibling element_ be the _element_’s preceding sibling

  3. Let _counter to remove_ be the CSS property counter-remove named counters.

  4. For each (_name_, _originating element_, _value_) of _counter source_:

    1. If _counter to remove_ also contains a counter with the same _name_ and _originating element_ is the _sibling element_, then remove a copy of _value source_’s counter (_name_, _originating element_, _value_) from _counter source_.

4. Else Let _counter source_ be the CSS counters set of _element_’s parent.

5. Let _value source_ be the CSS counters set of the element immediately preceding _element_ in tree order.

6. For each (_name_, _originating element_, _value_) of _value source_:

  1. If _counter source_ also contains a counter with the same _name_ and _originating element_, then append a copy of _value source_’s counter (_name_, _originating element_, _value_) to _element counters_.

[fantasai]

The purpose of counters is to count siblings, not depth. If math needs a depth counter, let's add a depth counter as a separate feature.

[lcchueri]

@fantasai , I see your point.

Reviewing @faceless2 comment and reviewing issues #3746 and #5389, I see I misunderstood the problem. Count depth needs a arbitrary start point in the structure, values would be absolute and would not help calculation of properties relative to the parent's properties. And also would inform which kind of elements were between the start of counting and the point being evaluated. So would be a problem to arbitrary choose which element to start counting.

The core of of the problem of both issues just needs knows de upper element's properties, and calculate its own properties from it. So, counting depth is useless.

I conclude the entire concept of counting depth is useless. I apologize.

[fred-wang]

The purpose of counters is to count siblings, not depth. If math needs a depth counter, let's add a depth counter as a separate feature.

Just to clarify, the current proposals that were discussed and agreed within the MathML CG are #5387 #5389 ; as said in comment #5402 (comment), it is not clear whether this one addresses all the use cases needed for math (e.g. using scale constants from the OpenType MATH table or conditional increase depending on display style).