info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intent to implement and ship: forced case-sensitive attribute selector matching
86 views
Skip to first unread message
Boris Zbarsky
Dec 11, 2018, 9:34:14 AM12/11/18
to
Summary: When matching CSS attribute selectors against HTML, some
attribute names lead to case-sensitive value matching, while others use
ASCII-case-insensitive matching. The proposed feature adds an 's' flag
on attribute selectors that forces case-sensitive matching, just like
the existing 'i' flag forces ASCII-case-insensitive matching.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1512386
Standard: https://drafts.csswg.org/selectors-4/#attribute-case
Platform coverage: all
Estimated or target release: Firefox 66.
Preference behind which this will be implemented: None.
Is this feature enabled by default in sandboxed iframes? Yes.
DevTools bug: None needed, as far as I can tell.
Do other browser engines implement this? Not yet. This is a new
addition to the standard.
web-platform-tests: This is tested in the tests in
http://w3c-test.org/css/selectors/attribute-selectors/attribute-case/
Is this feature restricted to secure contexts? No, like other CSS
syntax features.
Spec stability: Not 100% clear, but I expect it's pretty stable; on the
spec level this is a tiny change and there's not much controversy about
which letter to use for the flag, I would think.
Security & Privacy Concerns: None
Web designer / developer use-cases AKA Why a developer would use Feature
X? https://github.com/w3c/csswg-drafts/issues/2101#issue-280846560
describes the main use-case: HTML list styling needs this, because
type="a" and type="A" are different.
Example usage: [foo="bar" s] { color: fuschia }
-Boris
attribute names lead to case-sensitive value matching, while others use
ASCII-case-insensitive matching. The proposed feature adds an 's' flag
on attribute selectors that forces case-sensitive matching, just like
the existing 'i' flag forces ASCII-case-insensitive matching.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1512386
Standard: https://drafts.csswg.org/selectors-4/#attribute-case
Platform coverage: all
Estimated or target release: Firefox 66.
Preference behind which this will be implemented: None.
Is this feature enabled by default in sandboxed iframes? Yes.
DevTools bug: None needed, as far as I can tell.
Do other browser engines implement this? Not yet. This is a new
addition to the standard.
web-platform-tests: This is tested in the tests in
http://w3c-test.org/css/selectors/attribute-selectors/attribute-case/
Is this feature restricted to secure contexts? No, like other CSS
syntax features.
Spec stability: Not 100% clear, but I expect it's pretty stable; on the
spec level this is a tiny change and there's not much controversy about
which letter to use for the flag, I would think.
Security & Privacy Concerns: None
Web designer / developer use-cases AKA Why a developer would use Feature
X? https://github.com/w3c/csswg-drafts/issues/2101#issue-280846560
describes the main use-case: HTML list styling needs this, because
type="a" and type="A" are different.
Example usage: [foo="bar" s] { color: fuschia }
-Boris
fantasai
Jan 14, 2019, 9:21:13 PM1/14/19
to
On 12/11/18 6:34 AM, Boris Zbarsky wrote:
>
> Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny
change and there's not much controversy about which letter to use for the flag, I would think.
As the editor of the spec, I second this assessment. There are parts
>
> Spec stability: Not 100% clear, but I expect it's pretty stable; on the spec level this is a tiny
change and there's not much controversy about which letter to use for the flag, I would think.
of Selectors 4 that are a little shaky, but this is so closely analogous
to an existing feature that it doesn't seem like one of them.
~fantasai
0 new messages