## 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.
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?
<rdar://problem/88669337>
(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.
(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?
(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.
Duplicate of bug 8351?