Hacker News Reader

Comment by fao_ | Hacker News Reader

   <html id="b">
      <head id="c">
           <title id="d">

Ok, those ids are viscerally disgusting and immediately turned off any curiosity I had. My own HTML generator managed to generate meaningful IDs, why can't they?

Generated HTML should look like handwritten HTML for the sake of the poor sod who has to open up the generated files and figure out why they do not work, or debug using web dev tools, IMO.

View on HN

> Ok, those ids are viscerally disgusting and immediately turned off any curiosity I had.

Seems like a totally proportional response to a relatively minor issue that's probably easily fixed if someone created an issue for it.

It's a major issue, and not easily fixed unless the design is implausibly suitable (raw IDs in the input imply the absence of any ID management).

It says a lot about how they approach code generation that makes it a giant waving red flag, for me personally. A rule of code generation is "don't output internal structures unless it's necessary for runtime functioning". This isn't necessary, since no reference is being made to them, which it knows in advance. It tells me that they don't care about the output, which means that if I use it for a long term big project the output is likely to not be human readable, which actually means a whole lot when you are debugging it in-browser!

These short IDs are likely generated for performance reasons. Meaningful IDs would increase page size quite a bit (not just in the HTML, but in the CSS and JavaScript that references them as well).

Developers sometimes optimize their critical HTML to fit within a tuned initial TCP congestion window to improve performance, so this stuff can make a difference.

In that case, I hope they'll use esoteric Unicode characters for id names to save bytes /s

Those will to take more bytes than plain ASCII characters.

Don't both gecko and blink store those as UTF-16 anyways ? if so, "à" would take less storage than "aaa" when all of [a-zA-Z0-9]+ have been covered

In decoded memory perhaps, the data format in bytes over the network is going to be whatever the server/page says it is encoded in (utf8 overwhelmingly these days).

These could of course be generated as longer IDs during development and shortened for production.

I don't understand why they didn't do something like this instead:

    div.foo#thing {
      text: "Foo"
    }

Generates this:

    <div class="foo" id="thing">Foo</div>

I realise that there's issues with css name collisions, but there's different ways that can be resolved by the compiler.

That makes sense -- only give a tag an id if it needs one. It only needs one if ti's being referred to somewhere, and when that happens the user can give it a name, such as "thing" in this example.

See, that's exactly what I thought when I said about this.

I mean, worst case, give everything an id but don't _output_ it!

Was thinking the same thing. Or just copy HAML which would be...

   %div.foo#thing
     Foo

This is how JADE/PUG handled it. And, for anyone that's used css, querySelector or jQuery, it seems quite natural.

I also wonder why the author didn't pick up these standard methodologies and continue from there.

Reply on news.ycombinator.com