5 ms·

HTML Design Principles (2007)

119 points by kosasbest 3y ago

shadowfacts 3y ago
The whole document is good, but in particular, my favorite part (that I reference not infrequently in conversations) is the priority of constituencies: > In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
- butterNaN 3y ago
  Seems like a good general advice in most cases
  - beebmam 3y ago
    Disagree with implementers coming after authors, profoundly.
    - im3w1l 3y ago
      There are billions of users, probably 10's of millions of people of people writing html, 10s of thousands of implementers and 100s of designers. A tiny improvement for a huge group can outweigh many drawbacks for a smaller one.
      - nazgul17 3y ago
        It's probably right in this context, but I'd be careful with the last part in general contexts: assuming utility is linear makes for easy reasoning but also would say that a mild stomach ache for every single human (i.e. 7*10⁹ stomach aches) is worth more than the life of someone.
      - lolinder 3y ago
        But when designing a standard, if you ignore the needs of implementers you can accidentally write yourself into a place where it becomes impossible for new implementers to completely implement the spec, so we're locked to our existing implementations. I don't think that HTML has this problem so much, but it's absolutely an issue with both CSS and JavaScript.
        deleted 3y ago
        [deleted]
    - andirk 3y ago
      In the movie Tron, a user is this worst thing a program can encounter. > Greetings, programs! Oh, what an occasion we have here before us. Because your rumors are true. We do indeed have in our midst a User! (Can't find the 1982 quote, but this one from some 2010 redo gets the point across)
- defanor 3y ago
  This sounds tricky: since users depend on authors, both depend on implementors, and so on, issues and unhappiness may easily propagate from authors to users, from implementors to both those, etc; similarly to building a project with increasing tech debt, but at multiple layers. And then there is the question of application of this approach: whether one should consider picky and advanced users, or clueless ones, diverse users or an approximated average user, and likewise further along the chain, which is likely to lead to different results.
kdkirsch 3y ago
When posting old pages/articles it may help if the OP explained why they are sharing on HN. Is there a particular question it answers? Is there some development that has made the article more or less useful/accurate? A comment would help guide additional comments.
- eimrine 3y ago
  Internet was a heaven in 2007.
  - tannhaeuser 3y ago
    Then HTML5 and Google/Chrome devs taking over the Internet happened.
- calebegg 3y ago
  I don't disagree with you but I did find the linked article very interesting to read absent any context.
- layer8 3y ago
  The reason why the submitter found it interesting doesn’t need to be the same as why the upvoters found it interesting.
  - Wowfunhappy 3y ago
    I wholeheartedly agree, but I do appreciate it when submitters leave a top-level comment alongside the submission. There's no need for it to be special in any way, but it can help seed discussion IMO.
- paulddraper 3y ago
  Typically on HN people talk about whatever they want, no set agenda.
- chefandy 3y ago
  I see most internet forums as discussion groups where posts start out as invitations to conversation. However, I see HN more like a physical bulletin board in a workplace break room where people post whatever, whenever, and others passively view, interact with, or discuss it as they see fit.
doublerabbit 3y ago
I'm so bored of the "Do not Reinvent the Wheel" line. Why? I want it to be my wheel, what is wrong with reinventing the wheel? Inventing creates innovation and innovation sparks creativity and that's what programming is all about; creating. So if you don't your stuck with someone's else invention, that's no fun. Why should I use their invention and not mine? If it makes the spec, what's the issue?
- eimrine 3y ago
  Text areas, scroll bars, select inputs.
  - zdragnar 3y ago
    Select inputs are a decent example of why people reinvent things. There's no native combobox type input; html5 gave us list input + datalist, but no multiple selection. If anything, the select element has been a perfect example of a bad interface design: it is extremely difficult to use with large lists, but the lack of native combobox has had people reinventing the select input for years. Number inputs have always been a vile thing to work with, as is the "required" attribute.
- presidentender 3y ago
  If you're in the business of wheels, or if it is a hobby, make wheels. If you are in the business of carts, buy wheels. If you are in the business of transportation, buy carts.
  - doublerabbit 3y ago
    > If you are in the business of carts, buy wheels. I just don't agree with that logic. If you make your own carts, innovating your own wheels will yield cheaper costs in the long run. You have a new design and it could be something better. In conjunction you can than produce your own cart to that better design. Sure your not a wheel business, so you don't sell your wheels as that's not your specialty but you can now provide your own wheels for your own carts. Otherwise your vendor-locked to that manufacturer. And what then if they decide to stop selling the wheels or carts that you rely on, or increase the prices? You don't have Amazon (Cart) selling Google's Infrastructure (Wheels).
ninkendo 3y ago
> Some sites rely on the <u> element giving the presentational effect of an underline. > The b and i elements are widely used — it is better to give them good default rendering for various media including aural than to try to ban them. “Some sites”… “widely used”… yeah, because that’s the purpose of those tags. To underline, bold, italic, respectively. This isn’t some concession we should be giving to legacy user agents, it’s the whole original stated purpose of the tags. Any attempt to retcon them to mean other stuff in the name of (something something) “media independence” or some such academic nonsense, is totally backwards. I know that large parts of this article agree with me, but I still get angry that HTML took this purist direction to make huge swaths of markup useless in the name of semantic/display split that no user actually asked for. When I first read about the em tag and how it is the new way to do what the i tag used to do, I knew the whole thing had already been driven off a cliff.
- deleted 3y ago
  [deleted]
- ezequiel-garzon 3y ago
  The puzzling aspect is that, contrary to what most people would assume, the B, I, EM and STRONG elements all came out under the same version (2.0) of HTML: https://meiert.com/en/indices/html-elements/ https://meiert.com/en/indices/html-elements/
  - bensecure 3y ago
    > https://www.w3.org/MarkUp/html-spec/html-spec_toc.html#SEC5.7 https://www.w3.org/MarkUp/html-spec/html-spec_toc.html#SEC5.... > Phrases may be marked up according to idiomatic usage, typographic appearance, or for use as hyperlink anchors. So the original standard considered both approaches valid, later standards decided that typographic usage was invalid.
    - red_trumpet 3y ago
      No, there is a clear distinction between typographic and idiomatic markup. The i and b elements are considered typographic elements, not idiomatic ones (as em). So newer standards actually made them idiomatic.

119 points by kosasbest 3y ago

The whole document is good, but in particular, my favorite part (that I reference not infrequently in conversations) is the priority of constituencies: > In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

butterNaN 3y ago
Seems like a good general advice in most cases
- beebmam 3y ago
  Disagree with implementers coming after authors, profoundly.
  - im3w1l 3y ago
    There are billions of users, probably 10's of millions of people of people writing html, 10s of thousands of implementers and 100s of designers. A tiny improvement for a huge group can outweigh many drawbacks for a smaller one.
    - nazgul17 3y ago
      It's probably right in this context, but I'd be careful with the last part in general contexts: assuming utility is linear makes for easy reasoning but also would say that a mild stomach ache for every single human (i.e. 7*10⁹ stomach aches) is worth more than the life of someone.
    - lolinder 3y ago
      But when designing a standard, if you ignore the needs of implementers you can accidentally write yourself into a place where it becomes impossible for new implementers to completely implement the spec, so we're locked to our existing implementations. I don't think that HTML has this problem so much, but it's absolutely an issue with both CSS and JavaScript.
      - deleted 3y ago
        [deleted]
  - andirk 3y ago
    In the movie Tron, a user is this worst thing a program can encounter. > Greetings, programs! Oh, what an occasion we have here before us. Because your rumors are true. We do indeed have in our midst a User! (Can't find the 1982 quote, but this one from some 2010 redo gets the point across)
defanor 3y ago
This sounds tricky: since users depend on authors, both depend on implementors, and so on, issues and unhappiness may easily propagate from authors to users, from implementors to both those, etc; similarly to building a project with increasing tech debt, but at multiple layers. And then there is the question of application of this approach: whether one should consider picky and advanced users, or clueless ones, diverse users or an approximated average user, and likewise further along the chain, which is likely to lead to different results.

kdkirsch 3y ago

When posting old pages/articles it may help if the OP explained why they are sharing on HN. Is there a particular question it answers? Is there some development that has made the article more or less useful/accurate? A comment would help guide additional comments.

eimrine 3y ago
Internet was a heaven in 2007.
- tannhaeuser 3y ago
  Then HTML5 and Google/Chrome devs taking over the Internet happened.
calebegg 3y ago
I don't disagree with you but I did find the linked article very interesting to read absent any context.
layer8 3y ago
The reason why the submitter found it interesting doesn’t need to be the same as why the upvoters found it interesting.
- Wowfunhappy 3y ago
  I wholeheartedly agree, but I do appreciate it when submitters leave a top-level comment alongside the submission. There's no need for it to be special in any way, but it can help seed discussion IMO.
paulddraper 3y ago
Typically on HN people talk about whatever they want, no set agenda.
chefandy 3y ago
I see most internet forums as discussion groups where posts start out as invitations to conversation. However, I see HN more like a physical bulletin board in a workplace break room where people post whatever, whenever, and others passively view, interact with, or discuss it as they see fit.

doublerabbit 3y ago

I'm so bored of the "Do not Reinvent the Wheel" line. Why? I want it to be my wheel, what is wrong with reinventing the wheel? Inventing creates innovation and innovation sparks creativity and that's what programming is all about; creating. So if you don't your stuck with someone's else invention, that's no fun. Why should I use their invention and not mine? If it makes the spec, what's the issue?

eimrine 3y ago
Text areas, scroll bars, select inputs.
- zdragnar 3y ago
  Select inputs are a decent example of why people reinvent things. There's no native combobox type input; html5 gave us list input + datalist, but no multiple selection. If anything, the select element has been a perfect example of a bad interface design: it is extremely difficult to use with large lists, but the lack of native combobox has had people reinventing the select input for years. Number inputs have always been a vile thing to work with, as is the "required" attribute.
presidentender 3y ago
If you're in the business of wheels, or if it is a hobby, make wheels. If you are in the business of carts, buy wheels. If you are in the business of transportation, buy carts.
- doublerabbit 3y ago
  > If you are in the business of carts, buy wheels. I just don't agree with that logic. If you make your own carts, innovating your own wheels will yield cheaper costs in the long run. You have a new design and it could be something better. In conjunction you can than produce your own cart to that better design. Sure your not a wheel business, so you don't sell your wheels as that's not your specialty but you can now provide your own wheels for your own carts. Otherwise your vendor-locked to that manufacturer. And what then if they decide to stop selling the wheels or carts that you rely on, or increase the prices? You don't have Amazon (Cart) selling Google's Infrastructure (Wheels).

ninkendo 3y ago

> Some sites rely on the <u> element giving the presentational effect of an underline. > The b and i elements are widely used — it is better to give them good default rendering for various media including aural than to try to ban them. “Some sites”… “widely used”… yeah, because that’s the purpose of those tags. To underline, bold, italic, respectively. This isn’t some concession we should be giving to legacy user agents, it’s the whole original stated purpose of the tags. Any attempt to retcon them to mean other stuff in the name of (something something) “media independence” or some such academic nonsense, is totally backwards. I know that large parts of this article agree with me, but I still get angry that HTML took this purist direction to make huge swaths of markup useless in the name of semantic/display split that no user actually asked for. When I first read about the em tag and how it is the new way to do what the i tag used to do, I knew the whole thing had already been driven off a cliff.

deleted 3y ago
[deleted]
ezequiel-garzon 3y ago
The puzzling aspect is that, contrary to what most people would assume, the B, I, EM and STRONG elements all came out under the same version (2.0) of HTML: https://meiert.com/en/indices/html-elements/ https://meiert.com/en/indices/html-elements/
- bensecure 3y ago
  > https://www.w3.org/MarkUp/html-spec/html-spec_toc.html#SEC5.7 https://www.w3.org/MarkUp/html-spec/html-spec_toc.html#SEC5.... > Phrases may be marked up according to idiomatic usage, typographic appearance, or for use as hyperlink anchors. So the original standard considered both approaches valid, later standards decided that typographic usage was invalid.
  - red_trumpet 3y ago
    No, there is a clear distinction between typographic and idiomatic markup. The i and b elements are considered typographic elements, not idiomatic ones (as em). So newer standards actually made them idiomatic.