[css-properties-values-api] var() references to <length> type properties with font-relative lengths

[tim-loh]

Consider a property --font-size, registered to be of <length> type. What should the computed values of font-size and --font-size be?

--font-size: 10em;
font-size: var(--font-size);

If --font-size is substituted as "10em", then font-size is 10*parent and --font-size is 100*parent. If it is substituted after computation then what value do we use for the em unit?

[tabatkins]

Oh dang, this is a difficult question. I didn't anticipate this adding a new cyclic dependency. (Good thing currentcolor is converted at used-value time, or else it'd cause the same problem with color.)

We'll need to make an arbitrary decision here. I think my preferred solution is to lean on normal variable dependency-cycle resolution - custom properties containing a font-relative length (this requires them to be typed, with a <length> member) add an edge to the dependency graph marking them as depending on font-size, so in your example, the var() reference would be treated as invalid.

[jyc]

Is it valid to conceptualize this as there being a phony variable font-size and have cycle detection treat all dimension tokens with font size relative lengths in variables whose set of possible syntaxes contains <length>, <length-percentage>, or <transform-list> (anything where we could have a length) like it would treat var(font-size)?

Should the following declarations with --messy being an unregistered custom property and--some-transform-list being registered with syntax <transform-list> and initial value scale(1) end up with the font-size inheriting and --some-transform-list being ""?

It seems like because the 5em is actually the argument to scale which takes a <number> rather than perspective which takes a <length>, if var(--messy) were substituted then the declaration of --some-transform-list would be syntactically invalid and font-size be computed as 16px. However, if we are trying to detect cycles before substituting, then we can't know what parameter 5em ends up as the argument for, and can only assume the worst.

--messy: ) scale(
--some-transform-list: perspective(var(--messy) 5em);
font-size: var(--some-transform-list, 16px);

EDIT: Oops, can't have the unmatched ). But we can end up with the same effect I was intending (--some-transform-list is syntactically invalid if --messy is substituted) by just having --messy: ,.

[jyc]

Also, what about rems? Should these only create a cycle when we're at the root?

[jyc]

Actually, it seems like maybe something even stronger (like the following) would be needed:

font-size dependency cycles

Use of em units in typed custom property declarations can lead to dependency cycles involving the declaration for font-size, the directed tree of dependencies with font-size at its root has a node corresponding to a registered custom property whose syntax would require computations depending on the font-size, and either uses em units in its declaration, or has some child in the dependency tree corresponding to a variable whose declaration includes a dimension token with an em unit.

This is because even if the n em dimension token is not contained in the literal text of a declaration for a typed custom property whose syntax would require the font-size, an n em token might end up being substituted for a variable reference to another property which might not even require such computation; for example, an unregistered custom property, or one declared with syntax *.

EDIT: I have a patch to implement this for Servo.

[css-meeting-bot]

The Working Group just discussed var() references to type properties with font-relative lengths, and agreed to the following resolutions:

• RESOLVED: specify full set of unit and depdancyies and using that in exisitng variable dependancy logic. This issue is solved from there.

The full IRC log of that discussion

<nainar> Topic: var() references to type properties with font-relative lengths
<nainar> GitHub: https://github.com//issues/315
<nainar> TabAtkins: Issue has the case <look at it>
<nainar> TabAtkins: <Explains issue as written in github issue>
<nainar> TabAtkins: Preferr to lena on dependancy resolution. They should gain a dependacy on the font zie property and a cyclic dependacy would make the property invalid at computed time.
<nainar> dbaron: This isnt ehe only case of unit type dependacy on property.
<nainar> TabAtkins: Generalize to other properties too.
<nainar> dbaron: Is this only for typed custom props?
<nainar> TabAtkins: Yes.
<nainar> Discussion about naming typed/registered custom propries
<nainar> TabAtkins: Are we doing to get in this case 100px and 1000 px for font size and variable
<nainar> TabAtkins: Or will we get somethign invalid with font size returning to 1 em?
<nainar> dbaron: var reference is referencing a computed value it should be invalid.
<nainar> TabAtkins: Make sure I capture all teh cases that dcan cause this and add to graph. I am down with this.
<nainar> Rossen: <agrees>
<nainar> astearns: Property is invalid right?
<nainar> TabAtkins: If invalidation happens font would be invalid and retun to inherit.
<nainar> astearns: Typed property would be fine?
<nainar> TabAtkins: Yes
<nainar> dbaron: What about units that depend on font selection?
<nainar> dbaron: What if you use a calc expression in one of those units?
<nainar> TabAtkins: you can do this for font weight for e.g
<nainar> TabAtkins: they are depdant on font peropeties and if you depend on that you have a cyclic dependacy
<nainar> dbaron: Hard - that there is a dependacy graph in everyone's head - need to write this down
<dbaron> https://wiki.csswg.org/spec/property-dependencies
<nainar> fremy: Can you define font size as a custom property and get in the same situation?>
<nainar> TabAtkins: NO in that case you get a percent if y9ou ask for a computedvalue
<nainar> fremy: so a % can stay as a % on computedtime
<nainar> <discussion about link>
<nainar> TabAtkins: These tables need to be translated to spec txt for completion
<nainar> xidorn: color and currentColor comment in issue doesnt apply. currentColor should be computed at computedvalue tinme not used value time.
<nainar> TabAtkins: Yes it does.
<nainar> tantek: People want to specify full set of unit and depdancyies and using that in exisitng variable dependancy logic
<tantek> s/tantek/???
<nainar> Rossen: Solution to this issue would fall out of it?
<nainar> TabAtkins: ues
<TabAtkins> s/ues/yes/
<tantek> s/???/TabAtkins
<nainar> RESOLVED: specify full set of unit and depdancyies and using that in exisitng variable dependancy logic. This issue is solved from there.

[frivoal]

We need to:

• count all font-relative units other than rem and rlh (em, ch, ex, cap, ic, lh) as depending on font-size
• count lh as also depending on line-height
• count rem and rlh as depending on font-size when used on the root element
• count rlh as also depending on line-height when used on the root element

I think in terms of unit–property dependencies, that should cover it, no?

[andruud]

@tabatkins Close?