Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write HTML Right

lofi.limo

Post reply on HN
Print view View original

171–180 of 212 posts

Re: Write HTML Right

#171

Post by epolanski »

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.

Re: Write HTML Right

#172

Post by MrVandemar »

pineconewarrior wrote: post #77
andrew_ wrote: 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.

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

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.

Re: Write HTML Right

#173

Post by lolinder »

hsbauauvhabzb wrote: post #167
shakna wrote: 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…

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

If you're in a situation where resilience against odd browser quirks matters, you probably shouldn't be writing HTML like this anyway. This style is fine for writing HTML for a blog. For any kind of application, it would be a nightmare to try to maintain.

Every time the author introduced a shorthand, they had to clarify that it works only in specific situations. The result of those qualifiers is that you will have to have some code written in the more verbose style anyway. Context switching between those styles and having to decide whether the shorthand works in any given case just isn't worth it on a large project that you'll be making changes to over time.

Re: Write HTML Right

#174

Post by niconii »

epolanski wrote: post #171

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

Although there are some other uses for

, it is perfectly valid to use

tags for textual paragraphs and that has been the main use for

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

is used for each paragraph in the text.

Re: Write HTML Right

#175

Post by moralestapia »

niconii wrote: post #166
moralestapia wrote: post #162

Earlier quoted context omitted.

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

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%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 thu…

Read the quoted sentence again (from the source you brought here), none of those clauses apply to:

Block of text ...

Which is what they do in the article.

Re: Write HTML Right

#176

Post by niconii »

moralestapia wrote: post #175
niconii wrote: post #166

Earlier quoted context omitted.

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%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 thu…

Read the quoted sentence again (from the source you brought here), none of those clauses apply to: Block of text ... Which is what they do in the article.

I don't understand what you mean. Please elaborate.

That quote says that

is not needed in many cases. When you say "none of those clauses apply to

", this is true, you can't omit

, only

... but the blog article doesn't advocate for omitting

at any point.

Re: Write HTML Right

#177

Post by zeven7 »

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.

Re: Write HTML Right

#178

Post by jmalicki »

galaxyLogic wrote: post #132
throwaway894345 wrote: post #119

Earlier quoted context omitted.

Yes, CommonMark is a standard with implementations in many different languages.

That is an interesting development. From their Github page I read: "The spec contains over 500 embedded examples which serve as conformance tests." So it's not so simple any more, is it? ( https://github.com/commonmark/commonmark-spec )

Less than a 1000 conformance tests for a standard? Sounds Pretty simple to me, no way you could make an HTML compliance suite that small.

Re: Write HTML Right

#179

Post by nhooyr »

> 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?

Re: Write HTML Right

#180

Post by galaxyLogic »

throwaway894345 wrote: post #140
galaxyLogic wrote: post #132

Earlier quoted context omitted.

That is an interesting development. From their Github page I read: "The spec contains over 500 embedded examples which serve as conformance tests." So it's not so simple any more, is it? ( https://github.com/commonmark/commonmark-spec )

> So it's not so simple any more, is it? I claimed the specification existed, I didn’t claim it was a simple specification.

I'm not claiming you claimed it was a simple specification :-)

I just find it interesting. This would indicate to me that there are 500 "features" in the language. I thought mark-down languages just provided a few shortcuts for producing the most commonly needed HTML features and then provide a fallback to HTML. So if you cannot do it in the markdown language, use HTML instead.

Post reply on HN