14:57:42 <RRSAgent> RRSAgent has joined #css
14:57:46 <RRSAgent> logging to https://www.w3.org/2024/08/08-css-irc
15:00:36 <sanketj_> sanketj_ has joined #css
15:01:14 <MikeSmith> MikeSmith has joined #css
15:01:18 <gregwhitworth> Zakim, start meeting
15:01:18 <Zakim> RRSAgent, make logs Public
15:01:19 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:01:46 <gregwhitworth> Meeting: CSSWG + Open UI + WHATWG/HTML
15:01:54 <gregwhitworth> Chair: Greg Whitworth
15:02:39 <keithamus> keithamus has joined #css
15:02:47 <emilio> present+
15:02:55 <keithamus> scribe+
15:02:55 <jensimmons> jensimmons has joined #css
15:03:02 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10462
15:03:02 <github-bot> Topic: [css-ui] Pseudo-elements for stylable select
15:03:02 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10462.
15:03:21 <fantasai> present+
15:03:22 <gregwhitworth> q?
15:04:08 <keithamus> Both the pseudo elements for appearance base mode. Two issues, ???... should these elements cover the author provided thing or the button/datalist not be a target of the pseudo elements
15:04:45 <keithamus> The author provided button element; should the element target the author provided or just the fallback? There are trade-offs here.
15:04:51 <MikeSmith> RRSAgent, make minutes
15:04:52 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-css-minutes.html MikeSmith
15:05:11 <gregwhitworth> q+
15:05:11 <keithamus> ... Could be developer convenience but could have complications. How does it work with animations, subtree, etc.
15:05:31 <keithamus> ... There might be styles we could fall back but not both, so we'd need to invent some internal pseudo element to target the fallback
15:05:41 <keithamus> ... Might be better for developers if it targets both
15:05:42 <jarhar> jarhar has joined #css
15:05:54 <keithamus> s/Both the/jarhar: Both the
15:06:15 <akeerthi> akeerthi has joined #css
15:06:32 <gregwhitworth> ack gregwhitworth
15:06:35 <keithamus> gregwhitworth: when you go to change it, its no longer the element. I don't know the technical reasons emilio is pushing back on, but as a dev when I replace it I now own that element so wouldn't expect pseudo to work.
15:06:47 <gregwhitworth> ack fantasai
15:07:02 <chrishtr> present+
15:07:29 <keithamus> fantasai: we have several elements that replace default; button, dropdown, I think we have to think about when a dev is styling they might not know exactly how the control is put together.
15:07:49 <keithamus> ... It might be implemented as native for a while, upgraded to datalist, you didn't change your stylesheets, you're using a component library...
15:08:04 <keithamus> ... I can definitely see why you'd want them to match. The other technical concerns are certainly real.
15:08:08 <emilio> q+
15:08:12 <keithamus> ... From authoring it would be more convenient and more robust.
15:08:18 <gregwhitworth> ack emilio
15:09:18 <keithamus> emilio: I think I get both points. As author, I agree with Greg but if you have more generic styles it can be nice to have a single selector. As a component library, presumably they'd export the dropdown in some other way e.g. shadowpart or shadowdom so you cannot target directly yourself.
15:09:33 <dbaron> Present+
15:10:20 <keithamus> ... Given theres no precedent. Given the complications; like we have a bunch of APIs for exposing pseudo element stuff. Eg getanimations with subtree true returns pseudo element animations, but it would be weird to behave that way... you kind of want the element reference if you have the pseudo but can't do that with shadow root
15:10:30 <keithamus> ... Causes inconsistencies with various APIs like this.
15:10:55 <gregwhitworth> ack fantasai
15:10:56 <keithamus> ... Plus there are usecases for e.g. targeting built in UA one. It's just less complicated to explain if you use pseudo to match the provided, and otherwise not.
15:11:17 <emilio> q+
15:11:24 <keithamus> fantasai: I meant component library in a much more general sense, like not just web components but CSS libraries or something
15:11:30 <gregwhitworth> ack emilio
15:11:37 <fantasai> s/something/templates or something/
15:11:55 <keithamus> emilio: but then changing implementation from built-in datalist to custom one is a breaking change but no more changing than, for example, changing a button to a link
15:12:09 <keithamus> ... if you're using a 3rd party library you need to be mindful of these changes and breaking the API
15:12:36 <keithamus> jarhar: sounded like people are in favor of both sides?
15:12:50 <keithamus> gregwhitworth: We could straw poll or take it back to the github issue.
15:13:10 <keithamus> fantasai: from the agenda it looks like we have this one issue which is a superset of lots of small issues. Can we split this up?
15:13:22 <keithamus> gregwhitworth: you want to tackle this as 4 separate ones?
15:13:39 <keithamus> fantasai: if they're independently resolvable filing separately makes it easier to focus on each one
15:13:49 <keithamus> chrishtr: we could resolve on one of those
15:13:57 <keithamus> gregwhitworth: would we want to have a default position?
15:14:24 <keithamus> ... if an element gets replaced, the pseudo element being applicable irregardless of which one it is - do we want to resolve on that first?
15:14:29 <keithamus> jarhar: that's one of the three.
15:14:36 <keithamus> fantasai: I'd agree we should be consistent
15:14:50 <keithamus> ... as for which way, I feel like we've heard from two or three people
15:15:15 <keithamus> jarhar: I think we discussed this in openui before, a vague memory of people preferring the ???
15:15:19 <keithamus> q+
15:15:53 <gregwhitworth> keithamus: if we allow the pseudo's to target the author provided is the way to differentiate between author and useragent provided?
15:16:04 <fantasai> ::button:not(button)
15:16:09 <gregwhitworth> fantasai: yes, because you could...
15:16:17 <gregwhitworth> ^ typed out her example
15:16:27 <gregwhitworth> keithamus: is that more difficult than than the reverse
15:16:50 <gregwhitworth> keithamus: if I want to select for the built-in verse user provided; which one is more complicated
15:16:57 <emilio> q+
15:16:57 <gregwhitworth> q+
15:17:02 <gregwhitworth> ack keithamus
15:17:24 <keithamus> emilio: I think especially since you cannot use pseudo elements in :not()... I think fantasai's suggestion might not work without changes to pseudo syntax.
15:17:44 <keithamus> ... we don't reveal tag name of the pseudo element. You'd need select:has(datalist:thepsuedo) which is kind of annoyin
15:17:49 <keithamus> s/annoyin/annoying
15:18:00 <gregwhitworth> q?
15:18:01 <emilio> `select:has(> button)::button` or so
15:18:03 <gregwhitworth> ack emilio
15:18:03 <emilio> ack emilio
15:18:08 <keithamus> chrishtr: so this would be in favour of not ???. Like reducing complexity
15:18:35 <keithamus> chrishtr: if there's additional engine complexity in trying to match both at the same time, let's go with just the built-in. Let's developers in a straightforward way to differentiate and avoids complexity in the engine
15:19:00 <gregwhitworth> ack gregwhitworth
15:19:17 <keithamus> gregwhitworth: curious; two jobs to be done: when would I really want to differentiate? To interrogate if there's a user provided vs user-agent provided element.
15:19:26 <emilio> q+
15:19:42 <keithamus> ... I get fantasai's use case. The component library, there's a contract there... but its low probability. What's the use case though keithamus?
15:19:54 <gregwhitworth> keithamus: I don't think I have a good answer to that to be honest
15:20:00 <gregwhitworth> ack dbaron
15:21:02 <keithamus> dbaron: if we go down the path of making pseudo only match built-in, if the author provided ones are in some cases - I don't know how complex - but if they're complex they could have a pseudo class, to match an existing element. A pseudo class is a thing that matches what you already have, vs a pseudo class to match an element that exists in the UA
15:21:02 <keithamus> shadow. One way to do it.
15:21:04 <gregwhitworth> ack emilio
15:22:19 <keithamus> emilio: I dont think the rules here are particular complicated. You need to be a direct child of the select element, so I don't think the pseudo class is necessary. The reason for interrogating if it's a built-in, if you're not a built-in you can do more complex styling of the innards. If you have a big CSS codebase and 2 ways of addressing the
15:22:20 <keithamus> same thing in subtly different ways, it's not amazing but you could want
15:22:50 <keithamus> ... to target the built-in with basic styles and non-built-in for more complex styles. If the pseudo matches both you need to undo the pseudo rules with non pseudo selectors.
15:22:53 <jarhar> q?
15:22:58 <chrishtr> +1, good point
15:23:01 <Linux_Kerio> Linux_Kerio has joined #css
15:23:43 <fantasai> Option 1: Pseudo-element selectors apply to both the user-provided and UA-provided elements in a particular role
15:23:53 <keithamus> gregwhitworth: two foundational positions for this base one that informs the 3 other issues. User submitted will or won't apply. Should we take this back to the issues? I feel like I'm in favour of _not_ having them to apply to user-provided. Is there a strong reason to go in the other direction?
15:23:55 <fantasai> Option 2: Pseudo-element selectors apply only to the UA-provided elements in a particular role
15:24:01 <keithamus> ... does anyone have a strong position
15:24:25 <fantasai> Option 2.1: Also provide a pseudo-class to select to user-provided (and UA-provided?) elements in a particular role.
15:24:30 <keithamus> ... does anyone oppose doing a straw poll?
15:24:58 <keithamus> fantasai: I didn't fully catch what dbaron's position on pseudo classes was.
15:25:15 <keithamus> jarhar: I think it could differentiate what the element was selecting
15:25:29 <fantasai> 1.1: And also provide a pseudo-class on differentiating whether it's a real or pseudo element.
15:25:32 <keithamus> dbaron: you could do either way! But perhaps it's better to leave the sub-options out of the straw poll.
15:25:53 <chrishtr> option 2
15:25:54 <emilio> 2
15:25:54 <jarhar> 2
15:25:56 <ntim> 2
15:25:57 <keithamus> gregwhitworth: for straw poll we'll just do the main options. Please put opion 1 or option 2 in IRC
15:25:57 <fantasai> 0
15:26:02 <keithamus> 2
15:26:05 <gregwhitworth> 2
15:26:05 <astearns> abstain
15:26:09 <dbaron> 2 (weakly)
15:26:24 <fantasai> s/0/abstain
15:26:44 <fantasai> RESOLVED: Pseudo-element selectors apply only to the UA-provided elements in a particular role
15:26:56 <emilio> q+
15:27:05 <gregwhitworth> ack emilio
15:27:50 <keithamus> emilio: for the library use case, I think we resolved on the pseudo element kind of a part-like pseudo. If we were really concerned about providing the same API as a component library we could make exportparts work to expose the inner pseudo elements. Then you could expose the same API in both
15:28:26 <keithamus> gregwhitworth: does this resolve the other issues jarhar?
15:28:29 <masonf> masonf has joined #css
15:28:52 <keithamus> jarhar: I think it could be worth raising 1 new issue for each pseudo, asking should it exist and what should it be named. WIth that in mind we can close this issue
15:28:58 <keithamus> chrishtr: what are the three issues?
15:29:03 <keithamus> ... 1 is the one we resolved
15:29:08 <keithamus> ... 2 is do we need them
15:29:13 <keithamus> ... 3 is what are their names?
15:29:15 <keithamus> jarhar: yes
15:29:24 <keithamus> chrishtr: are we ready to discuss 2 or 3 yet?
15:29:31 <keithamus> gregwhitworth: yes I think it's a bookkeeping issue
15:29:42 <keithamus> chrishtr: jarhar could make issues after the meeting and copy the resolutions
15:30:02 <gregwhitworth> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10440
15:30:02 <github-bot> Topic: Styling form control pickers
15:30:02 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10440.
15:30:03 <keithamus> jarhar: I'd like to get to the second issue because it can affect how we name the pseudos.
15:30:45 <keithamus> jarhar: Proposal to have incremental opt in for elements with pickers using ::picker psuedo which you could add appearance:base on to get the new styling for the picker itself.
15:31:05 <keithamus> ... so this would be alternative for e.g. appearance: base-select opt in for each rule
15:31:21 <keithamus> ... one problem is that Chrome is looking to ship select first, so opt in for page pickers is not that helpful
15:31:40 <keithamus> ... on top of that Una posted a comment about it being more of a developer burden for developers to do this on each picker
15:31:54 <keithamus> ... IMO we should have appearance:base on root element for everything without incremental opt in
15:32:16 <keithamus> ... the push back was incremental opt in but una and anne are talking about the same issue regarding opt in
15:32:24 <keithamus> ... ???
15:32:27 <keithamus> ... the author has to remember more things for each element.
15:32:34 <keithamus> ... the whole thing is brought up as a need for incremental opt in
15:32:58 <una> q+
15:32:59 <keithamus> ... but we can add support for supported elments, tweak style to show it didnt apply properly or isn't supported on this element yet.
15:33:00 <gregwhitworth> q+
15:33:02 <keithamus> ... I think it simplifies it.
15:33:03 <gregwhitworth> ack fantasai
15:33:11 <gregwhitworth> ack gregwhitworth
15:33:27 <jarhar> q?
15:33:28 <jarhar> q+
15:34:01 <keithamus> fantasai: the issue isn't can we feature detect, incremental opt in is for compat reasons. Authors will use a more general selector than is needed then opt in, but then we end up with "we cant ship appearance: base" on, say, date controls. Now we need a _new_ keyword appearance: base-no-really including date pickers. That's _why_ we need an opt in.
15:34:22 <jensimmons> jensimmons has joined #css
15:34:45 <keithamus> ... the reason we split into in page and not-in-page. We believe we can pull together the necessary standardisation/implementation work to do this within a reasonable amount of time, but styling pickers is a multi year project. Something we'll have to do incrementally
15:35:03 <keithamus> ... it may be that developers are find with not-in-page pickers but want to style in-page
15:35:05 <keithamus> ... ???
15:35:22 <keithamus> ... thats why its incremental on the picker. to enable incremental styling of the in-page then add the picker
15:36:04 <keithamus> ... The reason we have picker with a bunch of identifiers is that we don't anticipate being able to tackle handling all of the pickers consistently and thoroughly in a single ship.
15:36:25 <keithamus> ... We can make the picker identifier optional after a certain point, authors can just use ::picker without the keywords, but this gives us a gradual transition towards that.
15:36:32 <keithamus> ... Allowing us to ship in pieces.
15:36:33 <gregwhitworth> ack una
15:36:38 <masonf> q+
15:37:02 <gregwhitworth> q+
15:37:08 <keithamus> una: thanks for the explanation fantasai. I've been playing with it quite a bit, the biggest aversion to the current proposal is having to do this in multiple places and remembering the names of all the pickers, in order to get this to work properl
15:37:25 <keithamus> ... ideally authors would not have to remember that and just do it in one place
15:37:41 <fantasai> Totally agree that this would be better. We just think it's not possible due to anticipated compat restrictions.
15:37:50 <keithamus> ... I think jarhar mentioned doing @supports to incrementally adopt. We cant use @supports to detect outside of CSS. What are your thoughts there?
15:37:55 <fantasai> But at least this gets us to a world where that can be possible in the future.
15:38:33 <keithamus> jarhar: @supports whether appearnace: base supported on specific elements. If we ship select first and you put it on input type=range that'll still be auto. We add an @support and we can say that works, we still need a unique identifier for that.
15:38:42 <keithamus> ... then we make a new @supports for each one
15:38:53 <keithamus> ... in your @supports rule you could style each one.
15:39:13 <keithamus> ... then if you put html in your select is a separate html thing, it would still support the new structure just render in the native browser way
15:39:15 <ntim> q+
15:39:18 <jarhar> q?
15:39:30 <keithamus> una: so would this work with the picker opt in?
15:40:06 <keithamus> ... so Anne mentioned putting appearance:base on both the base element and the ::picker(type-of-picker). Is it possible to make it just in one place, e.g. the pseudo element
15:40:44 <keithamus> fantasai: that would only select the picker, you could apply styles to the picker only. Setting appearance base on that would make the picker base, but the in-page control still auto
15:41:09 <keithamus> ... even before pickers are stylable we want the in-page control to opt into appearance:base. We think authors want in-page styling _the most_, over the pickers.
15:41:21 <keithamus> ... obviously they want both but in-page seems to be the most desired.
15:41:32 <keithamus> ... could we have it magically propagate? Maybe but that would be super weird
15:41:50 <keithamus> una: and the other way around, base on the in-page propagating to picker doesn't resolve the issue you're brining up?
15:42:25 <keithamus> fantasai: yeah. Its possible authors don't want to put in the effort to style pickers, just in-page, so it's useful to have the difference, but it also allows us to incrementally ship these features. So we don't run into compat issues
15:42:43 <keithamus> una: I'm curious if you've had feedback from authors about if they don't want to style pickers vs in-page?
15:43:23 <ntim> I could see developers wanting a native picker and base-styled in-page
15:43:26 <keithamus> fantasai: we haven't heard that specifically but the main thing driving the design is how to opt things in with minimal impact without memorising weird keywords, which we agree is undesirable but we need some way to handle opt in
15:43:28 <masonf> q?
15:43:53 <ntim> native picker have special capabilities such as expanding outside of the window bounds for instance
15:44:25 <keithamus> jensimmons: we've not done specific research for e.g from big corporate partners but remembering what it's like to be a web designer on a smaller budget, everything in-page needs to be represented in brand but budget restricts from designing every single thing, so we might want to style the select but not be able to style the picker.
15:44:40 <keithamus> ... bigger projects will, e.g. delta really wants their calendar to look like a delta calendar
15:44:46 <fantasai> +1 jensimmons
15:45:02 <keithamus> ... but where budgets are much smaller I think it'll be common that they want in-page styles but no budget to worry about styling the picker
15:45:26 <keithamus> una: I see where you're coming from. I'd like to do more research. I've heard it's currently hard to style the picker, not the button
15:45:29 <chrishtr> q?
15:45:54 <una> q+
15:46:02 <keithamus> jensimmons: asking for select menu, asking for calendars, this is what we hear a lot but thinking through styles - it's difficult. Styling buttons can be styled however you want but oh, unless its input type=file.
15:46:21 <keithamus> ... it would be very annoying to roll out changes to all controls one-by-one. It's a better project to do all at once.
15:46:33 <keithamus> ... but its impossible to do ALL in-page and pickers all at once.
15:46:46 <keithamus> ... tackle all in-page controls all at once and pickers one by one
15:47:00 <gregwhitworth> ack jarhar
15:47:54 <keithamus> jarhar: fantasai mentioned ::picker for compat for incremental opt in. All in-page first, then incrementally with pickers. masonf & chrishtr - correct me if I'm wrong but we can't do all in-page at once? And we want to ship select first? Still seems best for developers to me to have appearance base on root element, or ::picker(select) apply its
15:47:54 <keithamus> value to the root element, to ship select first.
15:47:58 <gregwhitworth> ack masonf
15:48:25 <keithamus> masonf: important to remember this is compat. We can do appearance:base and eat the risk, or two options: appearance:base-something or ::picker(something). Both are ugly but both work
15:48:54 <keithamus> ... but working on select for 5 years and talking to developers. All in-page controls are pretty stylable. The really tricky bits are stuff like select where there's a picker
15:49:04 <keithamus> ... for example putting rich content in the picker shows up in the base control.
15:49:29 <keithamus> ... I find it really unlikely well be able to ship all in-page in a year. I think each will have to be shipped hollistically, in its entirety, picker and all.
15:49:49 <keithamus> ... having said all that, if that's all true it seems to me that we should make it easy for developers to opt in to each control.
15:49:55 <keithamus> ... let's make it as easy as we can for developers
15:51:12 <chrishtr> opt-out is a good idea
15:51:13 <keithamus> gregwhitworth: I think there's 3 options. I haven't heard not caring about the picker a ton, but I personally lean towards... we all want appearance:base, I want to do *{appearance:base}. But to go to una's point, if I did that on select I'd expect it to apply to picker. Doesn't mean picker pseudo can't exist, we don't have to throw the premise of
15:51:14 <keithamus> opt-in/out for pickers, but I agree with masonf
15:51:34 <keithamus> ... so before we even talk about base we have to talk about the parts,e.g. file. How do we lay them out? Whats the base styles for that/
15:51:51 <keithamus> ... some may go faster than others but there is such disparity between even UAs as to what they do
15:52:27 <keithamus> ... so I think there are 3 options, appearance:base being north star, but same for gap, flex-gap grid-gap sucks let's just use gap...
15:52:31 <gregwhitworth> ack gregwhitworth
15:52:34 <keithamus> ... but we'll need that for appearance:base
15:52:35 <gregwhitworth> ack ntim
15:53:06 <chrishtr> opt-out gives a way to get a native picker
15:53:17 <keithamus> ntim: I want to emphasize on the value of the pickers having a different appearance. A native picker could be a design choice. e.g. on visionOS you might want the nice native picker going out of system bounds. There's value in picker being native.
15:53:29 <keithamus> ntim: having appearance:base toggling on everything goes against that.
15:53:48 <keithamus> ... from a design systems view pickers will likely be different going control-by-control.
15:54:05 <keithamus> gregwhitworth: most design systems to have base foundationals
15:54:32 <keithamus> ntim: yeah I am saying most design systems wouldn't want to style a specific control, in-page and picker. They'd separate by in-page vs picker.
15:54:44 <keithamus> ntim: you dont want 1 control to have native, and others to have base-styled. You want consistency.
15:55:00 <jarhar> q?
15:55:04 <gregwhitworth> ntim I want to +1 that the picker feature possibly being useful, I think I disagree with them being native by default
15:55:11 <keithamus> ... like in the future I would see systems libraries doing *::picker{appearance:base} or *{apperance:base} for in-page. This is the future I see.
15:55:17 <gregwhitworth> ack una
15:55:42 <jarhar> we could make select { appearance:base; } imply select::picker(select){appearance:base} and then you could also apply select::picker(select){appearance:auto} to make the picker go back to the native appearance
15:56:19 <jarhar> there are also existing ways to style the in-page part of select with appearance:none which we could extend with the new content model that allows an author button
15:56:19 <keithamus> una: +1 to appearance:base being north star. Changing way to opt into form controls. Theoretically users would be able to connect any button to the picker using invokers, that would give them control for any page control, whatever control that is. We talked about selectoption linking to any form control, e.g. outside of select, controlling the
15:56:19 <keithamus> control
15:56:29 <keithamus> ... this gives users more capability to customise in-page control vs pickers
15:56:36 <keithamus> ... right now we don't give users choice on picker
15:56:54 <keithamus> ... currently there is some styling with appearance:base-select. Users don't necessarily need to customise it
15:57:08 <jensimmons> q-
15:57:18 <keithamus> ... this could open the door for new controls having custom styles for appearance:base. We could do more there, e.g. 3d...
15:57:22 <jensimmons> q+
15:57:30 <keithamus> ... ???
15:57:33 <gregwhitworth> ack fantasai
15:57:52 <gregwhitworth>  q+ fantasai
15:58:22 <keithamus> jensimmons: what's great about appearance:base is it switches the very different operating system controls - per platform - its very hard to override those. appearance:base gives everyone a consistent control, same in each browser
15:58:38 <ntim> gregwhitworth: it's already the current default though
15:58:52 <keithamus> ... I'm responding to hearing people say it's not hard to design in-page controls. Putting your own styling on e.g. checkboxes right now is annoying. Doing it across all would be very valuable to all developers
15:58:55 <gregwhitworth> ack jensimmons
15:58:56 <gregwhitworth> ack fantasai
15:59:27 <jensimmons> And Apple is working on in-age controls now, coming up with a proposal to share when it's ready.
15:59:38 <jensimmons> *in-page
15:59:46 <keithamus> fantasai: I think we at apple generally disagree we can't ship apperance:base all at once. We think its doable within the next year or two, and not take as long as doing all of the pickers. In terms of select specifically, it's special, google's been working hard on it but it's also a form control where the picker and all components can be
15:59:46 <keithamus> represented as elements in the page.
15:59:57 <keithamus> ... most other form controls have pickers with UA magic
16:00:19 <keithamus> ... it might be reasonable to ship appearance:base-select just for selects, while we work on the rest, then ship appearance:base for everything
16:00:23 <jarhar> agree
16:00:24 <keithamus> ... so we can split the difference
16:00:29 <masonf> +1 to that approach!
16:00:40 <chrishtr> +1 to base-select
16:00:41 <keithamus> ... we dont want values foe every form control but a short-term phase for select seems reasonable and acceptable.
16:01:03 <gregwhitworth> Zakim, end meeting
16:01:03 <Zakim> As of this point the attendees have been emilio, fantasai, chrishtr, dbaron
16:01:06 <Zakim> RRSAgent, please draft minutes v2
16:01:07 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-css-minutes.html Zakim
16:01:13 <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent.  Goodbye
16:01:14 <Zakim> Zakim has left #css
16:46:46 <jamesn> jamesn has joined #css
17:48:48 <fantasai> dbaron, chrishtr mentioned that you had feedback on line-fit-edge... can you post it somewhere?
17:49:47 <dbaron> fantasai: what's line-fit-edge?
17:50:00 <fantasai> dbaron: the property we split from text-box-edge
17:50:11 <fantasai> https://www.w3.org/TR/css-inline-3/#text-edges
17:51:46 <dbaron> it seems entirely plausible that I did have feedback... but I'll probably need to figure out from scratch what it was... :-/
17:55:27 <dbaron> fantasai: reading it from scratch, it seems like some of the values (cap, ex) define only the top edge and others (alphabetic) define only the bottom edge, yet there's no way to specify a bottom and a top separately.  (I also don't feel like I've seen this before so maybe it was someone else who had feedback.)
17:55:53 <dbaron> oh, wait, there is, I misread the syntax definition
17:57:14 <dbaron> yeah, not immediately sure what feedback I have other than that the description of the values could perhaps be clearer about separating the definition-for-over-edge from definition-for-under-edge
17:57:32 <fantasai> The interesting parts are in the next section https://www.w3.org/TR/css-inline-3/#inline-height
17:57:43 <fantasai> so maybe it was about that...?
18:01:10 <dbaron> fantasai: yeah, maybe I'm not sure about some of the tradeoffs around using the first available font versus all glyphs on uniformity of spacing/alignment versus getting the desired separation.
18:01:42 <dbaron> but I don't think I could clearly state that I'd prefer to change to a different option
18:02:05 <dbaron> might want to think some more, though
18:02:06 <fantasai> wrt clarifying the edges, does this work? https://drafts.csswg.org/css-inline-3/#text-edges
18:02:30 <fantasai> dbaron: Yeah, I think "first available font" is what you definitely want in the case where that's the primary font.
18:02:44 <fantasai> dbaron: but in some cases it might be the secondary font, because of the way fallbacks work
18:03:03 <fantasai> dbaron: but in that case, I think we have a broader issue of "first available" vs "primary" across most of CSS...
18:03:10 <fantasai> right?
18:04:03 <fantasai> E.g. if you've got a Japanese page with english, and you use 'font-family: English Font, Japanese Font' this is reasonable -- or if you use 'font-family: Special Emoji Font, Regular Font' -- in these cases the primary font is the second one
18:04:44 <dbaron> yeah, that's a general problem, but even if your first available is your primary, there are some cases where the current spec text probably leads to line spacing/sizing jitter in cases where it's probably not needed or desirable
18:05:51 <dbaron> e.g., an alternative would be to say that the leading goes around only the first available font's metrics when the leading is positive, but goes around the metrics for any glyph when it's negative
18:06:17 <dbaron> (for the case of values other than `leading`)
18:07:10 <dbaron> I think we've discussed things somewhat like that in the past.
18:07:48 <fantasai> for positive leading (for case of values other than `leading`), we're only applying it to the root inline box, not to the glyphs ... or at least that was my intent :)
18:09:38 <fantasai> Yeah
18:09:48 <fantasai> For `line-height: normal` we account for all of the fallback glyphs
18:10:17 <fantasai> But for `line-height: anything else` we ignore fallback glyphs
18:10:35 <dbaron> oh, yeah, the last sentence of the line-height!=normal paragraph revises a bunch of the previous text in a way that I missed
18:11:03 <dbaron> er, next-to-last
18:11:38 <fantasai> I struggled a bit with trying to make this section understandable, so suggestions on how to improve it are welcome...
18:12:01 <fantasai> Maybe more subheadings would help.
19:48:56 <nucliweb> nucliweb has joined #css
20:40:21 <nucliweb> nucliweb has joined #css
21:22:27 <nucliweb> nucliweb has joined #css