Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write HTML Right

lofi.limo

Post reply on HN
Print view View original

91–100 of 212 posts

Re: Write HTML Right

#91

Post by aparks517 »

pronoiac wrote: post #86
btrettel wrote: post #5

Regarding writing "one-sentence-per-line", I've noticed that style before in LaTeX. While I don't use that style, one advantage that I like is the ability to include comments on the sentence level in LaTeX. So instead of this: First sentence. Second sentence. % Comment on first sentence. I can write: First sentence. % Comment on first sentence. Second sentence. (Of course, one could define a new TeX macro that doesn'…

I've been working on turning a pretty massive scanned book into a git repo of markdown files, with multiple collaborators. Using sentence-per-line has been useful (compared to line-per-paragraph) because, even with / despite --word-diff , PRs are far more concise, and merge conflicts are more rare. From memory, with paragraph-per-line, I think a series of paragraphs, each changed, even with minor changes, kinda break…

Oh, wow... I hadn't even thought of the diff angle, but it makes all the sense in the world. I've heard some authors even start each clause on its own line. I'm not sure I'm ready for that yet.

Re: Write HTML Right

#92

Post by ryanbrunner »

WillusFredus wrote: post #39
Spivak wrote: post #31

Earlier quoted context omitted.

Except for the fact that native apps also use SGML or XML inspired markup for their layout engines. A tree of heterogeneous objects maps extremely well to how people think about UI.

I agree that a tree structure can work well for mapping UIs, but HTML does not. It was specifically design as a textual markup language. Its role has been expanded, but it has been done so poorly. What really needs to happen it a separation of HTML from UI markup elements. HTML will be used solely for textual markup and a new markup language can be used for UIs. This would allow us to return to a proper separation of…

Sure, but that's an argument for creating new paradigms for having instantly available non-downloaded "apps". Right now, if you want a lot of what a webapp offers (100% cross-compatibility with any platform, instant updates, online syncing for free), you're basically stuck with HTML / Javascript.

Re: Write HTML Right

#93

Post by hombre_fatal »

jokoon wrote: post #88
shakna wrote: post #54

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…

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.

Re: Write HTML Right

#94

Post by iamben »

timw4mail wrote: post #80

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.

Agree 100%. It's also about a thousand times easier for people with a very basic HTML understanding to parse (if you open something, with pretty much the exception of an image, you gotta close it).

Periodically I have to send code to people who then make some of their own changes inline. God forbid trying to explain "yeah, they don't need to be closed, but that does because it's nested and..." Disaster (/hours of extra support) waiting to happen.

Re: Write HTML Right

#95

Post by shakna »

jokoon wrote: post #88
shakna wrote: post #54

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…

Are more strict html parsers/renderers, and aren't they faster?

> Are more strict html parsers/renderers, and aren't they faster?

Are what more strict? You're missing a subject there.

At a guess, you're referencing the differences between Chrome/Firefox rendering times? And are surprised that Chrome is always slower?

In the same completely unscientific stat taking, I found that Chrome was significantly faster at parsing the HTML head element of a document than Firefox, and that difference was enough for Chrome to pull ahead of Firefox in overall rendering times for smaller pages. (Chrome was about 30% of Firefox's time spent in the head.)

However, Firefox was faster at parsing the body, and as I had a larger-than-usual body (50k words is not your average webpage), Firefox was overall faster.

Re: Write HTML Right

#96

Post by SkeuomorphicBee »

robgibbons wrote: post #11
egeozcan wrote: post #8

Earlier quoted context omitted.

> Indentation _is_ information, which is lost here. Isn't it a "view" of information? Any sufficiently advanced text editor can recreate it with a simple key combination.

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 coding style not well suited for complex web apps with deep hierarchy.

Re: Write HTML Right

#97

Post by myfonj »

shakna wrote: post #54

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…

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

    
Content
[EOF fig3]
(with that that small insignificant `\n` text node between paragraph nodes), what should be possibly faster than "the worst scenarios":

    
Content
    
Content[EOF fig4a]
or even

    

    Content
    

    Content
    [EOF fig4b]
with paragraph text nodes `["Content\n","Content]"` / `["\nContent\n","\nContent\n]"`, where the "\n" must be also preserved in the DOM but due white-space collapsing rules not present in the render tree (if not overridden by some non-default CSS) but still with backtracking, that

    
Content
    

    
Content
    
[EOF fig5]
should eliminate (again, similarly to fig2 vs fig1).

(Sorry for wildly biased guesswork, worthless without measurements.)

Re: Write HTML Right

#99

Post by niconii »

clairity wrote: post #60
robgibbons wrote: post #7

This 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.

it doesn't work for even slightly complex documents either. there's been a little meme-fad lately around minimalistic html like this, but to claim it's the "right" way to write html is pompous at best. not closing tags for instance is really asking for future headaches. sure, it works for a simple text list, but not when it gets even a little complicated (add links, images, buttons, etc.). even worse are p tags, wher…

You have to know about what breaks out of

tags regardless of whether or not you leave off the end tag, though.

is invalid HTML because ends the paragraph, resulting in an unpaired

.
Post reply on HN