Pixel defense word media queries

    I will show you if the rabbit hole is deep.While reading publications about web page layout, you have repeatedly come across a recommendation not to use pixels in media queries. For example, here is a quote from a very recent article on Habré:

    Instead of using fixed sizes, it is better to use relative units to determine breakpoints. The topic of using relative sizes in layout has already been repeatedly revealed on the hub. Here is a partial list of articles: here , here , here . I’ll give you only the most important argument - this will allow browsers to change the design depending on the level of the established zoom size by the user, as a result of which the user will see a more pleasant, more accessible site for viewing.

    What if I tell you that using pixels in media queries not only does no harm to the layout, but also has advantages over using ems?



    The term “breakpoint” is used in the article. To programmers, he cuts the ear, because in the programming world it means something completely different. I assure you that in the English-speaking world of front-end development, this is an established and unambiguous term. It means the width of the browser window, beyond which the page layout changes. I did not distort it into Russian, as did the term “media query”.

     

    Pixel-mediated media queries do not interfere with zoom


    Let's start with the “most important argument” against pixels: supposedly, when a page is enlarged in an old browser, the pixel values ​​of media queries do not work. This is simply a lie. Pixel media queries work fine with zoom in all any popular browsers. Even in Internet Explorer 8!

    Yes, IE 8 does not support media queries. But if you use the remarkable polyphill Respond.js in your project , then IE 8 will display it with full support for media queries. And you know what? They work correctly with zoom even in it. Turn the mouse wheel while holding Ctrl - the page layout is rebuilt. For example, on a site whose zoom animation in IE is shown on the right, I used media queries of the following form:

    @media (min-width: 401px) {
      #header-first {
        float: left;
        width: 47.82609%;
        margin-right: 4.34783%; }}
    

    Older IE at hand was not, but it does not matter - the share of IE7 is in Russia only 0.7%, IE6 - 0.1%, and that for the most part, at the expense of state institutions.

    So, the problem, called as the main reason for rejecting pixels in media queries, simply does not exist. Apparently, this is just a legend that is blindly passed on by word of mouth, regularly gets into publications of influential publications and blogs of the front-line gurus, and no one bothers to just take and check if this is so.

    UPD 2013-10-31 : I found that Safari media queries will not work with zoom. But they do not work no matter what unit of measure they use. Krylcwhelped confirm that this is true for Safari 7. In addition, according to its data, media queries do not work when zooming in Yandex.Browser for MacOS (current version 1.7.1364.22074 (0b6c012)), but they work if you refresh the page after zooming .

    I tried Yandex.Browser under Windows (current version is 13.10.1500.8765 (e504cce)). There it is the other way around: pixel-based media queries zoom correctly, but relative ones don't! You zoom the page, media query works correctly. Let's say this happens at step 175% → 200%. Then you zoom in the opposite direction, and the media query at the 200% → 175% step does not work, but it works at the 100% → 90% step. And if you zoom back and forth, the gap with each cycle increases!

    For those who want to try it, they riveted a test themselves: pixels , em's.
     

    Changing the base font size causes all breakpions to “move out” if set in ems


    Imagine this situation. The chief or client calls you and says: “Why is the font so small on our site? My wife can’t read anything, make it bigger. ” It is useless to argue. You sadly inhale, take a guilty look at the door of the design department, open the CSS code and increase the base font size from 13px to 16px (yes, the base font size is still set in pixels, anyway).

    What happens with this? All breakpoints specified in ems are shifted. Now on tablets the site is displayed in one column: the way it used to look only on the phone. It looks something like this(make the window width less than 900px and be horrified). Are you glad about this? I’m ready to argue that if you find yourself in such a situation, you will swear in an undertone in a hurry to rewrite all media queries ... or in full voice if the project does not use a preprocessor.

    Yes, I’m aware of the Content First ideology , according to which breakpoints should shift, subject to a content scale that is comfortable for consumption. This allows you to get away from the need to take into account in the CSS code a durillion of different-sized devices with a browser. Instead, you set breakpoints in units relative to the font size and force the site to rebuild when the content gets too crowded or too spacious.

    But do not lie to yourself. Carrying out any commercial project, you want(or your client wants) a strictly defined layout on the most popular devices. For example, so that the thumbnails that appear on a mobile phone in one column on the iPad in portrait mode turn into a grid with three columns. You do not want this to break when you change the font size. If your designer has decided that there should be a sidebar on the iPad in landscape mode, then it should be there no matter what font size is used on the site. If the font for a narrow sidebar is too large, then you would rather reduce the font than get rid of the sidebar.

    Yes, for content-oriented sites, the width of the column of text should not go beyond comfortable limits. But, firstly, this width has a fairly wide range. I know the recommendation of 45-75 characters, that is, the width of the column can be painlessly changed by up to 66 percentage points. Secondly, why is such a width considered the standard? Open any glossy magazine, there are quite often columns of text 15 characters wide that come across and it doesn’t occur to anyone that this is bad. For example, it’s very convenient for me to roll up a magazine when I try to read it in a jam-packed metro car. And on Habré, the width of the column of text is from 75 to about 115 characters, and the vast majority of Habr’s visitors see the text is exactly 115 characters wide.

    By the way, have you noticed a substitution of concepts here? Optimum text width can also be made using pixel-based media queries.

    And finally, how often do you have to change the size of all fonts on an already completed project, and without re-arranging everything else? And if you have all the fonts in em'ah, and the client demanded to increase the font only the main text? Sorry, the last question does not apply to the topic of the article.

     

    Adjacent media queries defined in ems are overlapped


    I call a pair of media queries “adjacent” when the maximum width of one matches the minimum width of the other. Let me give you an example taken from the ceiling:

    .container {
      color: black;
      background-color: white; }}
    @media (max-width: 40em) {
      .container { color: red; }}
    @media (min-width: 40em) {
      .container { background-color: red; }}
    

    Guess what a visitor will see who is “lucky” to open this site in a browser exactly 40em wide?

    The overlap is only one pixel, but it is. If a visitor to a site suddenly has such a screen width, then the layout of the page and the design may be distorted, even to the point of complete unreadability.

    When using pixels, the problem is solved in an elementary and completely reliable way:

    @media (max-width: 600px) { /* ... */ }
    @media (min-width: 601px) { /* ... */ }
    

    When I blindly submitting to the majority, I wrote to media queries on em'ah and found overlap, I poprobvat solve the problem in a similar way: (min-width: 20,1em). The overlap was replaced by a gap: at a certain window width neither one nor the other media query is applied. I tried 20.01, then 20.001 ... Using the artillery fork, I managed to find the desired value of the remainder after the decimal point.

    I quickly realized that once picking up this balance is not enough. For each basic font size, the remainder will be different, otherwise there will necessarily be either a gap or an overlap. But I was not taken aback, because I am fluent in SASS and can write mixin, picking up the correct remainder for any value in ems. We take some em's at the input, multiply by the base font size, add one, divide by the base font size - and voila, we get a safe value at the output.

    You should have a vague feeling at this place that this path is somehow ... wrong. At least I have it. I tried to look at the situation from the side and asked the question: what am I actually doing?

    And this brings us to the following argument:

     

    Em's in media queries are an intermediary between two pixel values: the base font size and the width of the browser window


    As mentioned above, the base font size is always specified in pixels. Otherwise, the browser simply does not know what font size is considered equal to one em. If the base font size is not specified, any normal browser will take it for 16 pixels. If it is specified in em'ah, then the browser will multiply it by the same 16 pixels. The same applies to other relative units: 1 pt is taken 4/3 px, and the number of pixels in a centimeter is written in the OS.

    Min-width and max-width in media queries are mapped to the width of the window, which in any browser is given by an integer number of virtual pixels. For example, for the fourth iPhone inclusive, it is 320 × 480, and for iPhone 5 - 320x568.

    By setting media queries in ems, you first make the conversion from pixels to em in your mind, and then from em back to pixels in order to understand what width of the screen you actually get into this breakpoint.

    There’s no need to torture yourself like that. Just use pixels.

     

    Using pixel-based media queries does not mean abandoning the “content first” approach


    The fact that you use pixels in media queries does not deprive you of the ability to come from content when designing media queries.

    There are a lot of articles on how to correctly do media queries on the Internet, and this topic is beyond the scope of this article. Therefore, I will limit myself to a few recommendations that I will try to reinforce the thesis in the subtitle.

    At this point, the objective part of the article ends and a modest personal opinion begins, not implying that other ways are wrong.

    Firstly, do not use a separate CSS file for each screen width (IE support can be provided with polyfill). Structure the code according to the modules used on the site pages and arrange media queries individually for each module. This will facilitate control over each module and simplify code support.

    Secondly, when designing responsive layout, build on content. The method is very simple (and not invented by me). First, make up the module, focusing on the minimum screen width. Of course, the module should be "rubber". Then stretch the browser window until the module looks lousy. At this point, set a breakpoint and flip it to that width. Repeat until you hit the max-width of your site.

    By the way, do not limit the maximum width of the site to a narrow column of 980 pixels. If you have a large monitor, see how luxurious a site can look at a width of 1920 pixels. If you have a smaller monitor, then for God's sake, scrape five thousand rubles and buy yourself a big one. This is your professional tool!

    Third, use a preprocessor. Implementing a preprocessor in a project is not easy, especially for a beginner, but it will save you a tremendous amount of fuss.

    Any preprocessor will do, but I highly recommend Sass . Not because the Sass language itself is any better - they are all more or less equal in capabilities, but because it has a whole ecosystem of libraries. Libraries, commonly called “ Compass extensions, ” are very rich in functionality and interact effectively with each other.

    Fourth, in order not to be buried under a bunch of diverse media queries ...

     

    Slice the screen size scale into slices


    In order to facilitate the task of working with media queries, I built the Breakpoint Slicer extension (which, in turn, uses Breakpoint - a very powerful and universal extension for working with media queries).

    The idea of ​​Breakpoint Slicer is very simple. You set breakpoints at small intervals, for example: 400px, 600px, 800px, 1050px. The module numbers these spaces in order:

    1. 0-400
    2. 401-600
    3. 601-800
    4. 801-1050
    5. 1051 — ∞

    And then in the Sass code, you simply say from what interval you need to put the media query:

    • at(2) - equivalent (min-width: 401px) and (max-width: 600px)
    • from(2) - equivalent (min-width: 401px)
    • to(2) - equivalent (max-width: 600px)
    • between(2, 4) - equivalent (min-width: 401px) and (max-width: 1050px)

    This allows you to quickly and efficiently distribute the styles of the modules by ranges. The use of a large number of gaps allows you to cover all classes of devices, while not going into excessive specificity.

    If you have a question about using Breakpoint Slicer, do not hesitate to ask it in the bugtracker (if you know English, it is better in English).

    Also popular now: