- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2023 16:56:52 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values] Consider requiring same relative <length> units in atan2()`, and agreed to the following: * `RESOLVED: font-relative units resolve against the parent element when used in any font-* property (and anything else that affects font selection)` * `RESOLVED: Do something similar for line-height (details TBD)` <details><summary>The full IRC log of that discussion</summary> <fantasai> scriben+<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Emilio brought up originally, if your two calculations in atan2() have different units with potentially different calculation times (e.g. 'em' vs 'px'), can cause circular dependency issues<br> <fantasai> TabAtkins: this washes the units away into plain numbers, allowing them to be used in more places<br> <fantasai> TabAtkins: but if you use this property in other properties that affect resolution of those units it's a problem<br> <fantasai> TabAtkins: agree it's an issue, but not specific to atan2()<br> <fantasai> TabAtkins: it's a property of calc() unit division in general<br> <fantasai> TabAtkins: e.g. calc(1em/1ex) is a number<br> <fantasai> TabAtkins: Agree this is an issue, but we need to solve generally<br> <fantasai> TabAtkins: not address atan2() specifically<br> <fantasai> emilio: I agree<br> <fantasai> emilio: Firefox considers atan2() of two different lengths that aren't absolute, we consider that invalid and don't parse it<br> <TabAtkins> yeah that exact restriciton is *nonsensical*<br> <fantasai> emilio: I guess my question is, at least WebKit is completely broken and just ignores the units<br> <fantasai> emilio: this is an issue, but we shouldn't parse different units if we don't support the units<br> <fantasai> emilio: agree it's a general issue<br> <fantasai> TabAtkins: for the font-dependent units, when used directly where they can affect the resolution<br> <fantasai> TabAtkins: we resolve against parent element instead, and this resolves the circular dependency<br> <fantasai> TabAtkins: Can we do that here?<br> <fantasai> emilio: Using the parent makes sense<br> <fantasai> emilio: It's a little bit tricky<br> <fantasai> emilio: Note that implementation-wise this isn't only issue<br> <astearns> q+<br> <TabAtkins> 1) font-dependent units are invalid in proeprties where they're problematic, or 2) font-dependent units resolve based on parent metrics instead<br> <fantasai> emilio: also now things that can resolve to a number resolve eagerly, but with these units cannot<br> <fantasai> emilio: I agree resolving to parent font is less ugly solution<br> <fantasai> emilio: whether that's enough for custom properties etc, I need to think... probably it is?<br> <fantasai> emilio: Would be great to have a central place for these dependencies<br> <fantasai> astearns: Wanted clarification on using parent value for these things<br> <fantasai> astearns: that's in all contexts, not just when using calc() in problematic property?<br> <fantasai> TabAtkins: No, that would be fundamentally incompatible with existing usage of calc()<br> <fantasai> TabAtkins: using width in 'em' uses element's own font size, correct and necessary to maintain<br> <fantasai> TabAtkins: this is wrt font-dependent units, or other property-dependent units<br> <fantasai> astearns: Concern that if you use same function in two different properties, you might get different results<br> <astearns> ack astearns<br> <fantasai> TabAtkins: if you use font-size: 2em; and width: 2em they're different<br> <fantasai> TabAtkins: this just expands the set of properties affected, because unit algebra allows putting them in places not currently accepting units<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i agree - ideally doing same as font-size makes the most sense. probablyl should say generally for font-relative units in the font-* properties<br> <TabAtkins> fantasai: dont' think there's anything reasonable to do besides making them invalid, which is less godd<br> <TabAtkins> fantasai: other a little complex is line-height unit<br> <TabAtkins> fantasai: unlike font-size, line-height accepts font-relative units, but produces the lh unit. forget how we resolved that circularity<br> <dbaron> s/accepts font-relative units/treats font-relative units relative to the current element/<br> <fantasai> TabAtkins: Emilio also wanted a centralized location for all the dependencies we have<br> <fantasai> TabAtkins: We do have a wiki page tracking these, could move into appendix of Values?<br> <emilio> wfm<br> <TabAtkins> https://wiki.csswg.org/spec/property-dependencies<br> <emilio> fantasai: not all of the dependencies are unit dependencies<br> <emilio> ... not sure those make sense in values<br> <fantasai> astearns: put in definition of units?<br> <fantasai> emilio: discussing things like position affecting display, etc.<br> <fantasai> TabAtkins: tracking unit dependencies is what we need to define for this, could limit to addressing that<br> <fantasai> fantasai: That's easy, it's just everything in font-relative units section<br> <fantasai> astearns: So first is to define set of properties that affect font-relative units?<br> <TabAtkins> fantasai: so that's all the font-* properties, anything affecting font selection, affects 'ex' and similar units<br> <TabAtkins> fantasai: I think we just generally say all font properties need to look up the parent<br> <TabAtkins> fantasai: we didn't say this before because only font-size could take a numeric value, now many can<br> <TabAtkins> astearns: so you're arguing against a list of properties?<br> <TabAtkins> fantasai: Yeah we're gonna add more props over time. should literally just say "all the font-* props"<br> <TabAtkins> fantasai: So no fancy table needed, just say "all the font properties".<br> <TabAtkins> TabAtkins: and do something for line-height<br> <TabAtkins> fantasai: yes<br> <TabAtkins> astearns: so proposed reoslution is if you use the font-relative units in a math fucntion...<br> <TabAtkins> fantasai: No, not just in a function. Any usage. We might expand usage in the future.<br> <TabAtkins> astearns: concerns with the reoslution?<br> <TabAtkins> TabAtkins: i'll run the exact test by emilio when i get some text down<br> <TabAtkins> emilio: what happens with length-valued custom props?<br> <TabAtkins> emilio: if you use ems in a custom prop that takes <length>, and then use it in font-size...<br> <TabAtkins> fantasai: the substiution happens before computation...<br> <fantasai> s/happens/should happen/<br> <TabAtkins> emilio: but it has to compute to something<br> <TabAtkins> emilio: if you getComputedStyle() it has to return a length<br> <TabAtkins> TabAtkins: yeah there might be an issue there, i'll review<br> <TabAtkins> astearns: so proposed resolution is if you use font-relative units in font-* properties, you get the value from teh parent<br> <TabAtkins> astearns: objections?<br> <fantasai> ACTION TabAtkins: Figure out what to do on custom properties typed as lengths<br> <TabAtkins> RESOLVED: font-relative units resolve against the parent element when used in any font-* property (and anything else that affects font selection)<br> <fantasai> astearns: line-height?<br> <fantasai> TabAtkins: We need to dig into exactly what that works out to<br> <fantasai> RESOLVED: Do something similar for line-height (details TBD)<br> <fantasai> astearns: container query units?<br> <fantasai> TabAtkins: by definition, they're not circular because already resolvign against an ancestor eleent<br> <fantasai> s/eleent/element<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8169#issuecomment-1632890687 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 July 2023 16:56:54 UTC