The idea of MMQs came about when attempting to consolidate the various methods for producing responsive images:
<picture>. A goal is to have 1-1 correspondence so that it easy to convert a query between any of these formats.
Since MMQs tend to be very short, they may be particulary helpful as folder names, within a filename, or as a snippet.
1x,2x+480w reads as "1 pixel ratio density or 2 pixel ratio density and 480px width"
1x,2x+480w expands to the equivalent media queries:
(max-device-pixel-ratio: 1), (max-width: 480px) and (max-device-pixel-ratio: 2)
As part of a filename we could specify it like:
myImage@1x,2x+480w.jpg, where the
@ and file extension period act as delimiters.
srcset candidates would be straightforward:
myImage@1x,2x+480w.jpg 1x, myImage@1x,2x+480w.jpg 2x 480w
MMQs use the
srcset descriptor features:
h, which correspond to the
max-height media query features.
MMQs further defines descriptor features:
mh, which correspond to the
min-height media query features.
, (comma) to seperate individuals queries and
+ (plus sign) to combine expressions.
The 0.1.0 branch of the background-imager tool currently uses MMQs to produce responsive images with cross-broswer
@media rules. Implementation of
image-set should be straightforward. The next logical step would be to produce a related tool to generate
<img srcset> and
Why did you a plus sign?
An older version used the ^ (caret), unfortunately this character, like spaces, are escaped in URLs, so your filenames will appear ugly. Plus signs still remind people of "and" and are also what HTML forms use in place of spaces, which gives it some similarity to the
<img srcset> candidate string.
Those filenames look ugly! I know they're not pretty but when you produce hundreds of images for flat file HTML you live with the ugliness in exchange for hours of saved time. Automation is king.
We still can't use
em to specify queries.
I know, but I'm going to roll with Hixie on this one