- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Apr 2022 17:00:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text] Syntax for percentage-of-width-of-space for 'word-spacing'`, and agreed to the following: * `RESOLVED (for now): ‘word-spacing’ takes a number value` <details><summary>The full IRC log of that discussion</summary> <emeyer> Topic: [css-text] Syntax for percentage-of-width-of-space for 'word-spacing'<br> <emeyer> github: https://github.com/w3c/csswg-drafts/issues/3232<br> <fantasai_> https://github.com/w3c/csswg-drafts/issues/3232#issuecomment-1040836766<br> <emeyer> fantasai: We’ve been wanting to represent percentage spacing in word-spacing as a percentge of the character’s advance width.<br> <TabAtkins> we want the ability to say "words should be separated by two spaces worth of whitespace", for example<br> <emeyer> …We’re already using percentages against font size.<br> <emeyer> …we already have a meaning for all the lengths, and em for percentages. Still want “increase width of this word separator character by X%”.<br> <emeyer> …Space is the most commn word separator, but there are others with different advance widths.<br> <emeyer> …We want to represent a multiplier, not a percentage or length.<br> <emeyer> …I think we have some number of options. One: use a number. Cons: you can’t combine numbers and lengths in calc()s.<br> <emeyer> Two: Use a different unit, like ‘fr’. We could mint a new unit, either a generic one or one specific to this property.<br> <emeyer> Three: We could mint a new function.<br> <emeyer> TabAtkins: The fact that this can have different effects on per-character basis makes it more strongly not a length. My objections in the issue are largely irrelevant; fine with it being a number.<br> <emeyer> astearns: It’s a number that inherits as itself.<br> <emeyer> florian: Do we expect people to actually calc() this sort of thing?<br> <emeyer> fantasai: I don’t know.<br> <astearns> s/It's a number/It's a unit/<br> <emeyer> TabAtkins: In the general case, no, but it might be sense to double ASCII space a tweak it. I don’t think so, but…?<br> <astearns> ack dbaron<br> <emeyer> dbaron: This is a sort of general problem that we should find a decent solution for that isn’t a horrible hack. We keep running into situations where we want a value that’s relative to something computed for inheritance purposes. Maybe we need to actually figure out a more permanent solution for this.<br> <emeyer> fantasai: We have percentages usually, but we’re alreaday using them here.<br> <aja> q+<br> <emeyer> dbaron: Part of what I mean is that for lengths, we have different units. We might want different relative units. Maybe ‘fr’ was going down the right path. We should have a solution we can re-use multiple times.<br> <emeyer> fantasai: If the ‘x’ unit was available, that might be nice.<br> <emeyer> florian: If you know of it, it does the job find, but discovering is a mess.<br> <florian> s/of it/of the fr unit/<br> <emeyer> astearns: I agree this is a problem that crops up in several places and we have one relief valve, where we use a number and set that number to have a special relationship.<br> <emeyer> fantasai: Two relief valves: percentages and numbers. The problem with numbers is you can combine with calc().<br> <emeyer> s/can combine/can’t combine/<br> <emeyer> florian: We don’t need a unit system for percentages, we only ever need two at most.<br> <emeyer> fantasai: Maybe we need a generic “this is a number” unit for calc()<br> <emeyer> florian: I thikn dbaron said this is a problem in a number of places. What number of places? If it’s a few, maybve that’s okay. If it’s a lot, maybe ‘fr’ is the way to go because that’s learnable.<br> <emeyer> s/thikn/think/<br> <emeyer> fantasai: border-image uses both, I think.<br> <astearns> percentage(150%, font-size)<br> <emeyer> dbaron: I think there are a bunch of cases where percentage confuses people because they don’t always know what it means.<br> <fantasai_> also line-height, but that was a terrible mistake imho<br> <emeyer> florian: I retract my earlier comment about two types of percentages, we do have more.<br> <iank_> (even on single properties percentages can resolve to different things depending on the context, e.g. top :P )<br> <dbaron> dbaron: ... sometimes % of height, % of width, % of font-size<br> <TabAtkins> 5%(em)<br> <fantasai_> https://www.w3.org/TR/css-backgrounds/#border-image-width<br> <emeyer> astearns: Spelling out percentages in functoinal form would be easier than some abbreviation.<br> <emeyer> florian: Maybe you could do “2% height + 2% width” in some way.<br> <florian> s/2% height + 2% width/2%(height) + 2%(width)/<br> <emeyer> iank_: We want to be very careful if we’re introducing percentages that can resolve against specific things. Cyclic dependencies are a risk.<br> <TabAtkins> %(foo) is just a new unit, it's not currently allowed by Syntax<br> <iank_> I see.<br> <emeyer> astearns: We could restrict where those identifiers could be used to avoid cycles.<br> <TabAtkins> 5foo% vs 5%(foo) vs just 5foop<br> <emeyer> fantasai: That feels excessively complicated for what weære dealing with here.<br> <emeyer> dbaron: Maybe we should make more things like ‘fr’ rather than re-using it all the time. Doing that seems the least horrible.<br> <emeyer> astearns: We could resolve to use a unit, but we lack consensus on what that should be named.<br> <emeyer> fantasai: I number either a new unit, or just use numbers.<br> <emeyer> s/I number/I think/<br> <dbaron> iank_: new unit that's only valid for word-spacing?<br> <dbaron> fantasai_: yes, or maybe also tab-size<br> <emeyer> fantasai: It would be nice if there was syntactic compability.<br> <aja> 1) would % of 'ch' unit be appropriate? 2) consistency with letter-spacing would be a plus for authors.<br> <emeyer> florian: Bikeshedding aside, that sounds reasonable unless dbaron is right and we’ll need a whole bunch of new units that are conceptually similar.<br> <fantasai_> 1) no, because it resolves to an absolute length 2) no use case, but could in theory (generally people don't want inconsistent tracking)<br> <emeyer> …If we think we need a bunch, we do that but try to come up with a scheme that lets us group these.<br> <dbaron> Also, vh, vw, etc., etc., are very %-like (but the user can't tell which way they inherit).<br> <emeyer> astearns: I’m not hearing moving toward resolution aside from not being interested in making a length.<br> <emeyer> fantasai: I propose we use a number for now. If we come up with a good unit we want later, we could make this as ‘tab-size’ accept it.<br> <emeyer> s/this as/this and/<br> <emeyer> astearns: Anyone with concerns with resolving that ‘word-spacing’ takes a number and punting on general solution until a later date?<br> <dbaron> I'm not objecting, but it does feel like just postponing the problem...<br> <emeyer> RESOLVED (for now): ‘word-spacing’ takes a number value<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3232#issuecomment-1098281734 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 April 2022 17:00:37 UTC