- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 16 Oct 2025 15:26:56 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-forms-1] UA styles for base appearance listbox select elements`.
<details><summary>The full IRC log of that discussion</summary>
<masonf> jarhar: last time we talked about the block size with the calc expression, approx to set height to number of elements in size attr<br>
<masonf> ...Tim left feedback that listbox should grow to fit if no size attr<br>
<masonf> ...we could do that with size attr selector on the block-size property. Thoughts?<br>
<emilio> q+<br>
<masonf> astearns: what we did last time, if there's a size attr. What about if no size?<br>
<masonf> jarhar: grow to fit all contents<br>
<astearns> ack emilio<br>
<masonf> emilio: feels weird that select multiple with appearance base and single option, height is height of option. If size=1 then grow to 24px.<br>
<masonf> ...should we add a min-height: 24px?<br>
<masonf> ...I'm with Tim, let's avoid magic<br>
<masonf> ...someone will have an option with height>line-height, things get cropped.<br>
<masonf> ...if author is responsible for that rule, ok. If UA rule, it's worse.<br>
<masonf> ...too magic for my taste, but maybe ok.<br>
<masonf> annevk: we could also not honor size attr.<br>
<masonf> emilio: that's what Tim wants<br>
<masonf> fantasai: he's arguing only when it's there, no default<br>
<masonf> emilio: prefer not to honor it<br>
<masonf> fantasai: we're struggling to define it, so why leave it to authors. Let's do it right.<br>
<masonf> ...create UA magic if that's the right thing.<br>
<masonf> ...author can't do that, would need JS<br>
<masonf> emilio: point of appearance:base is to have as little magic as possible.<br>
<masonf> fantasai: true. But it can be overridable. Goal is stylable form control. If sizing behavior you want needs magic, but easy to override, fine.<br>
<masonf> ...we should figure out a reasonable way to get the right sizing behavior, but make it easy to override.<br>
<masonf> emilio: but height doesn't seem right. Tons of edge cases. Is this more similar to line-clamp?<br>
<masonf> ...can we line clamp without ellipsis? It's like that without the ellipsis.<br>
<masonf> fantasai: that's max-lines property<br>
<masonf> emilio: that digs into nested blocks {missed}<br>
<masonf> zcorpan: good enough to use max-height?<br>
<masonf> ...still concerned about select multiple without size and many options. For sites that get appearance:base from a stylesheet they don't control.<br>
<masonf> fantasai: if they get appearance:base without expecting it, they're already in trouble.<br>
<masonf> ...not concerned about not having a default size. But don't want to ignore the size attribute completely, because it's tricky.<br>
<masonf> ...how does it work today?<br>
<masonf> jarhar: in Chrome, iterate through every option in listbox. Figure out which is the tallest, multiply by size attr, that's the overall size.<br>
<masonf> ...won't work for base appearance. Funny things like circular layout, etc.<br>
<masonf> emilio: size works fine today, but limited today. Options are just text.<br>
<zcorpan> https://html.spec.whatwg.org/#the-select-element-2:~:text=box%2E-,When,size%2E<br>
<masonf> ...as soon as you have non-uniform options, things break. Multiple lines of text, e.g. 1lh stops working<br>
<masonf> fantasai: when you have size=4, not getting exactly 4 because non-uniform, seems fine. If you have uniform items, it should roughly work.<br>
<masonf> ...author not getting exactly 4, unless it's uniform, that seems fine.<br>
<masonf> emilio: current proposal doesn't achieve that. Simple listbox with small subtitle underneath, all uniform. Or with padding. All of those break.<br>
<masonf> ...lh-based size attr isn't great.<br>
<masonf> ...we may as well multiply by 24px fixed.<br>
<masonf> ...for anything complicated, equally broken.<br>
<masonf> ...options are blocks, right? If we force options to be block formatting contexts, which seems ok, then max-lines does the trick, doesn't it?<br>
<masonf> ...nested block is aligned<br>
<masonf> ...for uniform options, that works. If you have a top option that's taller, it'll be weird when you scroll, but maybe ok.<br>
<fantasai> "Only lines boxes in the same Block Formatting Context are counted: the contents of descendants that establish independent formatting contexts are skipped over while counting line boxes."<br>
<masonf> fantasai: right now, spec'd - independent formatting contexts are skipped. If we instead count as a single line, that would work.<br>
<masonf> emilio: that existing thing seems really bad anyway<br>
<masonf> fantasai: maybe not web compat, but if we could make them count as a line, that would work here, but generally more useful.<br>
<masonf> s/but generally/but also generally<br>
<masonf> emilio: nice to see how size attr maps to max-lines<br>
<masonf> astearns: this seemed like a small issue, but maybe it wasn't so small. Take back to the issue, to discuss max-lines?<br>
<masonf> jarhar: I just searched CSS max-lines, and I don't think I found it. Can someone point me to that?<br>
<masonf> fantasai: overflow-4<br>
<masonf> emilio: supposed to be line-clamp would be max-lines something something ellipsis<br>
<masonf> ?!<br>
<masonf> ...it does the thing we want here - clamping the block. But we need to change how it skips nested ifc's<br>
<masonf> astearns: separate issue for definition of max-lines?<br>
<masonf> fantasai: I can open one<br>
<masonf> astearns: see if the definition does what we want here, and fix it if not, and then bring it back here?<br>
<masonf> ...but back to Simon's concern about multi-select with no size attr<br>
<masonf> ...anything for base appearance that can set a max-height? Or should we?<br>
<masonf> jarhar: Tim was arguing to fit contents. I don't have a strong opinion. Following the existing thing seemed to make sense. Also did infinitely tall all the time.<br>
<masonf> jarhar: current behavior is a hard-coded size=4<br>
<masonf> zcorpan: if select multiple isn't well used, then maybe ok<br>
<fantasai> https://github.com/w3c/csswg-drafts/issues/12962<br>
<masonf> zcorpan: if better default, could live with it<br>
<emilio> test-case: data:text/html,<div style="display: -webkit-box; -webkit-box-orient: vertical; overflow: hidden; -webkit-line-clamp: 4"><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div<br>
<emilio> style="overflow: hidden">One</div><div style="overflow: hidden">One</div><div style="overflow: hidden">One</div></div><br>
<masonf> zcorpan: they'd also have to use appearance:base, which will happen more over time<br>
<emilio> It does indeed not clamp :')<br>
<masonf> zcorpan: maybe rarely used enough that it's ok to change behavior<br>
<masonf> emilio: ignore thing matches webkit-line-clamp, which is sad. Makes it harder.<br>
<masonf> fantasai: compat issue then.<br>
<masonf> ...we can evaluate how much compat impact. We can also check if there's a syntactic switch where line-clamp ignores, but max-lines doesn't.<br>
<masonf> emilio: needs some design if there's a compat issue. Check with Andreu and Florian.<br>
<fantasai> s/check if there's/consider adding/<br>
<masonf> astearns: so do some investigation and come back here?<br>
<masonf> jarhar: works fo rme<br>
<masonf> s/fo rme/for me<br>
<masonf> fantasai: if we don't find immediate compat answers, we might need help with use counter<br>
<masonf> emilio: use counter doesn't seem trivial here. Can use count whether clamping changes, but not whether it's better or worse.<br>
<masonf> ...easy to put behind a flag and experiment<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12510#issuecomment-3411452944 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 16 October 2025 15:26:57 UTC