- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Jul 2020 20:49:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `initial-letter used vs computed font-size`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: initial-letter used vs computed font-size<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4988<br> <faceless2> Scribenick faceless2<br> <faceless2> fantasai in some cases where the initial letter has multiple characaters, some of the characters may want to be of different sizes - for instances punctuation or superscripts or similar<br> <faceless2> fantasai the problem is that we can't just say the descendents of the initial letter take the font size of the parent, so we need to have some kind of distinction to see whether the author wants to make the descendent an absolute size or have it scale to the initial letter<br> <faceless2> fantasais proposal is the the initial letter sets a font size multiplier, so the font size is now a tuple - the font size and a multiplier. When font size inherits it inherits the multiplier, when the font size is set to a length it's set to one, and when it's a percentage the multiplier is not reset<br> <faceless2> this ensures that the multiplier set on an initial letter is inherited by its descendants, so they will be scaled to match the parent element.<br> <faceless2> so the author can choose between specifying an explicit size or one that is linked to the initial letter size<br> <fantasai> summary of the proposal: https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-644472219<br> <fantasai> properties affected by multiplier: https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-634920474<br> <faceless2> dbaron it sounds good. what if they wanted to use a font-relative unit that isn't an em, but they can use a calc for this: calc (1.5ch/1em * 1em)<br> <myles> q+<br> <faceless2> this leads to another problem - the unit dimensionality analysis in calc. Does this prevent you from using the calc() function?<br> <florian> I think the minutes above should be calc (1.5ch/1em * 100%)<br> <heycam> q+<br> <faceless2> fantasai can we multiply percentages by percentages any other place?<br> <astearns> ack dbaron<br> <faceless2> tab so long as the percentage resolves to a number, yes.<br> <dbaron> s/prevent you from using the calc() function/prevent you from doing calc(200% * 200% / 1em)/<br> <astearns> ack myles<br> <astearns> q+<br> <faceless2> fantasai percentages generally multiple to a length, so multiplying by another percentage would give you length squared which is not valid<br> <faceless2> myles the solution seems to add a lot of complexity for what is ultimately a corner case. and I don't see different sizes being very common<br> <emilio> q+<br> <faceless2> so I'm worried about the cost-benefit analysis<br> <faceless2> fantasai so we have to transfer this information down somehow otherwise we can't do this.<br> <faceless2> myles the other option is not to solve this problem<br> <dbaron> I could suggest another option...<br> <astearns> ack heycam<br> <faceless2> fantasai this is relatively common when for example an initial quote is supposed to be a different size to the text<br> <faceless2> heycam it's possible we could solve this for quotes in a different way, rather than relying on the author to put markup on this.<br> <faceless2> fantasai there is an open issue to alow initial punctuation to be done differnetly<br> <fantasai> s/done differently/selected via pseudo-element/<br> <astearns> ack heycam<br> <faceless2> heycam it's a bit weird that now we can't do getComputedStyle on an element and set it back as the computed style on en alement as now we'd get something that behaves differently. I don't like that there's a hidden value as that's not partcicularlyl obvious to the author<br> <AmeliaBR> +1 for heycam's concern. Computed style should be round-trippable. Used style could still be used for em units.<br> <faceless2> astearns i think the common case where the open quote is meant to match the size of the body text - is it going to be possibel with this to make this work?<br> <faceless2> fantasai yes, with this proposal you'd set the size to 1em to match the paragraph size<br> <astearns> ack AmeliaBR<br> <astearns> ack astearns<br> <faceless2> florian we want the abiliity to match the size to the parent text, and we want intervening markup to not mess things up.<br> <faceless2> fantasai we make font siz depend on the font sizr and line height of the containing block, which is not a dependency that we want to put in the computed value of the font-size. Doing so would make the font size computation much more complicated.<br> <astearns> ack emilio<br> <faceless2> s/siz/size/<br> <fantasai> s/we make/that would make/<br> <faceless2> emilio i wanted to echo some of the concerns raised by myles, but also to point out font size already has some complexity - for instance font-size: medium has complexity, if you change to a font that has a different meaning of medium there are already calculations going on there<br> <faceless2> myles we do that too but it's just for monospace, but the only reason that's there is because the default monospace font had weird metrics. I don't think we should consider that as a precedent.<br> <florian> s/to not mess things up./to not mess things up. Affecting the computed rather than used value would solve the second. Are is the first one the reason we're not going that way?/<br> <faceless2> emilio I agree, I don't think we should add to the complexity<br> <astearns> ack dbaron<br> <faceless2> dbaron so another idea which may be less complex is to have a separate property that causes an element to be excluded from the font size adjustment that the initial letter changes. We could have a property that could be set to prevent elements and exclude them from the size adjustment<br> <faceless2> so eventually ou'd take the multiplier and give it its wn property<br> <faceless2> q+<br> <faceless2> florian there's no use for a multiplier of 1.7em is there?<br> <dbaron> s/1.7em/1.7/<br> <dbaron> florian: if you wanted that you could just use 1.7em<br> <florian> me astearns , you were still very faint<br> <faceless2> fantasai so if we had an on/off switch, how are we tracking the multiplier? the property has to be stored somewhere, as a multiplier, not a boolean value.<br> <astearns> ack faceless2<br> <fantasai> faceless2: This is per-property multipler, you have a couple cases with e.g. margin-left: 1em<br> <fantasai> faceless2: want that to be font size of the paragraph<br> <fantasai> faceless2: but want the actual font size to be matching the initial letter<br> <fantasai> florian: So that works with fantasai's proposal, because can use ems or not; but not with dbaron<br> <dbaron> (dbaron and fantasai both start to disagree)<br> <faceless2> the proposap with the multipilier is it does not affect the use of em units or any other font units, just percentages.<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-634920474<br> <faceless2> it only applies to particular properties which are related to the font, and only to percentages.<br> <faceless2> s/proposap/proposal<br> <faceless2> this isn't purely about the font size its about several other things that are keying off the used font size.<br> <faceless2> so you can't use this for margin left, for example, because it only takes em values. and em values are not affected by the multiplier<br> <faceless2> the things where it needs to be relative to the used font size are things that are being done to the text itself, and in that case we're already allowing for percentages because they need to be inherited as percentages. But margin doesn't have this because we have no use case for it<br> <faceless2> astearns is not hearing a concensus on this<br> <faceless2> florian is not necessarily is opposed but was asking questions to help understand it better<br> <faceless2> astearns the way to go forward here is to go forward on the issue with some examples. I'm hearing enough reservations that we shouldn't resolve.<br> <faceless2> fantasai we'll take it back to the issues.<br> <faceless2> s/issues/issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4988#issuecomment-665275409 using your GitHub account
Received on Tuesday, 28 July 2020 20:49:43 UTC