14:56:01 <RRSAgent> RRSAgent has joined #css
14:56:01 <RRSAgent> logging to https://www.w3.org/2021/02/09-css-irc
14:56:02 <Zakim> inviting RRSAgent
14:56:03 <Zakim> RRSAgent, make logs Public
14:56:04 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:00:30 <futhark> present+
15:00:41 <dholbert> present+
15:00:53 <florian> present+
15:01:36 <alisonmaher> alisonmaher has joined #css
15:02:11 <gregwhitworth> present+
15:02:11 <leaverou> present+
15:02:33 <nicole> nicole has joined #css
15:02:36 <alisonmaher> present+
15:02:52 <chris> chris has joined #css
15:02:58 <chris> present+
15:03:16 <nicole> present+
15:03:54 <dlibby> dlibby has joined #css
15:04:12 <cbiesinger> present+
15:04:47 <miriam> present+
15:04:56 <oriol> present+
15:04:59 <rachelandrew> present+
15:05:13 <emilio> present+
15:05:41 <dlibby> present+
15:05:42 <dandclark> present+
15:05:43 <gregwhitworth> scribenick: gregwhitworth
15:06:06 <faceless2> present+
15:06:27 <una> una has joined #css
15:06:40 <brandon> present+
15:06:46 <bkardell_> present+
15:06:57 <una> present+
15:07:30 <TabAtkins> present+
15:08:49 <gregwhitworth> Topic: Reduce layout shift via @font-face descriptor(s) overriding inline spacing
15:09:15 <Rossen_> Rossen_ has joined #css
15:09:32 <Rossen_> present+
15:09:47 <tantek> tantek has joined #css
15:10:13 <chris> github: https://github.com/w3c/csswg-drafts/issues/5533
15:10:37 <xiaochengh> xiaochengh has joined #css
15:10:39 <drott> present+
15:11:03 <sanketj> sanketj has joined #css
15:11:22 <gregwhitworth> xiaochengh: we'd like to introduce a new descriptor called advance-override
15:11:36 <gregwhitworth> xiaochengh: it's to multiply the advance-width
15:11:51 <gregwhitworth> xiaochengh: the intent is to use it to reduce layout shift when switching between fallback and webfonts
15:12:12 <gregwhitworth> xiaochengh: it's intended to wrap a fallback font with wrapper to use advanced-override
15:12:28 <gregwhitworth> xiaochengh: this is in the same group with ascent-override and line-gap override
15:12:42 <gregwhitworth> xiaochengh: there are some considerations with this proposal
15:12:54 <chris> advance width described here https://www.w3.org/TR/css-values-3/#ch
15:12:55 <gregwhitworth> xiaochengh: the first one is whether to use a property or a descriptor
15:13:17 <gregwhitworth> xiaochengh: our consideration is to make things easy to implement and we've confirmed as we've done this behind a flag in Chrome
15:13:28 <gregwhitworth> xiaochengh: we want to make it easy for web authors to use it too
15:13:43 <fantasai> +1 to making it a descriptor and not a property
15:13:52 <gregwhitworth> xiaochengh: a web font provider can provide these in a stylesheet they provide to authors
15:14:15 <gregwhitworth> xiaochengh: so we think our proposal achieves all of the goals
15:14:30 <gregwhitworth> xiaochengh: font-display cannot really reduce layout shift
15:14:58 <chris> q+ to note that advance-width should be advance measure (it is a width for horizontal writing)
15:14:59 <gregwhitworth> xiaochengh: the third issue is typography, when we use such override descriptors we expect the legibility of the fallback font to be worsened
15:15:00 <myles> present+ myles
15:15:00 <myles> myles has joined #css
15:15:18 <gregwhitworth> xiaochengh: we don't think this is unacceptable as it only occurs when a web font fails to load
15:15:46 <tantek> present+
15:15:47 <gregwhitworth> xiaochengh: if the actual fallback font gets unusable means that the fallback font and web font differ too much
15:16:02 <gregwhitworth> xiaochengh: there is a similarity between this and letter spacing but they're different things
15:16:23 <gregwhitworth> xiaochengh: this is working with the width of the glyphs themselves, so letter-spacing doesn't apply
15:16:29 <gregwhitworth> xiaochengh: also happy for name feedback
15:16:31 <astearns> ack chris
15:16:31 <Zakim> chris, you wanted to note that advance-width should be advance measure (it is a width for horizontal writing)
15:16:33 <gregwhitworth> chris: minor point
15:16:48 <gregwhitworth> chris: advanced-width is correct for horizontal writing
15:17:20 <gregwhitworth> chris: in the units spec, the advance-measure it can be vertical and horizontal
15:17:39 <gregwhitworth> fantasai: the problem with that is you may want different numbers with width and height
15:17:54 <chris> advance measure described here https://www.w3.org/TR/css-values-3/#ch
15:17:58 <gregwhitworth> fantasai: you may not want the same adjustments in both directions
15:18:11 <drott> q+
15:18:17 <gregwhitworth> fantasai: if you're typesetting correctly you'll need to ensure you're talking about width or height
15:18:25 <myles> q+
15:18:29 <gregwhitworth> chris: I agree with fantasai
15:18:37 <gregwhitworth> xiaochengh: this is just for the horizontal width
15:18:37 <astearns> ack fantasai
15:18:59 <gregwhitworth> xiaochengh: we're using others for vertical for ascent and descent
15:19:21 <gregwhitworth> fantasai: I don't think you understood my point as this doesn't have to do with ascent & descent
15:19:42 <gregwhitworth> fantasai: depending on how you're typesetting you'll need a different number vertically or horizontally
15:20:02 <fantasai> When typesetting horizontally or vertically sideways, need the same number
15:20:06 <gregwhitworth> xiaochengh: for the same font, when it's used horizontally & vertically
15:20:17 <gregwhitworth> florian: for upright fonts you should probably have two numbers
15:20:19 <fantasai> but for vertical writing typeset upright, you will want a different number
15:20:35 <gregwhitworth> florian: for that particular problem you should take 2 numbers and the second is optional
15:20:36 <astearns> ack drott
15:20:36 <fantasai> because that's the height of the glyph you're measuring, not the width of it
15:20:56 <gregwhitworth> Domenic: is that required for the specificity of src local for wrapping a web font?
15:21:19 <gregwhitworth> fantasai: imagine two fonts Verdana and Times Roman and imagine they look a bit more similar
15:21:33 <gregwhitworth> fantasai: you'll notice that Times is very narrow but they're very close in height
15:21:43 <gregwhitworth> fantasai: so if you're vertically setting then you're fine
15:21:52 <gregwhitworth> Domenic: I was thinking more CJK
15:22:19 <gregwhitworth> fantasai: if I'm typesetting vertically (eg: I rotate it) then I'll need to typeset it
15:22:28 <astearns> ack myles
15:22:33 <gregwhitworth> florian: also the same font may be used in different directions in the same document
15:22:47 <gregwhitworth> myles: we've gotten a similar request for similar features that we should be thinking about
15:23:07 <gregwhitworth> myles: we're thinking about this in the time of loading to ensure that the fallback looks like the webfont
15:23:38 <gregwhitworth> myles: we've looked at this for when a font doesn't support glyphs that the page is asking for and we want to ensure that the fonts look alike
15:23:46 <jfkthame> jfkthame has joined #css
15:23:50 <chris> The next topic https://github.com/w3c/csswg-drafts/issues/126
15:23:51 <fantasai> s/need to typeset it/need a different multiplier
15:23:58 <gregwhitworth> myles: doing this requires more than just the advance of the font
15:24:16 <gregwhitworth> myles: I think it would be good to solve both of these at the same time with the same feature
15:24:28 <gregwhitworth> astearns: I agree they're similar
15:24:50 <gregwhitworth> astearns: matching the fallback with the webfont you don't know which font will match that font
15:25:15 <gregwhitworth> myles: yes each person that has asked for this is willing to spend the time to craft their page to get as close as possible
15:25:22 <florian> q+
15:25:26 <myles> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-245708960
15:25:30 <fantasai> s/page/@font-face rules with local/
15:25:32 <astearns> ack florian
15:25:47 <vmpstr> vmpstr has joined #css
15:26:15 <drott> florian, https://www.fauxfoundry.com/?
15:26:26 <chris> q+
15:26:28 <gregwhitworth> florian: reminds me of a project a while back, something like full greek but you were trying to match the style of greek font even if you only had latin fonts but they used variable fonts to adjust that. Not sure how we apply that idea to this use case
15:26:35 <jfkthame> q+
15:26:37 <gregwhitworth> florian: rather than just changing widths
15:26:45 <astearns> ack chris
15:27:21 <gregwhitworth> chris: yeah, the difference between that and they're changing the glyph outlines to produce a parametized fonts, this proposal is not changing glyphs at all just ensuring the spacing is correct
15:27:28 <gregwhitworth> fantasai: this won't work for cursive then
15:27:34 <astearns> ack jfkthame
15:27:41 <gregwhitworth> chris: I agree, won't work for Mongolian and Arabic
15:28:03 <gregwhitworth> jonathan: Seems like what panos was trying to do what Myles was wanting to do
15:28:29 <gregwhitworth> jonathan: when fallback happens based on meta attributes it can search for fallback that looks for attributes of the web font
15:28:29 <chris> https://www.w3.org/Fonts/Panose/pan2.html
15:28:53 <gregwhitworth> jonathan: that's rather different than using a fallback as a given font and behave as much like a particular font
15:28:59 <gregwhitworth> myles: yes, what you said is correct
15:29:15 <florian> [The project I mentioned earlier is https://www.fauxfoundry.com/ ]
15:29:46 <gregwhitworth> myles: the requests we've gotten is not trying to add serifs, like the example florian gave, but the examples are trying to adjust letter-spacing, font-weight (5 props) in the fallback font. And if you're going to use the fallback then bump up the weight
15:29:55 <myles> font-weight
15:29:55 <myles> font-size
15:29:55 <myles> letter-spacing
15:29:55 <myles> word-spacing
15:29:56 <myles> line-height
15:30:31 <chris> Faux Greek foundry https://www.fauxfoundry.com/
15:30:55 <gregwhitworth> myles: the direction I was going there, one possible way - we should solve this problem in multiple ways. We can have a descriptor or we can extend the properties to be fallback aware
15:31:03 <tobiashoegh> tobiashoegh has left #css
15:31:09 <leaverou> q+ to say this is starting to sound a lot like the next topic and maybe they should be discussed together?
15:31:10 <gregwhitworth> fantasai: I think using font-face is way better given you're describing the font
15:31:17 <gregwhitworth> jonathan: very much agree with fantasai on that
15:31:21 <chris> by Irene Vlachou & Laurence Penney
15:31:25 <fantasai> s/font-face/font-face to tie values to particular font faces/
15:31:29 <gregwhitworth> myles: I'm surprised to hear it although I understand it partly
15:31:44 <gregwhitworth> myles: the benefit of the properties is that you get selectors
15:31:56 <gregwhitworth> florian: why would you want to select against the element and not the font
15:32:24 <gregwhitworth> myles: only request is to consider them both
15:32:37 <gregwhitworth> leaverou: I'm hearing a lot of items from the next issue
15:32:45 <drott> q+
15:32:46 <jensimmons> jensimmons has joined #css
15:32:54 <gregwhitworth> astearns: I'm thinking of "Yes we should solve this but let's solve all the issues together"
15:33:22 <astearns> ack leaverou
15:33:22 <Zakim> leaverou, you wanted to say this is starting to sound a lot like the next topic and maybe they should be discussed together?
15:33:25 <astearns> ack drott
15:33:42 <gregwhitworth> drott: in solving this - do we want to distinguish between another font or what's available locally
15:34:10 <gregwhitworth> drott: that's a fast fallback solution or we load a foundry for variable fonts used for fallback that's completely different
15:34:20 <gregwhitworth> drott: and it would be required for load
15:34:35 <gregwhitworth> astearns: I'd want 1 way to define the override
15:35:06 <gregwhitworth> drott: there are two use cases, the more flexible way is a bit wider in scope.
15:36:00 <gregwhitworth> fantasai: so they're cursive, you can't letter space them so how do you ensure they're rendered properly if an author sets this
15:36:14 <gregwhitworth> myles: would it be the same as the scenario when you use letter-spacing
15:36:34 <gregwhitworth> myles: we have a request to ignore letter-spacing when an Arabic font is used
15:36:40 <drott> q+
15:36:41 <fantasai> fantasai: that's in the spec
15:36:44 <chris> Some arabic fonts do have a spacing axis (variable fonts again)
15:36:45 <gregwhitworth> fantasai: that's what we define already for letter-spacing
15:37:10 <gregwhitworth> xiaochengh: we tried it on Arabic and we see the width of the characters change and the shaping doesn't look bad
15:37:17 <TabAtkins> Lol, Chrome *does* apply letter-spacing to Arabic currently, it just... puts space between teh characters.
15:37:24 <TabAtkins> They're still shaped properly for their place in the word.
15:37:31 <florian> q+
15:37:39 <TabAtkins> Like kashida-ing without the kashida
15:37:46 <chrishtr> q+
15:37:57 <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8903
15:38:03 <gregwhitworth> fantasai: I don't think you used a large enough value, in order to avoid rendering at joins they have a small amount of overlap built in
15:38:03 <florian> q-
15:38:17 <gregwhitworth> fantasai: so to see if it is working or not you'd need a larger range than that tolerance
15:38:29 <gregwhitworth> drott: a little bit of adjustment doesn't break them apart
15:38:36 <rego> rego has joined #css
15:38:37 <drott> q-
15:38:55 <gregwhitworth> chrishtr: if letter-spacing then it seems logical to do the same with this descriptor
15:38:58 <chris> q+
15:39:05 <astearns> ack chrishtr
15:39:19 <gregwhitworth> chrishtr: the other thought I had was the only other concern would be to apply a different override in each direction
15:39:31 <fantasai> s/direction/axis
15:39:39 <gregwhitworth> astearns: that was brought up earlier you'll need one for inline and block
15:39:51 <gregwhitworth> TabAtkins: no it's inline in both times, just depends on the writing mode
15:40:02 <gregwhitworth> fantasai: it will be width/height to the font
15:40:16 <astearns> ack chris
15:40:38 <geheimnis`> geheimnis` has joined #css
15:40:41 <myles> https://en.wikipedia.org/wiki/Kashida
15:40:44 <gregwhitworth> chris: it's not true to say that those scripts don't have letter-spacing it's that you need to use them to use a longer connection but most fonts don't do that
15:40:53 <gregwhitworth> fantasai: it's more complicated than that
15:41:32 <gregwhitworth> fantasai: we would say that you don't do this for Mongolian or Arabic and some fonts may do it but most won't
15:41:39 <fantasai> s/would//
15:41:45 <chris> Arabic text alignment & justification https://www.w3.org/TR/alreq/#h_justification
15:41:49 <fantasai> This is specced in css-text-3
15:42:04 <gregwhitworth> astearns: I think we should close off with a general yes, we want to have this advance-override but move to the next issue about how to define it
15:42:12 <gregwhitworth> myles: is it going to be a length?
15:42:17 <gregwhitworth> xiaochengh: it's a percentage
15:42:21 <gregwhitworth> chris: it's a multiplier
15:42:34 <gregwhitworth> TabAtkins: it's going to be the best overall solution that works the most consistently
15:43:02 <gregwhitworth> Topic: Specifying changes to parameters for fallback fonts
15:43:45 <jarhar> jarhar has joined #css
15:43:48 <chrishtr> q+
15:44:18 <astearns> github: https://github.com/w3c/csswg-drafts/issues/126
15:44:41 <gregwhitworth> chris: the general principal is wanting to change things based on which font was actually used
15:45:07 <gregwhitworth> chris: so you set them conditionally, they expect a simple syntax. Much of this thread is to say that most simple solutions are not going to work
15:45:23 <astearns> ack chrishtr
15:45:29 <gregwhitworth> chrishtr: I wanted to point out a few things
15:45:39 <gregwhitworth> chrishtr: which syntax would be used
15:46:30 <gregwhitworth> chrishtr: main usecase that xiaochengh had in mind was automatically overriding when you have a fallback of a webfont you want to limit jumping of the webpage and add little to not difficulty to the author because it behaves automatically
15:46:39 <leaverou> q+
15:47:03 <gregwhitworth> chrishtr: the one alternative is to have a CSS property that has augmented syntax and I think that would end up being quite complex because it would need to repeat
15:47:08 <astearns> ack leaverou
15:47:22 <gregwhitworth> leaverou: there have been many proposals, they seem to revolve around changing the font-props
15:47:33 <gregwhitworth> leaverou: the syntax would get quite complicated
15:48:00 <gregwhitworth> leaverou: rather than change props let's add inline conditionals based on prior resolutions of inline conditionals
15:48:19 <gregwhitworth> leaverou: you can then branch however you want and it only gets as complicated as the author needs it to be
15:48:37 <gregwhitworth> leaverou: so you can end up with multiple font-families in a single element
15:48:58 <drott> q+
15:49:08 <gregwhitworth> leaverou: you don't want a different letter-spacing for every glyph for example
15:49:21 <gregwhitworth> leaverou: this gets future improvements for conditional syntax
15:49:41 <gregwhitworth> myles: one of the args against my proposal was unreadable and I think this may be more unreadable
15:49:54 <astearns> ack drott
15:50:01 <gregwhitworth> astearns: that would depend on the general usage but yes more flexibility usually adds complexity to parse
15:50:17 <gregwhitworth> drott: would you add a way to selector for the inline font?
15:50:28 <gregwhitworth> leaverou: no a keyword, such as accentColor
15:50:34 <gregwhitworth> leaverou: I can drop a link to the proposal
15:50:36 <leaverou> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-775990597
15:50:42 <leaverou> s/accentColor/currentColor/
15:51:14 <xiaochengh> q+
15:51:31 <drott> q+
15:51:37 <gregwhitworth> astearns: I'm thinking this is a good thing to get too, but this more immediate need a descriptor rather than waiting for a solution to the conditional styling
15:51:51 <astearns> q?
15:51:58 <gregwhitworth> myles: in the last issue we were going to add one of these degrees of freedom to the descriptor
15:52:41 <gregwhitworth> myles: as a more concrete proposal should we try to add 4 additional descriptors to ensure alignement?
15:53:01 <chris> q?
15:53:05 <astearns> ack xiaochengh
15:53:24 <gregwhitworth> xiaochengh: the proposed syntax of this property is complicated and the implementation will be complicated too
15:53:24 <drott> q-
15:53:31 <astearns> ack fantasai
15:53:34 <gregwhitworth> xiaochengh: I'm not sure how to implement that in Chrome to be honest
15:54:06 <gregwhitworth> fantasai: I think going with the descriptor is a much better way than trying to embed this in font properties especially so many CSS calculations depend on those properties
15:54:19 <gregwhitworth> fantasai: properties are really weird to bind font-face to some value
15:54:27 <myles> q+
15:55:07 <gregwhitworth> fantasai: we can't just put it into the font-face rule, you'd want different styles to different elements, we're going to have derivitives of the same font-face with different overrides
15:55:30 <gregwhitworth> fantasai: it would be good to cascade in so you don't have to repeat them
15:55:42 <gregwhitworth> myles: so inheritance for at rules?
15:55:57 <leaverou> q+
15:55:59 <gregwhitworth> fantasai: cascading rules which is what counter style does
15:56:09 <gregwhitworth> fantasai: I support jonathan's proposal overall
15:56:31 <astearns> ack myles
15:56:35 <smfr> smfr has joined #css
15:56:35 <fantasai> jfkthame's proposal https://github.com/w3c/csswg-drafts/issues/126#issuecomment-764641927
15:56:50 <gregwhitworth> myles: one of the degrees of freedom is font-weight and that is a matching property
15:57:01 <gregwhitworth> myles: so if we want to have an override I'm not sure how that would work
15:57:03 <florian> q+
15:57:10 <cbiesinger> q+
15:57:14 <cbiesinger> hm
15:57:15 <cbiesinger> qq+
15:57:19 <gregwhitworth> myles: what that should mean is that that element shouldn't select the defined font-weight
15:57:22 <drott> q+
15:57:31 <gregwhitworth> chris: that shouldn't impact matching
15:57:37 <astearns> ack cbiesinger
15:57:37 <Zakim> cbiesinger, you wanted to react to myles
15:57:46 <chris> q?
15:58:20 <gregwhitworth> christian: could you solve that issue by having a font adjustment factor, so if the fallback is used you can multiply by something like 0.9
15:58:22 <cbiesinger> q-
15:58:42 <gregwhitworth> myles: so if you fallback to font-x use a factor of .8 or .9 for font-y
15:58:52 <gregwhitworth> myles: I think that's what chris was saying
15:59:03 <gregwhitworth> fantasai: would that work with variable fonts?
15:59:09 <gregwhitworth> myles: no it wouldn't work for var fonts
15:59:17 <gregwhitworth> fantasai: jonathan's solution has a mapping table
15:59:28 <gregwhitworth> florian: font-weight is the odd one here
15:59:37 <astearns> ack florian
15:59:47 <gregwhitworth> florian: they're not really numbers they're a way to match a font that happens to map to numbers
15:59:51 <astearns> zakim, close queue
15:59:51 <Zakim> ok, astearns, the speaker queue is closed
15:59:59 <myles> q+
16:00:03 <gregwhitworth> florian: if we're dealing with variable fonts we need to map to ranges or series
16:00:15 <gregwhitworth> florian: the others are actual measurements, this one is weird
16:01:05 <gregwhitworth> leaverou: I want to say we're discuss two orthogonal issues and one is trying to provide a better fallback and one trying to improve styling for ones that were selected for fallback
16:01:06 <drott> q-
16:01:40 <gregwhitworth> leaverou: there are usecases that are local fonts eg: Mac vs Windows fonts
16:01:51 <gregwhitworth> myles: the folks we've talked with are fine with font-face being used
16:05:32 <astearns> zakim, open queue
16:05:32 <Zakim> ok, astearns, the speaker queue is open
16:15:15 <r12a> r12a has joined #css
16:16:28 <TabAtkins> ScribeNick: TabAtkins
16:16:37 <TabAtkins> myles: There are these props we're interested in
16:16:46 <TabAtkins> myles: weight, size, letter-spacing, word-spacing, line-height
16:16:55 <TabAtkins> myles: line-height might be taken care of by ascent/descent-override
16:17:16 <TabAtkins> myles: letter-sacping resolved in last issue
16:17:22 <TabAtkins> myles: font-weight sounds hard, need more time
16:17:33 <TabAtkins> myles: but font-size and word-spacing, maybe we could make progress
16:17:37 <TabAtkins> jfkthame: font-stretch?
16:17:42 <TabAtkins> myles: could be. would you like it to be?
16:18:11 <TabAtkins> chris: yeah, condensedness should be in the list
16:18:24 <florian> q+
16:18:26 <TabAtkins> astearns: Wondering if we should have a general reoslution to solve these things as @font-face descriptors, and start getting spec text for this
16:18:32 <leaverou> q-
16:18:33 <chrishtr> Agreed on font-face resolution being a good next step.
16:18:41 <chrishtr> And then discuss types of overrides.
16:18:42 <TabAtkins> astearns: For previous issue, for the simpler things here, and then ahve separate issues for each type of override
16:18:54 <TabAtkins> astearns: This is alread a giant issue that tends to spin out into overlapping convos
16:18:56 <chris> Yeah that sounds like a plan
16:19:01 <astearns> q?
16:19:31 <TabAtkins> florian: A discussion over the break: instead of specifying the amount you want to adjust the font, specify the target amount
16:19:46 <TabAtkins> florian: UA could adjust automatically, but could be flexible with variable fonts, etc
16:19:56 <TabAtkins> florian: Or choose different fallbacks with better metrics
16:20:17 <fantasai> TabAtkins: That might work for some things, but I can't see how it would work for advance
16:20:33 <TabAtkins> myles: It'd be an overall tracking value, like "make the average character width X sized"
16:20:43 <TabAtkins> jfkthame: Too many questions there, how to average?
16:20:52 <TabAtkins> florian: Not harder than just using the adjustment
16:20:58 <fantasai> TabAtkins: Disagree
16:21:06 <fantasai> TabAtkins: Current proposal only adjust the fallbacks.
16:21:15 <fantasai> TabAtkins: Take the good font, then load fallback and tweak it until to works
16:21:20 <fantasai> s/works/works the way you want
16:21:29 <TabAtkins> myles: This is why I opened an issue for font-size-adjust:auto
16:21:36 <TabAtkins> myles: Right now author needs to guess
16:22:01 <fantasai> TabAtkins: At least you can guess and check for font-size easily, but see your point in general
16:22:03 <TabAtkins> myles: So suggested we have an auto for that
16:22:05 <astearns> ack fantasai
16:22:10 <astearns> ack florian
16:22:17 <TabAtkins> fantasai: There was discussion about reoslution
16:22:26 <TabAtkins> fantasai: proposed resolution is to address these use-case with descriptors
16:22:35 <TabAtkins> fantasai: Don't think we can be more specific atm
16:22:51 <TabAtkins> fantasai: I know Chrome wants to address the advance-override case sooner rather than later, so we should make progress on making that concrete
16:23:16 <TabAtkins> astearns: So resolve the general descriptor, and specifically add advance-override
16:23:24 <TabAtkins> fantasai: in Fonts 5?
16:23:25 <TabAtkins> myles: yeah
16:23:30 <TabAtkins> astearns: objections?
16:23:48 <TabAtkins> jfkthame: Not quite sure we know what advance-override means yet - details tbd?
16:23:59 <TabAtkins> astearns: Yes, we resolve to add it, can spin out issues to nail down details.
16:24:20 <TabAtkins> RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors
16:24:35 <TabAtkins> RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD
16:24:47 <plinss> present+
16:25:19 <chris> present+ r12a
16:25:22 <jfkthame> present+
16:25:25 <Rossen_> Rossen_ has joined #css
16:25:27 <TabAtkins> Topic: ::indicator pseudo-element
16:25:28 <fantasai> present+
16:25:36 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/5914
16:26:24 <TabAtkins> gregwhitworth: Proposal for an ::indicator pseudo
16:26:38 <TabAtkins> gregwhitworth: Problem is appearance of checkbox and radio controls vary greatly across browsers
16:26:46 <TabAtkins> [shows slide of different browser checkboxes]
16:26:59 <TabAtkins> gregwhitworth: Investigating a bunch of components, but checkbox/radio is #2 most cited problem
16:27:19 <TabAtkins> gregwhitworth: OpenUI is already working on the more general problem [describes general checkbox internal structure]
16:27:40 <TabAtkins> gregwhitworth: So right now I'm just talkinga bout the indicator itself
16:28:01 <TabAtkins> gregwhitworth: Proposal is ::indicator pseudo on input[type=checkbox] and [radio], selecting the check/dot in the element.
16:28:20 <TabAtkins> gregwhitworth: There are probably more indicators, like in range inputs, but not getting to those now, they're more complex.
16:28:43 <jensimmons> jensimmons has joined #css
16:29:03 <TabAtkins> gregwhitworth: We saw from accent-color that often the functionality and visuals of a radio/checkbox are fine, they just want to change colors. We don't necessarily want people to ahve to rebuild from the ground up, like appearance:none requires
16:29:09 <TabAtkins> gregwhitworth: So interop becomes the questions
16:29:25 <TabAtkins> gregwhitworth: We've got a lot of variation cross-brwoser currently, how do we let authors have meaningful customization
16:29:47 <TabAtkins> gregwhitworth: I propose there is a "base" keyword for 'appearance', specifying that the widget must render with a standard-defined way.
16:30:01 <TabAtkins> [slide shows a standardized checkbox]
16:30:21 <fantasai> Better idea: use the checkmark Unicode character
16:30:40 <TabAtkins> gregwhitworth: So there would literally be an <svg><path></svg> to render the checkbox, and can thus style with SVG properties
16:30:41 <florian> q+
16:30:52 <TabAtkins> gregwhitworth: So people asked why we needed to go to this level of detail
16:31:06 <TabAtkins> gregwhitworth: You don't know what's between the component root and the checkmark
16:31:29 <TabAtkins> gregwhitworth: Earlier with password-reveal, our internal structure was actually really complicated, with some funny details that limited authors
16:31:43 <TabAtkins> gregwhitworth: So learning from that, we wanted to give authors well-defined DOM/styles that they can work off of
16:31:57 <TabAtkins> gregwhitworth: But make it opt-in so everything stays with the native look-and-feel by default
16:32:26 <TabAtkins> gregwhitworth: I've built a web component that follows this model, and was able to do a ton of variations [shows off many variations from the same SVG base]
16:32:56 <TabAtkins> gregwhitworth: Other possibilities we discarded:
16:33:04 <TabAtkins> gregwhitworth: using background-image on ::indicator rather than inline SVG
16:33:26 <TabAtkins> gregwhitworth: using a unicode character inside ::Indicator
16:33:33 <TabAtkins> gregwhitworth: Both of these, you just don't get the same flexibility
16:34:19 <TabAtkins> gregwhitworth: And the interop of unicode characters happens to be very good, but bc it's text you're very limited in what you can control about it
16:34:26 <TabAtkins> gregwhitworth: So open questions
16:34:29 <leaverou> (Also it's trivial to generate an SVG with a single <text> that contains a unicode character)
16:34:40 <TabAtkins> gregwhitworth: What happens if you want to change the graphic entirely?
16:34:49 <TabAtkins> [shows off an inverse path on a shield]
16:35:04 <leaverou> Question: What would ::indicator { content: "✔️"; } do?
16:35:49 <TabAtkins> gregwhitworth: Tangential to this, being able to adjust viewBox via CSS would b euseful for this
16:36:04 <TabAtkins> gregwhitworth: So while this gets us 80% there, there are much more ocmplex scenarios
16:36:13 <TabAtkins> gregwhitworth: [shows off animation flipping from check to x]
16:36:28 <TabAtkins> gregwhitworth: OpenUI's more freeform solution gives you fuller control if you need it
16:36:54 <TabAtkins> gregwhitworth: So proposal is we add "appearance:base", and add ::indicator for checkbox/radio to select the check/dot.
16:37:02 <emilio> q+
16:37:03 <florian> q?
16:37:27 <TabAtkins> TabAtkins: Does ::indicator select the <svg> or the <path?
16:37:34 <TabAtkins> gregwhitworth: <svg>, so you can control the box
16:37:51 <TabAtkins> TabAtkins: Okay so we'll need structure there so you can apply 'd', since it doesn't inherit
16:38:07 <TabAtkins> gregwhitworth: Yeah, another pseudo, or [...]
16:38:15 <TabAtkins> leaverou: Woudl 'content' property work?
16:38:23 <TabAtkins> gregwhitworth: Haven't considered it, would need to think about it.
16:38:47 <fantasai> +1 leaverou , exactly what I was going to say
16:38:50 <TabAtkins> leaverou: I'd expect 'content' to work, as an author, the same way it works for list markers.
16:39:02 <TabAtkins> gregwhitworth: So you'd expect it to cancel out the built-in SVG?
16:39:03 <TabAtkins> leaverou: Yes
16:39:38 <TabAtkins> fantasai: One of the things on my q would be to say the same thing as Lea.
16:39:49 <Rossen_> q
16:39:53 <TabAtkins> fantasai: I'd say it should be just a pseudo with 'content' that the UA sets to an SVG
16:40:28 <TabAtkins> TabAtkins: If you rely solely on that, the only way to plumb in an SVG is via an iamge, and it's not stylable
16:40:39 <tantek> IMO a Unicode checkbox character wouldn't match anything that anyone implements, so that seems like a bad idea
16:40:58 <TabAtkins> fantasai: So we could default to text, but the author could then style in more things.
16:41:19 <TabAtkins> fantasai: It would be easy to adjust that.
16:41:29 <TabAtkins> gregwhitworth: Only stuff you could do with text
16:41:33 <nicole> +1 for having multiple ways of creating the glyph e.g. svg, font, image (but it wouldn't be a background image)
16:41:51 <tantek> we really shouldn't define things with defaults that are ugly
16:42:10 <fantasai> TabAtkins: Still can style using content easily, even if we use default is an SVG
16:42:18 <fantasai> TabAtkins: and can do a lot more if the default content is a standardized SVG
16:42:30 <TabAtkins> leaverou: And you don't need graphics software, can just write a data URL
16:42:41 <TabAtkins> gregwhitworth: and how do you get that checkmark image put together?
16:42:54 <tantek> agreed with gregwhitworth, don't make authors completely have to redefine a checkbox in order to tweak its styling
16:42:56 <TabAtkins> gregwhitworth: Without reaching for graphics software, can't adjust padding or sizing, can't add drop shadows, etc
16:43:25 <TabAtkins> leaverou: I thought with "appearance:base" you could just set all those properties
16:43:38 <TabAtkins> gregwhitworth: You can, but SVG still offers more power in graphical means
16:43:50 <jensimmons> q+
16:44:05 <TabAtkins> gregwhitworth: And I'm also trying to set up the convo for the range pseudo in the next convo, and they'll ahve more complex needs that wouldn't be handleable via text
16:44:22 <nicole> q+
16:44:33 <leaverou> q+
16:44:45 <TabAtkins> fantasai: wrt appearance:base, you were hinting in October, glad to see this
16:44:54 <tantek> No browsers's current checkboxes look like Unicode checkbox characters, seems like a hack to try to shoehorn like that or to explore that
16:45:07 <TabAtkins> fantasai: agree with premise. concern with doing it *right now* is that before we ship it, we'll need a structure for every html element
16:45:24 <astearns> ack fantasai
16:45:29 <TabAtkins> fantasai: If we ship for checkbox/radio and haven't figured out the other inputs, we'll have compat problems when we alter try to ship it for other inputs
16:45:33 <leaverou> +1 to what fantasai just said
16:45:33 <TabAtkins> gregwhitworth: what compat problems?
16:45:46 <tantek> +1 to what fantasai said, e.g. range control
16:46:07 <dholbert> (in particular if someone styles using `input {...}` as their selector, I imagine)
16:46:17 <TabAtkins> fantasai: If there's an effect on checkbox, but not *currently* on selects/files/etc, then people will apply the property too widely and it'll just do nothing so they won't notice; later when we define effects it'll change the page
16:46:55 <TabAtkins> gregwhitworth: It'll take a very long time to get all those structures in place...
16:47:24 <fantasai> TabAtkins: You're missing fantasa's point. Right now, it doesn't do anything on file input, people will apply it to all inputs to get the effect they want
16:47:36 <tantek> +1 good summary TabAtkins
16:47:40 <fantasai> TabAtkins: and then if you make it have an effect later, then that'll break pages
16:47:47 <astearns> q?
16:48:00 <fantasai> gregwhitworth: I would like to figure out how to do that in less than 10 years
16:48:14 <fantasai> TabAtkins: You could have different keywords per input type
16:48:20 <fantasai> TabAtkins: e.g. base-checkbox
16:48:29 <fantasai> TabAtkins: A little more awkward to use...
16:48:39 <fantasai> gregwhitworth: but maybe 10yrs later we can have just 'base'
16:49:03 <TabAtkins> fantasai: Another thing: naming it ::checked-indicator would make it clearer, ::indicator is super generic
16:49:33 <leaverou> Or just embrace the generic-ness and call it ::marker :))
16:49:37 <TabAtkins> gregwhitworth: I purposely didn't do the openui agenda for naming; we resolved on "indicator" there bc it's the generic word across component libraries
16:49:55 <tantek> +1 fantasai agreed, "indicator" sounds too generic, unless we actually define what it means for all controls that have "indicators", e.g. the disclosure triangle from summary/details!
16:49:56 <TabAtkins> fantasai: Sure, no problem with "indicator" itself, just that *by itself* it's not clear what it refers to
16:50:06 <TabAtkins> fantasai: Another topic: 'content' should apply so we can swap out for text or other images
16:50:30 <TabAtkins> fantasai: If you want the default contents to be a particular SVG, sure; but 'content' should still apply
16:50:37 <TabAtkins> gregwhitworth: Oh yeah sure, please open an issue for this
16:50:55 <TabAtkins> gregwhitworth: I like the idea of not having `[type=checkbox]::checkmark-indicator`
16:51:15 <leaverou> -1 to ::checked-indicator, as greg pointed out it would end up being too generic
16:51:16 <fantasai> ::checked
16:51:19 <fantasai> ::checked-indicator
16:51:22 <brandon> wouldn't ::indicator be targeted by the elements state? e.g. checked, indeterminate? which then makes its specific?
16:51:25 <leaverou> s/too generic/too repetitive/
16:51:25 <TabAtkins> fantasai: ::checked-indicator to match :checked
16:52:01 <TabAtkins> gregwhitworth: You'll be applying this alongside selector that already targets the element, so it should be obvious from the fuller selector context that this is a checkbox indicator
16:52:23 <Rossen_> q?
16:52:42 <TabAtkins> florian: I'm unsure how this - i like appearnce:base
16:52:42 <Rossen_> ack florian
16:52:47 <TabAtkins> florian: Unsur ehow styling works in UA stylesheet
16:53:04 <emilio> hah, was going to mention just this
16:53:05 <TabAtkins> florian: Can't select off of the property value
16:53:17 <TabAtkins> florian: But the UA probably does want to style appropriately based on the base value
16:53:38 <tantek> semi-agreed with florian, please don't overload 'appearance'
16:53:40 <TabAtkins> florian: So probably want some magic in the UA stylesheet for this
16:53:41 <Rossen_> q?
16:53:51 <emilio> actually, on checkboxes border doesn't suppress appearance
16:54:04 <TabAtkins> gregwhitworth: Yeah wehn I discussed with TabAtkins earlier we realized that magic would be necessary.
16:54:17 <tantek> q?
16:54:29 <fantasai> TabAtkins: It's a UA stylesheet in the shadow
16:54:48 <fantasai> florian: It's not just the parts inside that you're styling, but the checkbox element itself
16:54:58 <fantasai> fantasai: You can select the host element from shadow
16:55:32 <TabAtkins> florian: For existing checkbox/radio button, wonder if we could get away with ::before in that magic stylesheet
16:56:05 <TabAtkins> florian: I think if we were defaulting to unicode for checkbox, we could use ::before; if you want to default to an SVG that wouldn't fly...
16:56:09 <TabAtkins> florian: Anothe rpoint
16:56:17 <gregwhitworth> btw, here's a non-production web component that shows this: https://codepen.io/gregwhitworth/project/editor/754e0097edc1dd2e17617a36fed89d06
16:56:23 <TabAtkins> florian: For the controls that are reasonably stylable with appearance:none, people have styled them
16:56:56 <TabAtkins> florian: For the ones that are complex enough that "none" is unusable bc too much structure is needed, maybe we could define that "none" is the same as "base". Like for range controls
16:57:16 <TabAtkins> gregwhitworth: Yeah I was going to piggyback on "none" ages ago
16:57:30 <TabAtkins> florian: Also, +1 to tab's idea of specialized keywords
16:57:32 <Rossen_> ack emilio
16:57:42 <TabAtkins> emilio: Was gonna mention some of Florian's point, namely tweaking UA stylesheet is annoying
16:58:08 <TabAtkins> emilio: Right now, checkbox and radios are trickier than most, because appearance:none changes the box itself - it'll start respecting the display value, for example
16:58:16 <TabAtkins> emilio: For most controls we can explain it as shadow DOM
16:58:54 <TabAtkins> emilio: So Gecko has the ability to create elements at layout time; webkit/blink can't do that, they have the shadow present immediately and change the styling
16:58:58 <faceless2> present-
16:59:06 <GameMaker> GameMaker has joined #css
16:59:13 <TabAtkins> emilio: So it would be tricky, but overall this seems sane
16:59:35 <TabAtkins> emilio: Also right now, no browser creates a bunch of elements for checkboxes/radios, so if you have thousands that gain "base" it could slow things down
16:59:52 <TabAtkins> emilio: Right now they're just a single elemnt with a paint-time rendering
17:00:35 <TabAtkins> emilio: The shadow dom-in-stylesheet thing only works if the shadow dom is not there with appearance:auto
17:00:53 <TabAtkins> emilio: I think gecko can do it, but other browsers maybe not. IMplementability is tricky.
17:01:21 <TabAtkins> emilio: Borders in particular don't have florian's issue - nothing suppresses auto appearance for checkboxes
17:01:36 <astearns> ack jensimmons
17:01:38 <TabAtkins> jensimmons: I don't feel comfortable resolving on this yet
17:02:16 <Rossen_> ack jensimmons
17:02:23 <TabAtkins> jensimmons: I'm not sure what's actually bieng proposed yet - there was no code examples in the slides, ther'es no explainer...
17:02:58 <TabAtkins> jensimmons: Not even deatils needed, just big-picture of what are we doing, what's the plan for the future...
17:03:10 <fantasai> gregwhitworth, just send an attachment to www-archive@w3.org
17:03:11 <TabAtkins> gregwhitworth: I think those are all answere din the explainer, which I just can't expose publicly quite yet
17:04:42 <TabAtkins> Rossen_: Very valid feedback - getting the explainer out ahead of the discussion would have answered these questions
17:05:31 <TabAtkins> gregwhitworth: So inverting, would someone be against me writing a PR as we reveal the explainer, etc?
17:05:51 <TabAtkins> Rossen_: There's a lot more details than just PR - you'll go thru a TAG review, etc. It'll speed up once you get an explainer out.
17:05:55 <tantek> +1 to a much more clear / expanded explainer, rather than spec text
17:06:05 <Rossen_> ack nicole
17:06:07 <TabAtkins> nicole: I think this is a problem worth solving.
17:06:17 <TabAtkins> nicole: We did some looking around how appearance:none is currently used
17:06:36 <TabAtkins> nicole: We foudn another compat problem - people applied props that *only* work when appearance:none is on, but don't set appearance:none so those props dont' do anything
17:06:49 <TabAtkins> nicole: So they get backwards non-compat accidentally
17:07:12 <tantek> +1 nicole, use of appearance is confusing already, and I'd take that a step further: OpenUI should (must?) not use 'appearance' for any aspect of its design
17:07:19 <TabAtkins> Rossen_: Are youa skign about a fallback mechanism?
17:07:55 <TabAtkins> nicole: No, this feature triggers many things working, but if people use this now without (accidentally) turning this on, it makes things hard to change in the future
17:08:03 <fremy> fremy has joined #css
17:08:22 <TabAtkins> nicole: So if they set, say, height on it, which only works with appearnce:none, then that makes it hard for us to ever make 'height' work on default appearance for those elements
17:08:29 <fremy> present+
17:08:44 <gregwhitworth> Explainer: https://github.com/salesforce/standards-explainers/blob/master/indicator-psuedo/explainer.md
17:08:49 <TabAtkins> fantasai: But that doesn't happen unless you set appearance
17:08:52 <gregwhitworth> yay, it went public just in time :)
17:09:09 <Rossen_> q
17:09:23 <Rossen_> ack leaverou
17:09:24 <TabAtkins> nicole: Right, this was building on the earlier talk about this making it hard to ship "base" for othe relements in the future
17:09:35 <TabAtkins> leaverou: ABout where :indicator points
17:09:54 <TabAtkins> leaverou: If it points to the SVG, you can set storke/fill on the svg and those inherit
17:10:20 <TabAtkins> leaverou: Anothe rpoint, not sure about base-checkbox/base-radio, seems ocnfusing that you can apply them to othe rprops and they don't work
17:10:50 <TabAtkins> gregwhitworth: I already proposed that ::indicator is on the SVG
17:10:55 <TabAtkins> leaverou: Oh, ok
17:10:55 <tantek> +1 leaverou yes 'appearance' is a complete mess (again, I'm sorry). please stop attempting to expand it.
17:10:59 <Rossen_> ack fantasai
17:11:16 <TabAtkins> leaverou: Woudl also be good to have slides posted
17:11:33 <tantek> (I'm not queuing because leaverou already made the points I wanted to make)
17:11:36 <Rossen_> ack tantek
17:11:38 <Rossen_> ack TabAtkins
17:11:47 <fantasai> TabAtkins: need to point to path as well, because some properties don't inherit, like the path
17:11:52 <fantasai> TabAtkins: Most things can go onto svg, no problem
17:12:11 <fantasai> TabAtkins: Wrt base-checkbox etc. Reason those were weird and bad for appearance is because they were defined as "make this element look like this other thing" on any element
17:12:23 <fantasai> TabAtkins: They were supposed to do something, didn't, and wasn't clear what they were supposed to do at all
17:12:28 <gregwhitworth> https://www.irccloud.com/pastebin/S1etVZTK/
17:12:37 <gregwhitworth> jensimmons: ^
17:12:38 <fantasai> TabAtkins: The new values would only work on the matching elements, and would be well-defined what it does
17:12:43 <florian> q+
17:12:49 <fantasai> TabAtkins: doesn't have any effect on other things, will be interoperable
17:12:56 <fantasai> TabAtkins: doesn't have same problems as the previous appearance values
17:13:22 <fantasai> leaverou: Wrt SVG path, can just replace the SVG
17:13:24 <fantasai> TabAtkins: Then can't style it
17:13:52 <TabAtkins> florian: Also: the appearnace list had all the control *parts*, which made the property's list enormous, and different brwosers had different anatomies so their lists were different...
17:13:58 <Rossen_> ack florian
17:14:00 <TabAtkins> florian: Not trying to reproduce that, so this would be more manageable.
17:14:17 <TabAtkins> Rossen_: So wrapping up, Greg has dropped an explainer link.
17:14:38 <tantek> (aside: correction: appearance didn't have the control *parts* but rather had a hierarchy of types of controls, I can see how that could be confusing though)
17:14:56 <TabAtkins> Rossen_: It feels like people in the group want to be able to read the explainer before resolving on anything. Can you bring it back next week's call after people have a chance to read?
17:15:02 <TabAtkins> gregwhitworth: Yes, and please file issues as you find things.
17:15:20 <TabAtkins> <br dur=10min>
17:17:26 <TabAtkins> emilio, it would still work to have the SVG always inside the checkbox but display:none'd by default, right?
17:17:35 <TabAtkins> it woudl increase the weight of the elements, which you reaised as a separate concern
17:18:07 <tantek> FYI: original 'appearance' definition in case anyone wants the sordid history: https://www.w3.org/TR/2002/WD-css3-ui-20020802/#appearance
17:18:57 <TabAtkins> tantek: If you consider 'appearance' poisoned, nothing particularly wrong with minting a new property here, it's just that 'appearance' *already* has the right semantics.
17:19:03 <emilio> TabAtkins: hmmm, you mean with `appearance: none`? Having something like a shadow dom with the hidden svg could work I suspect, yeah
17:21:04 <TabAtkins> emilio: Dunno quite what you mean wrt appearance:none here, but probably, yes.
17:22:55 <emilio> TabAtkins: yeah, I meant that it wouldn't affect current uses of appearance: none
17:23:40 <TabAtkins> emilio: Then yes, definitely.
17:23:54 <TabAtkins> Also: I'm out for the day so kitty can go to the vet. See y'all Thursday!
17:24:42 <myles> ScribeNick: myles
17:25:28 <Rossen_> Topic: [css-pseudo-4] Standardizing input[type="range"] styling
17:25:39 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4410
17:26:16 <myles> Rossen_: originally from a 3rd party person, added to the agenda by emilio
17:26:23 <myles> emilio: <silence>
17:27:19 <myles> emilio: we basically need a concrete proposal. I wanted to check with gregwhitworth to make sure. I don't know why I added this to the agenda. I wanted to check with gregwhitworth and ensure we can put this together if he's interested.
17:27:19 <myles> gregwhitworth: Can we just close this issue?
17:27:19 <myles> gregwhitworth: we already resolved that we should do the 3 pseudo elements
17:27:24 <myles> gregwhitworth: feel free to ping me on the side. The anatomy is ready to be defined.
17:27:33 <myles> Rossen: so we don't need an additional resolution?
17:27:35 <myles> gregwhitworth: emilio?
17:27:36 <myles> emilio: yes
17:27:58 <myles> Topic: [css-pseudo] Pseudo-element for dragged element
17:28:02 <myles> GitHub: https://github.com/w3c/csswg-drafts/issues/1703
17:28:26 <myles> fantasai: Do we want to do this or not? If we do, I can try to spec something up. If we don't care, I will defer the issue, I will defer to a future level of the spec.
17:28:36 <myles> Rossen: Has anyone had a chance to look this over and form an an opinion?
17:29:19 <myles> gregwhitworth: I did. I didn't ask what's in there. I'll go in there and ask. I wanted more concrete use cases. I can guess them, but b/c HTML drag'n'drop exists, i'm trying to figure out what they want beyond that.
17:29:19 <myles> gregwhitworth: I can go on there and ask them.
17:29:19 <myles> gregwhitworth: To answer fantasai's question: I wouldn't spend time on it until I got concrete gaps.
17:29:32 <myles> Rossen: Proposal: gregwhitworth to engage with sebastian, then come back
17:29:45 <myles> chrishtr: I'll check difficulty of implementation
17:29:47 <tantek> +1
17:29:48 <myles> Rossen: perfect. great.
17:30:43 <myles> Topic: [css-selectors-4] browser focus styles and focus-visible, example 38
17:30:47 <myles> GitHub: https://github.com/w3c/csswg-drafts/issues/4278
17:31:18 <myles> rego: florian reported it, but I added it to the agenda
17:31:18 <myles> rego: florian was asking about focus-visible in the spec. Was asking about using focus-visible to remove the old line from the element
17:31:43 <myles> rego: The thing is that, this was confusing to some people, and kind of a hack to disable the whole line instead of the focus when you have focus visible, to see the whole line but not always
17:32:00 <myles> rego: this is kind of confusing. you expect when it matches focus-visible, it matches only when the outline is painted.
17:32:04 <myles> rego: and if it's not painted it's not
17:32:25 <myles> rego: chromium was not using that in its default visible. So you would get an outline but the element wasn't matching focus-visible
17:32:45 <florian> q+
17:32:54 <myles> rego: Chromium's impl is updated. The default stylesheet uses focus-visible. So this example can be removed from the spec. Because it was only due to some browsers' implementations.
17:33:18 <myles> florian: We should double remove it.
17:33:35 <myles> florian: This is no longer how browsers work. It shouldn't stay there. Also, even when we were before that change, specs are a bad place to put descriptions of hacks you need to use to force browsers to not follow the spec behave correctly. And if we do that, it needs to be described deliberately
17:33:52 <myles> florian: now that it's no longer relevant, remove it, and if we need to highlight workarounds in the spec, be clear they are workarounds.
17:33:57 <Rossen_> q?
17:34:01 <Rossen_> ack florian
17:34:08 <myles> rego: So the proposal is to remove the example from the sepc
17:34:55 <myles> bkardell_: We should remove it. My recollection is that we added that to help people understand what it was doing, because you could explain that focused matched all the time, and people said it this way, but people wanted to remove it when that wasn't the case. but that made it into the spec in a way that it should not have. we should take it out.
17:35:19 <myles> Rossen_: proposed resolution: remove the example
17:35:20 <fantasai> If we agree on something, we resolve on it, so it's clear there was an agreement.
17:35:32 <myles> RESOLVED: remove the example
17:36:50 <Rossen_> Topic: [css-contain-2] Proposal: content-visibility: hidden-matchable
17:36:56 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5595
17:37:37 <Rossen_> q?
17:38:03 <emilio> q+
17:38:04 <myles> jarhar: content-visibility: hidden-matchable allows the UA to search for content inside the content, for like find-in-page, which will fire an event before the browser scrolls, which allows you to report a match before the browser does. There was a TAG review. We brought up reader mode, a11y, and css property vs html attribute. The TAG review has been approved. Looking forward to the next steps
17:38:35 <smfr> q+
17:39:31 <myles> emilio: I still feel like ... this allows the page to show content in response to ... putting this property on an element interacts with beforematch which allows you to show the content, and the page needs to a handshake with the browser, where the browser fires an event, and asynchronously will restart the search after the next runloop .... I haven't thought deeply about alternative solutions to this, but it sounds like complex, hard-to-get-right
17:39:31 <myles>  solution
17:39:35 <myles> emilio: that's my main concern.
17:39:44 <myles> emilio: I'm not sure how people are going to use this.
17:39:48 <Rossen_> ack emilio
17:40:10 <fremy> q+
17:40:13 <myles> emilio: ideally, i think the UA could show the content instead, but that's hard with it being a CSS property. It being an attribute could maybe allow this, but it restricts how authors can hide the content.
17:40:26 <chrishtr> q+
17:40:40 <tantek> +1 emilio
17:40:50 <Rossen_> ack smfr
17:41:19 <myles> smfr: I just wanted to reiterate what I said in the past. I don't like how we're adding yet another state to the whole display:none content-visible visibilty:hidden matrix. Will add complication in the future. I agree with emilio about the beforematch algorithm is complicated and error-prone. I would prefer the UA is the one to reveal the content.
17:41:32 <myles> smfr: I still think that the fact that UAs that have reader mode basically mostly undoes the optimization that is content-visibility:hidden-matchable is unfortunate. I'm not sure anyone in TAG was representing UAs that have reader mode and would be impacted by that
17:41:38 <myles> Rossen_: we've been shipping reader mode for quite some time
17:41:42 <tantek> +1 strong agreement with smfr. the complexity this adds to the author model (display:none, visibility:hidden, etc.) makes a bad thing worse.
17:42:31 <Rossen_> q?
17:42:47 <myles> smfr: In order to get reader mode correct you have to resolve styles and layout inside content-visiblity:hidden-matchabe, which defeats the optimization wehre the browser can skip layout. So if your UA needs to look through the page content to determine if there is readerable content, itw ould have to do almost all the work you would have to do if you had the real content. So it's unfortunate we've designed a feature that has that performance trap.
17:42:47 <myles>  Performance will not be portable between implementations.
17:43:13 <bkardell_> q+
17:43:24 <myles> Rossen_: You're under the assumption that reader mode won't take advantage of content-visbility:hidden-matchable the way the regular presentation in non-reader mode would do it. I'm not sure how all reader mode implementations are done.
17:43:40 <Rossen_> ack fremy
17:44:37 <myles> fremy: My impression of the use case, let's say you have a book or a long word document, you already know the text on each page, but you don't want to lay out the whole book before the user can see the first page. So you'll put each page in a div, and you want the user to search through the book, and so if the user agent finds some text on page 30, the UA goes to page 30 and says to the website, i'm about to display page 30, please re-lay-out
17:45:18 <myles> fremy: I don't see any other way you can do that optimization. If you were to hook up directly into the browser UI... when i'm first loading the webpage, don't do a whole layout, but when you search on page 30, the browser really needs page 30. Before the browser actually scrolls to page 30.
17:45:53 <myles> fremy: If you have reader mode, it can just stop doing layout eventually... like if you have already 10 pages, just stop laying out, and if the user scrolls, then continue. Or you could skip dirty page of the book and do the layout later. If i have a book, I shoudl be able to say "layout just the pages I need, but search through the entire book"
17:46:00 <smfr> q+
17:46:08 <bkardell_> q-
17:46:20 <Rossen_> ack chrishtr
17:46:28 <tantek> trying to read https://github.com/w3ctag/design-reviews/issues/511 to understand why it was considered acceptable to consider this as a CSS property (seem very much tied to content semantics)
17:47:19 <myles> chrishtr: it's not hard for sites to implement against this feature. We've found the opposite with experiments in partners. These are sections of the UI int he page that are already there and there are already a click handler that shows the hidden section. So the click handler is registered against another event and that's all you do
17:47:27 <myles> chrishtr: All these points about reader mode were discussed multiple times in previous CSSWG meetings. We all agreed we would defer to the upcoming TAG review for them to weigh in on it.
17:47:43 <myles> chrishtr: There are no new arguments here. I am expressing frustration.
17:47:51 <tantek> +1 chrishtr, this is my recollection also
17:48:11 <myles> Rossen_: I appreciate, the function of the TAG is not to make decisions on behalf of CSSWG. CSSWG is the venue for this. it's up to us, not hte TAG
17:48:23 <myles> Rossen_: From architectural poitn of view, it makes sense.
17:48:51 <tantek> +1 myles, we have these issues AND there should be a TAG review
17:48:53 <tantek> q+
17:49:09 <Rossen_> ack smfr
17:49:10 <tantek> q++ emilio
17:49:15 <tantek> qq+ emilio
17:49:20 <tantek> q- +
17:49:33 <tantek> q- later
17:49:49 <myles> smfr: Clarification in response to fremy: find has to resolve styles and do some amount of layout to determine if something should be shown. It will not show things that are 1px tall, not show display:none. So when you have hidden-matchable stuff ... <missed>
17:50:10 <myles> smfr: the problem with reader is detection, not display. we show a badge to let the user opt-in to reader.
17:50:13 <Rossen_> ack emilio
17:50:13 <Zakim> emilio, you wanted to react to smfr
17:50:20 <Rossen_> ack emilio
17:50:51 <myles> emilio: regarding complexity: the feature gets disabled once the page happens to not show the element in time. Because that's racey. Not only racey with loading, but other user actions. If the user hides by clicking on the icon in the next event loop turn, the page will not be able to show anything, or find again, ever.
17:51:19 <myles> emilio: There are other tasks that shows the element, the find process is ... you cannot use the feature any more. which is kinda weird
17:51:19 <myles> Rossen_: do we have an issue on this
17:51:33 <myles> emilio: I raised it on the HTML spec issue. This issue is spread around so much, i don't even know where I ....
17:51:56 <myles> emilio: I don't want to formally object, because I don't have a better solution that addresses all the features, but I don't want to be unconstructive. But ....
17:52:03 <fremy> q+
17:52:04 <myles> chrishtr: Can we move forward and work through these issues?
17:52:07 <myles> Rossen_: many issues.
17:52:24 <myles> chrishtr: Can we just resolve that we'll generally add the features and work on the details later
17:52:28 <myles> emilio: the details are important.
17:52:52 <tantek> I would object to starting the work without considering an attribute instead
17:53:02 <tantek> and I think the TAG neglected that part of the review
17:53:06 <tantek> q?
17:53:18 <myles> Rossen_: the expectation is that we're resolving on starting the work, not ending the work. I heard 3 or 4 major issues that people want to put forward for this feature. I didn't hear a major objection that says "the feature doesn't make sense, or belong to CSS" which is what we're trying to identify in order to add this to our charter
17:53:18 <myles> Rossen_: unless we think this doesn't belong to CSS then ....
17:53:22 <myles> tantek: I think it doesn't belong to CSS.
17:53:24 <Rossen_> la
17:53:29 <Rossen_> q
17:53:34 <Rossen_> ack tantek
17:54:26 <myles> tantek: fundamentally this is about the semantics of content. I'm surprised this has gotten this far as a CSS property because this should be in HTML. This is about whether contetn shoudlb e searchable, which is semantic. Meaningful = shows up in searches. I am surprised this even got so far. I read TAG 511, and it's pretty thin on whether it should be a CSS property or an HTML attribute. The TAG didn't come to a good conclusion there. This WG should
17:54:26 <myles>  have the purview to question and push back on.
17:55:33 <myles> tantek: The ergonomic issues that smfr and emilio are sufficient to object to starting work, until: 1. it becomes an HTML attribute, and works well with summary and details elements, which is where the use cases would work "despite the fact it's in details, it should be searchable". Once we get that, then i'd be open to re-opening the discussion about the CSS interaction: the visibility model and teh layout. Until that, we are jumping the gun and it
17:55:33 <myles>  will be bad
17:56:07 <myles> chrishtr: HTML attributes are already brought up to the TAG. Semantics are mixed between CSS and HTML. Alice, and expert, says there are plenty of other semantics things that are in CSS
17:56:28 <Rossen_> q?
17:56:31 <myles> tantek: The excuse "there are already other things in CSS" is not a good excuse at all. Just because there is some overlap doesn't mean we should continue being sloppy. I have great respect for Alice, though.
17:56:37 <Rossen_> Zakim, close queue
17:56:37 <Zakim> ok, Rossen_, the speaker queue is closed
17:57:19 <myles> chrishtr: There are argumetns in the issue about why it makes sense to be a CSS property. Please respond to those. Please look at the issue and see the arguments I'm making, try to respond to them, and we can have a constructive discsusion
17:57:19 <myles> tantek: I did.
17:57:19 <myles> chrishtr: The TAG did think deeply about this.
17:57:48 <tantek> the text in 511 does not back that up
17:57:48 <myles> Rossen_: Yes we did! We considered the presentation model of this, compared to other ways in CSS to hide and reveal content. We did consider HTML API surface and the event model and how it fits. This was not a lightweight flippant "go ahead we don't want to deal with this" review.
17:57:57 <myles> Rossen_: I appreciate the candor here but this is not how things went there.
17:58:06 <myles> tantek: Your description doesn't match issue 511.
17:58:12 <myles> tantek: There needs to be more discussion there.
17:58:25 <myles> Rossen_: Feel free to add to the tag review additional questions or reopening it if you want to.
17:58:36 <myles> Rossen_: if you believe this doesn't belong to CSS primarily, please reopen.
17:59:04 <tantek> if there's an hour of minutes about that, please point to that. that was not clear at all in 511
17:59:57 <myles> Rossen_: This topic has been discussed for hours before in CSSWG, and 1 hour in TAG, specifically on that topic. We did discuss the entire name computation model for aria and other a11y-related topics and whether it makes sense. it does. We talked about the visula presentation and how contents vs content-visiblity and how it works. If we had display-contents:none with searchable, that would be sort of this feature is describing, similar to the way we
17:59:58 <myles>  hide boxes for elements that are represented in HTML and in teh DOM while these elemnts are searchable and machable, with display:contents
18:00:21 <myles> Rossen_: if you're arguing about this not being in CSS, then you're also arguing against a bunch of parts of CSS which have already shipped
18:01:19 <myles> Rossen_: I find it very surprising to hear the fact that you're arguing against a large discussion and reasoning in TAG on the basis, and dismissed it as a "light" discussion. It was not a light discussion. I'm not going to force a resolution though. I will give people 1.5 days to cool off on this issue.
18:01:36 <myles> Rossen_: I'm happy to have this as the opening topic on Thursday when Alan is going to chair. And have the final resolution adopting this as part of CSS charter, and starting work, not ending work, and having this to be formally objected and brought back to the objection counsil for resolution
18:01:40 <tantek> clearly there are many aspects we disagree on
18:02:05 <myles> fremy: smfr, can I talk to you?
18:02:24 <myles> Rossen_: I need to end the meeting. Please don't talk over me. We resume back on thursday afternoon pacific time. Please stay healthy and happy
18:02:48 <Rossen_> Topic: end
18:02:58 <Rossen_> Zakim, end meeting
18:02:58 <Zakim> As of this point the attendees have been futhark, dholbert, florian, gregwhitworth, leaverou, alisonmaher, chris, nicole, cbiesinger, miriam, oriol, rachelandrew, emilio, dlibby,
18:03:01 <Zakim> ... dandclark, faceless, brandon, bkardell_, una, TabAtkins, Rossen_, drott, myles, tantek, plinss, r12a, jfkthame, fantasai, fremy
18:03:01 <Zakim> RRSAgent, please draft minutes v2
18:03:01 <RRSAgent> I have made the request to generate https://www.w3.org/2021/02/09-css-minutes.html Zakim
18:03:03 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:03:07 <Zakim> Zakim has left #css
18:03:11 <jfkthame> jfkthame has left #css
18:03:57 <r12a> r12a has left #css
18:07:09 <tantek> irony here is that trying to search for "attribute" in the github issues, I'm not seeing any results from inside the closed disclosure triangles of minutes etc.
18:07:43 <tantek> this isn't just about what *can* (or should) go in CSS or HTML (though yes that's an issue)
18:08:06 <tantek> this is also about fitting in well with existing features, in this case the summary/details element pair
18:08:06 <florian> tantek,maybe summary/detail should be using this system…
18:09:57 <fantasai> summary/detail should "just work" wrt matching content inside
18:09:59 <fantasai> imho
18:10:05 <fantasai> regardless of what happens here in this issue
18:10:24 <tantek> per florian's request, this comment would be greatly improved by linking to the respective minutes of the "Kronos" meeting that is referenced: https://github.com/w3ctag/design-reviews/issues/511#issuecomment-767932845
18:10:49 <tantek> fantasai, I think I agree with that default. Maybe that's worth filing a bug against the HTML spec?
18:12:21 <fantasai> "If a fragment ID or find-in-page targets content inside a closed details element, it should auto-open the element. Otherwise it's confusing."
18:12:25 <chris_> chris_ has joined #css
18:12:27 <fantasai> anything more to add to the issue?
18:13:12 <chris_> Hey TabAtkins what is the bikeshed metadata to make GH issues use their title instead of a bare link?
18:16:09 <tantek> strongly agreed with hober. TAG should be asked for guidance and input, not "deferred to"
18:20:01 <jamesn> jamesn has joined #css
18:21:51 <tantek> FWIW <details> should have been searchable by default
18:25:31 <tantek> discussion of lack of implementer interest incubation
18:25:42 <tantek> and encouraging fast failure of incubations
18:26:19 <tantek> I noted the difference between lack of interest, and active disinterest, discomfort, or even resistance from other implementers
18:27:43 <fantasai> florian: Incubation is the phase in which you're trying to convince people
18:28:05 <fantasai> florian: If someone wants to keep trying, let them keep trying. But not graduate until convinced other people.
18:29:02 <fantasai> hober: generally, yeah, but chairs also have to manage time
18:29:20 <tantek> need separation of use-cases (explainer) and specific solutions (proposals)
18:29:55 <fantasai> florian: incubation is the set of practices where you go from ideas about what you need to "this is officially on standards track"
18:30:16 <fantasai> florian: identifying use cases, coming up with potential solutions, assessing strengths and weaknesses of solutions, convincing ppl you're on the right track
18:30:49 <fantasai> florian: Once ppl convinced you're on the right track, can start standardizing
18:30:51 <tantek> the example of a book with chapters is a good one. you don't want to display all the chapters but you want to be able to search the entire book
18:31:43 <fantasai> florian: this proposal is in the uncomfortable place of not being obviously wrong, but not being obviously right to enough people
18:32:39 <fantasai> astearns: we have agreement that we should work on the problem, but not on the solution; but only one group is working on it, don't have an alternate proposal
18:36:01 <tantek> fantasai, re: https://github.com/whatwg/html/issues/6370, that's also missing a key piece that the text in <details> SHOULD be findable by default. Feels like potentially a separate issue (be findable, then yes, when found, open it)
18:36:38 <fantasai> tantek, add a comment?
18:37:07 <tantek> wasn't sure because it feels like a different issue? to be cross-linked of course
18:37:15 <fantasai> nah, just put it in
18:37:34 <fantasai> if it needs splitting out, can be split out, but they kinda go together
18:37:44 <tantek> they do kinda go together
18:37:53 <jensimmons> jensimmons has joined #css
18:44:28 <futhark> futhark has joined #css
18:44:57 <futhark_> futhark_ has joined #css
18:46:44 <tantek> I don't think I agree with "bias towards action" in the context of improving the web platform, I think that's how you end up bloating the platform with a lot of hastily designed features
18:46:50 <fantasai> +1
18:46:59 <tantek> +1 to what jensimmons is saying
18:48:54 <fantasai> jensimmons: websites have to ship in 6 months, but this is the foundation
18:49:01 <tantek> I think platform ergonomics is MUCH more important than "bias towards action"
18:49:05 <fantasai> jensimmons: need to look forward 50yrs, 20yrs
18:49:48 <fantasai> jensimmons: what we add is permanent, need good solutions not fast ones. We need regions 5 years ago, still don't have it because we don't have a good solution yet
18:51:03 <fantasai> jensimmons: I'm frustrated by that, but I agree with waiting for a good solution
18:52:38 <fantasai> christr: It's just a small feature
18:52:45 <fantasai> smfr: It's more than that, it's an entirely new visibility state
18:54:57 <fantasai> tantek: it's not about the number of properties or complexity of the algorithm, but it's at the interface between semantics and presentation and that's what makes it complex
18:54:58 <nicole> @tantek you aren't wrong regarding poorly designed features. Can be de-risked with well chosen developer partners and incremental testing?
18:56:15 <smfr> q+
18:56:30 <nicole> When we don't bias toward action developers chooses native apps over the web
18:56:56 <nicole> So how to balance the two opposing (but important) goals
18:57:04 <florian> nicole, maybe that's OK? Native apps platform don't all last as long as the web
18:57:20 <astearns> ack smfr
18:57:40 <nicole> It matters when users make the same choice... e.g. they think of the web as something they access through the facebook app
18:57:59 <fantasai> smfr: Shouldn't collapsed sections be accessible without JS enabled?
18:58:00 <tantek> I don't really believe in the native app as bogeyman. native apps are ephemeral fruit flies. they live much shorter lives than websites.
18:58:03 <nicole> Because then momentum is on the wrong side. It feeds into devs choosing apps and then more users choosing apps
18:58:12 <fantasai> smfr: Should be able to make this work without JS
18:58:16 <nicole> Um, facebook is ephemeral?
18:58:31 <tantek> florian is right too, native app platforms / APIs themselves are ephemeral compared to the web
18:58:44 <tantek> facebook is a website
18:58:51 <tantek> their apps are ephemeral
18:58:56 <nicole> I'm not talking about a bogeyman, I mean literally users spending more and more time in apps.
18:59:06 <nicole> time spent on their phones
18:59:56 <astearns> I have never been convinced that we should accept attention-time as an OKR of the web
18:59:58 <nicole> To be clear, I don't believe in the "web is dying" bogeyman. But I do think it's likely to need to massively reinvent itself.
19:00:17 <nicole> We probably need to start thinking of more of these apps as "browsers"
19:00:40 <tantek> +1 smfr, simple thing should be possible without script
19:00:53 <fantasai> smfr: revealing content should just be done by the UA
19:01:04 <nicole> For example, pinterest, it lets you browse the web through the lens of photos and pins
19:01:13 <nicole> Is it not a browser?
19:01:45 <tantek> I'm not sure what pinterest is except an inaccessible aggregator of images optimized for Google SEO :P
19:01:57 <nicole> Anyway, my real point was that both the desire to ship quickly and the desire to ship the right thing are valueable goals
19:02:30 <nicole> AND can be opposition to one another
19:04:34 <fantasai> https://github.com/whatwg/html/issues/6370
19:06:21 <fantasai> chrishtr, smfr ^
19:27:26 <jensimmons> jensimmons has joined #css
19:30:08 <fantasai> https://drafts.csswg.org/css-contain-2/#content-visibility
20:01:48 <jensimmons> jensimmons has joined #css
20:20:48 <tantek> tantek has joined #css
20:22:55 <futhark> futhark has joined #css
20:24:15 <projector> projector has joined #css
20:24:45 <leaverou> leaverou has joined #css
20:25:15 <Rossen> Rossen has joined #css
20:25:45 <shans> shans has joined #css
20:26:16 <sylvaing> sylvaing has joined #css
21:24:33 <tantek> fantasai brought up the 'hidden' attribute and how it was created maybe too late compared to display:none to be properly designed together, and this made me wonder if there was more we could have done there, or can do there now
21:26:18 <tantek> since 'hidden' is a boolean attribute, adding new values that work like the existing default but with some additional functionality is potentially backcompat
21:26:40 <tantek> e.g. (just off the top of my head) hidden='findable' would have the right backcompat fallback behavior
21:27:11 <tantek> to be clear, this is not a formal proposal, nor is it meant to be treated as something "instead of" a CSS property, but rather as another aspect to expand the discussion space
21:29:57 <tantek> obviously there are very different ergonomics between an HTML attribute (even "just" a new value) and a CSS property
21:33:01 <tantek> there are also other examples of where we've had a division of responsibilities / powers / capabilities between markup and styling
21:33:09 <tantek> e.g. direction attribute vs property
21:33:16 <tantek> e.g. lang attribute and :lang selector
21:33:52 <tantek> I think there are some ergonomically positive aspects to separating semantic being expressed vs a desired behavior
21:37:24 <futhark> futhark has joined #css
21:42:46 <fantasai> +1
21:44:14 <tantek_> tantek_ has joined #css
23:21:17 <tantek> I will also note that I looked into mobile Wikipedia and it does NOT use summary/details (really long h2 and div/span etc. markup)
23:21:43 <tantek> However GitHub *does* use summary/details and thus would be improved by fixing the default findability of details elements per https://github.com/whatwg/html/issues/6370
23:22:08 <tantek> (like we'd be able to "find" on a GitHub issue and text inside any CSS discussions would be found)
23:22:20 <tantek> CSSWG* telcon discussions
23:30:12 <geheimnis`> geheimnis` has joined #css