5 ms·

While we're on the subject of structuring content in HTML, guess what folks? <div> tags are now entirely unnecessary in almost every circumstance! They carry no

While we're on the subject of structuring content in HTML, guess what folks? <div> tags are now entirely unnecessary in almost every circumstance! They carry no semantic meaning in and of themselves and the only way they differ from <span> (which equally offers no meaning) is default display:block styling. *Use custom elements.* =) We now have carte blanch in modern HTML specs and web browsers to invent our own elements when the built-in semantic variety won't cut the mustard. In one example, it used a <div> for a newsletter subscription area instead of <section> or <article>. Why div? You could actually add <newsletter-subscription> and now you have a tag you can style and utilize PLUS it conveys meaning within the DOM. Note that I haven't yet mentioned web components…that's because you don't need to author a web component to use a custom element. A custom element in HTML starts life out as an HTMLUnknownElement object in the DOM. If you want to keep it there, that's perfectly fine! As an optional step, maybe you do want to attach some additional behavior via JavaScript. Now you can upgrade it using customElements.define and boom! It's a web component. I've actually set up linters in some projects now where HTML is checked for <div>/<span> tags and you get an error unless you consciously opt-in for those particular cases. Again, in almost every respect (perhaps a little more relaxed if you're deep in the bowels of a component shadow DOM, but still…), I find reaching for a true semantic element or a custom element is really the way to go in 2022+.

deleted 4y ago
[deleted]
TekMol 4y ago
Two downsides come to mind: 1: Visual noise. I would prefer to edit this: <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> </div> Rather than this: <article-section> <article-name>Hammer</article-name> <article-description> Buy this and everything will start to look like a nail. </article-description> </article> 2: Web scraping. Div soup makes scraping harder than a doc of nicely named elements.
- jaredcwhite 4y ago
  Point #2 seems to contradict point #1…?
  - TekMol 4y ago
    True. To some extend. But I can usually grasp very quickly "Ah yes, inside an article-section, the name comes first, and the description comes second". Writers of scraping software don't like ":nth-of-type(3)" though. They prefer ".price". As it is easier to write and will survive more changes to the site.
    - bryanrasmussen 4y ago
      I think from my experience .price is not to be preferred either, but rather XPath as that tends to be more robust, as per the following https://sepl.dibris.unige.it/publications/2016-leotta-JSEP.pdf https://sepl.dibris.unige.it/publications/2016-leotta-JSEP.p... discussed here https://news.ycombinator.com/item?id=24055733 https://news.ycombinator.com/item?id=24055733
      - TekMol 4y ago
        If you have a structure like this: <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> <div class=price>123.45</div> </div> How would you use XPath, and how would it be more rubust than '.price'?
        bryanrasmussen 4y ago
        first off I would probably want to use price as the starting point, if price is there and the contents of price when trimmed etc. is a decimal, cool. But if there isn't a .price because someone has changed it to .amount for some reason. Or hey started using Material-UI or some other framework and they no longer have any meaningful classes anywhere which is what I most often see people whining about. then you would probably get an absolute xpath to the item you want, then you would use the getRobustXPath(element, document) function for that element, using the linked library under discussion https://github.com/cyluxx/robula-plus https://github.com/cyluxx/robula-plus to get a robust xpath. This xpath will probably be pretty unreadable but you can then test to see it gets your stuff. How will it be more robust - well that depends but if I have something like this <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> <div class=price>123.45</div> </div> I might first off want to get products and their descriptions and their prices together. And I would probably say hey it might be that they are under this kind of class based structure but that can change but what is less likely to change is that a 'price' will be A number with either . or , as the potential decimal delimiter, with potential currency symbols either directly in the element with the number, not found, or in a directly preceding or following element. It would be useful to find prices on the page before everything else, and from there to figure out where product names and where descriptions where in relation to the price. Dependent on language of page product layout will probably change, but in a western language the price will probably come 'last' in our product container, which is exactly what you have done here. A non-robust xpath for matching the above might look something like product = //[local-name()='article' || local-name()='main']//[child::*[last()][xs:decimal(text())] The above might have an error in the xpath because hey, writing without testing in environment, and also obviously really expensive as have not optimized. But it should also be clear enough that by removing the need to have matching elements be based on the incidentals of how we style those elements we can add up with data extraction that is less likely to break with site redesigns. on edit: obv. article or main check would be optimized beforehand, just some sites use both, some use one, and some neither so would have to do all sorts of things first, etc. etc.
password4321 4y ago
a11y? I guess div/span don't offer much but I assume the screen readers etc. at least have experience dealing with that vs. randomness.
- bryanrasmussen 4y ago
  one of the things that people not used to a11y get confused by is that since div and span elements carry no information you can't add aria-labels to them (or shouldn't be able to, some readers may be non-compliant on this matter) without an explicit role. However you wouldn't be able to add them to any random element either. Of course divs and spans do get the benefit that they are read as separate elements by screen readers, however this can also be a curse https://stackoverflow.com/questions/60869293/accessibility-readout-multiple-spans-in-div-as-a-single-sentence https://stackoverflow.com/questions/60869293/accessibility-r... Don't know how it would behave with a bunch of readable-segment elements or what have you, as I haven't tested.
dmitriid 4y ago
> Use custom elements. That don't work without Javascript and that have multiple unsolved issues ranging from accessibility to not playing nice with SVGs. No. Use divs and spans.
- xigoi 4y ago
  Custom elements don't require JavaScript.
  - dmitriid 4y ago
    Without Javascript they are unknown to the browser. So the browsers fallback to treating them like a block element (so, a div). It's not because custom elements "work without Javascript". It's because browsers are trying to work even in the presence of errors and invalid/unknown markup. Javascript is required for custom elements.
5350-uiop-1130 4y ago
Thanks for the pointers. Although I think <div> is still incredibly useful, because in many circumstances people simply don't know which element to use or don't care to come up with custom elements. <div> to me is like the generic building "block", not meant to convey meaning most of the time, and you can use aria-role when needed. I don't think we needed <section> and <article>, many things in HTML-CSS naming/conventions don't make sense to me, after 15 years. Too many ways to do the same thing.
benibela 4y ago
It is like they have rediscovered XML with the custom elements

deleted 4y ago

[deleted]

TekMol 4y ago

Two downsides come to mind: 1: Visual noise. I would prefer to edit this: <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> </div> Rather than this: <article-section> <article-name>Hammer</article-name> <article-description> Buy this and everything will start to look like a nail. </article-description> </article> 2: Web scraping. Div soup makes scraping harder than a doc of nicely named elements.

jaredcwhite 4y ago
Point #2 seems to contradict point #1…?
- TekMol 4y ago
  True. To some extend. But I can usually grasp very quickly "Ah yes, inside an article-section, the name comes first, and the description comes second". Writers of scraping software don't like ":nth-of-type(3)" though. They prefer ".price". As it is easier to write and will survive more changes to the site.
  - bryanrasmussen 4y ago
    I think from my experience .price is not to be preferred either, but rather XPath as that tends to be more robust, as per the following https://sepl.dibris.unige.it/publications/2016-leotta-JSEP.pdf https://sepl.dibris.unige.it/publications/2016-leotta-JSEP.p... discussed here https://news.ycombinator.com/item?id=24055733 https://news.ycombinator.com/item?id=24055733
    - TekMol 4y ago
      If you have a structure like this: <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> <div class=price>123.45</div> </div> How would you use XPath, and how would it be more rubust than '.price'?
      - bryanrasmussen 4y ago
        first off I would probably want to use price as the starting point, if price is there and the contents of price when trimmed etc. is a decimal, cool. But if there isn't a .price because someone has changed it to .amount for some reason. Or hey started using Material-UI or some other framework and they no longer have any meaningful classes anywhere which is what I most often see people whining about. then you would probably get an absolute xpath to the item you want, then you would use the getRobustXPath(element, document) function for that element, using the linked library under discussion https://github.com/cyluxx/robula-plus https://github.com/cyluxx/robula-plus to get a robust xpath. This xpath will probably be pretty unreadable but you can then test to see it gets your stuff. How will it be more robust - well that depends but if I have something like this <div class=article-section> <div>Hammer</div> <div> Buy this and everything will start to look like a nail </div> </div> <div class=price>123.45</div> </div> I might first off want to get products and their descriptions and their prices together. And I would probably say hey it might be that they are under this kind of class based structure but that can change but what is less likely to change is that a 'price' will be A number with either . or , as the potential decimal delimiter, with potential currency symbols either directly in the element with the number, not found, or in a directly preceding or following element. It would be useful to find prices on the page before everything else, and from there to figure out where product names and where descriptions where in relation to the price. Dependent on language of page product layout will probably change, but in a western language the price will probably come 'last' in our product container, which is exactly what you have done here. A non-robust xpath for matching the above might look something like product = //[local-name()='article' || local-name()='main']//[child::*[last()][xs:decimal(text())] The above might have an error in the xpath because hey, writing without testing in environment, and also obviously really expensive as have not optimized. But it should also be clear enough that by removing the need to have matching elements be based on the incidentals of how we style those elements we can add up with data extraction that is less likely to break with site redesigns. on edit: obv. article or main check would be optimized beforehand, just some sites use both, some use one, and some neither so would have to do all sorts of things first, etc. etc.

password4321 4y ago

a11y? I guess div/span don't offer much but I assume the screen readers etc. at least have experience dealing with that vs. randomness.

bryanrasmussen 4y ago
one of the things that people not used to a11y get confused by is that since div and span elements carry no information you can't add aria-labels to them (or shouldn't be able to, some readers may be non-compliant on this matter) without an explicit role. However you wouldn't be able to add them to any random element either. Of course divs and spans do get the benefit that they are read as separate elements by screen readers, however this can also be a curse https://stackoverflow.com/questions/60869293/accessibility-readout-multiple-spans-in-div-as-a-single-sentence https://stackoverflow.com/questions/60869293/accessibility-r... Don't know how it would behave with a bunch of readable-segment elements or what have you, as I haven't tested.

dmitriid 4y ago

> Use custom elements. That don't work without Javascript and that have multiple unsolved issues ranging from accessibility to not playing nice with SVGs. No. Use divs and spans.

xigoi 4y ago
Custom elements don't require JavaScript.
- dmitriid 4y ago
  Without Javascript they are unknown to the browser. So the browsers fallback to treating them like a block element (so, a div). It's not because custom elements "work without Javascript". It's because browsers are trying to work even in the presence of errors and invalid/unknown markup. Javascript is required for custom elements.

5350-uiop-1130 4y ago

Thanks for the pointers. Although I think <div> is still incredibly useful, because in many circumstances people simply don't know which element to use or don't care to come up with custom elements. <div> to me is like the generic building "block", not meant to convey meaning most of the time, and you can use aria-role when needed. I don't think we needed <section> and <article>, many things in HTML-CSS naming/conventions don't make sense to me, after 15 years. Too many ways to do the same thing.

benibela 4y ago

It is like they have rediscovered XML with the custom elements