15 ms·

Write HTML Right

263 points by aparks517 4y ago

kuschku 4y ago
I appreciate that this blog post itself is written in the exact same style! I really miss being able to read the view-source: version of websites easily, but this blog post does it well :)
- Legion 4y ago
  Certainly beats the "you don't need so much JavaScript!" blog posts that load 10 external scripts.
  - account42 4y ago
    Or the articles about tracking and the ad industry with consent popups asking for permissions to let their ad "partners" track you.
sylware 4y ago
Regarding tables, there is one trick: size of borders are actually weighted semantic separators, and should be in HTML, not in CSS.
- Julesman 4y ago
  Regarding tables, don't use tables. :)
  - Rygian 4y ago
    Except, you know, for actual tables. :-)
  - egypturnash 4y ago
    …for non-tabular data such as “your pretty design elements that frame and organize the text because it is 1995 and CSS doesn’t exist yet and this is the only tool at your disposal for aligning stuff across the page”. Or because it is 2000 and putting stuff where you want it is a hell of CSS2 floats and box models and eventually you just say “fuck it” and assign table-like behavior to a bunch of divs because Tables For Layout Are Considered Harmful. If you’ve got stuff that would look good as a table, use a table.
    - temporallobe 4y ago
      It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible borders were nearly perfect for layout containers.
      - frosted-flakes 4y ago
        ...and absolutely unreadable for anyone using a screen reader.
        layer8 4y ago
        This was never true, I believe, and only a theoretical issue invented by the semantic-HTML obsessed. From [1]: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.” [1] https://webaim.org/techniques/tables/ https://webaim.org/techniques/tables/
        sylware 4y ago
        yep, then no pb as a layout.
      - kixiQu 4y ago
        https://eev.ee/blog/2020/02/01/old-css-new-css/ https://eev.ee/blog/2020/02/01/old-css-new-css/ <-- Sounds like it depends on how complicated you want things to get within those containers; Eevee here mentions nesting three levels of tables, which... Ew. Also, not being able to rearrange blocks for different size displays is kind of a non-starter relative to the mobile internet, which I'd guess was more important than frameworks. In my own hobbyist stuff, though, there's just something a little gross about putting layout in the HTML -- I want HTML to represent semantic structure, in ways I'd be okay with Lynx displaying, and I want CSS to do all the lunatic nonsense to make me happy with how it looks on a modern browser. I wonder how much it's this aesthetic principle of separation that motivates others as well.
  - temporallobe 4y ago
    Joking aside, tables are perfectly acceptable and actually the most appropriate markup for tabular data; in addition, accessibility tools know how to read them (IF they are coded correctly, but that goes for any HTML). I use tables where needed, but of course never for layout.
btrettel 4y ago
Regarding writing "one-sentence-per-line", I've noticed that style before in LaTeX. While I don't use that style, one advantage that I like is the ability to include comments on the sentence level in LaTeX. So instead of this: First sentence. Second sentence. % Comment on first sentence. I can write: First sentence. % Comment on first sentence. Second sentence. (Of course, one could define a new TeX macro that doesn't display anything to add comments anywhere in-line. That's not as readable, though.) I've also read that one-sentence-per-line works better with diff programs, but I haven't had any problems with the program meld, so this isn't convincing to me. The advantage the linked article mentions in terms of rearranging sentences also is worth considering, though I haven't found the normal way to be that bad so I'm not convinced by that either. Some other links on this coding/writing style: https://rhodesmill.org/brandon/2012/one-sentence-per-line/ https://rhodesmill.org/brandon/2012/one-sentence-per-line/ https://news.ycombinator.com/item?id=4642395 https://news.ycombinator.com/item?id=4642395 http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-editing-thinking-with-line-breaks/ http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...
- pronoiac 4y ago
  I've been working on turning a pretty massive scanned book into a git repo of markdown files, with multiple collaborators. Using sentence-per-line has been useful (compared to line-per-paragraph) because, even with / despite --word-diff , PRs are far more concise, and merge conflicts are more rare. From memory, with paragraph-per-line, I think a series of paragraphs, each changed, even with minor changes, kinda breaks git diff and GitHub diff.
  - aparks517 4y ago
    Oh, wow... I hadn't even thought of the diff angle, but it makes all the sense in the world. I've heard some authors even start each clause on its own line. I'm not sure I'm ready for that yet.
robgibbons 4y ago
This works for blog posts, where the body of the document is one long block of paragraphs, but I suspect this style would quickly become untenable for complex apps. Indentation _is_ information, which is lost here.
- pwdisswordfish9 4y ago
  That’s why HTML is not a language for ‘apps’.
  - Spivak 4y ago
    Except for the fact that native apps also use SGML or XML inspired markup for their layout engines. A tree of heterogeneous objects maps extremely well to how people think about UI.
    - WillusFredus 4y ago
      I agree that a tree structure can work well for mapping UIs, but HTML does not. It was specifically design as a textual markup language. Its role has been expanded, but it has been done so poorly. What really needs to happen it a separation of HTML from UI markup elements. HTML will be used solely for textual markup and a new markup language can be used for UIs. This would allow us to return to a proper separation of concerns.
      - ryanbrunner 4y ago
        Sure, but that's an argument for creating new paradigms for having instantly available non-downloaded "apps". Right now, if you want a lot of what a webapp offers (100% cross-compatibility with any platform, instant updates, online syncing for free), you're basically stuck with HTML / Javascript.
      - TedDoesntTalk 4y ago
        > What really needs to happen it a separation of HTML from UI markup elements Do you mean CSS? Using <b>, <I>, <strong>, etc has been “bad form” for a while (maybe not strong though)
gildas 4y ago
This is how SingleFile writes HTML by default :). However, it is also the most duplicated issue in the tracker.
- sph 4y ago
  You can link it: https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile Pretty neat extension!
  - gildas 4y ago
    I was hesitating, thanks!
    - pwdisswordfish9 4y ago
      The remarks by the person who opened #967 are beyond frustrating—and it's frustrating to see your responses to them. People putting stuff into the bugtracker that aren't bugs deserve a harsher response. Don't enable "putting stuff into the bugtracker without clearly articulating a defect [in the form of observed behavior versus expected behavior‡]" to be a viable way to interact with a project. Indulging these kinds of persons' requests for support and freeform banter is harmful in the long run. Giving them the answers that they're looking for even though their questions/comments are out of scope is way too forgiving, and it ends up causing problems for other maintainers when these numbskulls inevitably pop up around other projects and expect the same standard of treatment because they take it as a given that their fripperies are kosher. ‡ including sound, solid reasoning for why the former is incorrect and the latter is correct
      - gildas 4y ago
        At first, I thought people would respect the issue template. In practice, very few do, even when a proper bug is reported. I completely agree with you but it seems to be a losing battle. So I just deal with these kinds of cases according to my mood. Concerning the bug #967, maybe I was not angry enough. Overall, the atmosphere on the bug tracker is fortunately very positive.
iLoveOncall 4y ago
In 2022 how often do you actually write text by hand in your HTML files? I find that beside the few buttons here and there (and that's if you don't have i18n), text is always going to be served by a server. In 2022 we also all use text editors or IDEs that can collapse entire blocks of tags, to improve readability. I'm not sure I can see a clear benefit here outside of very few edge cases, and I am sure it comes with its lot of disadvantages.
- nojs 4y ago
  Static site generators (Jekyll, Hugo) are one example. Sometimes you can get away with markdown but often you end up marking up pages of text.
  - pineconewarrior 4y ago
    Even when you need to write actual HTML you still should use shorthand tools like emmet to write your markup faster and with less mistakes.
exodust 4y ago
Closing li tags is the right thing to do! I always close the kitchen drawer too after putting the scissors back. But I rarely write HTML as content anyway, it's mostly templates for the CMS, where it's best to close the tags.
- recursive 4y ago
  I too close my kitchen drawers. But not my li tags. Unless I'm using the bastardization known as jsx. The next li closes it automatically, as it's specified to do.
  - hinkley 4y ago
    "everybody knows" doesn't scale, because 1) not everybody knows and 2) you're relying on memorization for people to read your code, which means you're smashing the ladder rungs behind you Software on a team is a performance art. People are either watching you and copying your behavior, or watching you and getting confused. And if you've ever felt overbooked on a project while other people are idle? It's stuff like that that put you into that situation. And since you're the one who did the 'stuff like that', it's at least partly your fault you're in this situation. Stop being a ball hog, and you'll get fewer bruises.
    - recursive 4y ago
      > "everybody knows" doesn't scale Agreed. That's why I prefer to have things written down. In this case, WHATWG and W3C already did the work for us. > And if you've ever felt overbooked on a project while other people are idle? I've seen what you're talking about, but I'm not the one getting overbooked. I'm not generally the one fighting over this stuff. If I get feedback on a PR telling me to add li close tags, I'll probably just do it. If you're using a technology on a daily basis, it will pay big dividends to spend a little time learning how it actually works.
myfonj 4y ago
Although, as the article correctly points out, omitting the HTML tag is technically fine, there is one rather important argument for its inclusion: it can and should have a LANG attribute: <html lang=en-GB> It's not verbose after all, and IIUC may be omitted if and only if the document is served with corresponding information in `Content-Language:` HTTP header, but nasty (or rather annoying) things may happen if that fails [1], so when it comes to "right HTML", following this advice sounds reasonable. [1] https://adrianroselli.com/2015/01/on-use-of-lang-attribute.html https://adrianroselli.com/2015/01/on-use-of-lang-attribute.h...
JasonFruit 4y ago
Why does it matter? A good HTML editor ought to be able to take in HTML, display it and edit it according to the user's preferences, and save it in a size-minimizing way. Why should we have to choose only one way?
layer8 4y ago
> gator What do they mean here?
- aparks517 4y ago
  Less-than or greater-than signs (code points 0x3C and 0x3E in ASCII). A friend put me on to calling them that because they (sort of?) look like alligators with their mouths open.
  - trevcanhuman 4y ago
    My math teachers used an alligator analogy to remind us which is the correct symbol for using the greater - and less - than sign, the 'mouth' of the gator is always eating the greater number.
    - phabricator 4y ago
      Ex: https://cdn.themeasuredmom.com/wp-content/uploads/2014/07/free-printables-greater-than-less-than.jpg https://cdn.themeasuredmom.com/wp-content/uploads/2014/07/fr...
dasil003 4y ago
I like the aesthetic though I'm not sure how sustainable it is beyond basic content documents. On a side note though, I clicked around and big props to Aaron on the lofi.limo project, this is very cool.
- aparks517 4y ago
  Thank you for the kind words! I've been working on adapting this style for web apps, but I haven't got it figured out well enough to write an article about. Yet... I wouldn't mind if we had a bunch more basic content documents on the web.
math_dandy 4y ago
Keep calm and Prettier on.
spread_love 4y ago
omitting <html> works fine in browsers but breaks a lot of other developer tooling in my experience. It's nice to save 6B I guess, but compared to the behemoth webapp it's wrapping it's not much of an optimization.
shakna 4y ago
Whilst the spec certainly allows you to ignore closing of a whole range of elements, it's not necessarily the wisest of choices to make. The parser does actually get slower when you fail to close your tags in my experience. Unscientific stats from a recent project where I noticed it: + Document is about 50,000 words in size. About 150 words to a paragraph element, on average. + Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render. + The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words. + Curiously, Quirks Mode also increased the load times by about 250ms on Firefox and 150ms on Chrome. (Tried it just because I was surprised at the massive overhead of removing/adding the tag endings.) The most common place this was going to be opened was Chrome on Android, and a whopping half-second slower to first render is going to be noticeable to the end user. For some prettier mark up. Whilst you can debate whether that increased latency actually affects the user, a decreased latency will always make people smile more. So including the end tags is a no-brainer. Feel free to write it without them - but you _might_ consider whether your target is appropriate for you to generate them before you serve up the content.
- toqy 4y ago
  > For some prettier mark up. But then if you run it through Prettier it'll add all the closing tags for you :)
  - throwaway894345 4y ago
    If you’re running it through a processor, why it just write markdown and call it a day?
    - hombre_fatal 4y ago
      Well, one simply formats the source file as you write it. The other requires a infile -> outfile build step that's more complex. Whether the latter is worth it tends to depend on other things than parse time.
EugeneOZ 4y ago
XML is beautiful and clean, and I prefer to write full closing tags.
- enriquto 4y ago
  Of course, of course; but here they are talking about HTML (i.e., about HTML5), not about XML.
  - nayuki 4y ago
    HTML has a dialect in XML called XHTML. It is obscure but actually works. My website is a living example.
  - tannhaeuser 4y ago
    I've given up to try and educate XML heads that XML is just a proper subset of SGML, just as HTML is originally, and mostly still, an SGML vocabulary. Idk what people are talking about in this thread (seems to be about each one's personal preferences and wildly speculative assumptions about backtracking when in reality both SGML and WHATWG are deterministic); while there is exactly one reference to WHATWG at this time.
- anjbe 4y ago
  It’s funny how people’s aesthetic sensibilities can differ. Making use of HTML’s standard features to drop unnecessary elements and closing tags is very much in line with my own idea of “beautiful” and “clean.” Do you consider any table that doesn’t explicitly declare <tbody> “unclean”? That’s an implicit element in every <table>, according to the spec.
  - EugeneOZ 4y ago
    No, tbody is just an element. The power is in tags.
DustinBrett 4y ago
I've been using https://github.com/terser/html-minifier-terser https://github.com/terser/html-minifier-terser to get this kind of HTML for my personal site for a while. It passes W3C so I'm happy. After reading the connected blog post http://perfectionkills.com/experimenting-with-html-minifier/ http://perfectionkills.com/experimenting-with-html-minifier/
buzzy_hacker 4y ago
> A few years ago, I found out I'd been tying my shoes wrong for my entire life. I thought laces came undone easily and didn't usually look very good. At least that's how mine were, and I never paid much attention to anyone else's. It took a couple of weeks to re-train my hands but now I have bows in my laces that look good and rarely come undone. I’m equally interested in this as the HTML. Any clue what the author is referring to?
- aparks517 4y ago
  Aw... you didn't read to the end ;) > The right way to tie your shoes is with a square knot. It's easy to confuse this with the granny knot, which is the wrong way. The square knot is a simple and sound knot with many uses. The granny knot is an unsound knot whose only known uses are to make your shoelaces look crooked and to trip you.
- js2 4y ago
  Lucky you! [1] https://www.fieggen.com/shoelace/ https://www.fieggen.com/shoelace/ Specifically: https://www.fieggen.com/shoelace/grannyknot.htm https://www.fieggen.com/shoelace/grannyknot.htm An HN favorite: https://news.ycombinator.com/from?site=fieggen.com https://news.ycombinator.com/from?site=fieggen.com 1. https://xkcd.com/1053/ https://xkcd.com/1053/
- SpaceNugget 4y ago
  Likely the author was tying granny knots instead of slipped/bowed reef knots If your first cross is left over right you need to make your second cross right over left, or vice versa. I found an image showing the difference for the un-slipped version, but it's the same with a bow: http://www.tikalon.com/blog/2020/square_granny_knots.png http://www.tikalon.com/blog/2020/square_granny_knots.png Granny knots untie themselves and the bow will end up perpendicular to the knot instead of parallel.
- jjice 4y ago
  Possibly the Ian knot https://www.fieggen.com/shoelace/ianknot.htm https://www.fieggen.com/shoelace/ianknot.htm You look goofy trying to relearn to tie your shoes, but it really is fast and sturdy.
tiffanyh 4y ago
One of the easiest ways to improve SEO is to just properly use existing HTML tags (instead of using a custom DIV for everything).
andrew_ 4y ago
The lack of closing tags is giving me severe anxiety. I know it's valid non-xml syntax but all the hairs on my neck are at attention.
- pineconewarrior 4y ago
  I agree, and unless someone has a better reason than the ones I have seen, (saving tiny amount of bytes, less keystrokes, dx) I am convinced it's a bad idea to omit the end tags. It causes way more trouble than those benefits are worth
  - MrVandemar 4y ago
    I use an aggressively minnimal set of (valid) HTML because I prefer to write in HTML rather than Markdown-flavour-x. Omitting the closing tags where possible is less about saving keystrokes than minnimising interruptions to my writing flow. But I wouldn't advocate it for published documents, just my local scribblings.
- nayuki 4y ago
  To solve your anxiety, may I suggest XHTML? I use it on my website in practice and it works really well.
timw4mail 4y ago
No thanks. With the full markup you can see where things end, not just where they start. I think this is similar to semicolons in Javascript: with semicolons at the end of each statement there is no ambiguity, but if you do not have semicolons, you have to know about edge cases, like if a line starts with a square bracket or paren.
- iamben 4y ago
  Agree 100%. It's also about a thousand times easier for people with a very basic HTML understanding to parse (if you open something, with pretty much the exception of an image, you gotta close it). Periodically I have to send code to people who then make some of their own changes inline. God forbid trying to explain "yeah, they don't need to be closed, but that does because it's nested and..." Disaster (/hours of extra support) waiting to happen.
- mst 4y ago
  I have a tendency to forget ASI in JS exists when I've only been looking at my own code rather than other people's for a while. I remain unconvinced it was a wise idea.
  - lelanthran 4y ago
    What is ASI?
    - mikewhy 4y ago
      "Automatic semicolon insertion": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- currysausage 4y ago
  You have to know HTML in order to know where things end. Otherwise, you will see nested paragraphs here: <p>Hello <p>World</p>!</p> when it’s actually two consecutive paragraphs, an exclamation mark outside of any paragraph, and a closing p tag without an opening counterpart. And when you do know HTML, you might as well omit optional tags. If you think that HTML syntax is crazy, I won’t blame you, and you might consider XHTML instead, but you should be prepared for different woes.
sivers 4y ago
Thanks to Aaron for posting this. Such a great reminder. Anyone interested in this subject, check out a series of three very tiny books called “UPGRADE YOUR HTML” by Jens Oliver Meiert. They give great step-by-step examples for eliminating optional tags and attributes, reducing HTML to its cleanest simplest valid form. The author is a super-expert in this specific subject, working with Google and W3C on this. His bio here: https://meiert.com/en/biography/ https://meiert.com/en/biography/ From LeanPub: https://leanpub.com/b/upgrade-your-html-123 https://leanpub.com/b/upgrade-your-html-123 From Amazon: https://www.amazon.com/gp/product/B08NP4GXY2/ https://www.amazon.com/gp/product/B08NP4GXY2/
- xaduha 4y ago
  > Such a great reminder. Reminder of what? To me this reads like satire, even if it wasn't intended as such.
moralestapia 4y ago
- phabricator 4y ago
  You should try reading articles before you comment! The author explicitly states why this is perfectly "proper" and why they prefer it.
- niconii 4y ago
  https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
  - moralestapia 4y ago
    >A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element. Whoops! Not in the spec!
    - niconii 4y ago
      What's not in the spec? Every example in the article is valid HTML, and the article itself, which is written in the same style, is valid as well: https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fblog%2Fwrite-html-right https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fb... > Document checking completed. No errors or warnings to show. Or are you complaining that the rules are too complicated? It's very verbose and explicit because this is a specification, but the basic rule of thumb is that anything that would normally be a block element and thus doesn't make sense inside a paragraph will end that paragraph. In practice, this is not really an issue I run into. Moreover, you need to know about this rule even if you don't omit </p>, because this is the list of elements that implicitly ends a paragraph. For example, <p><div></div></p> is invalid HTML because <div> ends the paragraph implicitly, making it equivalent to <p></p><div></div></p>. If you don't like that, then your problem is not with this particular code style but HTML itself, which is reasonable. HTML's syntax is very complicated due to its history and doesn't always make sense. But you still have to know how it works regardless of how you personally like to write it.
jokoon 4y ago
I'm curious if a more strict html parser would actually be faster. Browsers are not really fast on my Android, and I wish they were fast.
- mst 4y ago
  Depending on what sites you're mostly accessing, it may be worth experimenting with Firefox Mobile plus uBlock Origin plus perhaps one or more of the extra anti-(ad|bloat)ware extensions. Chrome is definitely faster in a straight line but once I've got Firefox configured it's (to me) significantly more pleasant to use (and I like the current UI better than Chrome's though that's -definitely- not a universal opinion, mileage may vary as ever).
- exyi 4y ago
  I have yet to see a slow HTML-only website ;) (which is not 10MB single file spec or entire book). Really, I don't think html parsing is a huge bottleneck and these few parser exceptions don't seem to be that hard to implement - just close a tag if opening one of a predefined list, no backtracking or something expensive.
jacobsenscott 4y ago
If you must write html by hand this seems nice. But I would never actually write html by hand anymore. For most web apps you write more tags than text. I love slim because it was designed with that in mind. There is no overhead to writing tags, and just a little for writing text. Which is the right way to go for web apps.
martin_a 4y ago
While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?
- aparks517 4y ago
  I don’t expect it to as long as the mark-up is valid. Perhaps someone with more SEO knowledge will stop by to correct me.
  - martin_a 4y ago
    You're right. HTML5 does not work with DTDs anymore, so unclosed tags are not a violation of the document schema and therefore probably not "punishable" by search engines.
    - anjbe 4y ago
      Implicit end tags as described in the article have been allowed by every HTML DTD not named XHTML.
- exyi 4y ago
  I have no idea what Google does, but expect their parsers to be quite robust. I tried doing some web scraping, and so many pages are not even valid HTML (most often invalid nested tags, like a table inside span, missing closing tags even when required, random unopened closing tags, ...). Not closing <p> and <td> tags is quite common, I have not seen omitted <html> <head> and <body> yet.
JJMcJ 4y ago
I too found out I'd been doing my shoelaces wrong. YouTube set me straight. For HTML, these are good recommendations. Sometimes, like for technical writing where there are various distinct and important formatting choices, it's just hard work to get it the way you want it even with a WYSIWYG editor.
_glass 4y ago
love the troff reference. I wrote my first CV in troff. mostly because it was available on my linux machine, and working.
irrational 4y ago
This post needs an OCD trigger warning.
- ThatIsntOCD 4y ago
  "OCD" as in "I don't like clutter" or real OCD as in "if I don't clear away the clutter my family will die in a car crash, I know that's illogical, and yet I'm still encumbered with the intrusive thought?"
  - irrational 4y ago
    OCD as in “not having closing tags matching open tags is driving me insane”. Maybe OCD isn’t the proper term, but I don’t know of a better one.
    - ThatIsntOCD 4y ago
      Respectfully, please try to refrain from using OCD casually. It's not like you're the only one, but it's a debilitating disease.
      - irrational 4y ago
        What is a better term to use that means when things are not perfectly matched it drives me so insane that I can't function until I go in there and fix it so that everything is exactly right?
Kazkans 4y ago
Why dont just use groff/troff and output to html?
eatsyourtacos 4y ago
Rite HTML Wright (sorry)
movedx 4y ago
Author: write HTML right Me: this green on black background is terrible to read, I'll use reader mode Chrome: this author did not write their HTML correctly, so there is no reader mode available How ironic.
- zzo38computer 4y ago
  I use (a old version of) Firefox and can select "View > Page Style > No Style" to disable CSS, and this works OK for me (it is better than some web pages, where this does not work very good, but this one it works good). I do not know what criteria are needed for the reader mode in Chrome. (The HTML code looks OK to me?)
- exyi 4y ago
  Firefox's reader mode works just fine. You need a right browser for the right HTML. ... anyway, it bothers me sometimes that I'm not aware of any spec for "reader mode compatibility", did anyone see anything like that?
- frosted-flakes 4y ago
  I think Reader mode looks for a <main> section. When it's not present it either guesses or doesn't work at all.
Voeid 4y ago
Figure 2. showing the "common style" is something I've never used or seen before. What is the "right" way? Perhaps it is to use style from both of these extreme examples and write code that is easy to read and edit for the person that is working with it. Or perhaps the right way is to never imply the way you are doing things is the only correct way and then try to pass it on as facts?
iostream24 4y ago
At this point you are better off making a DSL that compiles to html. - it will be possible to be consistent with closing tags or not - you can do other arbitrary things to improve your working experience with it Ever tried Slang styled templates?
boringuser1 4y ago
epolanski 4y ago
Slightly off topic but I'd like to point out that paragraphs in HTML are grouping not textual elements. They are like divs or headers, not like span or b. They are mistakenly and traditionally associated with literature-type paragraphs but that is not correct. You generally use them in forms to split different groups or inputs, that has nothing with paragraphs of a written form and even less with textual paragraphs. I think there is really a lot of confusion about them in this whole thread.
- niconii 4y ago
  Although there are some other uses for <p>, it is perfectly valid to use <p> tags for textual paragraphs and that has been the main use for <p> for as long as HTML has existed. I'm not sure why you believe otherwise. Take a look at the source code for http://info.cern.ch/hypertext/WWW/MarkUp/Future.html http://info.cern.ch/hypertext/WWW/MarkUp/Future.html for instance, which was written by the creator of HTML, Tim Berners-Lee. You can also look at the source code for any page of the current HTML spec (e.g. https://html.spec.whatwg.org/multipage/introduction.html https://html.spec.whatwg.org/multipage/introduction.html) where, again, <p> is used for each paragraph in the text.
  - epolanski 4y ago
    I didn't say it's not a valid use, I said that it's not it's primary use. Paragraphs relate to grouping content[1], not textual one. There's no logic in paragraphs. I quote here the official spec, which makes various examples of how paragraphs are not related to logical paragraphs: > The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list. And I'll quote also the definition on MDN: > The <p> HTML element represents a paragraph. Paragraphs are usually represented in visual media as blocks of text separated from adjacent blocks by blank lines and/or first-line indentation, but HTML paragraphs can be any structural grouping of related content, such as images or form fields. Failing to realize that paragraphs are grouping rather than logical content leads to frequent misuses of paragraphs and this comment section is literally filled by bad paragraphs examples which suggests the community is largely ignorant on html. [1]https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element https://html.spec.whatwg.org/multipage/grouping-content.html...
zeven7 4y ago
I like this idea. As someone who argued vehemently for XHTML a couple decades ago (even wrote a fair amount of XSLT in those XML-crazed days), who's been wandering between different levels of "how strict should I be?" since that time, this article marks the step of my journey where I feel like I can really embrace the goodness that SGML has to offer for the first time. So thank you. This article has changed me.
nhooyr 4y ago
> It used to be the case that URL parsers would remove newlines and tabs, so we could split long URLs across lines and even format their query parameters nicely with tabs. Unfortunately, this was taken advantage of for data exfiltration via HTML injection and we no longer have this nice thing as URL parsers have been made more strict to prevent this kind of attack. Does anyone have a source/reference for this?
mekster 4y ago
HTML can't be fixed with a small trick like that. Just use templating engine like Pug and get away with most of the annoyances. It's concise about what part of the text is covered by a certain tag due to forced indentation, not to mention you'll never need to close any tag and you never write "class=" but are all turned into CSS selector notation among many other tricks. https://github.com/pugjs/pug#syntax https://github.com/pugjs/pug#syntax Unless the HTML I'm composing will be touched by people like designers who would get scared of new syntax, in which case I'll use Twig or Nunjucks, I'll never write plain HTML for myself. There's also a very solid implementation in PHP as well. https://github.com/pug-php/pug https://github.com/pug-php/pug You can either let server side (node.js or PHP) compile that on demand or let your editors compile them as you edit if you're working on a static file. I really think the language humans write should deviate from the language the runtimes understand to get all the convenience while never breaking how runtimes/crawlers interpret your output. Same goes for Stylus against CSS.
moreati 4y ago
Is there a tool to convert an existing HTML document into this style? E.g. strip out optional closing tags, without doing full minimisation/whitespace stripping.
account42 4y ago
> However, any content which cannot go in a p element (most other block-display elements, for example) implies the end of its content, so we can usually leave off the end tag. Note however that this means that the whitespace between paragraphs will be part of the paragraph which can be annoying if someone tries to copy the text on your website and gets an additional space after each paragraph which wouldn't have happened if you explicitly closed the </p> directly after the text. Also, you should keep the opening <html> and specify the language of your document even for english since e.g. automatic hyphenation does not work if you don't specify a language. Otherwise really like this condensed HTML style and have recently converted my personal website to it.

263 points by aparks517 4y ago

I appreciate that this blog post itself is written in the exact same style! I really miss being able to read the view-source: version of websites easily, but this blog post does it well :)

Legion 4y ago
Certainly beats the "you don't need so much JavaScript!" blog posts that load 10 external scripts.
- account42 4y ago
  Or the articles about tracking and the ad industry with consent popups asking for permissions to let their ad "partners" track you.

sylware 4y ago

Regarding tables, there is one trick: size of borders are actually weighted semantic separators, and should be in HTML, not in CSS.

Julesman 4y ago
Regarding tables, don't use tables. :)
- Rygian 4y ago
  Except, you know, for actual tables. :-)
- egypturnash 4y ago
  …for non-tabular data such as “your pretty design elements that frame and organize the text because it is 1995 and CSS doesn’t exist yet and this is the only tool at your disposal for aligning stuff across the page”. Or because it is 2000 and putting stuff where you want it is a hell of CSS2 floats and box models and eventually you just say “fuck it” and assign table-like behavior to a bunch of divs because Tables For Layout Are Considered Harmful. If you’ve got stuff that would look good as a table, use a table.
  - temporallobe 4y ago
    It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible borders were nearly perfect for layout containers.
    - frosted-flakes 4y ago
      ...and absolutely unreadable for anyone using a screen reader.
      - layer8 4y ago
        This was never true, I believe, and only a theoretical issue invented by the semantic-HTML obsessed. From [1]: “It is sometimes suggested, even by some accessibility advocates, that layout tables are bad for accessibility. In reality, layout tables do not pose inherent accessibility issues.” [1] https://webaim.org/techniques/tables/ https://webaim.org/techniques/tables/
        sylware 4y ago
        yep, then no pb as a layout.
    - kixiQu 4y ago
      https://eev.ee/blog/2020/02/01/old-css-new-css/ https://eev.ee/blog/2020/02/01/old-css-new-css/ <-- Sounds like it depends on how complicated you want things to get within those containers; Eevee here mentions nesting three levels of tables, which... Ew. Also, not being able to rearrange blocks for different size displays is kind of a non-starter relative to the mobile internet, which I'd guess was more important than frameworks. In my own hobbyist stuff, though, there's just something a little gross about putting layout in the HTML -- I want HTML to represent semantic structure, in ways I'd be okay with Lynx displaying, and I want CSS to do all the lunatic nonsense to make me happy with how it looks on a modern browser. I wonder how much it's this aesthetic principle of separation that motivates others as well.
- temporallobe 4y ago
  Joking aside, tables are perfectly acceptable and actually the most appropriate markup for tabular data; in addition, accessibility tools know how to read them (IF they are coded correctly, but that goes for any HTML). I use tables where needed, but of course never for layout.

btrettel 4y ago

Regarding writing "one-sentence-per-line", I've noticed that style before in LaTeX. While I don't use that style, one advantage that I like is the ability to include comments on the sentence level in LaTeX. So instead of this: First sentence. Second sentence. % Comment on first sentence. I can write: First sentence. % Comment on first sentence. Second sentence. (Of course, one could define a new TeX macro that doesn't display anything to add comments anywhere in-line. That's not as readable, though.) I've also read that one-sentence-per-line works better with diff programs, but I haven't had any problems with the program meld, so this isn't convincing to me. The advantage the linked article mentions in terms of rearranging sentences also is worth considering, though I haven't found the normal way to be that bad so I'm not convinced by that either. Some other links on this coding/writing style: https://rhodesmill.org/brandon/2012/one-sentence-per-line/ https://rhodesmill.org/brandon/2012/one-sentence-per-line/ https://news.ycombinator.com/item?id=4642395 https://news.ycombinator.com/item?id=4642395 http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-editing-thinking-with-line-breaks/ http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...

pronoiac 4y ago
I've been working on turning a pretty massive scanned book into a git repo of markdown files, with multiple collaborators. Using sentence-per-line has been useful (compared to line-per-paragraph) because, even with / despite --word-diff , PRs are far more concise, and merge conflicts are more rare. From memory, with paragraph-per-line, I think a series of paragraphs, each changed, even with minor changes, kinda breaks git diff and GitHub diff.
- aparks517 4y ago
  Oh, wow... I hadn't even thought of the diff angle, but it makes all the sense in the world. I've heard some authors even start each clause on its own line. I'm not sure I'm ready for that yet.

robgibbons 4y ago

This works for blog posts, where the body of the document is one long block of paragraphs, but I suspect this style would quickly become untenable for complex apps. Indentation _is_ information, which is lost here.

pwdisswordfish9 4y ago
That’s why HTML is not a language for ‘apps’.
- Spivak 4y ago
  Except for the fact that native apps also use SGML or XML inspired markup for their layout engines. A tree of heterogeneous objects maps extremely well to how people think about UI.
  - WillusFredus 4y ago
    I agree that a tree structure can work well for mapping UIs, but HTML does not. It was specifically design as a textual markup language. Its role has been expanded, but it has been done so poorly. What really needs to happen it a separation of HTML from UI markup elements. HTML will be used solely for textual markup and a new markup language can be used for UIs. This would allow us to return to a proper separation of concerns.
    - ryanbrunner 4y ago
      Sure, but that's an argument for creating new paradigms for having instantly available non-downloaded "apps". Right now, if you want a lot of what a webapp offers (100% cross-compatibility with any platform, instant updates, online syncing for free), you're basically stuck with HTML / Javascript.
    - TedDoesntTalk 4y ago
      > What really needs to happen it a separation of HTML from UI markup elements Do you mean CSS? Using <b>, <I>, <strong>, etc has been “bad form” for a while (maybe not strong though)

gildas 4y ago

This is how SingleFile writes HTML by default :). However, it is also the most duplicated issue in the tracker.

sph 4y ago
You can link it: https://github.com/gildas-lormeau/SingleFile https://github.com/gildas-lormeau/SingleFile Pretty neat extension!
- gildas 4y ago
  I was hesitating, thanks!
  - pwdisswordfish9 4y ago
    The remarks by the person who opened #967 are beyond frustrating—and it's frustrating to see your responses to them. People putting stuff into the bugtracker that aren't bugs deserve a harsher response. Don't enable "putting stuff into the bugtracker without clearly articulating a defect [in the form of observed behavior versus expected behavior‡]" to be a viable way to interact with a project. Indulging these kinds of persons' requests for support and freeform banter is harmful in the long run. Giving them the answers that they're looking for even though their questions/comments are out of scope is way too forgiving, and it ends up causing problems for other maintainers when these numbskulls inevitably pop up around other projects and expect the same standard of treatment because they take it as a given that their fripperies are kosher. ‡ including sound, solid reasoning for why the former is incorrect and the latter is correct
    - gildas 4y ago
      At first, I thought people would respect the issue template. In practice, very few do, even when a proper bug is reported. I completely agree with you but it seems to be a losing battle. So I just deal with these kinds of cases according to my mood. Concerning the bug #967, maybe I was not angry enough. Overall, the atmosphere on the bug tracker is fortunately very positive.

iLoveOncall 4y ago

In 2022 how often do you actually write text by hand in your HTML files? I find that beside the few buttons here and there (and that's if you don't have i18n), text is always going to be served by a server. In 2022 we also all use text editors or IDEs that can collapse entire blocks of tags, to improve readability. I'm not sure I can see a clear benefit here outside of very few edge cases, and I am sure it comes with its lot of disadvantages.

nojs 4y ago
Static site generators (Jekyll, Hugo) are one example. Sometimes you can get away with markdown but often you end up marking up pages of text.
- pineconewarrior 4y ago
  Even when you need to write actual HTML you still should use shorthand tools like emmet to write your markup faster and with less mistakes.

exodust 4y ago

Closing li tags is the right thing to do! I always close the kitchen drawer too after putting the scissors back. But I rarely write HTML as content anyway, it's mostly templates for the CMS, where it's best to close the tags.

recursive 4y ago
I too close my kitchen drawers. But not my li tags. Unless I'm using the bastardization known as jsx. The next li closes it automatically, as it's specified to do.
- hinkley 4y ago
  "everybody knows" doesn't scale, because 1) not everybody knows and 2) you're relying on memorization for people to read your code, which means you're smashing the ladder rungs behind you Software on a team is a performance art. People are either watching you and copying your behavior, or watching you and getting confused. And if you've ever felt overbooked on a project while other people are idle? It's stuff like that that put you into that situation. And since you're the one who did the 'stuff like that', it's at least partly your fault you're in this situation. Stop being a ball hog, and you'll get fewer bruises.
  - recursive 4y ago
    > "everybody knows" doesn't scale Agreed. That's why I prefer to have things written down. In this case, WHATWG and W3C already did the work for us. > And if you've ever felt overbooked on a project while other people are idle? I've seen what you're talking about, but I'm not the one getting overbooked. I'm not generally the one fighting over this stuff. If I get feedback on a PR telling me to add li close tags, I'll probably just do it. If you're using a technology on a daily basis, it will pay big dividends to spend a little time learning how it actually works.

myfonj 4y ago

Although, as the article correctly points out, omitting the HTML tag is technically fine, there is one rather important argument for its inclusion: it can and should have a LANG attribute: <html lang=en-GB> It's not verbose after all, and IIUC may be omitted if and only if the document is served with corresponding information in `Content-Language:` HTTP header, but nasty (or rather annoying) things may happen if that fails [1], so when it comes to "right HTML", following this advice sounds reasonable. [1] https://adrianroselli.com/2015/01/on-use-of-lang-attribute.html https://adrianroselli.com/2015/01/on-use-of-lang-attribute.h...

JasonFruit 4y ago

Why does it matter? A good HTML editor ought to be able to take in HTML, display it and edit it according to the user's preferences, and save it in a size-minimizing way. Why should we have to choose only one way?

layer8 4y ago

> gator What do they mean here?

aparks517 4y ago
Less-than or greater-than signs (code points 0x3C and 0x3E in ASCII). A friend put me on to calling them that because they (sort of?) look like alligators with their mouths open.
- trevcanhuman 4y ago
  My math teachers used an alligator analogy to remind us which is the correct symbol for using the greater - and less - than sign, the 'mouth' of the gator is always eating the greater number.
  - phabricator 4y ago
    Ex: https://cdn.themeasuredmom.com/wp-content/uploads/2014/07/free-printables-greater-than-less-than.jpg https://cdn.themeasuredmom.com/wp-content/uploads/2014/07/fr...

dasil003 4y ago

I like the aesthetic though I'm not sure how sustainable it is beyond basic content documents. On a side note though, I clicked around and big props to Aaron on the lofi.limo project, this is very cool.

aparks517 4y ago
Thank you for the kind words! I've been working on adapting this style for web apps, but I haven't got it figured out well enough to write an article about. Yet... I wouldn't mind if we had a bunch more basic content documents on the web.

math_dandy 4y ago

Keep calm and Prettier on.

spread_love 4y ago

omitting <html> works fine in browsers but breaks a lot of other developer tooling in my experience. It's nice to save 6B I guess, but compared to the behemoth webapp it's wrapping it's not much of an optimization.

shakna 4y ago

Whilst the spec certainly allows you to ignore closing of a whole range of elements, it's not necessarily the wisest of choices to make. The parser does actually get slower when you fail to close your tags in my experience. Unscientific stats from a recent project where I noticed it: + Document is about 50,000 words in size. About 150 words to a paragraph element, on average. + Converting the entire thing to self-closing p elements added an overhead of about 120ms in Firefox on Linux, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 480ms in Chrome on Linux, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 400ms in Firefox on Android, before initial render. + Converting the entire thing to self-closing p elements added an overhead of about 560ms in Chrome on Android, before initial render. + The time differences appeared to be linearly increasing, as the document grew from 20,000 to 50,000 words. + Curiously, Quirks Mode also increased the load times by about 250ms on Firefox and 150ms on Chrome. (Tried it just because I was surprised at the massive overhead of removing/adding the tag endings.) The most common place this was going to be opened was Chrome on Android, and a whopping half-second slower to first render is going to be noticeable to the end user. For some prettier mark up. Whilst you can debate whether that increased latency actually affects the user, a decreased latency will always make people smile more. So including the end tags is a no-brainer. Feel free to write it without them - but you _might_ consider whether your target is appropriate for you to generate them before you serve up the content.

toqy 4y ago
> For some prettier mark up. But then if you run it through Prettier it'll add all the closing tags for you :)
- throwaway894345 4y ago
  If you’re running it through a processor, why it just write markdown and call it a day?
  - hombre_fatal 4y ago
    Well, one simply formats the source file as you write it. The other requires a infile -> outfile build step that's more complex. Whether the latter is worth it tends to depend on other things than parse time.

EugeneOZ 4y ago

XML is beautiful and clean, and I prefer to write full closing tags.

enriquto 4y ago
Of course, of course; but here they are talking about HTML (i.e., about HTML5), not about XML.
- nayuki 4y ago
  HTML has a dialect in XML called XHTML. It is obscure but actually works. My website is a living example.
- tannhaeuser 4y ago
  I've given up to try and educate XML heads that XML is just a proper subset of SGML, just as HTML is originally, and mostly still, an SGML vocabulary. Idk what people are talking about in this thread (seems to be about each one's personal preferences and wildly speculative assumptions about backtracking when in reality both SGML and WHATWG are deterministic); while there is exactly one reference to WHATWG at this time.
anjbe 4y ago
It’s funny how people’s aesthetic sensibilities can differ. Making use of HTML’s standard features to drop unnecessary elements and closing tags is very much in line with my own idea of “beautiful” and “clean.” Do you consider any table that doesn’t explicitly declare <tbody> “unclean”? That’s an implicit element in every <table>, according to the spec.
- EugeneOZ 4y ago
  No, tbody is just an element. The power is in tags.

DustinBrett 4y ago

I've been using https://github.com/terser/html-minifier-terser https://github.com/terser/html-minifier-terser to get this kind of HTML for my personal site for a while. It passes W3C so I'm happy. After reading the connected blog post http://perfectionkills.com/experimenting-with-html-minifier/ http://perfectionkills.com/experimenting-with-html-minifier/

buzzy_hacker 4y ago

> A few years ago, I found out I'd been tying my shoes wrong for my entire life. I thought laces came undone easily and didn't usually look very good. At least that's how mine were, and I never paid much attention to anyone else's. It took a couple of weeks to re-train my hands but now I have bows in my laces that look good and rarely come undone. I’m equally interested in this as the HTML. Any clue what the author is referring to?

aparks517 4y ago
Aw... you didn't read to the end ;) > The right way to tie your shoes is with a square knot. It's easy to confuse this with the granny knot, which is the wrong way. The square knot is a simple and sound knot with many uses. The granny knot is an unsound knot whose only known uses are to make your shoelaces look crooked and to trip you.
js2 4y ago
Lucky you! [1] https://www.fieggen.com/shoelace/ https://www.fieggen.com/shoelace/ Specifically: https://www.fieggen.com/shoelace/grannyknot.htm https://www.fieggen.com/shoelace/grannyknot.htm An HN favorite: https://news.ycombinator.com/from?site=fieggen.com https://news.ycombinator.com/from?site=fieggen.com 1. https://xkcd.com/1053/ https://xkcd.com/1053/
SpaceNugget 4y ago
Likely the author was tying granny knots instead of slipped/bowed reef knots If your first cross is left over right you need to make your second cross right over left, or vice versa. I found an image showing the difference for the un-slipped version, but it's the same with a bow: http://www.tikalon.com/blog/2020/square_granny_knots.png http://www.tikalon.com/blog/2020/square_granny_knots.png Granny knots untie themselves and the bow will end up perpendicular to the knot instead of parallel.
jjice 4y ago
Possibly the Ian knot https://www.fieggen.com/shoelace/ianknot.htm https://www.fieggen.com/shoelace/ianknot.htm You look goofy trying to relearn to tie your shoes, but it really is fast and sturdy.

tiffanyh 4y ago

One of the easiest ways to improve SEO is to just properly use existing HTML tags (instead of using a custom DIV for everything).

andrew_ 4y ago

The lack of closing tags is giving me severe anxiety. I know it's valid non-xml syntax but all the hairs on my neck are at attention.

pineconewarrior 4y ago
I agree, and unless someone has a better reason than the ones I have seen, (saving tiny amount of bytes, less keystrokes, dx) I am convinced it's a bad idea to omit the end tags. It causes way more trouble than those benefits are worth
- MrVandemar 4y ago
  I use an aggressively minnimal set of (valid) HTML because I prefer to write in HTML rather than Markdown-flavour-x. Omitting the closing tags where possible is less about saving keystrokes than minnimising interruptions to my writing flow. But I wouldn't advocate it for published documents, just my local scribblings.
nayuki 4y ago
To solve your anxiety, may I suggest XHTML? I use it on my website in practice and it works really well.

timw4mail 4y ago

No thanks. With the full markup you can see where things end, not just where they start. I think this is similar to semicolons in Javascript: with semicolons at the end of each statement there is no ambiguity, but if you do not have semicolons, you have to know about edge cases, like if a line starts with a square bracket or paren.

iamben 4y ago
Agree 100%. It's also about a thousand times easier for people with a very basic HTML understanding to parse (if you open something, with pretty much the exception of an image, you gotta close it). Periodically I have to send code to people who then make some of their own changes inline. God forbid trying to explain "yeah, they don't need to be closed, but that does because it's nested and..." Disaster (/hours of extra support) waiting to happen.
mst 4y ago
I have a tendency to forget ASI in JS exists when I've only been looking at my own code rather than other people's for a while. I remain unconvinced it was a wise idea.
- lelanthran 4y ago
  What is ASI?
  - mikewhy 4y ago
    "Automatic semicolon insertion": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
currysausage 4y ago
You have to know HTML in order to know where things end. Otherwise, you will see nested paragraphs here: <p>Hello <p>World</p>!</p> when it’s actually two consecutive paragraphs, an exclamation mark outside of any paragraph, and a closing p tag without an opening counterpart. And when you do know HTML, you might as well omit optional tags. If you think that HTML syntax is crazy, I won’t blame you, and you might consider XHTML instead, but you should be prepared for different woes.

sivers 4y ago

Thanks to Aaron for posting this. Such a great reminder. Anyone interested in this subject, check out a series of three very tiny books called “UPGRADE YOUR HTML” by Jens Oliver Meiert. They give great step-by-step examples for eliminating optional tags and attributes, reducing HTML to its cleanest simplest valid form. The author is a super-expert in this specific subject, working with Google and W3C on this. His bio here: https://meiert.com/en/biography/ https://meiert.com/en/biography/ From LeanPub: https://leanpub.com/b/upgrade-your-html-123 https://leanpub.com/b/upgrade-your-html-123 From Amazon: https://www.amazon.com/gp/product/B08NP4GXY2/ https://www.amazon.com/gp/product/B08NP4GXY2/

xaduha 4y ago
> Such a great reminder. Reminder of what? To me this reads like satire, even if it wasn't intended as such.

moralestapia 4y ago

phabricator 4y ago
You should try reading articles before you comment! The author explicitly states why this is perfectly "proper" and why they prefer it.
niconii 4y ago
https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
- moralestapia 4y ago
  >A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element. Whoops! Not in the spec!
  - niconii 4y ago
    What's not in the spec? Every example in the article is valid HTML, and the article itself, which is written in the same style, is valid as well: https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fblog%2Fwrite-html-right https://validator.w3.org/nu/?doc=https%3A%2F%2Flofi.limo%2Fb... > Document checking completed. No errors or warnings to show. Or are you complaining that the rules are too complicated? It's very verbose and explicit because this is a specification, but the basic rule of thumb is that anything that would normally be a block element and thus doesn't make sense inside a paragraph will end that paragraph. In practice, this is not really an issue I run into. Moreover, you need to know about this rule even if you don't omit </p>, because this is the list of elements that implicitly ends a paragraph. For example, <p><div></div></p> is invalid HTML because <div> ends the paragraph implicitly, making it equivalent to <p></p><div></div></p>. If you don't like that, then your problem is not with this particular code style but HTML itself, which is reasonable. HTML's syntax is very complicated due to its history and doesn't always make sense. But you still have to know how it works regardless of how you personally like to write it.

jokoon 4y ago

I'm curious if a more strict html parser would actually be faster. Browsers are not really fast on my Android, and I wish they were fast.

mst 4y ago
Depending on what sites you're mostly accessing, it may be worth experimenting with Firefox Mobile plus uBlock Origin plus perhaps one or more of the extra anti-(ad|bloat)ware extensions. Chrome is definitely faster in a straight line but once I've got Firefox configured it's (to me) significantly more pleasant to use (and I like the current UI better than Chrome's though that's -definitely- not a universal opinion, mileage may vary as ever).
exyi 4y ago
I have yet to see a slow HTML-only website ;) (which is not 10MB single file spec or entire book). Really, I don't think html parsing is a huge bottleneck and these few parser exceptions don't seem to be that hard to implement - just close a tag if opening one of a predefined list, no backtracking or something expensive.

jacobsenscott 4y ago

If you must write html by hand this seems nice. But I would never actually write html by hand anymore. For most web apps you write more tags than text. I love slim because it was designed with that in mind. There is no overhead to writing tags, and just a little for writing text. Which is the right way to go for web apps.

martin_a 4y ago

While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?

aparks517 4y ago
I don’t expect it to as long as the mark-up is valid. Perhaps someone with more SEO knowledge will stop by to correct me.
- martin_a 4y ago
  You're right. HTML5 does not work with DTDs anymore, so unclosed tags are not a violation of the document schema and therefore probably not "punishable" by search engines.
  - anjbe 4y ago
    Implicit end tags as described in the article have been allowed by every HTML DTD not named XHTML.
exyi 4y ago
I have no idea what Google does, but expect their parsers to be quite robust. I tried doing some web scraping, and so many pages are not even valid HTML (most often invalid nested tags, like a table inside span, missing closing tags even when required, random unopened closing tags, ...). Not closing <p> and <td> tags is quite common, I have not seen omitted <html> <head> and <body> yet.

JJMcJ 4y ago

I too found out I'd been doing my shoelaces wrong. YouTube set me straight. For HTML, these are good recommendations. Sometimes, like for technical writing where there are various distinct and important formatting choices, it's just hard work to get it the way you want it even with a WYSIWYG editor.

_glass 4y ago

love the troff reference. I wrote my first CV in troff. mostly because it was available on my linux machine, and working.

irrational 4y ago

This post needs an OCD trigger warning.

ThatIsntOCD 4y ago
"OCD" as in "I don't like clutter" or real OCD as in "if I don't clear away the clutter my family will die in a car crash, I know that's illogical, and yet I'm still encumbered with the intrusive thought?"
- irrational 4y ago
  OCD as in “not having closing tags matching open tags is driving me insane”. Maybe OCD isn’t the proper term, but I don’t know of a better one.
  - ThatIsntOCD 4y ago
    Respectfully, please try to refrain from using OCD casually. It's not like you're the only one, but it's a debilitating disease.
    - irrational 4y ago
      What is a better term to use that means when things are not perfectly matched it drives me so insane that I can't function until I go in there and fix it so that everything is exactly right?

Kazkans 4y ago

Why dont just use groff/troff and output to html?

eatsyourtacos 4y ago

Rite HTML Wright (sorry)

movedx 4y ago

Author: write HTML right Me: this green on black background is terrible to read, I'll use reader mode Chrome: this author did not write their HTML correctly, so there is no reader mode available How ironic.

zzo38computer 4y ago
I use (a old version of) Firefox and can select "View > Page Style > No Style" to disable CSS, and this works OK for me (it is better than some web pages, where this does not work very good, but this one it works good). I do not know what criteria are needed for the reader mode in Chrome. (The HTML code looks OK to me?)
exyi 4y ago
Firefox's reader mode works just fine. You need a right browser for the right HTML. ... anyway, it bothers me sometimes that I'm not aware of any spec for "reader mode compatibility", did anyone see anything like that?
frosted-flakes 4y ago
I think Reader mode looks for a <main> section. When it's not present it either guesses or doesn't work at all.

Voeid 4y ago

Figure 2. showing the "common style" is something I've never used or seen before. What is the "right" way? Perhaps it is to use style from both of these extreme examples and write code that is easy to read and edit for the person that is working with it. Or perhaps the right way is to never imply the way you are doing things is the only correct way and then try to pass it on as facts?

iostream24 4y ago

At this point you are better off making a DSL that compiles to html. - it will be possible to be consistent with closing tags or not - you can do other arbitrary things to improve your working experience with it Ever tried Slang styled templates?

boringuser1 4y ago

epolanski 4y ago

Slightly off topic but I'd like to point out that paragraphs in HTML are grouping not textual elements. They are like divs or headers, not like span or b. They are mistakenly and traditionally associated with literature-type paragraphs but that is not correct. You generally use them in forms to split different groups or inputs, that has nothing with paragraphs of a written form and even less with textual paragraphs. I think there is really a lot of confusion about them in this whole thread.

niconii 4y ago
Although there are some other uses for <p>, it is perfectly valid to use <p> tags for textual paragraphs and that has been the main use for <p> for as long as HTML has existed. I'm not sure why you believe otherwise. Take a look at the source code for http://info.cern.ch/hypertext/WWW/MarkUp/Future.html http://info.cern.ch/hypertext/WWW/MarkUp/Future.html for instance, which was written by the creator of HTML, Tim Berners-Lee. You can also look at the source code for any page of the current HTML spec (e.g. https://html.spec.whatwg.org/multipage/introduction.html https://html.spec.whatwg.org/multipage/introduction.html) where, again, <p> is used for each paragraph in the text.
- epolanski 4y ago
  I didn't say it's not a valid use, I said that it's not it's primary use. Paragraphs relate to grouping content[1], not textual one. There's no logic in paragraphs. I quote here the official spec, which makes various examples of how paragraphs are not related to logical paragraphs: > The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list. And I'll quote also the definition on MDN: > The <p> HTML element represents a paragraph. Paragraphs are usually represented in visual media as blocks of text separated from adjacent blocks by blank lines and/or first-line indentation, but HTML paragraphs can be any structural grouping of related content, such as images or form fields. Failing to realize that paragraphs are grouping rather than logical content leads to frequent misuses of paragraphs and this comment section is literally filled by bad paragraphs examples which suggests the community is largely ignorant on html. [1]https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element https://html.spec.whatwg.org/multipage/grouping-content.html...

zeven7 4y ago

I like this idea. As someone who argued vehemently for XHTML a couple decades ago (even wrote a fair amount of XSLT in those XML-crazed days), who's been wandering between different levels of "how strict should I be?" since that time, this article marks the step of my journey where I feel like I can really embrace the goodness that SGML has to offer for the first time. So thank you. This article has changed me.

nhooyr 4y ago

> It used to be the case that URL parsers would remove newlines and tabs, so we could split long URLs across lines and even format their query parameters nicely with tabs. Unfortunately, this was taken advantage of for data exfiltration via HTML injection and we no longer have this nice thing as URL parsers have been made more strict to prevent this kind of attack. Does anyone have a source/reference for this?

mekster 4y ago

HTML can't be fixed with a small trick like that. Just use templating engine like Pug and get away with most of the annoyances. It's concise about what part of the text is covered by a certain tag due to forced indentation, not to mention you'll never need to close any tag and you never write "class=" but are all turned into CSS selector notation among many other tricks. https://github.com/pugjs/pug#syntax https://github.com/pugjs/pug#syntax Unless the HTML I'm composing will be touched by people like designers who would get scared of new syntax, in which case I'll use Twig or Nunjucks, I'll never write plain HTML for myself. There's also a very solid implementation in PHP as well. https://github.com/pug-php/pug https://github.com/pug-php/pug You can either let server side (node.js or PHP) compile that on demand or let your editors compile them as you edit if you're working on a static file. I really think the language humans write should deviate from the language the runtimes understand to get all the convenience while never breaking how runtimes/crawlers interpret your output. Same goes for Stylus against CSS.

moreati 4y ago

Is there a tool to convert an existing HTML document into this style? E.g. strip out optional closing tags, without doing full minimisation/whitespace stripping.

account42 4y ago

> However, any content which cannot go in a p element (most other block-display elements, for example) implies the end of its content, so we can usually leave off the end tag. Note however that this means that the whitespace between paragraphs will be part of the paragraph which can be annoying if someone tries to copy the text on your website and gets an additional space after each paragraph which wouldn't have happened if you explicitly closed the </p> directly after the text. Also, you should keep the opening <html> and specify the language of your document even for english since e.g. automatic hyphenation does not work if you don't specify a language. Otherwise really like this condensed HTML style and have recently converted my personal website to it.