Earlier quoted context omitted.
What’s a TFA?
The Fine(or Fucking) Article
The "F" has always been "Forementioned" for me.
Write HTML Right
141–150 of 212 posts
Re: Write HTML Right
#142Earlier quoted context omitted.
Are more strict html parsers/renderers, and aren't they faster?
Lenient parsers still benefit from strict input because it lets them avoid lookaround/backtracking.
What do you mean by lookaround/backtracking? You're inside
. You encounter another
. You can't nest one
inside another
, so you close current
and open new
. That's about it. I fail to see where do you need any kind of backtracking.
Re: Write HTML Right
#143This works for blog posts, where the body of the document is one long block of paragraphs, but I suspect this style would quickly become untenable for complex apps. Indentation _is_ information, which is lost here.
[deleted]
Re: Write HTML Right
#144Author: write HTML right
Me: this green on black background is terrible to read, I'll use reader mode
Chrome: this author did not write their HTML correctly, so there is no reader mode available
How ironic.
Re: Write HTML Right
#145Why dont just use groff/troff and output to html?
Re: Write HTML Right
#146No 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.
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.
Re: Write HTML Right
#147Earlier quoted context omitted.
Well this sounds like really interesting observation. May I ask where exactly were the original closing tags located and how the stripped source looked like? I can imagine there _might_ be some differences among differently formatted code: e.g. I'd expect Content Content[EOF fig1] to be (slightly) slower, than Content Content [EOF fig2] (most likely because of some "backtracking" when hitting ` ]`), or Content Conten…
It was just paragraphs of text. p, strong, em, and q mingled at most. No figures or images or anything of the like to radically shift DOM computations. That the effect can even be seen is probably due to the scale of the document, as I noted it's a little larger than most things. All paragraphs had a blank line between them, both with and without the p end tag. The p opening tag was always at the top-left, with no ga…
Yay, thanks for info and inspiration, sure it seems like fun weekend project.
(BTW your snippet's content sounds interesting and feels relatable, definitely intrigued.)
Re: Write HTML Right
#148Earlier quoted context omitted.
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…
At first, I thought people would respect the issue template. In practice, very few do, even when a proper bug is reported. I completely agree with you but it seems to be a losing battle. So I just deal with these kinds of cases according to my mood. Concerning the bug #967, maybe I was not angry enough. Overall, the atmosphere on the bug tracker is fortunately very positive.
I think having one set of fairly clear and complete polite responses to the question to then be linked from elsewhere (or possibly turned into an FAQ ... and then linked to when people inevitably don't spot it in the FAQ before opening an issue ;) is probably a net win in terms of maintaining a positive atmosphere on your bug tracker.
Re: Write HTML Right
#149No 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 have to know HTML in order to know where things end. Otherwise, you will see nested paragraphs here:
Hello
World
!
And when you do know HTML, you might as well omit optional tags.
If you think that HTML syntax is crazy, I won’t blame you, and you might consider XHTML instead, but you should be prepared for different woes.
Re: Write HTML Right
#150I'm curious if a more strict html parser would actually be faster. Browsers are not really fast on my Android, and I wish they were fast.
Depending on what sites you're mostly accessing, it may be worth experimenting with Firefox Mobile plus uBlock Origin plus perhaps one or more of the extra anti-(ad|bloat)ware extensions. Chrome is definitely faster in a straight line but once I've got Firefox configured it's (to me) significantly more pleasant to use (and I like the current UI better than Chrome's though that's -definitely- not a universal opinion, mileage may vary as ever).