5 ms·

Because it doesn't matter.

by teej 16y ago

joeybaker 16y ago
Sure, unless you'd like to validate, parse, maintain, or change the codebase. edit: oh, and proper markup is faster.
bradleyland 16y ago
If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone writing bad markup a pass. It degrades our artform. That matters.
- beoba 16y ago
  What's 'incorrect'? It's just following an older standard. Will all existing C++ code be 'incorrect' once C++0x is finally released?
  - prodigal_erik 16y ago
    <table> has a meaning. It expresses recurring, orderly relationships between <th> and <td> elements. It has always been incorrect to cram in content that isn't semantically linked that way, purely to exploit a typical rendering of it. It was incorrect even when there existed no supported way to request a similar rendering, though that was a reasonable excuse if you only cared about appearance.
- nostrademons 16y ago
  Part of being a good engineer is understanding tradeoffs and figuring out when contextually-dependent knowledge doesn't apply. IMHO, it doesn't matter - for Hacker News. That's independent of whether it matters for whatever website you're being paid to write at any given job.
  - bradleyland 16y ago
    I agree 100% regarding tradeoffs. However, saying that something is a "tradeoff" infers value. I.e., how can one evaluate a trade for something with no relative value? Saying something "doesn't matter" means it is not considered. Saying it's a "tradeoff" means you considered it, but found it less important than other factors. Those are two different things. This is just a semantic argument, but it's one I find important. At our startup, we came out of the gate with viable, working software in under six weeks. Believe me, there were tradeoffs. But at no point in that process did I say, "this doesn't matter". That's lying to myself. It matters, but I will accept for today that I cannot have both. This helps us avoid complacency and keeps our product sharp.
- wglb 16y ago
  In a previous lifetime, I worked on the code generator for a compiler for an implementation language. We had a rule that said "A good compiler generates assembly code that an assembly programmer would be fired for writing." Early releases of that compiler would get bug reports from the OS implementation team that "this code is wrong". We would sit down and walk through the generated code, and there would be an "Oh" moment where the programmer would realize that it was simply different, and in all cases, faster. Similarly, the code generated by good Python, to a CPU, looks like crap because it repeats stuff, allocates and releases memory, makes unnecessary calls, swaps stuff between stack and registers, and a whole host of other sins. But we don't care, because what we care about is the end result: the Python or Lua or Ruby code generates lovely computational results. Perhaps 1% of spend time looking in detail at the actual machine code generated. The purpose of these languages is to 1) Let us write good, readable code and 2) generate a useful, sometimes beautiful result. Similarly, the purpose of this particular Arc program is to generate a useful result, that is, a readable, useful set of html files that our browsers render readably. So really, "it doesn't matter" if the assembly language is junk, or if the html is not something early versions of Patrick would turn out with notepad. Think of the generated html as assembly language. It no more degrades our art form than the goofy stuff that modern languages make our CPUs eat.
  - bradleyland 16y ago
    I'm sorry, but you have an incorrect view of HTML. HTML's sole purpose is not display. If that were the case, it would be a simple matter of identifying what renders fastest and most accurately, but again, that's not HTML's sole purpose. The destination goal for HTML is to convey information about the structure and context of the content, not just how it is displayed. So we must care about the HTML generated. It is requisite to it's function in providing additional machine-readable information.
    - wglb 16y ago
      So what about the information and structure of the HN site is missing by the way that it is currently displayed? What additional machine-readable information is missing in the way that HN (or really any other site) produces the information? Search? There are a number of aggregator projects that various HN members have built by scraping this "broken" html and they seem to work quite nicely. I spent a couple of years deep in the SGML world and am fully cognizant of all the arguments about how content needs to be completely separated from presentation. HTML is really a weak sister in that world. I don't think my view of HTML is incorrect. In the real world, the ship of requiring correct HTML from a gramatical perspective left the harbor back in the 90's. If what you say were true, browsers would refuse to render broken HTML.
- jey 16y ago
  But you're looking at generated code, not written code. What you're suggesting is like criticizing the output of your C compiler for not following good assembly programming practices. On the other hand there's good reasons for fixing the markup as pointed out elsewhere in this thread (accessibility, JS DOM manipulation, etc).
  - bradleyland 16y ago
    That analogy doesn't hold up, because HTML is not just machine code. The next iteration of the web requires that we think of HTML as a means to provide meaning, not just format for display. Generated code doesn't have to misuse constructs. You can just as easily generate a nested unordered-list with good semantic IDs and class names.

Because it doesn't matter.

by teej 16y ago

Because it doesn't matter.

joeybaker 16y ago

Sure, unless you'd like to validate, parse, maintain, or change the codebase. edit: oh, and proper markup is faster.

bradleyland 16y ago

If someone writes C/Python/Lua/language-of-your-choice code that violates good principles, misuses constructs, and generally looks like crap, everyone calls them a lousy coder. Yet when it comes to HTML, using semantically incorrect markup is somehow ok. I understand why pg hasn't updated the display markup, and it's his website, so he can do what he likes with it, but to say "it doesn't matter" is to give anyone writing bad markup a pass. It degrades our artform. That matters.

beoba 16y ago
What's 'incorrect'? It's just following an older standard. Will all existing C++ code be 'incorrect' once C++0x is finally released?
- prodigal_erik 16y ago
  <table> has a meaning. It expresses recurring, orderly relationships between <th> and <td> elements. It has always been incorrect to cram in content that isn't semantically linked that way, purely to exploit a typical rendering of it. It was incorrect even when there existed no supported way to request a similar rendering, though that was a reasonable excuse if you only cared about appearance.
nostrademons 16y ago
Part of being a good engineer is understanding tradeoffs and figuring out when contextually-dependent knowledge doesn't apply. IMHO, it doesn't matter - for Hacker News. That's independent of whether it matters for whatever website you're being paid to write at any given job.
- bradleyland 16y ago
  I agree 100% regarding tradeoffs. However, saying that something is a "tradeoff" infers value. I.e., how can one evaluate a trade for something with no relative value? Saying something "doesn't matter" means it is not considered. Saying it's a "tradeoff" means you considered it, but found it less important than other factors. Those are two different things. This is just a semantic argument, but it's one I find important. At our startup, we came out of the gate with viable, working software in under six weeks. Believe me, there were tradeoffs. But at no point in that process did I say, "this doesn't matter". That's lying to myself. It matters, but I will accept for today that I cannot have both. This helps us avoid complacency and keeps our product sharp.
wglb 16y ago
In a previous lifetime, I worked on the code generator for a compiler for an implementation language. We had a rule that said "A good compiler generates assembly code that an assembly programmer would be fired for writing." Early releases of that compiler would get bug reports from the OS implementation team that "this code is wrong". We would sit down and walk through the generated code, and there would be an "Oh" moment where the programmer would realize that it was simply different, and in all cases, faster. Similarly, the code generated by good Python, to a CPU, looks like crap because it repeats stuff, allocates and releases memory, makes unnecessary calls, swaps stuff between stack and registers, and a whole host of other sins. But we don't care, because what we care about is the end result: the Python or Lua or Ruby code generates lovely computational results. Perhaps 1% of spend time looking in detail at the actual machine code generated. The purpose of these languages is to 1) Let us write good, readable code and 2) generate a useful, sometimes beautiful result. Similarly, the purpose of this particular Arc program is to generate a useful result, that is, a readable, useful set of html files that our browsers render readably. So really, "it doesn't matter" if the assembly language is junk, or if the html is not something early versions of Patrick would turn out with notepad. Think of the generated html as assembly language. It no more degrades our art form than the goofy stuff that modern languages make our CPUs eat.
- bradleyland 16y ago
  I'm sorry, but you have an incorrect view of HTML. HTML's sole purpose is not display. If that were the case, it would be a simple matter of identifying what renders fastest and most accurately, but again, that's not HTML's sole purpose. The destination goal for HTML is to convey information about the structure and context of the content, not just how it is displayed. So we must care about the HTML generated. It is requisite to it's function in providing additional machine-readable information.
  - wglb 16y ago
    So what about the information and structure of the HN site is missing by the way that it is currently displayed? What additional machine-readable information is missing in the way that HN (or really any other site) produces the information? Search? There are a number of aggregator projects that various HN members have built by scraping this "broken" html and they seem to work quite nicely. I spent a couple of years deep in the SGML world and am fully cognizant of all the arguments about how content needs to be completely separated from presentation. HTML is really a weak sister in that world. I don't think my view of HTML is incorrect. In the real world, the ship of requiring correct HTML from a gramatical perspective left the harbor back in the 90's. If what you say were true, browsers would refuse to render broken HTML.
jey 16y ago
But you're looking at generated code, not written code. What you're suggesting is like criticizing the output of your C compiler for not following good assembly programming practices. On the other hand there's good reasons for fixing the markup as pointed out elsewhere in this thread (accessibility, JS DOM manipulation, etc).
- bradleyland 16y ago
  That analogy doesn't hold up, because HTML is not just machine code. The next iteration of the web requires that we think of HTML as a means to provide meaning, not just format for display. Generated code doesn't have to misuse constructs. You can just as easily generate a nested unordered-list with good semantic IDs and class names.