Why is he bragging about being awful at web dev? tags exist for a reason. You're not cool for omitting them, you're hurting your users.
My browser doesn't allow the switch to read mode, for example.
Next Gen Static Blogging
171–179 of 179 posts
Re: Next Gen Static Blogging
#172Earlier quoted context omitted.
And since we’re talking about optional things: Trailing slashes on HTML tags are useless. They’re allowed on void elements, for XML compatibility, but are by definition simply ignored. I recommend against including them, because they’re simple visual noise, and misleading because they don’t actually close tags—you can only use them on on elements that are defined as having no children. (Note that I say HTML tags; on…
They're optional in the same way that braces around single-statement "if" clauses are optional in most curly brace languages—and indentation, for that matter—i.e. they still serve a purpose for many humans who are going to be tasked with upkeep and will choose to include them for personal reasons. Not every decision is rooted in trying to satisfy the machine. But speaking of machines, on that note... If you ever have…
I do think there’s an important difference from the optionality of curly braces on if statements in many languages: syntax highlighting will normally make it very obvious what is attribute name and what is attribute value, so that any error will be obvious, more obvious than the probable incorrectness of something like `if (a) b; c;` on one line.
Your point on HTML processing is a nice idea, but quite useless in practice for HTML. XHTML failed: people didn’t want to go to the effort of getting it all rigorously correct; they rather wanted the browser to guess what they meant, because it got their intent right most of the time, and now they could forget about various details like tbody elements and trailing slashes. I regularly look at page sources, and I regularly encounter people putting these trailing slashes on various void element; but I can’t remember when I last found a page that actually applied that consistently—invariably they have at least one void element without a trailing slash. My conclusion is that the whole thing is misguided. I would be curious to see the result of attempting to parse all the HTML in something like Common Crawl with an XML parser. I suspect that barely any pages would succeed.
The fact of the matter is that the HTML parsing algorithm is well-defined and very nuanced, so if you’re processing HTML you should use a real HTML parser, and to do anything else is folly—unless you are assiduous about maintaining XML correctness, which you can do, but it’ll be even more of a footgun for others than omitting quotes on attribute values. But if you’re writing something new, then by all means, strongly consider the comparatively simple and principled XML philosophy over the organic and complicated philosophies of the HTML serialisation.
Re: Next Gen Static Blogging
#173Earlier quoted context omitted.
They're optional in the same way that braces around single-statement "if" clauses are optional in most curly brace languages—and indentation, for that matter—i.e. they still serve a purpose for many humans who are going to be tasked with upkeep and will choose to include them for personal reasons. Not every decision is rooted in trying to satisfy the machine. But speaking of machines, on that note... If you ever have…
I do think there’s an important difference from the optionality of curly braces on if statements in many languages: syntax highlighting will normally make it very obvious what is attribute name and what is attribute value, so that any error will be obvious, more obvious than the probable incorrectness of something like `if (a) b; c;` on one line. Your point on HTML processing is a nice idea , but quite useless in pra…
This comment comes off as very, very, very... weird. A little condescension and a lot of pretending that the goalposts are there when before they were here (and still are, too); almost no "situational awareness" or acknowledgement of the actual context, constraints, and motivation behind making a choice about what to do. Syntax highlighting (esp. for attributes[???]) has _nothing_ to do with what we're talking about (trailing slashes, void elements), for example—and it gets worse from there.
The logical coherence of this response is in "not even wrong" territory.
Re: Next Gen Static Blogging
#174Earlier quoted context omitted.
Yeah, fine. The tool is broken. Right. But YOU have still an issue. The Point is: There a lot of broken tools out there, and you can't know which of them will be used in the future. Just avoid a lot of headaches for your future self and your colleges by not testing out the spec-compliance of all those tools you'll probably use at some point.
> But YOU have still an issue. I disagree. > There a lot of broken tools out there A tool that incorrectly handles optional tags may handle other parts of the spec incorrectly too. Such a tool may provide incorrect results for even perfectly well-written HTML. There is no know what it takes to make all the broken parsers out there happy. I know you made a point about ETL tools[1] where XML parsers are used to parse H…
Most of the "plenty of good HTML5 parsers out there" are broken. No wonder as the spec is nuts. (It took years before there was even a correctly working validator).
Also I was explicitly talking about XML compatible HTML. It's called so because it's XML compatible.
Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)
Re: Next Gen Static Blogging
#175Note that closing tags are optional † , so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this: Lorem Ipsum Lorem Ipsum Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis id maximus tortor. Sed nisi ante, fermentum vel nunc et, tincidunt sagittis magna. In ultrices commodo lacus, id tristique ipsum euismod laoreet. Maecenas at neque posuere, aliquet era…
> † These tags
Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
Re: Next Gen Static Blogging
#176Earlier quoted context omitted.
> But YOU have still an issue. I disagree. > There a lot of broken tools out there A tool that incorrectly handles optional tags may handle other parts of the spec incorrectly too. Such a tool may provide incorrect results for even perfectly well-written HTML. There is no know what it takes to make all the broken parsers out there happy. I know you made a point about ETL tools[1] where XML parsers are used to parse H…
Most of the "plenty of good HTML5 parsers out there" are broken. No wonder as the spec is nuts. (It took years before there was even a correctly working validator). Also I was explicitly talking about XML compatible HTML. It's called so because it's XML compatible. Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)
> Most of the "plenty of good HTML5 parsers out there" are broken.
Can you name a few popular and widely used HTML5 parsers that are broken and tell us what the bugs are in those parsers? I would be surprised if you can find or name even two such parsers that are popular but cannot handle optional tags correctly as required by the spec.
> Also I was explicitly talking about XML compatible HTML.
There is no such thing as XML compatible HTML (unless you mean XHTML which we are not discussing here). Maybe you mean XML-serialized HTML5. I can only guess since the terminology you are using is vague and unclear. In any case, HTML5 by itself is incompatible with XML. I mentioned this in my previous comment. Not all tags in HTML5 are self-closing, thus incompatible with XML. XML-serialized HTML5 is however compatible with XML, by definition, and in that case, one would use an XML parser, not an HTML5 parser. More importantly, you can safely omit the optional tags and still convert your HTML5 document into XML-serialized HTML5 document without any issues whatsoever. This was explained to you by anjbe here at https://news.ycombinator.com/item?id=25706163. He is absolutely right.
> Btw, have you ever seen HTML in the web browser dev tools? Guess why it shows always the "optional" tags. ;-)
You see all the tags there because it shows the entire DOM. The browser automatically creates the elements when optional tags are not explicitly present in the HTML. This is all spelled out in the spec very clearly. Any HTML5 parser worth its name follows the spec. I am not sure what your point is here.
See https://html.spec.whatwg.org/multipage/syntax.html#optional-... for details, especially:
"Omitting an element's start tag in the situations described below does not mean the element is not present; it is implied, but it is still there. For example, an HTML document always has a root html element, even if the string doesn't appear anywhere in the markup."
I hope that explains why you always see the elements for the optional tags in a web browser's developer tools.
Re: Next Gen Static Blogging
#177Earlier quoted context omitted.
I am not a frontend developer. I agree with you. I write my blog posts with handwritten HTML because that is how I began writing blog posts many years ago when Markdown was not as popular as it is now. Indeed I never omit any optional tags while writing my blog posts or blog layout. I am not necessarily recommending that one should omit the optional tags. However, it is worth noting that the option to do so while con…
> Indeed I never omit any optional tags while writing my blog posts or blog layout. Do you type every time you write a table? That is an optional implicit tag that can be left out just like , , and .
I don't type and . I believe that's an exception to the practice of never omitting optional tags. Maybe there are a few more exceptions like that but none that I can remember right now. Thanks for posting this comment. It made me realize that my previous claim was inaccurate.
Re: Next Gen Static Blogging
#178I ran to my desktop to load this up and have a look. I'm ALWAYS looking for a more simple blogging solution. I was hoping for mostly plain text plus an em tag here or there. It's a little more involved than that, but it's given me some ideas. Shameless plug, I created the NeatCSS framework to have this "simple" look and feel. On that, however, I didn't try to avoid your typical HTML code. https://neat.joeldare.com
> I'm ALWAYS looking for a more simple blogging solution. Why?
I built my first blog on Dokuwiki somewhere around 15 years ago. Since then Markdown has become the standard for text. Dokuwiki also updates a lot and is difficult to move from one server to another.
I'm always on the hunt because I haven't found the perfect solution to replace it yet. I'm convinced it's either plain text (including Markdown) or plain html, but I am not sure I've found the perfect solution.
Today I'm using Markdown hosted on GitHub, but who knows how long I'll use GitHub or if GitLab or BitBucket will work as replacements in the same way.
It's easy to say, "stick with it", but technology changes a lot as the decades begin to pass by.
Re: Next Gen Static Blogging
#179Note that closing tags are optional † , so one can be an HTML purist and still write a decent HTML document with a relatively clean markup like this: Lorem Ipsum Lorem Ipsum Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis id maximus tortor. Sed nisi ante, fermentum vel nunc et, tincidunt sagittis magna. In ultrices commodo lacus, id tristique ipsum euismod laoreet. Maecenas at neque posuere, aliquet era…
> † These tags Could you explain the use of that "cross" symbol, versus what I use normally, [0] [1] etc. ?
The dagger (the typographic name of that symbol) is usually employed as a footnote indicator if an asterisk is already present.