1. 26

  2. 18


    I don’t know, I feel like it’s not my fault that the iPhone came along and rendered pages unreadable. Why is it not just a button in Safari – like reader mode, but honestly better – that toggles that meta tag on and off? Instead it’s up to literally every web page that existed and worked for fifteen years before the iPhone to add Apple’s special meta tag…

    1. 10

      Nor is it your readers’ fault. The buck could have stopped with browsers, and I think it probably should have, but it didn’t. Why pass the buck to users?

      I think it’d be useful in this conversation to remember what the web looked like in a 320px-wide desktop browser in 2007. If I recall, every site had a sidebar or two, and Apple used the multi-column New York Times as an example case. Responsive layout was harder then, unless you had a one-column page, and lots of sites had a desktop site and a mobile site rather than one responsive site. Desktop sites were often designed toward an exact width for display and just centered that block in the browser window. I think a very slim desktop browser would have had a hard time making then-current pages look decent. You’d just have to scroll sideways. And if that’s true, mobile Safari would have the same problem if they hadn’t given it a desktop-size viewport by default, and asked pages to identify when they are meant for mobile devices. I don’t know if this was a great long term solution because now more traffic is mobile than desktop, but it did make the existing desktop web nice to use on a phone 13 years ago.

      1. 3

        Yes! This infuriates me. We’ve cut down on so much crufty boilerplate in HTML5, why do we have to write this annoying piece of boilerplate on every web page? Every browser that needs this meta tag to be readable should assume it is the default, that should be part of the HTML spec.

        This tag is a waste of precious characters, and in all seriousness a waste of energy / resources that we cannot afford in the climate crisis. How much energy would be saved if every web page deleted that tag tomorrow? I bet a non-trivial amount.

        1. 6

          It’d be great if browsers made that tag unnecessary. But until then, there’s a worse energy cost of loading pages that lack the tag on phones, seeing that the text is too small to read, and then loading those entire pages again on another device with empty caches. Especially in this era of page bloat, I think it’s responsible to put effort into making the page body usable on any requesting device.

          1. 3

            You’re absolutely correct, I’m not saying that web devs should avoid this tag today. What I’m saying is that this tag should be made unnecessary ASAP, the browser makers should assume it is the default rather than requiring every web page to include it.

          2. 5

            This tag is a waste of precious characters, and in all seriousness a waste of energy / resources that we cannot afford in the climate crisis.

            I do not see how this follows at all from the OP’s suggestion.

            1. 1

              Yeah I don’t think 16 bytes or so is going to be a significant problem with web usage versus something like, oh I dunno, all the shitty javascript adding 16k bytes or sometimes upwards of a megabyte in data to be transferred.

              Premature optimization starts here, apparently folks.

        2. 8

          Amen. This one line will make most “old” websites “mobile-friendly”.

          I know it’s fucked up that it has to be included.

          But this is the world we live in, and this is kind of how the Web evolves.

          Stupid shit gets introduced, and then everyone has to include it in their page.

          The bare minimum which you have to have on a page to make it work? There’s no term for that yet, but I’m looking for it.

          1. 8

            Boilerplate is the term. It matches exactly.

            1. 2


          2. 5

            what does it actually do, though?

            1. 2

              It tells devices to layout the page at “100% zoom”. Which you would think would be the default thing, but back when the iPhone was brand new and 320 pixels wide (480 if you held it sideways), and responsive design wasn’t even an idea yet, laying out pages to fit in the actual device width would have made pretty much everything on the web look like total trash. So Apple decided to render pages onto a 980-pixel-wide canvas (the size of a fullscreen window on a modest PC monitor, minus scrollbar) and give the user a “zoomed out” view of that canvas. They would have to zoom in to be able to read or interact with much of anything, and scroll around a lot while zoomed in, but at least the page would look approximately right.

              And once Apple did it, that became the default behavior for every mobile browser henceforth.

              And then Apple came out with the iPhone 4, which was 480x960, but still told the world that it was 320x480, and would render a CSS size of “10px” as 20 real pixels, in order to make everything nice and consistent with the older models. Again, world+dog followed suit, and pixel scaling was born, so today, if you’re well off you probably have something like a 1440x2560 phone, but it’s 360x640 “CSS pixels” with a scaling factor of 4, so that pages that request a “14px” font get 2.7mm-high letters (which are readable) and not 0.7mm-high letters (which aren’t).

              So, it’s still normal for a phone to be 300-500 “CSS pixels” wide, and mobile browsers still lay pages out at 2-3 times that wide and then zoom out to provide an overview — unless they see that meta tag. The meta tag says “actually, my layout won’t break at narrow widths, it’s designed for it. Go ahead and let the page width be the same as the actual device width (still in fake pixels, but not artificially expanded), so that users can see it at 100% zoom from the get-go.

            2. 3

              This post inspired me to go rip out a bunch of unnecessary pieces of my personal website infrastructure. Now I am marginally less locked into Jekyll and Liquid!

              1. 2

                The other day I was debugging an issue where I did include the meta tag, but I still had weird zooming issues; when an input field would get focused, Safari would zoom towards it, even though it already was in full view.

                Long story short, Brutal CSS should be the meta tag, and input { font-size: max(1em, 16px); }

                (I checked with the inspector afterwards. Without that rule, my input had font size 15.852px, and Safari auto-zooms if it’s less than 16px)

                1. 1

                  I tried adding the viewport to my personal site and it made the mobile experience worse. It seems I’d accidentally made a (reasonably) mobile friendly design in the first place.

                  1. 1

                    Hah, I felt the same. Specifically, images are not scaled (I link them from Flickr). That said, the change was one line in a template and a regeneration of all pages, so it was not very painful.