Live data from Hacker News

Write HTML Right

lofi.limo

11–20 of 212 posts

Re: Write HTML Right

#11
post #8

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.

> Indentation _is_ information, which is lost here. Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.

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)

Re: Write HTML Right

#12
post #4
post #3

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

Regarding tables, don't use tables. :)

…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.

Re: Write HTML Right

#14
post #8

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.

> Indentation _is_ information, which is lost here. Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.

I don’t think the author means the information-theory kind of information. I could gzip the file without a loss in that kind of information.

Re: Write HTML Right

#15
post #8

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.

> Indentation _is_ information, which is lost here. Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.

Sometimes I indent in a way that my text editor doesn't exactly understand to better state where complex expressions begin and end.

Re: Write HTML Right

#16
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.

Re: Write HTML Right

#17
post #4
post #3

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

Regarding tables, don't use tables. :)

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.

Re: Write HTML Right

#18
post #4

Earlier quoted context omitted.

Regarding tables, don't use tables. :)

…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 Fo…

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.

Re: Write HTML Right

#19

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.

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.

I feel like this style just makes it harder to read and understand the HTML. But hey, if it works for you, great.

Re: Write HTML Right

#20
post #8

Earlier quoted context omitted.

> Indentation _is_ information, which is lost here. Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.

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)

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.
Post reply on HN