3 ms·

> so there often aren't semantic HTML tags that would make sense. Pet peeve of mine: there should really be `<grid>` and `<flex>` elements, as well as `<fi>` (

> so there often aren't semantic HTML tags that would make sense. Pet peeve of mine: there should really be `<grid>` and `<flex>` elements, as well as `<fi>` (flex item) and `<gi>` (grid item) for the child element instead of relying on a div soup with CSS attributes everywhere.

assimpleaspossi 4mo ago
HTML describes the content, not visual display.
- icedchai 4mo ago
  If you remember earlier versions of HTML, with all the tables and font tag soup, it was not always the case. Sadly, it was easier building layouts with tables instead of CSS for a very, very long time.
  - assimpleaspossi 4mo ago
    How the elements were abused does not take away from the fact that HTML elements represent their content, not their layout except for <table> which is probably the only the exception.
    - icedchai 4mo ago
      These elements weren't "abused." It was the only alternative before CSS was around! Then CSS took years (decades?) to catch up to the simplicity of table-based layouts.
- littlestymaar 4mo ago
  Not really. This would not be different to <table> and associated elements, which are arguably better than a div soup.
  - assimpleaspossi 4mo ago
    Yes, really. Even <table> is used to represent the data, not the layout, though it will be laid out as a table but it's probably the only element that does such a thing.
    - littlestymaar 4mo ago
      > Yes, really. Even <table> is used to represent the data, not the layout Nope. It's a html tag to lay out data in a table form! > but it's probably the only element that does such a thing. <pre>, <b>, <i> all come with an associated layout implication. But the worst offender are <div> and <span>, which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of <flex> or <grid> elements. And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data. The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.
      - jkrejcha 4mo ago
        Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why <font> was deprecated. With that: <table> is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email) <b> and <i> I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with <strong> and friends. This happened with other elements too. I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use <b> to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
        littlestymaar 4mo ago
nicoburns 4mo ago
There's nothing stopping you from defining those yourself for your own websites: grid { display: grid } will work in every modern browser.
- littlestymaar 4mo ago
  For that to work I would need to define a custom component from JavaScript, wouldn't I? (and I thought custom components had to contain an hyphen in there name, is that wrong?)
  - FelipeCortez 4mo ago
    try it! data:text/html,<grid><p>A</p><p>B</p><p>C</p></grid><style>grid{display: grid}</style> afaik to create a CustomElement you need to use dashes, yes, but in this example `<grid>` is an HTMLUnknownElement, which renders just fine. some discussion here: https://stackoverflow.com/a/22545622/2393963 https://stackoverflow.com/a/22545622/2393963
    - littlestymaar 4mo ago
      TIL thx!
- yencabulator 4mo ago
  You're supposed to only use custom elements with a dash in the name. Otherwise the spec can add an element that means something new, and you've accidentally used that name.

assimpleaspossi 4mo ago

HTML describes the content, not visual display.

icedchai 4mo ago
If you remember earlier versions of HTML, with all the tables and font tag soup, it was not always the case. Sadly, it was easier building layouts with tables instead of CSS for a very, very long time.
- assimpleaspossi 4mo ago
  How the elements were abused does not take away from the fact that HTML elements represent their content, not their layout except for <table> which is probably the only the exception.
  - icedchai 4mo ago
    These elements weren't "abused." It was the only alternative before CSS was around! Then CSS took years (decades?) to catch up to the simplicity of table-based layouts.
littlestymaar 4mo ago
Not really. This would not be different to <table> and associated elements, which are arguably better than a div soup.
- assimpleaspossi 4mo ago
  Yes, really. Even <table> is used to represent the data, not the layout, though it will be laid out as a table but it's probably the only element that does such a thing.
  - littlestymaar 4mo ago
    > Yes, really. Even <table> is used to represent the data, not the layout Nope. It's a html tag to lay out data in a table form! > but it's probably the only element that does such a thing. <pre>, <b>, <i> all come with an associated layout implication. But the worst offender are <div> and <span>, which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of <flex> or <grid> elements. And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data. The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.
    - jkrejcha 4mo ago
      Eh. HTML in its recent iterations made it very clear to try and separate itself from layout concerns. It's why <font> was deprecated. With that: <table> is really only meant for actual tabular data and not about layout. It really isn't about the layout. It got abused for layout because it was the only thing that worked in a lot of cases (especially amusingly enough, email) <b> and <i> I think I'd agree, even if they did eventually get retconned to be "bring attention to" and "idiomatic text". Same with <strong> and friends. This happened with other elements too. I think it's fair to acknowledge the realities (people who are writing HTML a lot of times use <b> to mean "bold") of usages but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
      - littlestymaar 4mo ago

nicoburns 4mo ago

There's nothing stopping you from defining those yourself for your own websites: grid { display: grid } will work in every modern browser.

littlestymaar 4mo ago
For that to work I would need to define a custom component from JavaScript, wouldn't I? (and I thought custom components had to contain an hyphen in there name, is that wrong?)
- FelipeCortez 4mo ago
  try it! data:text/html,<grid><p>A</p><p>B</p><p>C</p></grid><style>grid{display: grid}</style> afaik to create a CustomElement you need to use dashes, yes, but in this example `<grid>` is an HTMLUnknownElement, which renders just fine. some discussion here: https://stackoverflow.com/a/22545622/2393963 https://stackoverflow.com/a/22545622/2393963
  - littlestymaar 4mo ago
    TIL thx!
yencabulator 4mo ago
You're supposed to only use custom elements with a dash in the name. Otherwise the spec can add an element that means something new, and you've accidentally used that name.