W3C home > Mailing lists > Public > www-style@w3.org > February 2017

[css3-mediaqueries] min-width, max-width, & fractional-pixel widths

From: Nick Levinson <nick_levinson@yahoo.com>
Date: Sun, 05 Feb 2017 02:08:13 +0000
Message-ID: <30313174.1561130.1486260459443@mail.yahoo.com>
To: www-style@w3.org
The Firefox browser allowed fractional-pixel widths with many decimal places. They may have fixed that by now, but other browsers could do the same. This creates a problem for writing breakpoints for at-media styles.

Suppose I want this:

@media screen and (max-width:1500px) and (min-width:1200px) {. . . . .}
@media screen and (max-width:1199px) and (min-width:1000px) {. . . . .}

If the user drags the browser window's edge manually so the viewport is 1199.734682 pixels, neither at-media block applies and most users won't know why.

I've seen it advised that one should write the widths with equal values at the edges, like this:

@media screen and (max-width:1500px) and (min-width:1200px) {. . . . .}
@media screen and (max-width:1200px) and (min-width:1000px) {. . . . .}

But then a browser could choose either at-media block or neither, especially, since, logically, this shouldn't be allowed. If it chooses one and not the other, it might do so according to which it encounters first when reading a stylesheet from top down, by preferring a min-width when a max-width is equal, or by preferring a max-width when a min-width is equal, and each browser could proceed differently, causing inconsistent results.

A solution should not break existing websites.

I suggest the following addition to the specification:


meaning not the number stated after the colon but any value over the number, including fractional values.

This would allow this coding:

@media screen and (max-width:1500px) and (min-width-over:1200px) {. . . . .}
@media screen and (max-width:1200px) and (min-width:1000px) {. . . . .}

resulting in unambivalent renderings.

I see no objection to adding max-width-under to the spec, but either one would probably be sufficient.

Received on Monday, 6 February 2017 19:38:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 6 February 2017 19:38:15 UTC