Implement the <general-enclosed> syntax for media conditions.

NEW
Unassigned

Status

()

P3
normal
9 months ago
9 months ago

People

(Reporter: emilio, Unassigned)

Tracking

({dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 months ago
See bug 1422225. All our current parsing tests rely on _not_ doing this, and I don't think I know a way to rewrite those in any meaningful way.
(Reporter)

Updated

9 months ago
Summary: Implement the <general-enclosed> syntax for media feature ranges → Implement the <general-enclosed> syntax for media conditions.
(Reporter)

Updated

9 months ago
No longer blocks: 1422225
Depends on: 1422225

Comment 1

9 months ago
This is a change, but it is a feature, not a bug.

Just like the fact that discarding the entire selector when it contains an unknown part, instead of discarding to the next comma is considered a mistake (see https://wiki.csswg.org/ideas/mistakes), dropping the entire media query because of an unknown part if that part would not affect the end result is a problem too, and gets in the way of adoption by authors of newer media features.

This is becoming particularly problematic with mediaqueries level 4 (and later), because of the change in focus. With CSS2 and Mediaqueries 3, the focus was on media types, width and height queries, and not much else. As we deemphasize media types in favor of media features, more complex boolean expressions will be on the rise, and blowing up the whole media query for unknown terms will be bad.

Example:
@media (update: slow) or (hover: none) {...}

If 'hover' does match 'none', but the browser doesn't know about 'update', the media query should match.

So, with regards to existing tests, the fact that we can no longer distinguish unknown features from known-but-not-matching features is fine. They do not need to be distinguished in normal usage.

You may still want to distinguish for instance, to emit warnings in the dev tools / console, but you can use any internal mechanism for that.
(Reporter)

Comment 2

9 months ago
(In reply to Florian Rivoal from comment #1)
> This is a change, but it is a feature, not a bug.

To be clear, I agree! I just think it requires a lot more work that doesn't need to go in bug 1422225, because I want that landed sooner rather than later, given it's most of the feature.

In particular, I need to audit all those tests, ensure other vendors are fine with removing the parsing tests, etc. Your help with all that work would be really appreciated, btw :)
Priority: -- → P3
(Reporter)

Updated

9 months ago
Depends on: 1469957
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.