Bug 181327 – <option> element can't increment CSS counters

• Status: NEW
• Component: CSS

[Roman Komarov]

## Steps to reproduce the problem:

Go to https://codepen.io/kizu/pen/PEJgpr

## What is the expected behavior?

The number after “Selected value:” should be equal to the selected option's inline CSS variable.

## What went wrong?

The counters on <option> element don't work

Other major browsers — Firefox & Edge support this behavior. Support for this in Chrome/Safari would mean we could do a lot of interesting stuff with <select>s.

[Roman Komarov]

A note: counters for options at select with `multiple` attribute work in Chrome, but don't work in webkit, so at least is should be possible to get a patch for the multiple selects and/or implement it for common ones?

[Radar WebKit Bug Importer]

<rdar://problem/88669337>

[Ahmad Saleem]

(In reply to Roman Komarov from comment #1)
> A note: counters for options at select with `multiple` attribute work in
> Chrome, but don't work in webkit, so at least is should be possible to get a
> patch for the multiple selects and/or implement it for common ones?

Safari 16.4 is still broken with 'select multiple' as per following test case (got from Chrome bug):

https://bugs.webkit.org/show_bug.cgi?id=181327

but it is fixed in WebKit ToT.

So only broken case is the one mentioned in Comment 0 and it is also in both Chrome Canary 114 and Safari 16.4.

[Ahmad Saleem]

(In reply to Ahmad Saleem from comment #3)
> (In reply to Roman Komarov from comment #1)
> > A note: counters for options at select with `multiple` attribute work in
> > Chrome, but don't work in webkit, so at least is should be possible to get a
> > patch for the multiple selects and/or implement it for common ones?
> 
> Safari 16.4 is still broken with 'select multiple' as per following test
> case (got from Chrome bug):
> 
> https://bugs.webkit.org/show_bug.cgi?id=181327
> 
> but it is fixed in WebKit ToT.
> 
> So only broken case is the one mentioned in Comment 0 and it is also in both
> Chrome Canary 114 and Safari 16.4.

NOTE - I just checked Firefox Nightly 113 and it seems - it now behaves same as Chrome Canary 114 and Safari 16.4 and don't show anything for other value for this test case:

https://codepen.io/kizu/pen/PEJgpr

______

GitHub Issue - https://github.com/w3c/csswg-drafts/issues/4004 (Leaving this behavior as undefined).

____

While 'https://codepen.io/kizu/pen/EowqxX' (on <select>) works now on WebKit ToT (not on STP166 and Safari 16.4).

^ This might have been fixed because of 'https://github.com/WebKit/WebKit/commit/febbe13cd11cd845645ec472954d2048e3289cda'.

_______

Do we need to do anything here because spec suggest that it is undefined and all browsers agree on Comment 0 testcase?

@Aditya & @Ryosuke - appreciate if you can share your input?

[Tim Nguyen (:ntim)]

(In reply to Ahmad Saleem from comment #4)
> (In reply to Ahmad Saleem from comment #3)
> > (In reply to Roman Komarov from comment #1)
> > > A note: counters for options at select with `multiple` attribute work in
> > > Chrome, but don't work in webkit, so at least is should be possible to get a
> > > patch for the multiple selects and/or implement it for common ones?
> > 
> > Safari 16.4 is still broken with 'select multiple' as per following test
> > case (got from Chrome bug):
> > 
> > https://bugs.webkit.org/show_bug.cgi?id=181327
> > 
> > but it is fixed in WebKit ToT.
> > 
> > So only broken case is the one mentioned in Comment 0 and it is also in both
> > Chrome Canary 114 and Safari 16.4.
> 
> NOTE - I just checked Firefox Nightly 113 and it seems - it now behaves same
> as Chrome Canary 114 and Safari 16.4 and don't show anything for other value
> for this test case:
> 
> https://codepen.io/kizu/pen/PEJgpr
> 
> ______
> 
> GitHub Issue - https://github.com/w3c/csswg-drafts/issues/4004 (Leaving this
> behavior as undefined).
> 
> ____
> 
> While 'https://codepen.io/kizu/pen/EowqxX' (on <select>) works now on WebKit
> ToT (not on STP166 and Safari 16.4).
> 
> ^ This might have been fixed because of
> 'https://github.com/WebKit/WebKit/commit/
> febbe13cd11cd845645ec472954d2048e3289cda'.
> 
> _______
> 
> Do we need to do anything here because spec suggest that it is undefined and
> all browsers agree on Comment 0 testcase?
> 
> @Aditya & @Ryosuke - appreciate if you can share your input?

I'm still not seeing interoperable behavior here in either of the testcases. This is caused by option not having any renderers, which also causes a variety of other issues in WebKit. I think we should fix this.

[Anne van Kesteren]

Duplicate of bug 8351?