1. 33
  1. 14

    You can balance your additions by dropping the explicit html, head, and body tags. They’re not required, even for spec-valid HTML, as the parser adds the elements automatically.

    1. 4

      From what I found it is best not to omit charset declaration. Additionally we could get rid of few quotes. Then it could look like this (this validates with W3C validator):

      <!DOCTYPE html>
      <meta name=viewport content="width=device-width,initial-scale=1">
      <meta charset=utf-8>
      <style type=text/css>body { max-width: 800px; margin: auto; }</style>
      <title>Mark's Internet Presence</title>
      <h1>Mark's Internet Presence</h1>
      At Mark's Internet Presence, we leverage HTML5 technologies to...
      Next paragraph.

      title could be the first element after DOCTYPE, but for me it looks good just before h1 element.

      There could be <html lang=en> (without closing tag) added at front.

      I like it! For some time I plan to do a rehash of my website and was thinking about writing html directly as it does not need any processing. I was also toying with use of a very simple SSG. It generates fully static pages, but with a bit more pleasant CSS (although certainly longer).

      In a way writing fully static page directly reminds me of printing. Just as an old book or newspaper issue will look the same as it was when it was printed. Every article can have it’s own character and that is nice.

      1. 3

        title could be the first element after DOCTYPE, but for me it looks good just before h1 element.

        You always want to put the title after the charset declaration, or else you won’t be able to use special characters in your title ;)

        1. 2

          That is false. Once the charset is sniffed from the document itself, the entire page up to that point is re-parsed with the new charset.

          1. 7

            As a nitpick, the browser only has to reparse if it finds the charset early in the document, specifically:

            The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.

            Seems to occasionally come up in the wild, with people on StackOverflow confused about why their charset declaration isn’t working, who turned out to have had >1024 bytes of stuff before it (e.g. a big HTML comment at the top).

      2. 2

        Wow, apparently that’s been valid for a long time, but this is the first I’m hearing of it. Intriguing. Looks like the only case the explicit tags are really required is if you want certain elements (like a script) to be the first tag in the body, while they’d be put as the last tag in the head if you leave it implicit. But for everything else it’s unambiguous.

        1. 6

          It has been valid since before “valid HTML” was a thing — SGML allowed you (as a schema author) to specify arbitrary tags as optional so long as they could be inferred unambiguously.

          Some day we will catch up to the markup technology of the 1980s.

      3. 5

        I mostly agree that plain HTML is a great way to go, and letting the browser display semantic markup however it likes (ideally well, and according to user preferences) is right.

        But setting max-width to 800px? That jumps out as a very bad idea.

        1. 11

          It’s pretty subjective, but I just picked it as a number that’s roughly in the range of what most text-oriented sites seem to use. Medium uses 700px, for example. My linked blog above uses a slightly wider 900px. BBC News uses a bit narrower 600px (not counting the right sidebar).

          1. 9

            I like limiting it to 52em^H 40 em. That way the printed page looks exactly like the web page. See for example: https://www.btbytes.com/notebooks/nim.html

            1. 9

              The BBC News article body width has had a surprising amount of thought and effort put in. The intention is to strike a balance between readability (~80 characters max per line) and aesthetics (too much whitespace on either side can look strange).

              The choice of 645px has worked well for the last several years but is too narrow on high resolution displays. We’re going to be rebuilding the article pages later this year and I hope we will take the approach of using rems instead of pixels, as mentioned by @btbytes.

              1. 3

                I think it’s better to specify a max-width in ems, because that naturally accommodates people with vision issues who’ve increased their font size to cope (and some older people apparently make fairly drastic font enlargements). How many ems it should be, I don’t know. I’m currently using 45 ems and the result seems okay, but I picked it more or less out of the air.

                1. 1

                  Hmm, that’s a good point. I didn’t realize it’s common for people set font size explicitly. (I know browsers support user-specified CSS, but thought of it as basically a “strictly for programmers” feature.) I personally like larger font size than most pages have by default, but I use the zoom function for that instead of specifying fonts in user-CSS, which is also what the elderly people i know do. From some testing, specifying max-width in ems or pixels behaves the same w.r.t. zoom. But there’s no real reason not to use ems afaict, so I might switch to that if there’s an advantage.

                  1. 1

                    This is interesting. I just did a test in (desktop) Firefox and Chrome, and they behave differently. In Firefox as I have it set (which is to not zoom images, just text), zooming does not change a max-width set in px, so the text on your page doesn’t get wider. In Chrome, zooming does apparently increase the max-width even when it’s set in px, so the text on your page gets wider, eventually going up to a full screen width. Given the difference in behavior it seems worthwhile to set the size in em.

                    1. 1

                      Odd. I was also basing my comment on testing desktop Firefox and Chrome (on OSX), which with the default settings for me both do zoom width on my blog post, and with seemingly identical behavior whether you specify px or em. I wonder if it’s your don’t-zoom-images setting for Firefox that turns off resizing of all pixel-specified areas' sizes, not just images per se? I don’t see an option for that in the prefs; is it one of the ones behind about:config?

              2. 5

                I’ve been persuaded that some max-width is a good idea. Some number of people do browse with their browsers in full-screen mode on wide (or absurdly wide) screens, and if you don’t limit your site’s width you get really long lines of text that are hard to read. It annoys me to have huge amounts of empty space that could be filled with something useful, but so it goes.

                (I prefer to center the text in an over-wide screen rather than leave it at the left side, but that’s a taste issue. I think it looks better in the full-screen browser scenario, and it puts the text hopefully straight in front of the person, if they’ve centered themselves in front of their screen.)

                1. 2

                  I like the long lines of text. I would ask site makers to please please find a way to let me have the long lines when I want them. If motherfuckingwebsite can manage to make it work then so can you.

                  1. 4

                    in typography a traditional line length is 2-3 alphabets long, aka like 60-70 characters. This usually falls much below 700px, so already web designers are more generous than say, magazine layout designers or newspapers - but having a line length that’s too long results in reader fatigue from too much left-right motion and not enough vertical.

                    The effect of the fatigue is something testable and measurable - so no doubt news websites from profit from people clicking multiple stories will try not to strain the viewers eyes after reading their first article.

              3. 4

                Here’s how I’d do it:

                doctype, charset, viewport meta, title, style, content!

                No need to specify default types on things like style tags, or include things like head or body if you’re not changing anything about their default display :D

                <!DOCTYPE html>
                <meta charset=utf-8>
                <meta name=viewport content="width=device-width, initial-scale=1">
                <title>HTML5 Template</title>
                  body { 
                    margin: 0 auto;
                    max-width: 800px;
                <h1>Website Headline!</h1>
                <p>Site content can go here…</p>
                1. 4

                  When building F5Bot over the last couple days, I waffled on which framework to use. In the end, I decided to go with nothing but my own css, and I’m pretty happy with the choice. It actually felt really liberating, and the page loads are noticeably faster than with something like Bootstrap.

                  I think that limiting yourself to only a few lines of css is extreme, but I do think that I’ll be defaulting to no framework in the future.

                  1. 4

                    Oh I agree on CSS. I personally use quite a bit more than what’s in this post (my style.css) and don’t have any real purism about it. But I wanted to point out that the required minimum to get working semantic HTML that renders ok on the modern web is very reasonable and doesn’t require becoming a massive web guru. (I started out with something pretty close to this, and only learned some more CSS later.)

                    Many of my colleagues in academia used to maintain their own pages in plain HTML once upon a time (the classic example.edu/~username/ sites that lived in your ~/public_html directory on the departmental Unix server), but I get the impression that for many people who don’t “do” webdev, the modern web is seen as too complicated to DIY, so you need to go directly for a CMS or a framework unless you want to invest a bunch of time learning the ins and outs of the HTML/CSS/JS stack. I mean, there are small static sites with 5 pages that are built on Wordpress, because that’s just the default thing people reach for to make a site. Which is understandable, since I almost had that reaction myself: I load my old site on a mobile phone for the first time, notice it renders horribly, Google to try to figure out what’s going wrong, then end up down a rabbit hole of blog posts about “responsive design” and “grid models” that are way more involved than I wanted the answer to be.

                    I eventually stumbled across the four minimal things I suggest here from various sources, e.g. I think I first got the viewport line from a Google Webmaster Tools help page, realized I needed a charset line the first time I tried to use an m-dash in a document and it broke, etc. I hadn’t seen them summarized anywhere (along with an explanation of why things like a viewport where width=device-width aren’t the default in the first place), so figured I’d write it up. The other part of the motivation for writing the post is that I’m not even sure if these are the minimal set; since it’s picked up entirely ad-hoc from fixing things, there might be some 5th thing that has a good complexity:advantage ratio that I should know about.

                    1. 2

                      Agreed. I didn’t mean to come off as critical in my first comment. I think your write-up is a very good one, and you’ve identified important declarations that I hadn’t really thought about before.

                      Like many developers, I didn’t really bother to learn css thoroughly. Css didn’t exists when I first learned HTML. Once I started making web pages seriously, I just copied and pasted Boostrap examples like everyone else.

                      I think it can be really intimidating for some developers to forgo the heavy-duty framework. Few people understand how the frameworks work exactly, because they are quite complicated with many moving parts. And I thought that if I couldn’t duplicate Bootstrap, then I was stuck with it. Of course, it turns out, for most things you just don’t need all that complexity, but that was hard for me to realize.

                      I think it was (warning profanity) this website and this website that finally convinced me to throw away the 2mb framework and start from scratch.

                      1. 1

                        What convinced me to dig into it a bit more personally was a very bad experience with Wordpress (plus a few less-bad-but-still-annoying experiences with Wordpress). Wordpress “just works” to set up a simple website initially, but if anything goes wrong with it, good luck…

                    2. 3

                      I tend to use straight css that I pass through cssnext with postcss-cli. It takes care of alot of cross browser conpatibility.