Live data from Hacker News

Write HTML Right

lofi.limo

101–110 of 212 posts

Re: Write HTML Right

#101
post #31

Earlier quoted context omitted.

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…

> What really needs to happen it a separation of HTML from UI markup elements

Do you mean CSS? Using , , , etc has been “bad form” for a while (maybe not strong though)

Re: Write HTML Right

#103
post #74

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.

To solve your anxiety, may I suggest XHTML? I use it on my website in practice and it works really well.

Re: Write HTML Right

#104

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

Of course, of course; but here they are talking about HTML (i.e., about HTML5), not about XML.

HTML has a dialect in XML called XHTML. It is obscure but actually works. My website is a living example.

Re: Write HTML Right

#105
post #99

Earlier quoted context omitted.

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, wher…

You have to know about what breaks out of tags regardless of whether or not you leave off the end tag, though. is invalid HTML because ends the paragraph, resulting in an unpaired .

And not just because of that. In XHTML‐as‐XML, where does not implicitly end the paragraph, what you posted is still invalid because

cannot contain .

Re: Write HTML Right

#106
post #28

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.

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

Re: Write HTML Right

#107
post #102

Earlier quoted context omitted.

The Fine(or Fucking) Article

And this terminology (TFA) comes from at least the Slashdot days, about 20 years ago.

In turn, probably descended from “RTFM”—on Slashdot people who commented despite obviously not having read the article were told to “RTFA,” which eventually led to “TFA” as a general term to refer to the original article.

Re: Write HTML Right

#108
post #97
post #54

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

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 Content Content[EOF fig1] to be (slightly) slower, than Content Content [EOF fig2] (most likely because of some "backtracking" when hitting ` ]`), or Content Conten…

It was just paragraphs of text. p, strong, em, and q mingled at most. No figures or images or anything of the like to radically shift DOM computations. That the effect can even be seen is probably due to the scale of the document, as I noted it's a little larger than most things.

All paragraphs had a blank line between them, both with and without the p end tag. The p opening tag was always at the top-left, with no gap between it and the content.

So, for example:

    

Cheats open the doorway for casual play. They make it easier for disabled players to enjoy the same things as their peers, and allow people to skip parts of a game that they bought that they find too difficult.

Unfortunately, cheats are going away, because of extensive online play, and a more corporate approach to developing games that despises anything hidden.

Versus:

    

Cheats open the doorway for casual play. They make it easier for disabled players to enjoy the same things as their peers, and allow people to skip parts of a game that they bought that they find too difficult.

Unfortunately, cheats are going away, because of extensive online play, and a more corporate approach to developing games that despises anything hidden.

(You can also discount CSS from having a major effect. Less than a hundred lines of styles, where most rules are no more complicated than: `p { font-family: sans-serif; }`. No whitespace rules.)

However, if you wanted to look at this in a more scientific way - it should be entirely possible to generate test cases fairly easily, given the simplicity of the text data I saw my results with.

Re: Write HTML Right

#109

Earlier quoted context omitted.

If you’re running it through a processor, why it just write markdown and call it a day?

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.

Why would I care if one is merely “formatting” or not? If I have to run a tool either way, I would prefer one that accepts a user-friendly input language and decouples content from presentation.

Re: Write HTML Right

#110

Quoted post unavailable.

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