Open
Bug 1469173
Opened 6 years ago
Updated 2 years ago
Implement the <general-enclosed> syntax for media conditions.
Categories
(Core :: CSS Parsing and Computation, enhancement, P3)
Core
CSS Parsing and Computation
Tracking
()
NEW
People
(Reporter: emilio, Unassigned)
References
()
Details
(Keywords: dev-doc-needed)
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•6 years ago
|
Summary: Implement the <general-enclosed> syntax for media feature ranges → Implement the <general-enclosed> syntax for media conditions.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years 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•6 years 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 :)
Updated•6 years ago
|
Priority: -- → P3
Updated•6 years ago
|
Keywords: dev-doc-needed
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•