[css-writing-modes][css-values] Font metrics calculation on elements which writing-mode doesn't apply to

[upsuper]

I realized that this could be an issue when I was thinking about #1773.

There are some elements that writing-mode doesn't applied to, specifically, table row groups, table column groups, table rows, table columns, ruby base container, and ruby annotation container, per css-writing-modes spec. However, there are some font-relative units defined in css-values which depend on writing-mode property.

The question is, for an element which writing-mode doesn't apply to, should the font-relative units be computed based on the value of the computed (but not applied) writing-mode, or the used writing-mode (from some ancestor)? I guess the same question applies to logical properties as well.

The description of "Applies to" in CSS 2.1 says

All elements are considered to have all properties, but some properties have no rendering effect on some types of elements.

I guess it indicates that the computed value should probably be used? It also seems to me that it could be hard to have style computation based on used value, because that would create more complicated dependencies.

Probably the spec should mention that, although writing-mode doesn't apply to these elements, the style computation is still done based on the computed value of writing-mode of the same element.

[kojiishi]

This looks reasonable to me to use computed values of writing-mode for unit resolutions and logical properties. @nainar, thoughts from the style engine?

[fantasai]

Agreed that we should just use the computed style for simplicity. Agenda+ for WG confirmation.

[fantasai]

Proposed text: replace Applies to lines for writing-mode and text-orientation with “all elements”, and add the following paragraph (where?):

Table row groups, table column groups, table rows, table columns, ruby base containers, and ruby annotation containers use their formatting context’s writing mode for layout. Their 'writing-mode', 'direction', and 'text-orientation' properties are otherwise ignored, except insofar as they affect computed values that depends on them (through e.g. inheritance,
computed font-relative lengths or flow-relative properties).

[upsuper]

Would it make more sense to put this into CSS 2 stating something like "Applies to" doesn't affect CSS computation?

[dbaron]

Section 6.1.2 already says:

The computed value exists even when the property does not apply, as defined by the 'Applies To' line. However, some properties may define the computed value of a property for an element to depend on whether the property applies to that element.

which I think is clear enough one of the underlying points here. It should probably be part of a level 3 draft somewhere if isn't already, though.

(Linking to the 2.1 REC rather than editor's drafts because I've lost track of which editor's draft is which, and which editor's draft (if any) is reliable.)

[dbaron]

It's actually in section 4.4 of css-cascade as well:

The computed value exists even when the property does not apply (as defined by the “Applies To” line). However, some properties may change how they determine the computed value based on whether the property applies to the element.

[css-meeting-bot]

The Working Group just discussed Font metrics calculation on elements which writing-mode doesn't apply to, and agreed to the following resolutions:

• RESOLVED: Add a clarifying note referencing cascade and then close issue #1782

The full IRC log of that discussion

<dael> Topic: Font metrics calculation on elements which writing-mode doesn't apply to
<dael> github: https://github.com//issues/1782#issuecomment-328222293
<dael> astearns: There's a proposed change and I think dbaron had a comment this might be covered?
<dael> fantasai: Possible.
<dael> dbaron: There is text in 2.1 saying applies to doesn't effect computed unless it explicitly says it does.
<dael> fantasai: That's fair. Do we need to clarify in spec?
<dael> dbaron: Possibly. That also feels like it should be in l3
<dael> fantasai: There isn't a L3 of that chapter
<dael> dbaron: It's in definition of computed value which I think would be cascade. I didn't really look at that.
<dael> dbaron: Actually, it's in. I think it's okay
<dael> fantasai: You rec close no change?
<dael> dbaron: I think so unless someone sees something else?
<dael> astearns: Would a note make sense?
<dael> astearns: Fo rimpl clarity?
<dael> fantasai: I can change the proposed text into a note and reference cascade
<dael> astearns: Obj to add a note?
<dael> dbaron: sgtm
<dael> fantasai: If there's a suggestion on section, we can figure that out. I might stick it in module interactions.
<dael> astearns: Sounds alright.
<dael> RESOLVED: Add a clarifying note referencing cascade and then close issue #1782