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.
I can't verify your numbers. As far as I can tell, loading a ~900,000 word document with no other differences than including or excluding </p> has about the same load time, though there's too much variance from load to load for me to really give definitive numbers.
Are you sure you converted it properly? I'd expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it's not valid to do so), but I don't see why leaving out </p> should be so slow.
Well this sounds like really interesting observation. May I ask where exactly were the original closing tags located and how the stripped source looked like? I can imagine there _might_ be some differences among differently formatted code: e.g. I'd expect
<p>Content<p>Content[EOF fig1]
to be (slightly) slower, than
<p>Content</p><p>Content</p>[EOF fig2]
(most likely because of some "backtracking" when hitting `<p[>]`), or
<p>Content</p>
<p>Content</p>[EOF fig3]
(with that that small insignificant `\n` text node between paragraph nodes), what should be possibly faster than "the worst scenarios":
<p>Content
<p>Content[EOF fig4a]
or even
<p>
Content
<p>
Content
[EOF fig4b]
with paragraph text nodes `["Content\n","Content]"` / `["\nContent\n","\nContent\n]"`, where the "\n" must be also preserved in the DOM but due white-space collapsing rules not present in the render tree (if not overridden by some non-default CSS) but still with backtracking, that
<p>Content
</p>
<p>Content
</p>[EOF fig5]
should eliminate (again, similarly to fig2 vs fig1).
(Sorry for wildly biased guesswork, worthless without measurements.)
That’s interesting, but surely relying on user agent to ‘fill in the gaps’ is error prone? Surely transpiling prior or during render would be more resilient than trusting browser behaviour
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.
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.
You can't disable this "feature", so you still don't know where things end / begin. Some tags can't be nested in <p> while you could expect that they can:
<p>
Paragraph with a list won't work as you could think
<ul> <li> Test </li> </ul>
Something else
</p>
Parses to:
<p>
Paragraph with a list won't work as you could think
</p>
<ul> <li> Test </li> </ul>
Something else
<p></p>
Similarly, in JS you are paying the price for optional semicolons even if you decide to use them.
return
{
x: 1
};
Will still not work even if you use semicolons elsewhere. So I don't see any advantage to actually using semicolons. JS is not worse than Python with it's basic inference, and yet in Python people will almost yell at you if you attempt to use a semicolon :)
I'd much prefer these features to be opt-in (yea, give me XHTML back for generated content). But when I can't can't disable them, why not embrace them ;)
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.
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.
it doesn't work for even slightly complex documents either. there's been a little meme-fad lately around minimalistic html like this, but to claim it's the "right" way to write html is pompous at best.
not closing tags for instance is really asking for future headaches. sure, it works for a simple text list, but not when it gets even a little complicated (add links, images, buttons, etc.). even worse are p tags, where you have to memorize a whole matrix of what it can contain and what breaks out implicitly. with every insertion/deletion, you need to check the list. it's needless mental drag.
I've been using this style - with some tweaks - for web apps too. I don't think I have it completely figured out yet, but it's promising so far. You can view the source of http://lofi.limo/ to see how it's working out.
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.
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.
> 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?
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
Granny knots untie themselves and the bow will end up perpendicular to the knot instead of parallel.
> 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.
Not sure what he's referring to, I'm not familiar with the parallel posts. I just do the "rotate around the loop" part twice. I have had untied shoelace approximately twice in the last 5 years.
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 :)
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/
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.
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.
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.
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.
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.
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.
> 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.
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
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.
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.
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?
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
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?)
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.
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.
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.
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.
> 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.
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?
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.
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.
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.
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.
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).
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.
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.
"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?"
Similar mindset that drives people to create HTML-targeting template languages that use indentation rather than surrounding tags, to indicate nesting. Maybe fine in some limited cases but it'll bite you in the ass eventually.
shakna|3 years ago
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.
niconii|3 years ago
Are you sure you converted it properly? I'd expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it's not valid to do so), but I don't see why leaving out </p> should be so slow.
Try these two pages:
https://niconii.github.io/lorem-unclosed.html
https://niconii.github.io/lorem-closed.html
myfonj|3 years ago
(Sorry for wildly biased guesswork, worthless without measurements.)
toqy|3 years ago
But then if you run it through Prettier it'll add all the closing tags for you :)
unknown|3 years ago
[deleted]
jokoon|3 years ago
hsbauauvhabzb|3 years ago
myfonj|3 years ago
[1] https://adrianroselli.com/2015/01/on-use-of-lang-attribute.h...
timw4mail|3 years ago
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.
exyi|3 years ago
I'd much prefer these features to be opt-in (yea, give me XHTML back for generated content). But when I can't can't disable them, why not embrace them ;)
iamben|3 years ago
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.
currysausage|3 years ago
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.
mst|3 years ago
I remain unconvinced it was a wise idea.
robgibbons|3 years ago
clairity|3 years ago
not closing tags for instance is really asking for future headaches. sure, it works for a simple text list, but not when it gets even a little complicated (add links, images, buttons, etc.). even worse are p tags, where you have to memorize a whole matrix of what it can contain and what breaks out implicitly. with every insertion/deletion, you need to check the list. it's needless mental drag.
aparks517|3 years ago
unknown|3 years ago
[deleted]
egeozcan|3 years ago
Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.
jahewson|3 years ago
pwdisswordfish9|3 years ago
btrettel|3 years ago
So instead of this:
I can write: (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://news.ycombinator.com/item?id=4642395
http://www.uvm.edu/pdodds/writings/2015-05-13better-writing-...
pronoiac|3 years ago
buzzy_hacker|3 years ago
I’m equally interested in this as the HTML. Any clue what the author is referring to?
js2|3 years ago
https://www.fieggen.com/shoelace/
Specifically:
https://www.fieggen.com/shoelace/grannyknot.htm
An HN favorite:
https://news.ycombinator.com/from?site=fieggen.com
1. https://xkcd.com/1053/
SpaceNugget|3 years ago
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
Granny knots untie themselves and the bow will end up perpendicular to the knot instead of parallel.
aparks517|3 years ago
> 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.
jjice|3 years ago
You look goofy trying to relearn to tie your shoes, but it really is fast and sturdy.
MindTwister|3 years ago
exyi|3 years ago
kuschku|3 years ago
Legion|3 years ago
sivers|3 years ago
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/
From LeanPub: https://leanpub.com/b/upgrade-your-html-123
From Amazon: https://www.amazon.com/gp/product/B08NP4GXY2/
xaduha|3 years ago
Reminder of what? To me this reads like satire, even if it wasn't intended as such.
gildas|3 years ago
isp|3 years ago
(Also: a huge thank you for creating SingleFile. One of my favourite extensions of all time.)
sph|3 years ago
Pretty neat extension!
iostream24|3 years ago
- 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?
zeven7|3 years ago
sylware|3 years ago
Julesman|3 years ago
dasil003|3 years ago
aparks517|3 years ago
I wouldn't mind if we had a bunch more basic content documents on the web.
mekster|3 years ago
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
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
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.
account42|3 years ago
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.
andrew_|3 years ago
pineconewarrior|3 years ago
It causes way more trouble than those benefits are worth
nayuki|3 years ago
jacobsenscott|3 years ago
spread_love|3 years ago
JasonFruit|3 years ago
movedx|3 years ago
How ironic.
exyi|3 years ago
... anyway, it bothers me sometimes that I'm not aware of any spec for "reader mode compatibility", did anyone see anything like that?
zzo38computer|3 years ago
I do not know what criteria are needed for the reader mode in Chrome. (The HTML code looks OK to me?)
frosted-flakes|3 years ago
moreati|3 years ago
DustinBrett|3 years ago
After reading the connected blog post http://perfectionkills.com/experimenting-with-html-minifier/
epolanski|3 years ago
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|3 years ago
Take a look at the source code for 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) where, again, <p> is used for each paragraph in the text.
layer8|3 years ago
What do they mean here?
aparks517|3 years ago
nhooyr|3 years ago
Does anyone have a source/reference for this?
Kazkans|3 years ago
Voeid|3 years ago
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?
JJMcJ|3 years ago
For HTML, these are good recommendations.
Sometimes, like for technical writing where there are
distinct and important formatting choices, it's just hard work to get it the way you want it even with a WYSIWYG editor.exodust|3 years ago
recursive|3 years ago
martin_a|3 years ago
exyi|3 years ago
aparks517|3 years ago
tiffanyh|3 years ago
jokoon|3 years ago
Browsers are not really fast on my Android, and I wish they were fast.
exyi|3 years ago
mst|3 years ago
_glass|3 years ago
iLoveOncall|3 years ago
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|3 years ago
EugeneOZ|3 years ago
anjbe|3 years ago
Do you consider any table that doesn’t explicitly declare <tbody> “unclean”? That’s an implicit element in every <table>, according to the spec.
enriquto|3 years ago
irrational|3 years ago
ThatIsntOCD|3 years ago
eatsyourtacos|3 years ago
(sorry)
math_dandy|3 years ago
boringuser1|3 years ago
[deleted]
moralestapia|3 years ago
[deleted]
anjbe|3 years ago
phabricator|3 years ago
niconii|3 years ago
corrral|3 years ago