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

181–190 of 212 posts

Re: Write HTML Right

#181

Post by mekster »

HTML can't be fixed with a small trick like that.

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.

Re: Write HTML Right

#182

Post by anjbe »

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.

You misunderstand the spec. Exactly what confuses you is hard to discern, but perhaps you misread “the p element” as referring to the

start tag, when in fact the element includes the start tag, text contents, and (if present) the end tag.

Re: Write HTML Right

#183

Post by anjbe »

epolanski wrote: post #169
progval wrote: post #168

Earlier quoted context omitted.

> give me XHTML You can still use XHTML; just send "Content-Type: application/xhtml+xml". You can express the same things as an HTML document, but with a saner parser mode.

What is saner parser mode?

In this context (although I would dispute calling it “saner,” as someone who was fully on board the XHTML train a decade ago), an XML parser, which among other things enforces that the markup is “well‐formed” by the XML definition, thus prohibiting implicit closing tags and unquoted attributes.

Re: Write HTML Right

#184

Post by chrismorgan »

jokoon wrote: post #88
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…

Are more strict html parsers/renderers, and aren't they faster?

To you and all that have responded: there is no variation in HTML parsing between browsers. All engines are using precisely the same exhaustively-defined algorithm. There is no leniency or strictness. Their performance characteristics may differ outside of parsing, which includes what they do with the result of parsing, but in the parsing itself there should be basically no difference between engines or parsers.

Re: Write HTML Right

#185

Post by chrismorgan »

progval wrote: post #168
exyi wrote: post #153

Earlier quoted context omitted.

You can't disable this "feature", so you still don't know where things end / begin. Some tags can't be nested in while you could expect that they can: Paragraph with a list won't work as you could think Test Something else Parses to: Paragraph with a list won't work as you could think Test Something else Similarly, in JS you are paying the price for optional semicolons even if you decide to use them. return { x: 1 };…

> give me XHTML You can still use XHTML; just send "Content-Type: application/xhtml+xml". You can express the same things as an HTML document, but with a saner parser mode.

> You can express the same things as an HTML document

This is not quite true. There are a number of mutual incompatibilities between the XML and HTML syntaxes at both parse and run time.

At parse time, it’s mostly in the direction of XML syntax making things possible (e.g. nesting paragraphs or links, which the HTML parser prevents), but also in the other direction (e.g. has no effect in XML syntax since it’s essentially an HTML parser instruction); you’ve also got case sensitivity which matters for SVG; and there’s the matter of the contents of and elements and their handling of &, where the best but still imperfect solution is a crazy mix of XML comments, JavaScript/CSS comments and XML CDATA markers. (See https://www.w3.org/TR/html-polyglot/ for more details of all this kind of stuff.)

At run time, behaviour changes in such a way that it will break some JavaScript libraries, due to differences like .tagName being lowercase instead of uppercase, and .innerHTML requiring and producing XML syntax.

Re: Write HTML Right

#186

Post by minitech »

exyi wrote: post #153
timw4mail wrote: post #80

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 while you could expect that they can: Paragraph with a list won't work as you could think Test Something else Parses to: Paragraph with a list won't work as you could think Test Something else Similarly, in JS you are paying the price for optional semicolons even if you decide to use them. return { x: 1 };…

> JS is not worse than Python with [its] basic inference

JS semicolon insertion is worse, because it depends on the following line. In Python, an unescaped newline outside of brackets always ends the statement, but in JavaScript, parentheses, brackets, binary operators, and template literals on the following line change that. The Python rule also makes a dangling operator outside of brackets a syntax error, which is a potential source of unintentional introduction of ASI when making changes to code in JavaScript.

Re: Write HTML Right

#187

Post by chrismorgan »

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

HTML parsing is exhaustively defined, so there’s not any filling of gaps, but only rules to be aware of. If you don’t know those rules, this may be error-prone, but if you do, it’s not, and things like the start and end tag omissions discussed in the article are quite straightforward rules to learn.

Re: Write HTML Right

#188

Post by leonsegal »

epolanski wrote: post #170
Ontonator wrote: post #163

Earlier quoted context omitted.

On the point about semicolons in JavaScript, the logic I’ve heard is that if you consistently use semicolons, you can have a linter warn you if there is an inferred semicolon, so you know if you have made a mistake. If you don’t use semicolons and accidentally produce code with an inferred semicolon that should not be there, then there is no way for any tool to warn you. (Well, no general way; in your example with th…

I never use semicolons and I never have these issues. Even in the rarest cases I maybe had them like when copy pasting in the wrong place they were so rare that I don't think it's worth the additional noise of semicolons.

There are 3 major footguns with automatic semicolon insertion iirc (one involves having the return statement on its own line. As long as you know them all it's fine I guess, but not my taste.

Re: Write HTML Right

#189

Post by Thiez »

galaxyLogic wrote: post #180
throwaway894345 wrote: post #140

Earlier quoted context omitted.

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

I can't really be bothered to take a look at the tests, but I strongly doubt there are actually 500 features. A large part of those tests are probably trying combinations of features. E.g. suppose markdown only had tables as a feature, and nothing else. That feature alone deserves several several tests (for tables of various sizes, edge cases such as having only the header, having rows with an incorrect number of columns, etc.).

But let's assume we can get away with just a single test for tables. And then we introduce the features "section headers" and "bold" and "underline". All these features can interact (e.g. underlined bold section headers), so we want to test combinations of all those features, and have a nice combinatorial explosion.

Re: Write HTML Right

#190

Post by epolanski »

niconii wrote: post #174
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…

I didn't say it's not a valid use, I said that it's not it's primary use.

Paragraphs relate to grouping content[1], not textual one. There's no logic in paragraphs.

I quote here the official spec, which makes various examples of how paragraphs are not related to logical paragraphs:

> The solution is to realize that a paragraph, in HTML terms, is not a logical concept, but a structural one. In the fantastic example above, there are actually five paragraphs as defined by this specification: one before the list, one for each bullet, and one after the list.

And I'll quote also the definition on MDN:

> The

HTML element represents a paragraph. Paragraphs are usually represented in visual media as blocks of text separated from adjacent blocks by blank lines and/or first-line indentation, but HTML paragraphs can be any structural grouping of related content, such as images or form fields.

Failing to realize that paragraphs are grouping rather than logical content leads to frequent misuses of paragraphs and this comment section is literally filled by bad paragraphs examples which suggests the community is largely ignorant on html.

[1]https://html.spec.whatwg.org/multipage/grouping-content.html...

Post reply on HN