161–170 of 212 posts
Earlier quoted context omitted.
I have a tendency to forget ASI in JS exists when I've only been looking at my own code rather than other people's for a while. I remain unconvinced it was a wise idea.
What is ASI?
Quoted post unavailable.
https://html.spec.whatwg.org/multipage/syntax.html#optional-...
Whoops! Not in the spec!
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 };…
- it will be possible to be consistent with closing tags or not
- you can do other arbitrary things to improve your working experience with it
Ever tried Slang styled templates?
Earlier quoted context omitted.
https://html.spec.whatwg.org/multipage/syntax.html#optional-...
>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…
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 thumb is that anything that would normally be a block element and thus doesn't make sense inside a paragraph will end that paragraph. In practice, this is not really an issue I run into.
Moreover, you need to know about this rule even if you don't omit
, because this is the list of elements that implicitly ends a paragraph. For example, is invalid HTML because ends the paragraph implicitly, making it equivalent to .If you don't like that, then your problem is not with this particular code style but HTML itself, which is reasonable. HTML's syntax is very complicated due to its history and doesn't always make sense. But you still have to know how it works regardless of how you personally like to write it.
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…
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 };…
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.
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.
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 };…
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…
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.