121–130 of 212 posts
For HTML, these are good recommendations.
Sometimes, like for technical writing where there are
various
Earlier quoted context omitted.
Well, one simply formats the source file as you write it. The other requires a infile -> outfile build step that's more complex. Whether the latter is worth it tends to depend on other things than parse time.
Why would I care if one is merely “formatting” or not? If I have to run a tool either way, I would prefer one that accepts a user-friendly input language and decouples content from presentation.
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…
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…
+ 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.
XML is beautiful and clean, and I prefer to write full closing tags.
Do you consider any table that doesn’t explicitly declare “unclean”? That’s an implicit element in every , according to the spec.
Earlier quoted context omitted.
Why would I care if one is merely “formatting” or not? If I have to run a tool either way, I would prefer one that accepts a user-friendly input language and decouples content from presentation.
How does Markdown decouple content from presentation?
Earlier quoted context omitted.
I was hesitating, thanks!
The remarks by the person who opened #967 are beyond frustrating—and it's frustrating to see your responses to them. People putting stuff into the bugtracker that aren't bugs deserve a harsher response. Don't enable "putting stuff into the bugtracker without clearly articulating a defect [in the form of observed behavior versus expected behavior‡]" to be a viable way to interact with a project. Indulging these kinds…
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.
For me, on Firefox on Linux (I know it's the one with the smallest difference, but I don't have the others on hand, sorry), using the "load" time at the bottom of the Network tab, with cache disabled and refreshing with Ctrl+F5, interleaving the tests:
- Unclosed: 1.38s, 1.49s, 1.45s, 1.52s, 1.48s
- Closed: 1.47s, 1.37s, 1.48s, 1.49s, 1.35s
The one with
omitted takes about 0.032s longer on average going by these numbers, but that's about 2 frames of extra latency for a page almost twice the length of The Lord of the Rings.Regarding the page itself, I tried to keep everything else as identical between the two versions as possible, including the DOM, hence why I wrote the
immediately before each. As for backtracking, I'm not sure what you mean. The rule for the parser is simply "If the start tag is one from this list, and there's an open
element on the stack, close the
element before handling the start tag."
Thanks to Aaron for posting this. Such a great reminder. Anyone interested in this subject, check out a series of three very tiny books called “UPGRADE YOUR HTML” by Jens Oliver Meiert. They give great step-by-step examples for eliminating optional tags and attributes, reducing HTML to its cleanest simplest valid form. The author is a super-expert in this specific subject, working with Google and W3C on this. His bio…
Reminder of what? To me this reads like satire, even if it wasn't intended as such.