I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case.
The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is just the tip of the iceberg. For each tag, I have to learn the whole history of its development and make an inquiry about what's the right way to do it nowadays.
(I don't know what tools you use so this isn't a comment directed at you specifically)
If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot.
There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and more eyes on when specs could use an update to fix our replace some of these quirks.
Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt.
But when I built a quick PoC using `<template>` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experienced developers doing web-ui development for their job, 40+ hours a week. And they didn't know, not even realized, that HTML had them covered for loads of use-cases.
Edit: I am no frontend-dev, so I have to look up everything anyway. Which is probably why I come across those "new" things easier.
Broadly, broadly broadly I agree with you and I’m endlessly frustrated with the state of React-based frontend dev.
But that said you really do get a lot more out of the box with these frameworks. Tailwind makes consistent styling far far easier. MUI helps with the same and also (often overlooked) has a lot of accessibility features built in.
Nesting in CSS became broadly supported in Chromium and other evergreen browsers a few months ago. This is a feature that developers have had to use inside of some kind of tool that compiles down to “regular” CSS since 2006. That’s 17 years. 17 YEARS.
> Even now, it’s not supported by older versions of iOS/mobile Safari which could easily be 15-20% of a large US based websites’ traffic.
Yeah, actual global support is probably still below ⅔—caniuse.com is showing global support at 72.89%, and its methodology is hopelessly broken for mobile browsers (treats all mobile Chrome/Android WebView as the latest version, which is wildly wrong), quite apart from excluding browsers that block the StatCounter script, leading to particularly heavy undercounting of Firefox and general undercounting of more conservative or unusual configurations; so the true numbers on newish features are always much worse than it suggests.
For these sorts of features, if all browsers ship around the same time, you’ll normally want to wait for about another two years before you start depending on it. (When shipped out of sync, it depends—you’ll encounter two-year-old Safari more commonly than six-month-old desktop Chrome, for example.)
Thanks, that analysis was worth adding. You're saying 2 years, I've heard other people say they would maybe consider relying on this in 5. It's really dependent on the software you work on.
So an estimate of around 20 years from the time people started using things like variables and nesting to improve writing CSS to being able to actually write real CSS using those features and actually being able to count on broad browser support.
Then I think about things like JavaScript modules, and how completely fucked up that entire ecosystem is for so many reasons.
And then condescending comments in the parent like "I think they just don't understand what can be done with just HTML/CSS these days, they're so used to complexity" - people who have clearly never worked in front-end development as their day job. It's insulting and reductive.
I am glad that this stuff made it into the spec, and I know that over the next 5 years, things like native CSS variables and nesting will become more common until Sass/PostCSS is scarce, but they will probably still be being used inside of abstractions like SPA frameworks. And all of the JavaScript will unfortunately probably be written in TypeScript.
To me, the holy grail end game of front-end development is the elimination of a build step. And for that to happen before I hit retirement we have to find some way of decreasing the lead time of innovation -> spec implementation -> browser support from 20 years to < 5 years. Obviously, browsers becoming evergreen and Internet Explorer finally dying will help. Already, simpler tooling is becoming more prominent than the dark days of Webpack. But there's still a long, long way to go. This is all assuming Google doesn't finally figure out a way to destroy the open web all together before this happens.
i've played with nesting on firefox and, much like the :has() selector, it seems good enough for the 80% case, so i wish they'd unflag it so we could get the clock started on having it be commonplace in a year or two to use it confidently.
I have never heard of this term before. But I do think it is quite apt. Is this an established concept (can I read more about it somewhere)? Or did you come up with it on the fly?
Part of the slow adoption of ultra modern HTML tags might be that the divorce from Internet Explorer 6 to 10 finished so recently that no one has bothered to update their knowledge yet. In my corporate environment, IE 11 was removed only last year.
But with just a little JS you can have a full SPA. You don't need a virtual dom to manage some HTML tags. You don't need UI libraries to render a UI. You don't need complex state management hook flow whatevs to manage some state. You don't need routing frameworks to read and write the URL. And so on.
With just HTML and CSS you can get a very long way. And if that last mile is truly a requirement, DOM APIs and a few lines of JS (or TS) have it covered. Only when all that grows wieldy do you need npm, frameworks and complex trees of dependencies.
Using your favorite language, a simple http listerner+routing and what ever HTML templating engines are supported, MPAs are simple and enjoyable to build.
I think product people enjoyed pretending they were facebook for a while and decided the world needed more infinitely scrolling SPAs and forced a lot of people into having to use react and other frontend heavy frameworks to try to wrangle all the (often times brittle) javascript involved to juggle client state. I don't think we're better off as users or developers because of this.
It's rather easy to add infinite scrolling to an MPA too, though. A few lines of JS is all you need.
I'd argue this is simpler and easier than investing in a full blown ui library and state manager or painting yourself into some corner of today's JS framework.
Covered is stretching it. Most raw HTML elements look terrible and wouldn't pass muster with pretty much anyone.
IMHO, this is a big miss with browsers. Sites look awful without styling and you have to be pretty good with CSS to even make them look passable. Way easier to reach for a framework with prebuilt components
This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway).
You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to.
Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used.
>You can style a lot of these native elements. And where you cannot, I'd argue that's actually good. I've worked with designers who insisted that everything looked and feeled the way they had designed it. But I've also worked with designers who, when showed how the date-picker looked on IOS, OSX and even Gnome, were incredibly happy that finally there was design that just followed what the users were used to.
The native browser date picker is very limited. You can't do basic things like disable weekends or select a range making it unsuitable for a wide swath of usecases.
>Point being: it will vary. But I'm certain we need all these JS UI-frameworks like MUI far less than we use them. I'm certain plain-old HTML, CSS and a little JS suffices far more often than it's currently used.
These UI frameworks are just plain-old HTML, CSS, and a little JS. All conveniently built for you to easy build a site that looks pretty good and covers most UX needs.
>This anecdote was a "pixel perfect" HTML version of some figma design. I did some CSS tricks to style the `<details>` and was lucky the designer was lazy and never specified the styles of all the dialogs around date/time pickers (they weren't that important anyway).
If you had used MUI you wouldn't have had to do CSS tricks and if it's using a small fraction of MUI then treeshaking will result in a negligible amount of JS/CSS sent over the wire. So no real performance gain, harder for the next engineer, and no great path forward if the UI needs to be snazzier. It's just worse all around than picking one of the well known frameworks.
> The native browser date picker is very limited. You can't do basic things like disable weekends or select a range making it unsuitable for a wide swath of usecases.
I think that you'd have to reevaluate your users and your use case then. As someone, like berkes, who builds sites almost entirely with HTML / CSS, it's often the case that the developer is RIGHT over what the user needs. After speaking to many clients about the limitations of native HTML elements, I've successfully convinced users to change negative browsing patterns.
Why should I write my own HTML and CSS over using what Bootstrap gives me? I can't think of a single reason to believe that my HTML/CSS will look or perform better than Bootstrap's.
Especially since you can selectively import only the components you use. You're essentially betting that you can like for like implement what Bootstrap gives you better than what they can. Which just seems like a terrible bet regardless of how good that particular developer may be.
I think what that person meant was if browser default styles made semantic HTML look more beautiful, it would probably reduce the incentive for lazy devs to make div soup.
Like imagine if every browser preloaded a dozen attractive classless CSS frameworks for users and/or devs to choose from sort of like CSS Zen Garden.
If all browsers had that, I think we'd get less div soup.
(2) There's relatively few native components and the ones that exist are limited. Like not even what JQueryUI gave you 15 years ago limited. No cards, accordions, avatars, and other sorts of basic building blocks.
(3) No real support for common page layouts. Like a Dashboard or Hero marketing page sorts of things.
This is one of the things I like best about Remix (https://remix.run) -- it leverages React in a way that "grounds" it in web fundamentals instead of piling on further layers of abstraction. Remix is refreshingly simple, and its docs are chock full of references to MDN as the more authoritative source for web platform APIs.
I mean. Doesn't it always boils down to supporting all "old/different browsers" hence why all web-agencies have to use all those JS libraries that seamlessly abstract it all?
But do you really need to support a browser that less than half a percent uses? And isn't the fallback that HTML offers out of the box good enough then?
Sure, there are those rare cases where you build an appointment system for a hospital and where laws (rightfully!) dictate that the date picker must be both accessible and working on anything from IE6 to the browser on the first Wii.
I think if the web apps we were working on were marketing landing pages, you'd be right.
For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know.
The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, they're hosted applications that have a mind boggling amount of interactivity.
Attitudes like that are why so many "real applications" have things like progress bars assembled from divs and JS instead of using a progress element or show/hide toggles assembled from divs and JS instead of using details/summary elements. Turns out there are so many HTML elements for a reason.
Everyone likes the idea of keeping things simple and using web native constructs. The problem is that web native constructs can't do the things people them to do.
Even the progress bar example is a good one. Yes, there is a minimal progress indicator element shipped in the browser. It is completely useless for all but rudimentary cases.
I am using svelte as it seems the best of both world, I can actually pretend I am just writing html and js where related pieces are colocated with a module system enough that it is actually readable while also harnessing my html and js/ts knowledge.
And since js has to be minified there's a "compilation" step anyways.
Didn't find a better solution so far. The web is almost nice to write code for.
> I have to think about labeling a input (why is this not an attribute ?)
If input labels were html attributes, forms would be much less versatile. It would merge 2 visual elements into one, which would make it hard to adjust the display (think of inputs with right-aligned labels to their left, or checkboxes with labels to their right). And a "label" attribute would mean a plain text content... Seems awfully restrictive to me.
Granted, HTML has a complex history and several layers, like anything that's been in use for decades. But it hasn't changed much recently, and (thanks, MDN) it's easy to learn learn enough to identify what is possible with HTML5 and dig later if necessary.
For what it's worth, I've found that I almost always want to put the label tag after the input tag. That enables me to select and style the label based on the input state via CSS pseudoclasses.
safari and chrome have had :has() for a while, but it's behind a flag in firefox. the firefox version is good enough that i wish they'd unflag it already (as in, it's good enough to handle this particular input/label issue for instance, but not really complex selector combinations and edge cases).
> For each tag, I have to learn the whole history of its development and make an inquiry about what's the right way to do it nowadays.
That you have to learn the semantics of the tags is inherent in any semantic tagging system. If you don't like that idea then you fundamentally disagree with the idea of the semantic web.
Of course, with any publishing system -- or any system at all -- you're going to need to learn how to use the primitives it provides to use it effectively, so this isn't really about the semantic web.
We could have had nice things.
Ssssshhh, calm down, let go.