- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jun 2019 02:21:46 +0000
- To: public-css-archive@w3.org
> I think a strict reading of the spec says no - since `<select>` is replaced, [...] It's wrong to say that `<select>` is a [replaced element](https://www.w3.org/TR/html5/rendering.html#replaced-elements), because it's not, it's a [widget](https://www.w3.org/TR/html5/rendering.html#widgets). I would assume that `<option>/<optgroup>` are neither replaced elements, nor widgets, since they are not listed in those sections. > ... its children don't generate CSS boxes I tend to disagree with that. We certainly create boxes for `<option>/<optgroup>` internally in Gecko, albeit with severely restricted styling, and only for its text children etc. (Those limitations are completely artificial, btw. We could support pretty much all of CSS, and arbitrary child content, if the specs allowed it (in fact we did, but then we had to dumb it down to be compatible with other UAs/specs).) > and on _displayed_ `option` elements, but not on `display:none` `option`s. All UAs suppress incrementing counters on all `display: none` elements. I don't see why `<option>/<optgroup>` should be special in this respect. > That's terrible, this is terrible, the web is bad and a mistake. The web is terrible because the CSSWG put that in the spec :-p. Seriously though, it's 2019 and I still can't do this: ```html <select> <option><img src="Pineapple.png">Pineapple <option><img src="Apple.png">Apple <option><img src="Lemon.png">Lemon </select> ``` Sigh. Now _that_ is truly terrible, because web authors routinely has to work around that in all sorts of terrible ways. It makes me sad because it would be so trivial to support if the specs just allowed it... -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4004#issuecomment-504264169 using your GitHub account
Received on Friday, 21 June 2019 02:21:48 UTC