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.
And not just because of that. In XHTML‐as‐XML, where <div> does not implicitly end the paragraph, what you posted is still invalid because <p> cannot contain <div>.
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.
This is the output of an app/templating system, i.e. not a single HTML page. Have you ever read the HTML of any dynamically generated page? It's unreadable.
All the HTML code in the app I maintain is pretty readable. At some point of complexity any HTML is difficult to parse, but if I hand-wrote a page in my app I think the HTML would be largely the same.
Sure, but the author is advocating that you compose HTML this way. It would quickly become a mess of nested elements with zero visual indication of hierarchy.
The DOM is a tree, with nested elements. Losing that information doesn't get you anything but tag soup (which is, oddly, what the author suggests this style is supposed to avoid)
First and foremost, the author advocates for organising documents in a much flatter DOM tree. In this style all major page elements sit at the same hierarchical level, so there is no "mess of nested elements", the is no need for visual indication of hierarchy if there is no hierarchy to begin with.
I think that is a very compelling format for a text-first web page, like a blog post or news article. Of course it is a coding style not well suited for complex web apps with deep hierarchy.
In a tree you have branches off branches off branches etc.
You can’t orient yourself - you can’t tell where you are - unless you count the branches. And indenting makes that visible.
In the examples for TFA, you can tell your location from the names of the elements. Eg <td> is enough for you to know you’re probably inside a tr inside a table.
And that is the more common case than the general tree example.
But a method of describing html does have to answer the question of how it represents arbitrarily deep nesting. But I like the answers it’s given for the more common case of structures that are not arbitrarily deep.
The problem is that HTML has multiple uses. The author is describing the case of authoring content, with HTML used as a markup language. However a lot of websites and web applications use HTML more like a layout and templating engine for a GUI framework.
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.
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.
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.
<strong> and <em> are the recommended ways to semantically bold and italicize text. <b> and <i> don't have any semantics and can still be used where it makes sense.
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.