131–140 of 212 posts
While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?
Earlier quoted context omitted.
Is there a standard definition for the "Markdown" -language? There are several for HTML different versions and it is standardized that you can omit some closing tags and some tags altogether. The benefit of writing in a standardized language is that later you or anybody can run tools against your sources that check for conformity. So that is why I prefer HTML. But I would like to hear your opinion on what is the best…
Yes, CommonMark is a standard with implementations in many different languages.
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?
Earlier quoted context omitted.
Sure, but the author is advocating that you compose HTML this way. It would quickly become a mess of nested elements with zero visual indication of hierarchy. The DOM is a tree, with nested elements. Losing that information doesn't get you anything but tag soup (which is, oddly, what the author suggests this style is supposed to avoid)
First and foremost, the author advocates for organising documents in a much flatter DOM tree. In this style all major page elements sit at the same hierarchical level, so there is no "mess of nested elements", the is no need for visual indication of hierarchy if there is no hierarchy to begin with. I think that is a very compelling format for a text-first web page, like a blog post or news article. Of course it is a…
http://info.cern.ch/hypertext/WWW/MarkUp/HTMLConstraints.htm...
Earlier quoted context omitted.
This is the output of an app/templating system, i.e. not a single HTML page. Have you ever read the HTML of any dynamically generated page? It's unreadable.
> Have you ever read the HTML of any dynamically generated page? It's unreadable. Not with that attidude... if you write consistently and with intention, it turns out just fine. Check out the source for https://try.nodebb.org , for example. Dynamically generated, (mostly) syntactically correct, (mostly) human readable.
(sorry)
Earlier quoted context omitted.
The "Tables are Harmful" club largely came from the crew who thinks HTML carries lots of semantics and that if you don't use the Blessed Tags that carry those semantics you're doing Bad Design. The rational evidence in favor of this claim has always been weak. The "div" tag basically finished it off. The people who use HTML "semantically" have always been dwarfed by the people just making it look good on the screen,…
> the idea persists to this day despite its near complete failure to pay off significantly in nearly twenty years I am not clear on exactly what "the idea" refers to, perhaps you could clarify. Also, how has the idea "completely failed"? And what would complete success look like?
As it stands now, it's very practical to just slap some s down and do some CSS and be done.
Earlier quoted context omitted.
I can't verify your numbers. As far as I can tell, loading a ~900,000 word document with no other differences than including or excluding has about the same load time, though there's too much variance from load to load for me to really give definitive numbers. Are you sure you converted it properly? I'd expect those kinds of numbers if your elements were very deeply nested by mistake (e.g. omitting tags where it's no…
For five runs, on the same hardware with the same load: + Unclosed: 4.00s, 3.91s, 3.59s, 4.45s, 3.93s + Closed: 3.90s, 2.74s, 3.9s, 2.05s, 3.39s Though I'd note that the newline you have immediately following the paragraph, even when closing, would probably reduce the backtracking effect. And having no explicit body or head element would probably cause some different rendering patterns as well.
And, spoiler alert: after repeated runs I'm not seeing any substantial difference between these test pages. And based on how the HTML parser works, I wouldn't expect it.
(I work on web performance on the Chrome team)
Earlier quoted context omitted.
The "Tables are Harmful" club largely came from the crew who thinks HTML carries lots of semantics and that if you don't use the Blessed Tags that carry those semantics you're doing Bad Design. The rational evidence in favor of this claim has always been weak. The "div" tag basically finished it off. The people who use HTML "semantically" have always been dwarfed by the people just making it look good on the screen,…
Obnoxiously bad take. > Google info boxes[...] have nothing to do with the semantic web and everything to do with Google throwing a crapton of machine learning and humans at the problem of parsing distinctly non-semantic HTML until they cracked the problem This is verging on /r/SelfAwarewolves material.
Which is why it is bizarrely unselfaware when Semantic Web advocates almost inevitably cite that as their biggest success. It isn't. It's their biggest failure.
Earlier quoted context omitted.
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 th…
Agreed. That's why I prefer to have things written down. In this case, WHATWG and W3C already did the work for us.
> And if you've ever felt overbooked on a project while other people are idle?
I've seen what you're talking about, but I'm not the one getting overbooked. I'm not generally the one fighting over this stuff. If I get feedback on a PR telling me to add li close tags, I'll probably just do it.
If you're using a technology on a daily basis, it will pay big dividends to spend a little time learning how it actually works.
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 )
I claimed the specification existed, I didn’t claim it was a simple specification.