6 ms·

Reading this article made me realize what it is that's broken about the concept of semantic markup and why websites even today are div soup. It's the same reas

Reading this article made me realize what it is that's broken about the concept of semantic markup and why websites even today are div soup. It's the same reason why divs won in the first place. You can't dictate the shape of a document to people and it be anything other than a kludge. Take the site I work on, Great Big Story[1]. We have sections and headers, but our content isn't defined by text, it's defined by graphics and videos, with little metadata sections on the video player page that I suppose could be semantic if we had the right descriptive tags. I use semantic markup when it seems to make sense, but we have so many weird little needs to introduce elements just for styling purposes. Take a recent example, I need four elements to make a styled file input form. Two labels, one to look like a button and can be clicked, taking advantage of the browser behavior of treating clicks on the label to be clicks on the form. The other label is the actual label, could be just a span if I wanted, it doesn't have the htmlFor attribute set. The actual form input button is hidden using CSS tricks because the actual button can't be styled. Finally there's the filename display, which is set to the filename of whatever was uploaded or the existing one if present. This uses Javascript callbacks to get set. None of these elements are semantic, legacy cruft keeps the markup from being simple and readable. I suppose you could demand our video presentation site to be a motherfucking website[2], but I fail to see how that will actually improve much of anything and would just hurt our brand. I'm getting a little tired of coder hatred for web fashion. It keeps us all employed. But I think we're at least 10 years out from being able to actually use semantic markup. Web standards and browser vendors still have some maturing to do. [1] https://www.greatbigstory.com https://www.greatbigstory.com [2] https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/

baby_wipe 8y ago
> but we have so many weird little needs to introduce elements just for styling purposes. I think this is the number one reason why I prefer mobile dev over front-end web dev.
iris-digital 8y ago
> input button is hidden using CSS tricks because the actual button can't be styled. Buttons can be styled.
- vinceguidry 8y ago
  Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.
  - jandrese 8y ago
    Heaven forbid your buttons look like buttons.
    - vinceguidry 8y ago
      shrug Fight web fashion all you want, I like the high rise condo that it pays for.
    - s73v3r_ 8y ago
      If you want to fight that fight with design, go right ahead. The rest of us have work to do.
    - jahewson 8y ago
      The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it? Why does there even have to be a button? I want an API not a button...
      - jandrese 8y ago
        Is that a problem with the file input button, or with every other button on your website? The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
        Jaruzel 8y ago
        IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...
traverseda 8y ago
Well, it's a problem of mixing data and visual elements. In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist. In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph. That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems.
- vinceguidry 8y ago
  Thanks for introducing me to the concept of the scene-graph. I tried to make an argument on a React community slack that components are purely visual, that they should express the visual structure of the web page, in the context of an argument over how state and props should be used. He hated the rise of the Redux ecosystem, and I was trying to make the point that if you don't manage global state in your application sanely, you'll only end up reinventing it poorly, passing onChange across the Atlantic in the case where your save button doesn't live in the same visual space as the rest of your form. His response was to bring up the Router component to make the point that not all components are visual. UIs are complicated things, I've found that the visual model is the best encapsulation concept. Components aren't bad, but you need to first have a need to use them, because there's definitely a tradeoff, and second you need to use the right abstraction techniques. Routing components are a hack, different pages should just load different base components in the site backend. But it seems like once someone swallows the functional paradigmatic koolaid, they lose all perspective to see when the paradigm fails to produce erudite design.
  - deleted 8y ago
    [deleted]
taeric 8y ago
The whole debate between semantic markup and visual styling in CSS looks to me to be a massive exercise in people yelling past each other and needlessly making all life difficult. I've ranted about this before, but worse is that everyone insists on trying to go with the default flow of elements as much as they can. Example I used last time was that it is actually easy to layout things and have them look pretty solid between browsers, iff you embrace absolute positioning. http://taeric.github.io/cube-permutations-1.html http://taeric.github.io/cube-permutations-1.html is a page where I played with laying out a Rubik's cube. I confess I have not tried it in all browsers, as I don't care too much, but it works in all of my browsers, including my phone. I shudder to think how I could have done that with just using floats and inline-block style concerns. Why do I claim that makes it worse? Because you wind up with more markup just to trick the layout engine to calculate where to put things. Instead of you just figuring it out largely on your own and not building a Rube Goldberg machine to layout a page. Internally for a previous company, I did this only to have the next person try to get rid of absolute positioning because "gross". Over two sprints later they caved and went back to the working solution that was a) less code, b) worked everywhere, and c) was easy to modify by virtue of a.
- vinceguidry 8y ago
  I like absolute positioning but it's really hard to learn how to use fluently. New devs need to be educated on the concepts otherwise you get a total mess. Flex and grid are more intuitive so they're easier for juniors to train up on.
  - taeric 8y ago
    How is it hard to learn. Put someone in front of some graph paper and let them layout what they want the page to look like. Get someone a little more experienced to help them pick the points that can grow, and off you go. Not to say that they can't do better with flex and grid. But it was like our entire industry didn't even bother trying to learn with the first tools that our industry made.
    - vinceguidry 8y ago
Washuu 8y ago
The site you work on is blank if Javascript is turned off. I do not see anything in particular on the home page that should require Javascript to render.
- vinceguidry 8y ago
  Me neither but I didn't decide on the site architecture. If I did, it would work.
stackola 8y ago
Just thought I'd let you know, Great Big Story is running a development build of react. You save some of bundle size and performance by switching to a production build.
- vinceguidry 8y ago
  We're replatforming for a redesign and so that should fix that, but thanks for the heads up. Just about all maintenance on the current site is on the back burner atm except for GDPR stuff.
HelloNurse 8y ago
What do you mean by "semantic" markup? The markup in the file upload widget you describe is rather generic (label, button, p or span, presumably div) but almost completely meaningful (caption, button text, file name, widget/drag and drop target), not a div soup; I don't see how you could improve it.

baby_wipe 8y ago

> but we have so many weird little needs to introduce elements just for styling purposes. I think this is the number one reason why I prefer mobile dev over front-end web dev.

iris-digital 8y ago

> input button is hidden using CSS tricks because the actual button can't be styled. Buttons can be styled.

vinceguidry 8y ago
Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.
- jandrese 8y ago
  Heaven forbid your buttons look like buttons.
  - vinceguidry 8y ago
    shrug Fight web fashion all you want, I like the high rise condo that it pays for.
  - s73v3r_ 8y ago
    If you want to fight that fight with design, go right ahead. The rest of us have work to do.
  - jahewson 8y ago
    The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it? Why does there even have to be a button? I want an API not a button...
    - jandrese 8y ago
      Is that a problem with the file input button, or with every other button on your website? The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
      - Jaruzel 8y ago
        IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...

traverseda 8y ago

Well, it's a problem of mixing data and visual elements. In a good model of the web, html is your data, css is your styling, and javascript doesn't really exist. In another model of the web, your data would be your data, html/css would work together to form a scene-graph. Javascript defines the relationship between your data and it's scene graph. That friction, are we using html as data or as part of our scene-graph, is what causes a lot of these problems.

vinceguidry 8y ago
Thanks for introducing me to the concept of the scene-graph. I tried to make an argument on a React community slack that components are purely visual, that they should express the visual structure of the web page, in the context of an argument over how state and props should be used. He hated the rise of the Redux ecosystem, and I was trying to make the point that if you don't manage global state in your application sanely, you'll only end up reinventing it poorly, passing onChange across the Atlantic in the case where your save button doesn't live in the same visual space as the rest of your form. His response was to bring up the Router component to make the point that not all components are visual. UIs are complicated things, I've found that the visual model is the best encapsulation concept. Components aren't bad, but you need to first have a need to use them, because there's definitely a tradeoff, and second you need to use the right abstraction techniques. Routing components are a hack, different pages should just load different base components in the site backend. But it seems like once someone swallows the functional paradigmatic koolaid, they lose all perspective to see when the paradigm fails to produce erudite design.
- deleted 8y ago
  [deleted]

taeric 8y ago

The whole debate between semantic markup and visual styling in CSS looks to me to be a massive exercise in people yelling past each other and needlessly making all life difficult. I've ranted about this before, but worse is that everyone insists on trying to go with the default flow of elements as much as they can. Example I used last time was that it is actually easy to layout things and have them look pretty solid between browsers, iff you embrace absolute positioning. http://taeric.github.io/cube-permutations-1.html http://taeric.github.io/cube-permutations-1.html is a page where I played with laying out a Rubik's cube. I confess I have not tried it in all browsers, as I don't care too much, but it works in all of my browsers, including my phone. I shudder to think how I could have done that with just using floats and inline-block style concerns. Why do I claim that makes it worse? Because you wind up with more markup just to trick the layout engine to calculate where to put things. Instead of you just figuring it out largely on your own and not building a Rube Goldberg machine to layout a page. Internally for a previous company, I did this only to have the next person try to get rid of absolute positioning because "gross". Over two sprints later they caved and went back to the working solution that was a) less code, b) worked everywhere, and c) was easy to modify by virtue of a.

vinceguidry 8y ago
I like absolute positioning but it's really hard to learn how to use fluently. New devs need to be educated on the concepts otherwise you get a total mess. Flex and grid are more intuitive so they're easier for juniors to train up on.
- taeric 8y ago
  How is it hard to learn. Put someone in front of some graph paper and let them layout what they want the page to look like. Get someone a little more experienced to help them pick the points that can grow, and off you go. Not to say that they can't do better with flex and grid. But it was like our entire industry didn't even bother trying to learn with the first tools that our industry made.
  - vinceguidry 8y ago

Washuu 8y ago

The site you work on is blank if Javascript is turned off. I do not see anything in particular on the home page that should require Javascript to render.

vinceguidry 8y ago
Me neither but I didn't decide on the site architecture. If I did, it would work.

stackola 8y ago

Just thought I'd let you know, Great Big Story is running a development build of react. You save some of bundle size and performance by switching to a production build.

vinceguidry 8y ago
We're replatforming for a redesign and so that should fix that, but thanks for the heads up. Just about all maintenance on the current site is on the back burner atm except for GDPR stuff.

HelloNurse 8y ago

What do you mean by "semantic" markup? The markup in the file upload widget you describe is rather generic (label, button, p or span, presumably div) but almost completely meaningful (caption, button text, file name, widget/drag and drop target), not a div soup; I don't see how you could improve it.