Page MenuHomePhabricator

ResourceLoader should support using @media in files that media set in the module
Closed, DeclinedPublic

Description

It is very unfriendly to be stuck writing stuff like this:
"foobar/style/mobile.css" => array( 'media' => 'only screen and (max-width: 600px)' ),
"foobar/style/mobile-hidpi.css" => array( 'media' => 'only screen and (max-width: 600px) and (-webkit-min-device-pixel-ratio: 1.3), only screen and (max-width: 600px) and (-o-min-device-pixel-ratio: 2.6/2), only screen and (max-width: 600px) and (min--moz-device-pixel-ratio: 1.3), only screen and (max-width: 600px) and (min-resolution: 1.3dppx), only screen and (max-width: 600px) and (min-resolution: 124.8dpi)' ),

Just so you can add a few hidpi styles.

We should support just having the mobile.css and using @media for just the hidpi stuff inside the css file. Which would combined together as top-level @media entries in the final output.

For that matter since RL is already screwing with things by turning media="" into @media we might as well just expand all nested @media entries into top-level ones.

Nesting queries is valid in css3-mediaqueries but only a few browsers implement that part of the spec correctly. Which the RL pattern messes with.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz46933

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:16 AM
bzimport set Reference to bz46933.
bzimport added a subscriber: Unknown Object (MLST).

If you want to avoid having to create a file to use a different @media, simply don't specify 'media' in the module definition and use them both inside the css file:

  • module

{

styles: [ foo.css ]

}

  • css

@media ... {
}
@media .. {
}

That works fine.

Supporting it inside a module that has 'styles: { "foo.css" => "screen" }' is not possible because:

We doesn't use the media attribute on the <link> or <style> element because we concatenate stylesheets (in load.php requests that are only=styles[1]).

As a result, the @media in your css file is a second level @media. Though we don't strip that out, it would fail in any browser that doesn't support css3-mediaqueries. However, as said, it isn't not-supported so if css3-only is acceptable, you can do so already.

The only way around it is to strip those sections out and wrap the individual subsections outside the user @media, and then modify the rules of the user @media. That'd get quite hacky, but its possible. Is it worth that?

[1] we also concatenate them in <style> for IE, but that's another story which could be avoided if we hack something in js.

(In reply to comment #1)

...

The only way around it is to strip those sections out and wrap the individual
subsections outside the user @media, and then modify the rules of the user
@media. That'd get quite hacky, but its possible. Is it worth that?

...

https://gist.github.com/dantman/5323001.

CSS has well defined and simple rules we can use to pick out the @media entries in the files. And the queries inside @media itself are also defined well enough with similar rules for us to combine rules together.

It's not much more hacky than the @embed, @noflip, flipping, and concatenation we already do.

I'm declining this task for now because I do not believe it is worth the minimal gain in developer usability, compared to the cost in complexity and maintenance.

Whenever possible, I'd like to avoid significant differences between code that is authored and the code used by browsers.

I'd prefer not to emulate support for nested queries but instead require the original stylesheets not to be nested in the first place. Or, if acceptable by your project, use nested queries directly (which ResourceLoader won't break).

This should incur a minimal one-time maintenance cost at implementation time, but I believe that is worth it in this case and allows us to focus those efforts on other parts of the infrastructure instead.