HTML is the solution to walled-garden lock-in? What? Those walled gardens already use HTML, including some of the semantic elements mentioned (plus ARIA semantic attributes, which are much more sophisticated).
> ChatGPT-like interfaces are likely the future of human data access.
And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to process input. ChatGPT (and its future offspring) can navigate regular websites the same way humans do. They don't need us to hold their hand. They know when a sequence of paragraphs constitutes a "list", without it having to be explicitly marked as such, etc.
What the author appears to be describing is simply an API mediated through HTML semantic elements. But if you have an API, you don't need a Large Language Model for automatic data access – a good old Python script using Beautiful Soup will do just fine. And it has the added benefit that it runs entirely locally.
There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use.
Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully or poorly. An apprentice with a circular saw and a fully charged battery can do a hell of a lot of damage. A master may elect to use no tool at all and simply bang on the side of the thing (I.e. push back on the business).
The latest websites I have built are some of my most compatible ever. I don't use web sockets anymore. I don't depend on JavaScript to have piecemeal conversation with the server. You can actually use ~80% of the product with JavaScript entirely disabled. How are the engineering choices demonstrated here not exactly the solution for walled garden lock-in?
The idea of maintaining two entirely different versions of the same side gives me flashbacks to the days when they sir had a separate "m." codebase for mobile. There's a reason we found better solutions there, building and maintaining the same site twice is almost never worth it.
That may not work for a lot of sites that depend on client rendering and don't server-render the full page content
Its really easy for this to break and go unnoticed for a while as well. You could run tests against the static version, but I wouldn't be surprised at all to see them "temporarily" disabled because a new feature needs to go live and something is the breaking in the static tests
> That may not work for a lot of sites that depend on client rendering
Products that depend on client-side rendering don't deserve to have regression-free experiences. You are literally doing layout with javascript and wondering why things get funny on edge case clients.
The web is fucked until it becomes truly popular to build vanilla, SSR applications again. I feel like we are almost at the end of the tunnel of client-side hell, but perhaps some aggressive final pushes could help ship the narrative.
The server is fast. Stop doing your layout on the client. Use media queries to address the wide range of viewport dimensions. You can have a responsive website, installable as a PWA on home screen of any mobile device and also as a 4k detailed desktop layout with 0 lines of JS required. All you have to do is stop outsourcing your independence to framework vendors and pick up the MDN bible.
This sounds regressive and the battle has been over for almost a decade now. Server-side rendering is silly and client-side rendering should not be used for the entire page. Even for complex web apps, the majority of the HTML is static.
The best web experiences are static HTML with client-side rendering only used for the dynamic sections of the page. It's not even a choice to do it any other way anymore if you care about a11y and SEO.
> This sounds regressive and the battle has been over for almost a decade now
This sounds like what google would like for everyone on HN to believe.
Using "a11y" and "SEO" to push bad technology abstractions is tantamount to petty bullying in my view.
Genuinely, I don't understand the position that SSR somehow makes accessibility worse. Can you walk me through how adding more javascript on top somehow solves the problem of making a website compatible with a screen reader?
> Can you walk me through how adding more javascript on top somehow solves the problem of making a website compatible with a screen reader?
I didn't say to add javascript to make the page more accessible. I said that a static HTML page is most accessible and should be strongly preferred over any dynamic content regardless of how it's rendered. Screen readers can misannounce dynamic elements and leave the user confused about the state of the page.
But when dynamic elements do need to be reannounced due to an event, refreshing the page would be a terrible experience since the screen reader loses focus and starts back from the top of the page. Aria alerts also require javascript. It makes perfect sense that if you're pushing out an aria alert with js already that all that rendering logic should also go on the client side.
As for SEO, I'm specifically talking about good metadata in the head tag, a static page that's comprehensible, and a sitemap. Static pages are better than SSR for this because SSR doesn't always respond with the same page for the same URL.
ChatGPT (and its future offspring) can navigate regular websites the same way humans do
It seems to be at least a not-yet-true claim, but let’s ignore that for now. It’s interesting if LLMs actually could do this. As I understand it, LLMs are trained on texts and source code among other things. But lacking… let’s name it a reasoning apparatus, can they really look at a DOM tree and tell what it is/does? It’s not a text, and barely can be a well-structured source code that was ever discussed (it’s a result of either bundling or componentization). This is almost on par with “LLMs will look at any .exe and be able to integrate with it immediately”.
I am 100% sure that parent poster was being sarcastic at the hype around LLMs and how many think they can solve everything, even if said thing is impossible to do, e.g. the halting problem.
Do note that the halting problem is fundamentally true, no AGI will realize some new way around, unless are mathematics are flawed to the core.
There is some nuances here. While the general halting problem for a general Turing machine is undecidable, and with a fairly easy to understand proof as well, the computers we run today are not a general Turing machine. They are of a weaker class called Linear Bounded Automatons and for the programs they can run, the halting problem is fact decidable, on a theoretical level due to their finite nature.
So we will probably never practically solve the halting for LBAs, but the quest for this AGI that should be able to solve this, is not just day dreaming, it's rooted in the theory.
It’s fun to think about. What about the Collatz conjecture? If we run it for arbitrary n, on a computer that represents numbers up to n_max, we could know if it will halt within n_max steps. Since only n_max numbers are representable, we could track all visited numbers to detect any cycle that might occur. If on the other hand any iteration would exceed n_max, then the program would halt by crashing.
hailstone :: Integer -> Integer
hailstone n
| n `mod` 2 == 0 = n `div` 2
| otherwise = 3 * n + 1
collatz :: Integer -> Bool
collatz n
| hailstone n == 1 = True
| otherwise = collatz (hailstone n)
Edit: however, you would need enough disk space to store the cycle-detection index.
We have actually done something like that up to the 32bit n_max for sure (but maybe even 64bit?), without any number that would contradict the conjecture.
But yeah, it is not even trivial to say whether it has a bounded max memory, so in case of an arbitrary precision int type, it may not be LBA, but Turing?
I guess I was thinking about indexing the visited numbers from a graph-traversal-algorithm-interview perspective instead of a CS theory one.
We can actually do it in O(1) space complexity in exchange for higher time complexity.
For i in range 1..n, compute n_i, the ith number in the hailstone iteration, and then continue the hailstone iteration n_(i+1)..n_max to see if n_i is equal to any of them. This takes us to quadratic time complexity, O(n * n_max), or constant complexity depending on how you look at it, but it only requires storing a single n_i at a time for cycle detection.
But then again, if you actually loop for n_max iterations without halting by reaching 1 or crashing, then you had to reuse a number somewhere, so the explicit cycle detection isn’t really important.
I have to admit my knowledge of complexity theory doesn’t extend too far, but isn’t the solution to LBAs just.. brute forcing? Also, is it even decidable a priori whether a program is LBA vs requiring a tape that is not only linear function of its input?
The worst case solution is just brute forcing, yes.
An LBA is effectively "just" a Turing machine that has a finite tape.
A typical current computer is an LBA only if you disallow all IO of any sort or bound that IO and include it as part of the system you analyse and so fix the values which will be provided as IO, which of course is a very unusual situation, and so that constraint does not really make the halting problem more tractable in situations we usually care about.
The naive way of deciding it it halts is executing it and keep track of all state between steps. If the machine halts, you're done, if it repeats a state, it's looping.
If you can represent a program with an LBA, it is by definition a context sensitive language and decidable. You could also show it by making a equivalent gramma for the language, that accepts the same input as the program. This gramma must be constructed in a certain way, and then you know it is a context sensitive language.
A machine we have to today in isolation with no form of IO are not general Turing machines, but almost all of them do have that and so if you consider them in isolation rather than the full system (which would include all sources of inputs) the halting problem applies. E.g. code to the effect of "while gets() {}" will either halt or not halt depending on the input, but which isn't decidable without knowing or constraining that input.
We can certainly look for AGI that can do better at deciding the halting of decidable programs, but even for current computers the general halting problem is undecidable without adding artificial constraints.
IO is just state and can be represented on the tape. You can construct a machine for every conceivable input at every time during the execution and reason about them.
You can, theoretically, keep constructing machines for every input you need. Yes you are bounded, but you can say "this machine will halt for every input it can receive in the next 100 years", because you need to quantify the input in blocks of time.
The halting problem is absolutely solvable in some cases, it's just the general case in which it is unsolvable. If LLMs were able to decode web pages and executables in a high proportion of the interesting cases, that would already be extremely useful. Humans can't do this in the general case either, but we still hire them to do jobs like this.
Halting problem is one of the problems that arise from precise mathematical definition and its outskirts. LLMs are all about making sense from unstructured text, i.e. lying on the opposite end of the spectrum where math has no direct way to do anything. So while the poster was sarcastic, they also missed the mark.
The halting theory is analogous to Gödel’s incompleteness theorems and these are fundamental truths to any system. That matrix multiplication that deep learning does is hardly immune to that.
What. There are no proofs of convergence for many of the most popular NN optimization algos. IIRC Adam is known not to converge in some cases.
The bitter lesson is that Messy AI is better able to cope with Messy World Problems than Neat AI (by light-years at this point), not that it can hack Neat Problems.
They are fundamental truths to systems based on certain assumptions we are taking for granted, e.g. binary logic (and not e.g. quantum logic), Turing-like computing model etc. Not that deep learning has anything to do with those, but it excels in human-like properties where simple formula-derived math descriptions fail all the time.
Is a NN a computable function? Yes, as we calculate them on Turing machines. Then it is prone to every limitation of computable functions.
Humans are also limited by the Turing model’s limits, we can only ever determine computable functions as well. With all due respect, it is stupid to assign more capabilities to ML than what we know is fundamentally the limit..
While that's true, halting problem is completely useless in the real world (nobody designs user-facing apps while thinking about whether the program halts), whereas picking data from speech is a much more useful one that was long unreachable for "clean" closed-formula math.
Ok, and it is completely irrelevant. Besides, guess what enables the training of those neural networks? I’m fairly sure gradient descent has a bit to do with mathematics’ closed-formulas.
Of course ML has use cases where traditional tools are less fit, my gripe is the hype-based anti intellectual nonsense that often surrounds it. They are no magic tools, the fundamental limits these giants of math/CS discovered still apply to them and we can save ourselves from a lot of pain if we don’t bother solving unsolvable problems.
Yeah, hype is driven by business and marketing who want to sell more of a new thing pointing out what was not possible before using all kinds of silly arguments. Still, there is some noticeable progress there (compared to e.g. crypto that outside logistics and large-scale fraud didn't bring much despite being based on super solid number theory concepts).
I think KronisLV's point, presented ironically, is that not even an AI superior to human reasoning, which can figure out things we cannot, can decide the undecidable.
Being undecidable is a hard limit, not something that requires better algorithms. Another phrasing of it could be: No finite program can decide it.
(And what even is an infinite program? Not something we can run on any current computer.)
If an AI is itself a finite-sized program, something we run on computers, it cannot possibly solve the halting problem.
And _any_ non-trivial property of programs is undecidable, so an AI "integrating with any .exe file" isn't really meaningful. It's just words.
> Another phrasing of it could be: No finite program can decide it. (And what even is an infinite program? Not something we can run on any current computer.)
The complexity of the program trying to decide is not really the issue. An "infinite program" could add an infinite number of extra rules to try to cut down on the time taken to determine if a decidable program halts, but the issue with the halting problem is that there is an infinite set of undecidable programs where the size of your detector will make no difference to your ability to decide them.
E.g. "while next_symbol() == some_arbitrary_symbol {}" is undecidable unless you add constraints on the length or contents of the input.
Even if you haven infinite-sized program you can't decide whether or not the unconstrained version of that halts, because deciding it is equivalent to being able to determine if an infinite tape contains a given symbol, and no matter how long you scan the tape the symbol can always be the next one on the tape after the last symbol you scan.
> And _any_ non-trivial property of programs is undecidable
I don't think I agree with this without adding the qualifier "in general". There are a whole lot of useful properties we can decide, but often the properties will have constraints. E.g. for a whole lot of programs where we can't decide whether or not they will halt, we can still decide whether or not they will halt assuming certain properties of their inputs. E.g. we can decide the property of my pseudo-code above that it will haltIF "some_arbitrary_symbol" is in the input. We can also decide the property that whether or not it will halt in general is undecidable, and that is itself useful to know, because for many programs knowing what makes them undecidable is useful in order to suggest e.g. adding timeouts, or ensuring there are ways to bail early from certain actions without restarting the machine or killing the program.
For a whole lot of problems we also do not really care whether or not a given property is decidable. We care whether they're decidable often enough within certain time constraints, and that's a very different ballgame.
It has meaning. By looking at a table in e.g. getopt() call and an output of --help I can often infer modes of a program that I probably need, to do my job when someone asks me to. Whether this getopt() gets called or if a program does what it claims in usage() is not my concern. I was commanded to guess the usage and I do it without burying into the halting problem. And so does that hypothetical AI.
Decidable or undecidable is about maths, not practice.
That’s still a stupid pedantry, and is even false.
A Turing machine only makes use of at most n cells of its tape after n steps - so running it for a finite number of steps is possible even in finite memory. Especially that modern computers can do arbitrary side effects, having access to the whole universe as tape, which is still finite, but so is time.
There is no way to differentiate between a magical Turing machine with infinite tape and a “fake” one that has n-sized memory under any program that takes n steps, so for all practical purposes they are identical.
A Turing machine can either go left or right on its tape (some versions have a stay step as well, doesn’t matter). If all your program does is step right forever, than it will use the maximum amount of memory, but only ever a finite amount, that is equal to the number of steps taken.
So if you don’t have infinite time (you don’t have), and you have big enough memory for the particular use case so that you don’t get OOMKiller involved, then you have a Turing machine for all complexity theoretical and practical purposes, especially that RAM is not analogous to the Turing machine tape - your computer has much more state than only its memory, if it has network access, you can basically make use of a cloud vendors whole army of servers as storage, just as an example.
The reason for undecidability of halting is that a program's state may grow without bound. If a program's memory usage is bounded, its halting can be determined. So the computer is not like a Turing machine since its programs don't use Turing machine's key feature - infinite tape.
Although the naive way of deciding halting requires exponential time in program's memory bound, AGIs will speed that up for many programs by using clever math.
"ChatGPT (and its future offspring) can navigate regular websites the same way humans do"
I don't know how much deeper it goes, but it does have some context:
Prompt: Given this html, what does an end user see?
<div style="display:none">hello</div><div>you</div>
ChatGPT:
An end user would see only the text "you" on the webpage.
The first <div> element has the inline style display:none, which means it is set to be hidden, and its content "hello" will not be visible to the user. On the other hand, the second <div> element has no specific display style, so it will be visible, and its content "you" will be displayed on the webpage.
> can they really look at a DOM tree and tell what it is/does
Yes, if you encode the DOM as a list of options for ChatGPT to choose from. In fact I developed a proof of concept of this for a client. https://jarvys.ai/ although they seem to have pivoted from automating just the browser to automating all software.
Well if the DOM is all unstructured divs with no semantic information, can a human even tell what it means without applying the structural styling on the page?
A good example would be a misguided approach at making a bunch of labels with values that are aligned. Someone told this poor developer that <table> is bad, so they figure hey, let's use CSS to lay it out. They make a dictionary of the key/value pairs and iterate over all the keys in the first column into the first div and then output all the values in the second div.
div
- label 1
- label 2
div
- value 1
- value 2
If there's 100 key/values it's going to be hard for a human to figure out which value is for the 76th item, and LLMs have proven to be very bad at indexing problems like that so I wouldn't expect it to be a better story there.
(Not saying this wouldn't work in some cases, just couldn't be a general solution given the crap out there)
if you encode the DOM as a list of options for ChatGPT to choose from
Not sure if I understand this, does it mean you have to pre-cook DOM in a specific way? If yes, then isn’t the answer to my question “no”, like “no, it can’t take any site and use it as is”?
You have to give GPT an objective, like "find an apartment in Florida" and then say something like "given the following options, which one would you interact with to get closer to your objective."
So if you assume that you start on google.com, then your options are like
1.) Input with name "search", placeholder "search anything", value ""
2.) Button with label "I'm feeling lucky"
3.) Button with label "search"
Obviously, doing just one of these doesn't achieve the objective - it just needs to pick which one it thinks has the most "value" for completing the objective. If you repeat that enough times, then it can actually do what your overall goal of the session was.
I'm just giving a simplistic answer, and if you implemented only what I've written, then it's going to get stuck in a loop more often than not. But that's the gist of how you could encode the DOM into something that GPT can interpret and make decisions/take actions based on.
Remember HATEOAS? I have a feeling LLMs would excel at navigating proper REST (not "RESTful") APIs - HATEOAS is, in principle, just what you did here: providing a list of possible/useful next steps along with the response.
In fact, the problem of HATEOAS is exactly what LLMs seem to be good at - inferring the interface at runtime, from dynamically received metadata. This should even be easy to try in practice today - HATEOAS can be trivially mapped to the "function calling" feature of OpenAI's GPT-3.5/GPT-4 APIs.
I would guess that it's just a matter of converting the DOM accessibility tree into text descriptions, e.g. "There is a button that says 'Start'"
And then converting text like "Click the Start button" back into an actual action on the page.
I got the sense that the article was advocating for using good semantic machine readable content over HTTP instead of (or at least in addition to) JS-only div soup so that automated agents like the new wave of LLMs can easily pull out the important details without spinning up a headless browser and rendering the page first.
I have the same interest but for the purpose of crawling and upstart search engines. If indexing every page required running the page in a headless browser first, the barrier to entry for new search engines is a lot higher.
ChatGPT had a Browser Plugin (via the Plus subscription) but last I checked it was removed, (possibly because it cannibalized Bing? Or just the reliability issues).
AI in general could "see" a website like we see it. But LLMs specialise in text. They will find it much easier to figure out the correct semantic interpretation of tag soup than deriving the same information from the rendered output like we do.
Also, the big question is cost. I think semi structured text will forever be far cheaper for an AI to process than a completely unstructured data stream representing visual information.
> And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to process input.
I don't require a cup to hold my drink. That doesn't make cups useless or undesirable.
Point being: if a machine can make sense of the veritable clusterfuck that is the "pile of infinitely-nested divs" status quo, then surely it'd have a much easier time making sense of pages that actually use HTML properly. If you're an AI trying to figure out how far along something is, which is gonna be a more obvious indicator?
An LLM is much slower and requires more resources at runtime than Beautiful Soup (if you are hosting yourself), and could fail to retrieve data. It's a worse solution unless your HTML parser/scraper is broken by website changes.
This is only the case for now, however. I expect this to change in favour of LLMs as time goes on and they become easier to deploy and better at their job.
Completely agree with you. The magic of LLMs is being able to chuck it an unstructured mess of data and have it parse and interpret this data in some semblance of the way that a hooman would.
LLMs will only get smarter, and we can only guess what comes after the transformer model anyway. LLMs atm have the very obvious problem of appearing smart but not quite getting all the way there; I think this is pretty much down to it simply trying to predict the next token at its core. Perhaps we'll see something smarter when figure out that an LLM should only be used for output of semantic natural language and not ideation/conceptualisation (which should be handled by a separate model that deals in abstract concepts).
But if they first need a browser to chew through the usual tens of megabytes of javascript so that they can finally get the 100KB DOM to parse through, they'll be way less efficient (and often run into the token limits) than if the page has some nice semantic HTML with some optional JS for interactivity (that the AI doesn't need).
Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever."
I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it. As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out. Eventually in principle both the semantic web and that pile of heuristics are entirely replaced by AI.
(Note also my replacement of LLM with the general term AI after my first usage of LLM. LLMs are not the whole of "AI". They are merely a hot branch right now, but they are not the last hot branch. It is not a good idea to project out the next several decades on the assumption that LLMs will be the last word in AI.)
Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.
Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for.
I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though, I bet they could do it, or get very close.
80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perform the manual testing need to be experts in semantic HTML and ARIA to be able to identify problems and create reports. That means that semantic HTML remains important.
>80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments.
That's if you want actual accessibility support on a wide range of old and new devices.
But the business idea the parent proposes is automated accessibility for compliance, which is the real thing that could be sold, and has a much lower bar.
My estimate of 80% included 6-12 months of serious development first, and a certain amount of budget for manual intervention for the first several dozen jobs. Certainly just flinging HTML at ChatGPT as it stands today would do nothing useful at all. Providing manual testing could easily be done as part of a higher service plan. Not only is there no rule that a startup using AI has to be just in the form of "throw it at the AI and then steadfastly refuse to do anything else", that's probably a pretty good way of filtering out the ones that will make it from the ones that won't.
Do assistive technologies have more "bugs" and "quirks" and "different behaviors" than natural text? I don't really think so. In fact I'd expect they have qualitatively fewer such things.
Semantic HTML would be important in this case... but it would be important as the output, not the input.
This hypothetical startup could also pivot into developing a better screenreader pretty easily once they built this, but there would be a good few years where an AI chewing on the HTML and HTML templates in use by a server would be practical but you can't expect every assistive technology user to be using a 64GB GPU to run the model locally. Certainly that would factor into my pitch deck, though.
I'd give more credence to the "it has to be perfect to be useful at all" argument you're going with here if it weren't that I'm pretty sure every user of such technology is already encountering a whole bunch of suboptimal behavior on almost every site today.
Unless it’s 100% reliable or near 100% reliable, you’d still need manual testing. Right now, automatic accessibility testing can’t even detect most accessibility issues. So we haven’t even reached the stage where all issues are detected by tools, and probably never will. Fixing all issues automatically is significantly harder than detecting them.
>Unless it’s 100% reliable or near 100% reliable, you’d still need manual testing.
Not unless:
(a) it's X% reliable now, and it would be Y% < X% if done via LLMs.
(b) businesses actually care for increased reliability, and not just for passing the accessibility requirements.
Most businesses could not give less f...., and don't do "manual testing" today either. Just add the token required tags. That's true even when they do business with the government (which mandates this even more highly).
LLM-driven accessibility info would be an improvement.
The idea generalizes. Imagine an archiver which applies a transform to a site. Adding semantic markup - or censoring parts that someone finds offensive. If the original author agrees, they might offer an api so the transformation is linked to by the original. Or perhaps the transformer could make an agreement with/fool Google into linking to their version rather than the original. Perhaps because it's "safer".
If semantic HTML is important for accessibility and for software to be better able to parse information out of it, and AI solves the latter, semantic HTML is now less important because some of the use cases that needed it previously no longer need it. If you take "less important" as a moral/value statement instead of in terms of total utility provided, and assume that AI will have zero accessibility benefits, it will merely be as important as today, which is still at odds with the assertion of the original article that it would become more important. N.B. this seems doubtful, given how e.g. you can now past a bunch of code into an LLM and ask it questions quite naturally -- something I can easily see adapted to e.g. better navigating apps using only voice and screenreaders.
This has been tried and doesn't work, which doesn't mean it will never work in the future! There are a few companies offering solutions in this space, but they don't work, are often worse than the problems they're trying to solve and are a privacy disaster. The companies peddling them often engage in shady business practices, like falsely claiming that their overlays can protect you from ADA lawsuits[1], while actually suing the people who expose their lies[2]. Most accessibility practitioners and disabled users themselves are warning the public to avoid those tools[3].
AI will solve web accessibility by screen readers that summarize visual content, ignoring ARIA and making it irrelevant. Multimodal GPT-4 can take a screenshot jpeg and answer questions about what’s in it (buttons, links, ads, headers, etc). The future of accessibility is rendering DOM to jpeg and asking GPT to be your eyes; we’ll look back on semantic markup as a failed idea that was never going to work
I am curious about what post-LLM SEO is going to look like.
> The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it.
Arguably, there were insufficient incentives to fully adopt semantic HTML, if your goal was just to have the most relevant parts of your content indexed well enough to get ranked.
> As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out.
If the goalpost shifts from “getting ranked” to “enabling LLMs to maximally extract the nuance and texture of your content”, perhaps there will be greater incentive to use elements like <details> or <progress>. Websites which do so, will have more influence over the outputs of LLMs.
Feels like the difference between being loud enough to be heard vs. being clear enough to be understood.
> The semantic web has failed and what replaced it was Google spending a crap ton of money
Aren't schema.org and Wikidata/Wikipedia still powering most of Google's rich search results?
I heard them announce the new result page with bard but I probably didn't see it because of ad-blindness or it's not yet releases in my location, have to look this up...
Well schema.org was not referring to an organization or entitity, but its published schemas.
I'd argue these were and are driving a lot of rich results, especially for local businesses.
AIs are magic to me. The pattern recognition feature of human I've always thought pretty unique and hard to replicate. We use it when scanning the slop on websites to do some kind of data extraction. I was part of the semantic web camp in my brain, but you are right, if machines can seemingly make sense of the slop then why bother?
agree so much. Projects that aim to build a data resource and then let AI use that resource are missing the point. The AI is the data resource.
Some projects claim that knowledge graphs or other data assets can help the AI retrieve 'true' knowledge. Personally, I believe that the better approach is to develop methods that allow AIs to create their own data assets, the weights in their networks is one of those assets.
The question of truth is still a very hard one. How do you tell an AI that some knowledge is more trustworthy than other knowledge? People have this issue too though.
While the issue of "truth" is interesting and important, it is also fairly orthogonal to the task of simply extracting what a given page or bit of content claims. (Perhaps not 100% orthogonal in the absolute limit, but generally so.)
As absolutely hard as I have gone against the semantic web community at times over the post few years, I do not in the slightest hold a failure to "determine truth" against them. I consider them to have been tilting at windmills as it is, criticizing them for failing to conquer that windmill, which humanity has been jousting with since the dawn of recorded history (and probably beyond), would be a degree of cruel I couldn't entertain. :)
what projects are trying to use knowledge graphs to retrieve truth? i've been playing around with that approach. how do you encode your own "truth" that may be different from anothers?
literally by no metric is this true other than tech bros saying it on HN. The entire internet is powered by websites using semantic markup and clients querying it.
I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager).
I'm starting to think my dream browser might be something like visurf https://sr.ht/~sircmpwn/visurf/ but with the underlying Netsurf engine updated to support various modern HTML+CSS, such as these elements. I bet you could have a nearly JS-free smolweb through that browser that:
1. is more accessible (in the "doesn't break screenreaders, system theming, keybinds, etc" way)
2. could be made to use way fewer resources than these heavy JS contraptions these elements can replace
3. would still be able to do most things we expect the median web app of today to do (sure, fire up Firefox for WebGL or whatever still, but I could see, say, a Matrix client potentially needing only a smidge of JS (largely for WebSockets and E2EE stuff) over top of very-modern HTML)
In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app.
They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you full power, works identical on all systems, etc.
In the end all these extra components just end up as bloat all browsers have to implement but no one uses.
Unfortunately this is a case where we'll have to agree to disagree. Half the time with Electron apps I wish I could disable CSS completely and just use my system theme because it sucks less than whatever the designer came up with for that app (the definition of "sucks less" falls into many axes that vary per application and context; no point in digressing far into that), so what you described would be a feature, not a bug, to me.
(Further, I basically never, ever want an app to theme itself. Ever. If I set a system theme it's because I want the system to look like that. I've gone on tirades here and on other forums for years about finding https://stopthemingmy.app/ and even just the freedom of every electron app to pick its own HIG and UX as absolute heresy, so if nothing else, my opinions are consistent here.)
I couldn't agree more, unfortunately we are a minority :(. Before react was mainstream, you could "fix" websites pretty easily with things like greasemonkey, but even that is super painful now. CSS modules mangle classnames, so every new version (which are pushed multiple times per week/day) will break your naive css modifications. You can't naively modify DOM elements because React will overwrite them almost instantly.
I know you can write regex in your CSS selectors and use MutationObserver's to update the DOM after react and co are done with it, but it's just so much more painful. Something that used to take maybe 1-2 hours to get some site working/looking how you like it, is now a part time job.
This is what really bugged my about “portable” Java apps way back. Java Spring was especially noticeable. It stuck out like a shore thumb compared to the regular system UIs.
Some like Magic User Interface for the Amiga, but across Operating Systems, and which provides the resulting stylesheet to the browser (with no ability for sites to override it unless I allow it) would be my dream and a marketers nightmare. Just information and media, displayed how each person prefers them to be displayed (and obviously with a lot of user made themes for people to browse and try out). With sub-configs like super-compact, whimsical etc. that users can apply to individual apps and sites.
JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility.
Take the datepicker; the native mobile version works great, why annoy users with a custom component?
Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.
My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.
That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.
That's totally on point, but I think the core issue is less about "why the native date picker isn't always appropriate" and more "why do we keep half-assing non-native alternatives?"
The way I see it, so much of the web is a clunky mess precisely because software development today pretends to be engineering while simultaneously being about the bottom-line and little else. No doubt, a great date picker could be developed in JavaScript that would serve everyone's needs, be totally accessible, and not a bowl if <div> soup. So why don't we do it? Why are what should be basic HTML forms on corporate websites difficult to navigate or in some cases fundamentally broken, requiring workarounds? Nobody is interested because solving real problems doesn't carry any of the prestige of building another framework. Who wants to build a date picker that is standards compliant when you could write another web framework, bro? Even if a developer is not trying to build the next React, they're probably spending more time on their toolchain than actually coding. It's gotten so bad that seemingly every company I've joined in the last 6 years needs a bunch of people dedicated to maintaining toolchain and CI crap for the rest of the team.
I love programming, but the web needs to get its head out of its own ass. We're acting like our jobs are more important than the value the software delivers, and more effort is being put into making sites impractical for machines to parse (because muh intellectual properteh!) than in making web components that aren't riddled with bugs.
There’s a little more harshness than needed in your comment, but I generally agree with it. Having brought this up before, I’ve usually seen either no or strange reactions to it. It feels like web dev consists of people who only have done their job for an unknown faceless client sitting behind layers of teams and toolchains. Driving to a specific person, listening to their brutal feedback on your system and being asked to maybe fix it right now would be a sobering experience to some of them.
You're absolutely right on the 'why' part, but sadly a lot of custom implementations are annoying in terms of UX and accessibility. My only point here is that building proper custom components is far from easy, it takes a lot of time and effort.
* Can and often does accidentally place the user in American-style MM/DD format where it should be European-style DD/MM (I have a replicable case now on that page example).
* No ability to force date style by design. So there's no way to fix the above from the server, or to use ISO-style dates. Only way to reliably prevent MM/DD by default is to fix every client configuration - not very likely even in small companies.
* No way to have the datetime dialog open by default.
* Poorish but getting better keyboard support (the pagedown-up keys finally work in most browsers, but once you've opened the dialog you can't enter a new date with the keyboard).
* Timezones must be handled separately, which is just poor design.
> ...place the user in American-style MM/DD...
> No ability to force date style by design.
There is datetime-local, date, and time. And there's a lot of control over what is allowed with min-max ranges, steps, etc.
The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird; or at least not a problem a web-dev should solve.
> Lets you enter nonexistent dates like 31/2
This may be an issue in specific browsers/versions/os. But enabling the "validation" by setting required and/or some other attributes, gives an error for these dates AFAICS. But, in any and all cases: server-side validation is needed anyway. You just cannot trust a value sent by a user, whether that's "validated" with sixty npm-packages and their dependencies, or by the browser.
>The only thing I can imagine to go wrong here, is when a user has their browser set in US-en but when they are not aware of that. Which seems... weird;
Legacy Edge used to look at keyboard locale and ignore the actual region settings. I have no idea why chromium uses MM/DD on my machine when Firefox does DD/MM. Back when $COMPANY used HTML date widgets we got a small but constant stream of complaints which we tried to triangulate (that's how I know about the Legacy Edge behaviour), but we never understood most cases.
Autodetection has been broken on a tail edge of cases for a long long time, and nobody in browser space seems to have any interest in fixing this - or worse, allowing the server to set the correct date style. The only practical fix is JS datetime widgets.
>or at least not a problem a web-dev should solve.
I think 'a not-insignificant amount of people constantly enters the wrong dates and eventually bothers support and writes bad reviews, plz fix this' is a good business cases and is something web-dev should try to handle.
>> Lets you enter nonexistent dates like 31/2
>server-side validation is needed anyway.
True, but it's a better user experience to disallow this also on client. If we only let the server do validation, why do we even bother with the SPA and the sixty-thousand one-line npm packages?
I normally use en_US but I want dates formatted as DD-MM-YYYY (or using dots, slashes etc ) and I want a 24-hour clock.
LC_TIME does not work very well with most apps.
And there is a big difference between just throwing an error if a date-time cannot be parsed because of a nonextent date, and communicating it to the user in a nice way, especially without using JS.
But the webdev has to solve this problem. Users with wrong locales and not aware of that are not very uncommon. I would also love the US to fix their stupid date format and even fully adopt the metric standard but sometimes you have to compromise and write code instead.
WRT dates, there's no "metric" standard. Not really. E.g. Belgium commonly uses DD/MM/YYYY whereas the Netherlands uses DD-MM-YYYY. Both use "metric standard" for lengths, weights etc. Same with currencies: "13,37 €" vs "€ 13,37" vs
"€13,37", all depending on where in Belgium you are from, vs Dutch in the Netherlands. It's an utter mess.
Which is another reason to let browsers - the user agents - deal with this. There's absolutely no way a lonely JS dev, or even a community around something like MUI to get all this right. And they don't. There's always something broken for me with these custom elements. If it's not some US-centric web-app enforcing their MM/DD/YYYY format, then it's some "ignorant" dev being unaware that in Europe in many countries decimal separators are a comma, or that in Thailand the current year is 2566 and that this is not "too far in the future".
> the native mobile version [of datepicker] works great
Strong disagree. It does work for simple forms, but definitely has a variety of quirks on different browsers/devices. Blank dates are especially quirky. Try “tabbing” through a date on iPhone or iPad and have some poor UI. datepicker really doesn’t work well for some less common situations (cut n paste, copy, from/to date, restricted date min/max past/future, year pick, month pick, etcetera).
This is my biggest criticism of all these modern HTML pseudo components. It’s a wonderful idea, truly, but if you don’t provide style hooks to customize and theme them they are useless.
A month ago I wanted to use the input + datalist to have a searchable drop-down but there was no way to control where the dropdown will appear when popped open and what width will it have. Eventually I just gave up. Such a shame.
100% agree. One big challenge is that we've made browsers and the full list of web specs so complicated that we're likely not going to see any new browser rendering engines competing any time soon.
Ideally we would all take a bit of a step back and throw out old specs that aren't needed and improve the ones that need it, like styling support for built-ins. Unfortunately we're at the whims of Google and Appe though, and I can't imagine they would ever be interested in such a potentially large rewrite to their browsers when it functions as-is
<progress> requires some vendor-specific prefixes last time I tried theming it using CSS (unless you're using "theme" to mean host system/window mananger/browser - wide theme). There is no common subset (that I am aware of) of CSS properties shared amongst browsers that can be leveraged to even decently change the <progress> element's appearance. So I'm not sure that it is the best example.
I agree that many of the list _are_ themable enough to warrant investing the effort to wrangle their particular interfaces over reinventing them entirely with <div>s.
I think the idea is rather, that you "extend" by composing primitive elements, and not that you change the primitive elements. Kind of like "composition over inheritance".
Take the html select component, you can't extend or compose this in any way. A request so common that it goes without saying is that you should be able to search for items. This is impossible to implement with the default component.
If you want to do another common thing like allow selecting multiple items, this is also impossible. It's not worth starting with the HTML one and then extending later because there is no path to do this. You have to totally scrap the HTML version so you may as well start with a JS library that does everything you need today and everything you will need tomorrow. Which you can theme to fit in with the rest of the app rather than looking like a pimple on a pumpkin that UX and end users spot and complain about instantly.
I think you misunderstand what I mean by "compose".
You can compose most HTML elements including <select> easily:
<label>
What do you like?
<select name="choice">
<option value="first">First Value</option>
<option value="second" selected>Second Value</option>
<option value="third">Third Value</option>
</select>
</label>
There you go, you did composition. The logic between those elements, how doing something with one element affects the other element, that is a different matter.
For some elements it might be invalid HTML if one is inside the other. Like a <div> inside a <span> or so.
>And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app.
Wouldn't that be a feature?
"Modern looking" as far as I'm concerned means "Can't figure out WTF this bloody thing is." and that assumes I even know there is a thing in the first place.
I noticed this helping an elderly neighbor with her banking. "No, you don't click there, but there... you can tell because..." then realized there's literally no way to tell. It's all flat.
then realized there's literally no way to tell. It's all flat.
I hate that. I'm waiting for that fad to be over. I kind of liked material design, but it's too much of a pain to put into everything. Flat, borderless, and unidentified is so easy to do.
The all flat approach encourages dark patterns. Lists of trackers you can opt out of, scrollable, with no scroll bar and no window border. There are important buttons hidden which, if pressed, do things favorable to the user but unfavorable to the site operator.
Also, the pop-up box with no visible dismiss button, just an "x" which appears if you mouse over it.
A non-web example - someone made the console window in Ubuntu borderless. If you have two console windows overlapping, you can't see the boundary.
There is something nice about plain old <button> default look and feel. It probably is the kind of feedback they give, that does not require me to always roll my eyeballs elsewhere for confirmation, that my click did actually cause some action to start.
The flat look is borrowed from phones, from UIs where buttons were few and large, and the concept of "mouse-over" is not meaningful. Now it's everywhere, even for complex interfaces where it's not appropriate.
The process pretty much started with Windows 8, which was released in 2012. I don't think the flat style will go away anytime soon. At most, skeuomorphic elements will be slowly phased in. Material design at least adds shadows, and "neumorphism" adds back some 3d popping out, although I haven't seen it much.
Windows 95 was probably the optimal UI—in the Windows world, at least. Meaningful buttons, a reasonably-contained set of components, proper scrollbars. I'm not sure what the next major revision was after that (98 didn't change that much, IIRC) but I bet it was probably a regression.
I think the idea was that when dealing with UI elements where it can be unclear what even is a UI element, it's easier to shape user behavior. e.g. making it harder for the user to "opt out of all tracking".
Those cookie consent boxes are definitely full of dark patterns. My "favorite" one was one that would take 45+ seconds to save your changes. I sent a complaint to the company that makes the consent box, and they responded "website owner configured it incorrectly, nothing we can do" LOL
I just ran into "datalist" and my first impression was "wow, game changer". The behavior is the same across browsers but the appearance is strictly browser-specific. You can't style it with CSS.
Sometimes the list displays the text of the data, sometimes, the text and the "value" attribute. So you are not selecting "Atlanta" - you are selecting "234290780 Atlanta" (the ID and the value).
And with the on-click action, you can't just get the ID - you have to get the whole thing and parse the ID out.
That's am incentive alignment problem, browser vendors' job is ultimately to make money not improve the specs.
Anyone that's interested can get involved in the specs process though. If anything it's web developers who haven't done our job there, it feels to me good specs are more our concern and responsibility than anyone else's.
This is also why I think frameworks like Flutter that render everything to canvas are going to become more and more popular over time - as more and more WASM standards are implemented in browsers.
HTML will be used only for docs and not for web-apps.
Unfortunately, I suspect that this is 100% intentional. datalists can draw outside of the browser window, which is fantastic, but also probably means that there are security considerations for letting it be styled by users. Imagine malicious ads/websites being able to draw outside the browser window.
Hahaha wow I have to say that was the least convincing demo I’ve seen.
- Fills history with massive amounts of entries, and back button doesn’t do anything
- Slider UI look like crap (ok fine, can be fixed) but use not just css but SCSS (requires a precompiler) but wait, not enough, it also needs hardcoded number of images. It’s not reusable in the most basic sense.
- Input validation has phone number on xxxx-xxx-… format and doesn’t fill dashes automatically. It’s also type=number which opens a numpad on iOS which does not have dashes available at all. I can’t proceed unless copy pasting a dash from somewhere else?
- Gave up after that but I’m sure there’s plenty more
Yeah, I’m leaning towards that JS isn’t the nemesis of accessibility. It’s simply not knowing what works and testing properly. It’s funny that frontend folks are seen as lesser beings and then counter-claims like this is passed as enlightened. Yeah on first glance maybe, but it’s proof that these regurgitated claims are made with very little insight. Like all tech, you have to know how to hold it right which takes a little time and humility to get right.
And yes, we still use too much JS. But it’s not the fault of JS or dev practices that we have newsletter popovers, cookie banners and 100 ad delivery and click tracking requests per page load. Indeed JS became extremely bloated for a while but nowadays everything is equally bloated, just look at all the backend snake oil with 1000 cloud microservices and leftpad-like APIs.
I disagree. I've built entire sites that rival the most popular SPA's today with HTML / CSS and a tiny bit of JS, and I've had less issues with those than other sites at my agency built with a JS framework. User reports often come in telling me "Wow, this site is so good! I'm really glad you took on this project".
It tells you, by looking at a thin bar, how far down the page you are! What a novel idea!
I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll.
(Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horizontal scrollbar just won't show until you interact with the keyboard in some way).
FF devs have to justify their jobs like any other. Someone was promoted for shipping a fancy-looking feature that some other browser, somewhere, probably has as default.
Still better than the Borg, at least you can fix it.
Yeah, seriously bugs me too. Scrollbars were one of the most powerful, useful UI components out there, and we had to sacrifice them because of mobile, for some reason.
Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.
Level 0 developer: don't know how to do this in JS
Level 1 developer: knows how to do things in JS, even when sometimes it should not
Level 2 developer: knows how to do things without JS
Level 3 developer: knows when to use JS and when to use CSS or something else to achieve the goal
I was more the opposite. I avoid learning JS for as long as possible since it seemed so complicated following the resources I tried to learn.
Ideally we’d have just a few more semantic elements that are obvious common patterns introduced to the HTML spec (like details & dialog were). We’re pretty close now, but I would like to see better accessible no-JS options for building menus.
Seems like aot of people misunderstand what these examples are best for. Sure you wouldn't want to ship these as-is on most sites, but it shows how much can be done without JS. That can/should make it more clear that you can likely get by with much less JS when you do need to reach for it.
It's not about throwing out JS, it's about avoiding 30kb of JS if all you need is a few summary/detail elements where only one can be opened at a time. Use the example code here then write a small I line script that closes all siblings. Done.
> I had heard of almost none of these HTML elements
I'm not disagreeing with the gist of your post, but come on, these elements have been around for ages. It's definitely on you to become acquainted with the basics before your HTML critic can be taken seriously ;)
The post links to MDN (arguably the most useful short reference) but there is of course also WHATWG's HTML spec or, if that's too voluminous, SGML DTD formal grammars for WHATWG HTML 2021 and 2023 snapshots [1], as well as for the older HTML 5.x series.
When I use the datalist element with a text input, Chrome shows an arrow on the right and the list drops down when you focus the input. Firefox, however, shows neither until you start typing, at which point it suggests just those items that match your input. So there's no way to see the full list of options.
I think Chrome's behavior is correct here, but the larger point is that precisely because these are native elements, when they don't work there's nothing you can do. So your only option is to reimplement them from scratch.
Datepicker was fundamentally broken in many ways in safari for a long time. And it still doesn't have the functionality that most apps need, so it's pretty pointless.
<abbr> has always been interesting to me. I've been aware of it for as long as I can remember, since it's been in all the tutorials I remember reading as a teen, and other docs as I got older. Unlike some other forgotten elements, it's one that's clearly very useful, and yet I can count on one hand the amount of times I've seen it used in the real world (yet plenty of times where someone has reinvented it with JS)
Likewise, image maps. Remember messing about with those when I was young, but Wikipedia is the only place I've seen them used. To be fair, the UX isn't great, and I've often ended up navigating to an article when I was expecting to view the image page instead
Everybody was using imagemaps in the 90s because it was the only way to have multiple links over an image, something we wanted to do because without CSS we could not have a row or a column of buttons with fancy colors and fonts and placed where we wanted them to be. So nav bars were a large image with imagemap anchors placed over the buttons.
Then we got CSS, tables (used for layout!), divs with positioning and eventually the features that web developers are using today.
I've used qutebrowser off and on for many, many years. At the end of the day, it's a skin over QtWebEngine, which uses Blink under the hood, and thus contributes to Google's overdominance of the web and the standards that define it, so I try to avoid it, despite it being a better implementation of a Vim layer than, say, Tridactyl for Firefox is (in my opinion).
Beyond that, QtWebEngine is about the polar opposite of the type of engine I described in one key area: resource usage.
Extensibility is the problem here. Either you force everyone to use the a limited set of UI controls (won't happen) or you need to allow some way to create custom UI controls, which leads to JS (or some other programmable system).
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.
After a few years of dabbling with Flutter I just came back to the same conclusion: bet on HTML.
Astro / Tailwind / Daisy UI / Alpine.js makes it lovely to build an HTML site with a lot of simple SSR and a little bit of client side reactivity peppered about.
The result is simple sane HTML files that look and work great on desktop web browser and and mobile wrapped web view.
My app is basically static so it caches in a CDN, works offline, and view source makes it easy to debug.
After trying a bunch of fancy frameworks and platforms I ended up doing exactly this - a static site with alpinejs and tailwind. It has been by far the best decision I've ever made. And the best thing is I'm confident any new dev will be able to pick up my 100 line build file and grok it in about 3min. No matter whether they're react, angular, PHP or python folks - it's dead simple and I love it.
Lately I've been doing raw html and css. No build. I just write the files. It's really easy. Yeah there's some duplicate code in the header but grep is not that hard to use.
i am building sites with aurelia without a build system. there used to be a quick-start tutorial where you could just download an archive with aurelia ready to run. no serverside tools or build tools necessary at all. it even used to work loading the whole app via file://... back when browsers still trusted that. it no longer works only because of browser restrictions on using file://
I use Flutter for some web apps, it works fine. It's good for web apps, not web sites, and compared to other desktop or mobile apps, there is literally no difference between rendering on a canvas to rendering on Qt or SwiftUI. People, in my experience, just get up in arms about the web that does not happen with other technologies.
Do you realize that Flutter has an accessibility system that is often more advanced than most desktop UI frameworks? [0] I notice this often from non-Flutter devs, Flutter has some pretty good a11y.
I don’t know if even that was actually true? As far as I know the moment they introduced canvas as a rendering target they also produced a DOM structure along side it to capture the accessibility tree as they were still waiting on a more native solution in the form of AOM (accessibility object model) to be finalised.
The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the <main> tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of <main>, <aside> etc.), very little sites use it properly. Even the fancy professional sites wrap all the page content, including navigation, footers and the like inside the <main> tag, which should only be for the main content of the page.
If such a simple element can't be used properly, I have no hope for all the others.
literally every developer who has ever used a `<p>` tag for paragraph has used it properly. An `class="card"`. A `<link>`.
How are so many tech literate people in this thread bemoaning the "uselessness" or "failure" of semantic web? It's like if you told me "Man I wish motorvehicles were successful, it'd sure be nice to travel long distances!"
> simple element can't be used properly, I have no hope for all the others.
The first solution that comes to mind, is stricter validation. Where the browser would just refuse to render a <footer> properly unless it's structure is correct.
But we had that. Anything before HTML4 really. And it sucked even more.
So maybe browser dev-tooling that throws warning or errors when devs are Doing It Wrong?
Give me an incentive to use it. If it looks exactly the same and behaves exactly the same, "div" is half the characters of "footer" so it wins.
Personally, the argument that search engines will do nice things with semantic HTML didn't convince me back then, and I don't even see it brought up today, because search, like fish, stinks from the head, and we stopped pretending otherwise.
So that leaves accessibility. Is there a way to visualize what screen readers to with a page? I know about the tools that check for missing ARIA roles and whatnot, but that still doesn't catch me using a div when I should have used aside. And I know I won't try to navigate and use every aspect of things I make by actually using a screenreader. Call me lazy, but that's just not going to happen. But I also don't want to just give up and make it the problem of other people, either. I wanna meet halfway if possible. Any tips or tools or ideas welcome.
Maybe invest in an editor that helps you write ooter></footer> after typing f in the correct place. If amount of characters truly is your reason to avoid semantic markup.
I am not "avoiding" it, I am not going out of my way to implement something that has no effect on anything, other than taking up more characters in files.
If semantic markup is so important to you, give me a reason for why. If the reason is "because I told you so", you just added a reason not to do it.
The browser approach is best effort at rendering, rather than enforcing conventions.
And I doubt that tooling can help with all the complicated ways in which HTML is generated (React, SSR etc). I was actually surprised at how underbaked editor support for CSS is in VSCode (the most widely used frontend editor). If the most modern tooling can't understand that a CSS variable is declared in a different file and autocomplete it for me in a .vue file, I get the impression that tooling is severely lagging behind the frameworks.
There simply is no incentive whatsoever of using them correctly. I try to use them correctly but aside from the time spent in deciding what each element should be there were no differences at all
I find it interesting that many of the comments here seem to view this as an anti JS article. To me a lot of these are going to be immensely useful tools in combination with the TS heavy frameworks we use for modern Enterprise App frontends, exactly because they are HTML native tools that aren’t going to require a bunch of stuff.
Like the meter tag, which I assume will replace every loading module we currently use in React when I get to work today because that is soooooooo much better than what we currently use.
But maybe I’m just misunderstanding people, or the article in some way. But to me this is very interesting even if your entire frontend is basically all TypeScript like many larger applications are today.
I think (at least with my comment that's one of the kind you alluded to) my hope is that it replaces huge piles of JavaScript code. I have, sadly, no illusions of a JS-free web, but at least we could get rid of huge gobs of it and have more-standard UX that the system can help guide and shape (with the benefits that entails).
It also enables a whole slew of new applications to be made that need way less JS than we used to need. So while, sure, these might be in-place "upgrades" for existing Enterprise TS apps, the hope is that it'll allow shunning those Enterprise Frameworks entirely for net-new app development. Or at least, a boy can dream, right?
I've worked with Enterprise Frontends since the Mainframe CICS systems and I'm not sure why things like React and Angular gets such hate for Enterprise apps. I can't think of a single way of doing client server applications in an enterprise setting that's ever been nicer to work with. To be completely honest CICS was better than most GUI attempts from Java and C#, and it was a console UI.
I'm not saying JS frameworks can't be overused. I'm not personally afraid of the page refresh, but it's not like it was a joy to work with websites before these enterprise frameworks.
Maybe WebGPU and to some extend WASM (and whatever is going on with that) will change things, but probably not.
I’m not sure about that. Some of the ASP web forms frontends that I build something like 13 years ago are still being happily consumed today.
The only thing enterprise really cares about is money, and IT getting in the way, in any way, is costing money. Web fronts have been instrumental in cutting down the hate on enterprise applications in any org that I’ve worked with over the years. You’d see something with a great WPF frontend score a 3/10 and something with a shitty Vue frontend score 9/10 because it just worked, was never slow and “never needed to be updated”.
I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of date. Not updated or whatnot. There's still lots of fire once and forget sites. Probably because budgets are tight and people can't afford updates. Or the updates are just technically too difficult for people to grok.
The complexity of sites is paralysing. What could be a few simple pages of texts and images is totally over-engineered for no good reason and is burning a stupid amount of CPU cycles. Probably built on a hacked off-the-shelf CMS that could do with security updates.
CMS and frameworks are being used, because there wasn't a good alternative to something as neat as frames.
A site I'm working on at the moment has quite a pretty design, but pull the CSS and it's just a mess.
I was looking at going to the cinema recently and the local picture house made it practically impossible to just scan the handful of films that were playing that week. I realised you could pretty much shove it all in a spreadsheet and it would read better. Heck, I downloaded the JSON from their API, and it was easier to read.
Most of it is all tiresome lipstick on a pig.
Facebook was a success for a few reasons, one was the easy on-boarding (which uses nefarious privacy trade-offs), the other is that you could actually share photos easily. Also see: Whatsapp and Instagram. Publishing needs to be easy. And despite a simple FTP being easy, there's a weird disconnect in the usability process that makes this tricky for mere mortals. People want to drag and drop, or upload, fire and forget and edit easily. And those wanting to consume data, really just want the bare essentials: The data.
> And those wanting to consume data, really just want the bare essentials: The data.
I don't think they do. The average HN reader, probably; but not the average person.
What they want is a well styled and usable webpage. Unfortunately, there aren't enough effective and talented UX designers (or stakeholders at companies with decent UX intuition).
This leads to the current situation where the average person would be better served by bare essential data, even if it's not their preference, because it's still better than the kludgy UX average design a company is able to afford.
{bad UX} << {raw data} < {good UX}
The end run around this is what WordPress realized: create professional styles/themes and allow users to purchase and apply them. But that can't solve bad stakeholder taste.
Which brings me back to Facebook, which I would argue succeeded because it standardized and mandated a professional UX.
{data from people} + {professional, standardized UX} = {winning}
You can dislike the original Facebook UX, but I don't think anyone would claim it was amateur level work. Which is what everyone's perception of MySpace/Geocities et al. was.
You hit the nail on the head when you mentioned WhatsApp. In my country in Africa WhatsApp is so popular so much so that mobile network providers even sell WhatsApp data bundles. If I want to find something, like wire fencing I start by asking WhatsApp groups I am in. Family, neighborhood and even high school friends. Typically I get a few numbers and then I WhatsApp the service provider and I get up to date information. The service providers can't afford up to date web sites. WhatsApp also has a feature to include a catalogue in your profile. This is for business accounts which are also free.
That's why I suggest for most small business to use Wix. Does your site tend to look like everybody else's? Yes - and that's not necessarily a bad thing, and since it's so easy-to-use and update, customers will appreciate having the up-to-date information they need.
What I'd like to see (maybe it exists, I haven't looked in a while) is something I would market as "Wix Widgets." These would be data-connected widgets where there's some customization to wire-in a REST service call and map the data points to the widget display. This would go a long way to handling the needs for internal-facing web sites every company has these days.
We really need simple solutions for the 90%-95% of web pages out there.
It's funny how I hear that web platforms are the best and most consistent cross-platform GUI systems, but then building on that system is awful.
So I'm wondering if maybe this is just the nature of GUI. Where you have to give every single instruction, eat up a bunch of cycles, or it simply won't function as cross-platform.
I don't think it's that funny, given that "best" and "most consistent" are both highly subjective.
I am a huge fan of the HTML/CSS/JS stack—it's far, far easier to knock up simple GUI-based apps using those technologies than, for example, the Visual Basic / Delphi tools that we were all using beforehand. And, remember, apps are not really what HTML was ever intended for, so any kind of 'app' support is a big bonus.
Funny, I grew up making GUI apps on VB (and then VB.NET) using Windows Forms and I've always found it really easy compared to the web stack. You're not fighting against a flow algorithm that was designed for documents, trying to position your widgets in ways NCSA Mosaic wouldn't ever had dreamt of, it just works.
Part of this is the ever increasing amount of tags and elements in HTML files. Instead of being a document markup, it's a page markup, and it's difficult to discern where one stops and the other begins, although the W3C has tried with the addition of article and section elements. But then I suppose the raw HTML code was never meant to be read by other than devs in the first place, so there's that.
There was that small window of niceness, where the html diminished in size. Now it's just all pseudo inline styles painted by class names with lashings of scripts. Always surprised when you peek under pretty much a bereft page of nothing and it's a whole heap of code.
I'm one of those annoying people that just uses reader mode anyway - not that it always works. Because I get fed up of zooming in and out, inflating text size etc etc.
This is why I want a browser where I can use Reader Mode on everything. Not just articles and blogs but also forums, q&a sites, online stores, image galleries, video sites.
Because of this I don't bet on the web because it's really designed to be an app framework now (admittedly the best one) not for being a simple client that sends and receives data (like XMPP, SIP, IRC, SMTP, IMAP and NNTP).
ugh I was so excited to see pure HTML modals were a thing with <dialog> only to find out there's no way of triggering them without JavaScript. Using pure HTML you can only dismiss them, not trigger them.
> dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a <dialog> you need to use JavaScript to set the open attribute.
> It'd be great if there was a way to make a <a> or a <button> elements capable of opening dialogs.
> Precident already exists for page interactivity baked into HTML - for example <a href="#.."> can already scroll the page, and <details> elements are capable of hiding elements behind interactivity, so I think it stands to reason <dialog> elements could be opened by other page elements.
I don't see the higher purpose of "HTML only" if that means we need to extend HTML with scripting capabilities. In that case I rather just use JavaScript.
Users might prefer, say, that 99% of the time a data selection widget behaves the same whenever accessed by their browser. When devs choose a JS UI library then that's usually what users get. Wouldn't it be good to have all tables have the same features (sort, collapse, column-select, data export), rather than only having rich features if the dev implemented them, duplicating the effort of millions of other devs.
There's a sliding scale here, with html at one end and each page ships a parser and libraries at the other - why have an img tag, just let the page developer implement a JS based interpreter?
There are useful tricks to changing CSS properties via checkbox state and pseudo-selectors to implement simple modals (which won’t be accessible), but you can’t open a modal <dialog> element without JS.
Weirdly, you can close them with a form submission, but you can’t open them with one.
I didn't realize some of these elements existed. Neat!
However, I think if we want an open/federated system to win, we need to make it compelling to normal people. That means making it fun and entertaining. I've found that no argument about freedom, privacy, or anything actually important will work.
The point of walled garden is that they are very tempting to stay inside off for users. Their power comes from most users not resisting that temptation.
Becoming the equivalent of a digital hermit and living in a hole in the ground outside these walls, which is what I would characterize this as, is not going to result on a lot of people stepping outside those walls. If you've ever watched Life of Brian, you'll have a good mental picture here.
It's a variation of brutalist web development (let's not call it design) that just doesn't really appeal to the masses. It never has. The history of the web is endless attempts to pimp it with Applets, Flash, Shockwave, Silverlight, etc. The latest incarnation of that is web assembly. This basically allows you to use anything native that works elsewhere (desktop, mobile, game consoles, AR/VR, etc.) in a browser as well.
Of course there's a severe risk of this to disappear into more walled gardens. But I don't think sitting in a dusty old hole in the middle of nowhere while shaking your fists at progress does much to change that.
Sometimes though, that dusty hole in the middle of nowhere seems to be the most progressive in terms of using standards, when the person sitting in it adopts new HTML elements, immediately having accessibility, while their JS-based rivals still struggle with restoring the functionality of the back button and adding routes in their SPA to get back something resembling normal linking behavior. In a way that is a much deeper dusty hole in the ground to dig for oneself.
Anyway, it is questionable, how much progress there is in moving into walled gardens and throwing multi megabyte websites at visitors, when we can have the same functionality with less.
I think there's a middle ground here where we're building good-looking web pages with a sub-10 MB weight. Unfortunately, it makes no business sense to do so.
I would care more about markup if the browser would actually be able to do anything interesting with it, but for most part markup is a just a default style for an element, the semantic meaning is ignored. The <time> tag is about the last one I can think of that actually made a difference from the users perspective.
There is also a lot of markup for really common tasks still missing, I'd like to see an <advertisment> and something to handle pagination at the browser level (rel="next" has been around for decades, but browser don't care). And more broadly, I'd really like to see much better support for long-form documents in HTML or at the very least native ePub support in the browser.
What is the author suggesting? That instead of "social" networks, people will rush to building their own online presence from first principles?
I can't see that working, for so many reasons:
- most people are passive consumers of content, maybe interact a little, enough to tweak their feeds
- a small minority creates content on the large networks / aggregators, and (I think) a large portion of that is spurred on by monetization
- the "internet" and all the devices that access it have become so "user friendly" that the people who have come online in the last decade or so are effectively technically illiterate; you cannot count on them building anything from scratch, only to arrange the big duplo pieces already provided
You have just highlighted the main fact about the www that so many technical skilled people are missing to see. Most consumers have little to no knowledge about anything technical, which is not bad at all since there is no reason why they should care. Now imagine telling those people that everyone should have their own website instead of a social media account. What a horrible and illogical thought in my opinion. Digital consumers only change behavior if something is 10x better. So from a consumer perspective, who cares about things like decentralized networks? Or Duckduckgo.com for example is probably for 99% of the www users some chinese russian inbreed virus. People started using ChatGPT besides google because it is simply 10x better for many cases, and not because it promoted with more privacy feature and less ads than google.
Hey OP, I notice you're using Berkeley Mono, which is beautiful. But your website's CSS appears to be applying boldface on an already boldface font in the headers (despite the typeface name claiming to be 'Regular', it is actually bold; see the datasheet[1]), which is causing bad hinting. Consider changing your typeface file!
Thank you, I believe I have fixed it. TIL variable fonts on web are not great! AFAIK they don't distribute the regular/bold/italic/bold italic 4 font mix?
Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2]
Quoting from the doc here's the stack:
- WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being actively extended with features such as WasmGC.
- WebGPU provides an API (to JavaScript) that exposes a modern computation and rendering pipeline.
- Accessible Rich Internet Applications (ARIA) provides an ontology for enabling accessibility of arbitrary content.
- WebHID provides an API (to JavaScript) that exposes the underlying input devices on the device.
This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.
> On its HN submission (referencing the wrong URL) he defends against criticism [1]
And it's a very weak defence. There are great rebuttals to whatever he writes in there.
I mean, he rants that HTML failed, and then literally proposes "By providing low-level primitives instead, applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures, enabling a much richer set of interactions and custom experiences with much less effort on the part of the developer."
Has he tried to implement any of those from scratch using only low-level primitives? How is it "much less effort on the developer"?
In general it just reads like a justification for Flutter:
"This API alone is not useful for application developers, since it provides no high-level primitives. However, as with other platforms, powerful frameworks will be developed to target this set of APIs. A proof of concept already exists in Flutter"
Why not provide high-level powerful primitives out of the box? Oh, then Flutter wouldn't have a reason to exist.
So what are these great rebuttals? "Why not provide high-level powerful primitives out of the box?" <- the browser is a 30 year effort to do that and has always failed at it. This thread is full of people complaining that the browser implementations of even basic widgets aren't usable, of course any higher level or more complex features are often missing, and that's with web tech relying heavily on patrons that have budgets the size of the Sun.
So in practice most devs bypasses them and write their own high level primitives anyway, relying on the browser only for low level APIs. That's the point the article is making. Hixie is merely observing that this situation exists, has always existed and probably always will, so browser makers may as well embrace it. And if you see the discussion thread, that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy. And then just tell web devs to adopt a high level framework that isn't HTML.
Those that you apparently read but didn't understand.
> the browser is a 30 year effort to do that and has always failed at it
And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work?
> browser implementations of even basic widgets aren't usable
The problem with the basic widgets is not that they are incomplete, but that they are not enough. Almost any attempt to re-build even the built-in widgets sucks and fails in numerous ways. Now Hixie wants to remove event that and pretend that building all that from scratch is "easier for developers".
> that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>
Here's what that PM said, verbatim:
--- start quote ---
No one needed <section> and <aside> they needed <tabs> and <accordion>
Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.
--- end quote ---
How you read this as "give up on HTML tags" and "refocus on obscure features" is beyond me.
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).
--- end quote
But sure, "give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy". Making the platform be only extreme primitives will definitely not make framework authors happy.
You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic.
We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems
In other words, the Chrome team (today) assumes the use of frameworks as a given and sees their job as empowering frameworks. Note that "devs" here clearly refers to framework authors, the sort of people who architect component systems. She doesn't mean app devs.
So HTML as an all-inclusive app framework is going to die, arguably has already died, and the argument between Hixie and stubbornella is just an argument about what specific way to empower framework authors. Hixie argues that the focus should be on features for big frameworks that skip HTML entirely, stubbornella argues for features for smaller frameworks that still use some HTML, but they're both in agreement that raw HTML is just kind of useless and not the way devs want to go anymore. After all "state queries" is not <tabs> either. There's less between these positions that may seem.
Now the real question is not could browsers theoretically ship really great HTML widgets. Sure, there's no rocket science in GUIs, in theory, browsers could do this. Yet after 30 years of immense effort they don't do so. That suggests some deeper structural issue. It might be team scalability issue. Chrome has a truly enormous team, but clearly they're struggling to do everything people might want from a browser. All that code has to be maintained after all, so as Chrome gets bigger we should expect them to slow down. Since the death of plugins the web is a completely monolithic platform. Given a choice between implementing some API that only a browser developer can do (e.g. WebUSB) or implementing an API that devs can hack up their own alternative to (a widget), it's clear why they always choose the former. Anything that browser makers can push off to web developers they clearly will, because there's so much to do that can't be pushed off in that way. Hence why HTML is still a poor UI toolkit and why JS frameworks are so widely used. It's a division of labor issue.
Ah, that is enlightening, thank you. I knew he works for Flutter, but I know very little about Flutter and the standards it uses. That WebHID I hadn't heard of till this doc, so figures if this is a non-standard. More Google worrying power play then, similar to the web integrity bomb under the open web.
> I wrote this post and then GPT-4 fixed my grammer and spelling
I wrote an Autohotkey + Go script that I constantly use for fixing grammar using ChatGPT's API. You can select the text, press F8, wait a bit, and your input will be replaced by correctly grammatical text. The only catch is that it "fixes" the tone and makes it professional, which is kinda annoying.
Alternatively, you could set up LanguageTool[1], which runs much faster, is more reliable, is open source, and, crucially, doesn't require sending what you wrote to a server on the Internet. Plus, it already has high-quality integrations with standard software like LibreOffice, so you don't even need to write anything yourself.
Grammer, should of, datbase, mangement, timzone, accept/except, except/expect ..... We should accept these as part of normal written conversations and try to understand the context. With the amount of AI-generated content that is being produced, misspellings should be celebrated!
But who am I to say that? I am literally converting my rants on the internet into professional arguments and using sophisticated synonyms like the architect from the Matrix. "Ergo", I am part of the problem.
I'm going to have disagree with you on misspellings. AI can trivially replicate them (the Elizabot you used to get on old school BBSes would make deliberate mistakes/corrections) and they just make it ever so slightly harder for your audience to parse what you've written. If nothing else - expect/except sounds quite different from a screen reader.
> The only catch is that it "fixes" the tone and makes it professional, which is kinda annoying.
Then why send your text to a slow third-party in the first place? There are craptons of spelling and grammar checkers available which will work offline, be significantly faster, consume less resources, and not change the meaning of your text. We solved this problem decades ago, we don’t need to shove AI in everything.
It’s not like the ChatGPT solution is flawless anyway, there are still basic mistakes in the text:
Grammar checkers are essentially typo checkers and are not context aware to be truly grammar checkers. Context aware grammar checking means the program has to consider each line of text and identify grammar mistakes. As traditional grammar checkers check typos in real time, every mistake you do is flashed in front of you. You have to stop evaluate, fix and continue. This is distracting.
My solution is to get your thoughts immediately out of your head in a big chunk. Check the grammar of that chunk of text in a single button press wait a few seconds and then just paste the text.
The tone shift is good in technical writing, but in forum style communication it kinda dehumanizes the comment. But it is not a major thing.
I use grammarly pro, but I find this solution to be extremely robust as this solution is platform and software agnostic. Like writing in my text editor - LiteXL.
Please feel free to give this method a shot for a week.
---
Edit
---
Grammar Checker with ChatGPT
Grammar checkers are essentially typo checkers and are not context aware enough to be considered truly accurate grammar checkers. Context aware grammar checking requires the program to analyze each line of text and identify grammar mistakes accordingly. Traditional grammar checkers usually highlight typos in real-time, which means that every mistake made is immediately brought to your attention. Consequently, you are forced to pause, evaluate the error, correct it, and then resume your writing, creating a distracting workflow.
My solution is to encourage you to initially get your thoughts out onto the page without worrying about the grammar. In this approach, you can check the grammar of the entire chunk of text with a single button press, wait a few seconds, and then conveniently paste the corrected text.
The tone shift is acceptable and even beneficial in technical writing; however, in forum-style communication, it can somewhat dehumanize the comment. Nonetheless, this is not considered a major issue.
Although I personally use Grammarly Pro, I find this solution to be highly effective as it does not depend on any specific platform or software. For instance, I can comfortably write in my text editor, LiteXL.
Please feel free to give this method a try for a week.
---
Grammarly Pro
Grammar checkers are essentially typo checkers and are not context aware enough to be considered genuinely accurate grammar checkers. Context-aware grammar checking requires the program to analyze each line of text and identify grammar mistakes accordingly. Traditional grammar checkers usually highlight typos in real-time, meaning every mistake made is immediately brought to your attention. Consequently, you are forced to pause, evaluate, correct the error, and then resume your writing, creating a distracting workflow.
My solution is encouraging you to get your thoughts onto the page without worrying about the grammar. In this approach, you can check the grammar of the entire chunk of text with a single button press, wait a few seconds, and then conveniently paste the corrected text.
The tone shift is acceptable and even beneficial in technical writing; however, forum-style communication can somewhat dehumanize the comment. Nonetheless, this is not considered a significant issue.
Although I use Grammarly Pro, this solution is highly effective as it does not depend on any specific platform or software. For instance, I can comfortably write in my text editor, LiteXL.
Please feel free to give this method a try for a week.
> As traditional grammar checkers check typos in real time, every mistake you do is flashed in front of you. You have to stop evaluate, fix and continue. This is distracting.
Or you can disable that feature (or the software entirely) and do a full pass at the end. You’re not forced to do live checking.
> Please feel free to give this method a shot for a week.
No, thank you. I have no desire to send what I write to third-parties I don’t trust. Also, your examples were far from compelling. I’d rather not have my words padded with fluff.
In a world where pages takes x10 more time to load than to render some hyperrealistic scenes in AAA games on some Unreal Engine 5 with 140 fps?
Yup, I’m betting too on a front-end stacks that change every 6-12 months but only lead to more and more poorly optimized websites.
Half of the times even mobile apps are useless, when they can’t download a freaking JSON response in areas with poor network coverage.
> Pretty much you can highlight text. By default Safari shows a yellow highlight. I like it!
Chrome also shows a yellow highlight by default. But since I don't have Safari installed on my machine, I don't know if it's exactly the same color. Also, I'm not sure if other browsers have the same default color. Isn't it a good use case for CSS?
CSS will let you choose the highlight color for your readers. Semantic markup lets the reader choose the highlight rendering, including the choice of leaving it to the browser.
A blind reader can configure their client to speak highlights.
Of course it doesn't need to be one or the other. You can still use CSS to give the highlight a uniform colour, while allowing for reader modes to still have the highlights and have the accessibility of the screen readers speak the highlight.
Semantic markdown and CSS should ideally be seen as complementary and be used as such.
I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume).
That said, this is me speaking about htmx based on what I know about it. They may have some tricks up their sleeves these days to account for those issues. But those tricks would need JS.
That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multiple extra round trips and device speed/power. And you could get into the hydration and SSR mess, but then you could just render on the server in the first place and simplify the entire system, reduce your LOC by 5x, opt out of the entire js ecosystem shitshow (or keep it for select high interactivity components, I won't judge), and eliminate an entire api that doesn't need to exist.
If you are building the next google maps, maybe htmx isn't for you. But if you're building another LOB app with mainly forms and data views, or an ecommerce site, or another CMS, there's a 99% chance that htmx is plenty.
Personally, I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing here: https://github.com/infogulch/caddy-xtemplate I'm currently co-developing this with an rss reader webapp to work out the kinks.
I almost have ptsd from these dark days, I won’t go into details ;-) but there’s plenty of literature about separation of concerns. Having the templates doing the data access takes me back 20 years ago, but I can see why this idea comes back in a web component era.
I actually like htmx (I find Unpoly superior so that’s what I use, but it’s the same general idea) and the example given makes sense, but one should not extend locality of behaviour to the point of sprinkling SQL in templates. I don’t think that’s what the htmx folks had in mind in this essay either, their canonical example being the html/css/js trio. But hey… there’s no better experience than first-hand experience, you will find soon enough if it works for you.
I agree that it's taking the idea of LoB to an extreme that wasn't intended (at least not explicitly) in the essay. But I still don't see why it's a bad idea considering that SQL-level abstractions (views, procedures, etc) are available. What value does adding a layer of application-level abstraction provide? So I have to name and call a function that calls the sql; to what end?
There’s plenty of literature (and debate !) about mvc/mvt (and its numerous variants and interpretations) in the context of web apps. It’s interesting that you challenge the consensus though.
You make good points. And these are different use cases, where one is simple client behavior where JS is suitable, whereas the other needs a round trip anyway.
I wouldn’t go as far as 99%. There are a lot of web apps where you toggle between panes, expand certain things, and so on. But I think you are still right in the sense that htmx is a very fruitful starter kit that can cover many if not most “boring” standard use cases.
One thing is for sure, this SSR hydration shit show is not a good state of affairs. It’s way too much complexity for what it does. And now you have to worry about reaching the same logical state from two different starting points.
> I'm betting that you can make a whole interactive site on top of Go's html/template library + htmx, using a pattern I'm developing
This is cool, and indeed reminiscent of PHP. Cycle of life!
Some social networks used to offer rich page customization with Wiki or markup or something like that. And that essentially was the HTML wheel reinvented. Some even offer in-app apps, some even lock whole life oof the whole population in them (e.g. China).
A social network with (or without) this essentially is reinventing the wheel of the whole Internet which is made of HTML pages (which are replaced by personal pages on a social network), RSS/ATOM (which is replaced with in-app notifications), e-mail (which is replaced with in-app direct messages), Usenet (which is replaced with in-app groups) etc. Everyone theoretically could just have a personal www page on their own domain instead of a social network account.
Oh, and HTML never needed CSS to be not ugly - that's the browser default settings which make unstyled (styled with default styles) HTML pages look this way. We always could just change the default fonts/colors or apply a userstyle for more complex things.
Once general population joined to the Internet (where in the past there were only nerds) the demand emerged for it to become much easier and prettier and the corporations responded offering the features pople want taking their freedom, privacy and independence in exchange (which an average person doesn't mind, all they ace about is that being "for free"). We could just build better apps (browsers with sensible defaults, intuitive e-mail and Usenet clients and web servers), but we still lack them because nobody wants do serious work for free and make great products which would suit everybody ather than themselves.
You don't use CSS just to make pages pretty. It is useful for accessibility and user experience as well. Not to mention personalization. Not every page needs to have a carbon copy style of others. CSS is so useful it is almost ridiculous to say HTML never needed it.
> CSS is so useful it is almost ridiculous to say HTML never needed it
I didn't mean CSS is useless, I meant it is not necessary for every website to define their own CSS to look nice and not ugly. The problem is almost no ordinary user knows they can define their own defaults (fonts, background - in browser settings, more complex - in user CSS).
Long, long ago, when i first learned that i could define my own (css) defaults on my browser, my mind was blown! I can't recall if it was back in netscape navigator or early fireforx days...but learning the command path from the menu to "turn off css styles" (View -> Page Style -> No style) made me feel like some sort of superpowered being! lol :-D More seriously, it actually helped me better understand the web, html, web pages as documents "downloaded" by the browser, etc. I became a much better web dev for it - beyond feeling like i had more freedom due to software/app.!
Not sure why people are banging against css. Its just fundamental separation of content logic from content representation which is best practice (see e.g grammar of graphics)
I think people are just burning out from the oppresive tech environment, the endless hypes, the lack of a feel-good factor. All these negatively experienced developmemts are taking their toll. This forces people into all sorts of extreme corners, like the gemini protocol or css-less sites.
I'm aware of all these HTML elements, I use them for my personal digital garden website that just uses CSS grid to align everything, no external scripts or styles.
Guess what? It still looks bad! The <summary><details> element for instance is hard to style with CSS, things don't work the way you'd expect. Frankly that element was leapfrogged in terms of usability and customization by pretty much any jQuery accordion script from 2009.
HTML was designed as an SGML application for networked hypertext.
As an alternative to what the original post posits, we could leave it for that purpose, and design another (now XML) application for user interfaces: windows, buttons, scroll bars (if desired), text controls (no I'm not talking about textarea for CGI), the kind of controls that Windows or X11+MOTIF provide, expressed as tags in a UIML (User Interface Markup Language). This would have the advantage that we could start from a clean slate, and the open source interpreter for this technology could be integrated into all Web browsers, so behavior would be identical.
UIML would be designed as an XML application for networked software applications' user interfaces.
Of course, you could execute them locally, too. There could be graphical UI designer of the types that already exist, e.g. Visual Studio would just write out a UIML as a new export format.
Crazy idea? Actually, it's just applying the "Do one thing, and do it well." mantra to XML <-> XHTML + UIML instead of packing everything possible into one now-bloated markup language it was never designed to do. So if this comment had a title, it would be "I'm betting on Internet standards" (plural).
It's been done many times. Mozilla had XUL. Internet Explorer had XBAPs (XAML Browser Apps) [1]. Android has an XML UI language. Java has FXML, which IMHO is the cleanest and nicest of the lot.
It never works. Same reason as to why adding non-JS languages never works: because making a GUI toolkit or implementing a language is a huge amount of work, other browser makers refuse to get on board because it'd mean they're playing catchup. Then web devs refuse to use it, because not every browser supports it. The only acceptable way forward is to gradually glue lots of small things onto HTML, and see which ones get implemented by the others. Because this is such an incremental and random process you end up with a pretty inconsistent platform that lacks a lot of stuff you'd intuitively expect.
Wouldn't that be XUL[1] ? It's been there since 1997 and never took off outside of Mozilla, so it was deprecated and removed in 2017. It wasn't meant for use in the wen directly as replacing an entire ecosystem with a completely different way of doing UIs would be close to impossible, all for small benefits.
I agree with this idea. We need a toolkit standard for the web and to stop shoving application code into a document model. What's strange to me is that so many people have been trying so hard to either resist or deny this.
The proposed solution is a non-starter, though. Anything involving XML is probably DOA for the web. I know I don't want to touch it. But something needs to fill this space because UI on the web is so god-awfully atrocious.
I'd argue that the modern markup elements you're showing are still way off from what the Semantic Web (as Tim Berners-Lee proposed) would enable. Image the possibilities of an 'AI' if it could understand the relationships between data and not just be a statistical parrot like LLMs are.
Combined with something like Solidproject, that give users back control over their data, THAT would be a major leap!
I've been doing web development full-time for nearly a decade now, and I didn't know about all of these. I think I failed a job interview last month because I didn't know about <datalist>. Sigh.
Yes, always bet on HTML. I made the chart here in semantic HTML with a definition list, which is also keyboard accessible, and overlaid by a canvas: https://www.skrill.com/en/currency-converter/ – no libraries needed.
> With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever.
It's odd: I remember seeing an argument recently, though can't remember where exactly (perhaps [0]?), that LLMs make semantic HTML obsolete, because they "understand" the text anyway.
After all, humans didn't need html to be semantic in order to be able to read it — machines did. And if machines are approaching humans' capability to read texts, then doesn't this put the whole semantic html exercise into question?
Humans interpret text as rendered by the browser. That includes a lot of visual information and even text that only becomes visible in response to user interaction.
For an LLM (or an AI in general) to do what humans do, it would have to process the rendered output and interact with the site like we do (such as clicking on a dropdown to make the available options visible).
The same information represented as semantic HTML (i.e text) is far cheaper to process for an AI. I think cost is a key consideration in everything AI. If it's too expensive then it won't happen, even if it could theoretically be done.
>> Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time.
Why do I want to make my website AI-accessible? It, or some mega-rich company will reap the rewards, not me.
You'll be fine. If anything CSS is the one thing that's gotten easier in web dev. It might take some time but you'll be able to grok it for sure if you've dealt with old school CSS.
Easier? Well, even if you don't have to deal with legacy styling (which had moments of insanity, like floats, and other things which were fairly reasonable, like tables, br, b, i), there is so much new CSS to replace the old: variables, transforms, complex animations, using borders to make arrows and other visual content, in flow vs out of flow, container queries, view transitions api, px, pt, em, rem, vh, vw, query units, initial vs inherit, vs unset vs revert, new color formats, a million new properties for the complexity of interactivity with the gamut of user agent form factors
You know what? I'm going to stop because the list goes on and I don't even think I touched on 1% of the "new" CSS
These days I mostly just use tailwind. It gives me a sane, easy to work with api, and the updates are a more manageable trickle than a deluge
>In fact, recently I’ve become acutely aware of reader mode. All time spent on styling will be obliterated by reader mode, and that’s a great thing!
Reader mode is mostly for longer text. Doesn't help with WPAs as much.
>Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time. The shift from primary data interfaces to secondary interfaces is already underway. RSS refuses to die. ChatGPT-like interfaces are likely the future of human data access. We’re going back to the beginning. Advertisers may be scared, but I’m not! Let’s start the revolution and set the world on fire with modern HTML.
Not sure what this (the most important part) attempts to say.
What does the advent of ChatGPT-like interfaces have to do with "adopting modern HTML" and "proper tagging"? If anything ChatGPT-like interfaces would require less tagging, and can do the "figuring out what the text is" part of semantic web without sementic metadata (and they can do it directly on the actual text, whereas the metadata would more likely be abused and misleading for SEO).
I noticed <details> made the list but not <summary>. Is the latter a well-known tag compared to the former? In any case, semantic HTML is nice because they usually have good accessibility attributes by default.
In general, <summary>, <details>, <aside>, <main>, <nav>, and <dialog> prove to be highly useful for quickly hacking together a personal site without having to write much JavaScript, if at all.
Amusingly, the MDN guidance [0] on <em> vs <i> is exactly backwards from the example they give a paragraph below:
> The <em> element represents stress emphasis of its contents, while the <i> element represents text that is set off from the normal prose, such as... when the text refers to the definition of a word instead of representing its semantic meaning.
And then [1]:
<p>
In HTML 5, what was previously called
<em>block-level</em> content is now called <em>flow</em> content.
</p>
...which would be an exemplar case of when to use <i>.
I thought <em> was semantic ("emphasis") and <i> is stylistic ("italics")? And last I heard (when <em> came out) you weren't supposed to use <i> anymore because it's bad form to use HTML for styling! Much like <center>.
Yes, that was the mantra some 15–20 years ago. Then HTML 5 came out, in which <center> was indeed obsoleted, but <i>/<b>/<u> weren't and instead got a semantic meaning. (A semantic meaning which, admittedly, is subtle, borderline esoteric, so it's very rarely used as intended.)
Links are represented as portals, and unlike in VRChat you can just walk straight through them like in the Portal games - allowing one to "walk through the web": https://youtu.be/jYQtAcQddRg?t=48
Now, language models can generate HTML, and I feel this may be an opportunity to revive it again. To generate VRChat rooms, you have to learn Unity, which is heavy and has a steep learning curve. But if you can go from a text description to HTML, then you just need a text file!
> I believe we now have virtually a complete set of all UI elements needed to build any modern web application.
This is pretty far from the case. Three examples:
* Dropdown menu. This is a superset of selects, which can only contain options: a dropdown can contain anything in its dropdown, including a nav which contains links displayed as icons, for example.
* Carousels/slideshows.
* Tab areas.
I've got a library of these kinds of elements implemented as CustomElements, but they're pretty geared toward the websites I've worked on in the last year, so I want to spend more time making them extensible before I release them as open source--I don't want people depending on my work until they are better-designed.
That said, HTML by default has gotten a lot more powerful than a lot of web devs know about. In particular, there's a lot of custom data lists and date pickers out there which are less powerful than the built-in HTML datalist and input type='date'
I think the #1 issue with HTML (and CSS) is that it is portrayed as being trivial, easy, "not a programming language". Someone who has written a few `<td>` "knows HTML". It's not respected. Consequently, people don't invest time in learning to use it well and keeping up with new features. And then they use it poorly, or run into awful examples of it, and come to the wrong conclusions about it.
While the idea of a markup/styling language is pretty simple, HTML+CSS deal heavily with difficult concepts like ontologies, cascading and non-imperative behavior, balancing UX & machine interpretability (accessibility), etc. Add in HTTP and browser APIs. Web dev is distributed computing par excellence, and is extraordinary deep and challenging, yet it's also viewed as among the lowest forms of programming. That's a big mismatch.
Good luck making anything complex by relying on a bespoke library for DOM updates. In contrast, React became a breath of fresh air, emulating the game development approach to rendering new frames: just literally rebuild the components.
Yes reactive UI is the only thing I can’t live without. React, Svelte, Vue are all fine. Trying to mirror state into and back from DOM manually is absolute disaster.
I really hope this becomes standardized at some point. Would be great to have consensus around.
There are probably occasions where that is the whole reason I pulled a JS framework in, since default alert boxes are horrible and anything better is a heap of work to do in a nice looking yet portable way.
It only exist because browsers decided to remove alert/confirm/prompt. Before this it existed in a limbo plagued by so many issues that Chrome even suggested to remove the spec.
None of the issues were fixed. But within a year from Chrome's botched attempt to remove alert it suddenly shipped in all browsers.
It's about structuring text with a consensual function as every tag has an intention implied. Creating sites and webapps using this, results in a less contradictory foundation of the text and elements exposed in the UI.
I've been meaning to build some utility websites like a simple forum and a simple pastebin and the like for a while just entirely without javascript, kind of like the old days. I want a simpler web with less bloat.
I'm not javascript free, but i've been actively pursueing building useful things with as little if any javascript and have been impressed with what I can get done with forms and html templating.
A few years ago moving to a new area I was trying to find a CPA and saw simple brochure sites are loading 10+ mb of resources and 10+ JS snippets and realized how bad things have really gotten, even with an adblocker on these days a 3g network is hardly enough to browse a massive portion of the web.
Always been fascinated with this type of development. I come from the era where JS was typically frowned upon, later learned to like it during ES6 because I had to use it a lot but now I mostly use it for Node and not the frontend anyways.
Mostly agree, but datepickers are still a problem. The range of user experiences is so broad, and sometimes so counterintuitive (fuck you in particular, Android), that I still hesitate to suggest a native date input.
There are some situations where date pickers do make sense, like when booking an appointment in the future - being able to see the day is useful. Being able to overlay the date picker with other information like days where you're free or when appointment slots are available makes them unbeatable.
But, when asking for a date people know, like their date of birth, date pickers just slow people down and confuse them. User research has shown this repeatedly.
HTML is one of these technologies that (still) feels pregnant with infinite possibilities. But we can't really project meaningfully what can / should happen to the web platform (and the role of HTML in it) without considering the tortured trajectory it already has traversed, e.g., the major XHTML vs HTML5 (or W3C vs WHATWG) battles, its more recent "annihilation" in the hands of SPA and JS frameworks and the multiple roles it can play. In a sense HTML is too powerful for its own good. So prevailing interests will always try to tame it towards their own needs.
HTML is the conduit and enabler of at least three distinct functionalities that are made available by a decentralized internet comprising clusters of server and client machines:
* transmitting the information to implement hypertext (=the simplest implementation of linked textual documents). This transmission of linked natural language data has changed the world already and is sufficient to support e.g., a planet of interconnected bloggers. HTML purists (like the OP) focus on this angle but this is very limiting and will never unlock all the positive potential of the web.
* transmitting semantically annotated non-text data of all types (numerical, graphical, objects etc). This vision has never really materialized in either its XHTML or SVG guises. Today the only hint that HTML is capable of transmitting such data is the table element. Yet it has enough in-principle semantics to transmit any JSON object.
* transmitting UI elements. Why do we need UI elements at all and are they intrinsically evil? The core function of UI elements, both the semantic aspect (hierarchical relations) and the geometric aspect (i.e. CSS and mapping stuff to a 2D screen) are essential and entirely benign. They simply help organize more complex patterns. HTML ultras that avoid CSS essentially rely on default such mappings.
Imho an alternative vision to the degenerate web of today that is simply the funnel that gets you to the walled gardens built by adtech (actually humanity grinding machines) must stop being naive, simplistic and Luddite. In all these web technologies of yesterday you can trace battles that were lost, paths not taken.
The web we want is an empowering, democratic, decentralized platform that respects and elevates individuals in the digital realm. This web is not tech-phobic. It is confident and develops / adopts any and all technologies that fit is values.
>> ... semantic HTML is more important now than ever
Except... semantic HTML has never been important. Forget about implementation and adoption, even the abstraction falls apart after about 30 seconds of critique. It's a weird mix of structure-like tags that seem to solely serve the newspaper industry from 25 years ago, half-baked UI elements and a handful of directives. The non-semantic elements have to make up more than 99.9% of the internet today. It seems the author missed the of XML and transforms if this is what they wanted.
One question is: "How easy is HTML to read for humans." Everyone who has spent more than a few months writing software will be familiar with the idea. But for someone who has never seen it - is the concept intuitive? Do bright 8th graders get it if shown it for the first time on a test?
I used to think the answer was "pretty difficult," but I haven't come up with anything better. Maybe there is something to be done with indentation - but that has it's own challenges.
Honestly, what we need is a new browser. I think everyone is sort of done with the URL bar, point click GUIs and we're going to see the need to transform things as LLMs become a more dominant query medium. It means the starting point is a search interface, it means much of what we want is automatically rendered as an embedded app in the page and it probably means we stop "browsing" and start consuming information on the web in a slightly different way.
I'm not clear from reading the article twice on how HTML helps solve issues interopping with sites like Facebook, Twitter, or reddit. I've scraped these sites before and they render in html but either do obsfucation or detect that you're scraping and block you. Actually html was worse than the previous reddit thing that used to exist, where you could add `.json` to basically any reddit url and get back the page in json format. So easy!
When you semantically describe your HTML, indeed the intent and meaning of your data becomes easily machine-readable.
That's not a solution, it's the entire problem. In today's ecosystem it means somebody takes your shit and runs with it. That's why the walled gardens are getting ever higher walls. "Open data" is an existential threat if you're the one paying for the creation/hosting of that data.
Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.
What was also surprising is that there is a Slider as well as Color picker element.
Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation of those elements (if needed).
> Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.
It is in the names:
<em> = emphasized, as in "this part of the text should be emphasized in whatever way the styling dictates
<i> = italic, just a way to style directly
<strong> = strongly emphasized
<b> = bold, just a way to style directly
<i> and <b> do not make a statement about semantics, they are for styling, and probably not much used in modern valid HTML, or at least should not, if you have CSS available. <em> and <strong> make statements about importance of a part of text, in whatever way you want to style that. It just happens, that the default styling for those is italic and bold.
I have been using JS widgets instead of datetime-local inputs because of patchy desktop browser support years back. In FF on Mac I noticed time widget with prefilled times in datalist doesn't work as intended. Should we still rely on the widgets if there are browser kinks?
I also feel multivalued tag inputs also require JS widgets. Is there a pure HTML version?
<datalist> is so close to being perfect but I know the people I work for would want it to show the full list always and just float the selected value or closest spelled value to the top. Right now if you select a value on chrome and then click the list again it just shows that one value until you delete your entry.
If I (non native English speaker) write a blog post it will be shit English and won’t read “smoothly”. Then ChatGPT makes it nice and smooth. I check if my intentions are left unaltered and then post. For professional stuff I used to ask my American colleague, now I don’t have to bother her anymore.
I don't see it as confessing their sins, more like "FYI, I used X tool to help me with Y" like you'd see "Page generated by Z" in a footer except in a header since it's related to the content itself. Unless you're writing an assignment for an English class I don't think anyone would feel lied to if they found out you had help from an AI translator.
I think SEO is dead and the Semantic web will soon take over as search transitions to LLMS. If your data is better digested with minimal work by the LLM trainers, does your content perform better?
And maybe search isn’t the killer feature of the semantic web, maybe it will be agents?
That said, I live in Melbourne, Australia, so yeah they are considered a local group - information travels fast here to support them. That said, it feels like they perform more in the US than here!
Author and posters both are equivocating: the term "semantic HTML" is the OP author's term and is not clearly defined. In contrast the "semantic web" IS well-defined.
tl;dr - this article and discussion is a confused waste of time.
The main thing I want added to the html spec is a spreadsheet element. It could be an enhancement to the table element. I want it to support sorting, filtering, pagination out of the box. And be responsive to boot.
When browsers finally have full and first-class WASM ecosystem integrated (and ecosystem developed), we'll be looking back on this "pretend-that-HTML-is-an-UI-framework" thing with genuine horror.
Web pages can still be in HTML. It's a bad choice for UI apps.
(With current state of web ecosystem it's hard to tell the difference between what is page and what is an app, of course. But imagine we had a real choice on the outset of web.)
I would really really like to see a full-blown retro-looking social network (say, a Twitter/X clone), that works solely with pure HTML. It would be really amazing.
I've been using `dialog` and `details` of late, and couldn't be happier. At the same time, `section`, `article`, `header` and `footer` confuse me a lot. I've stopped using them.
I'm not 100% sure if assistive technologies use section and article for any end user context like "jump to content", but they at least can be used to get more context than just another div
Reader mode is one I don't think about enough. I could see that purposely hiding content outside of the article element.
Yeah, Reader mode is weird. I know it prioritises semantic tags like article, but since the behaviours are not standardised, I never know what will and will not work.
Same. This is mind-blowing! And just goes to show how different “markup” is meant to be from “formatting.” Not that you’d know it when so much content is made by people using a WYSIWYG editor that basically tells them “you are doing formatting.”
They don't. Like, that linked document is a cool idea but it's utterly inaccurate as a description of how the tags are used by actually existing website or handled by actually existing user agents (yes, including screenreaders).
Perhaps the tags have not been de facto treated semantically by existing practices. There’s a great deal wrong with the tag soup pervading the web. Current convention doesn’t mean they can’t have semantics.
Potentially they could have semantics in the future, but right now they don't. If you make a user agent that relies on them having those semantics, that user agent will misinterpret a lot of web pages.
I can create CSS to style the two tags accordingly, and in within my own work I can make them mean different things to the tools I use to create and manage html.
There are only two hard problems in programming: cache invalidation and naming. When programmers give something a name inconsistent with it's behavior, it's going to cause a problem.
this article's making me think. In this AI-driven landscape, the focus on semantic structure totally makes sense. But, is it really the remedy for the social media interoperability problem? Are we underestimating the appeal of decentralized platforms? And, do people genuinely not care about these alternatives?
While the term "HTML 5" hasn't been used by WHATWG HTML snapshots, and was neither endorsed by W3C for the single 2021 snapshot it blessed as recommendation in the past, the post below is arguing HTML review draft 2023 and newer should in fact be getting a new major release version since it removed/de-emphasized and invalidate Ian Hickson's historic section elements/outlining which was a major HTML 5 era innovation (which, in turn, was the problem since browsers and screen readers ignored it).
> ChatGPT-like interfaces are likely the future of human data access.
And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to process input. ChatGPT (and its future offspring) can navigate regular websites the same way humans do. They don't need us to hold their hand. They know when a sequence of paragraphs constitutes a "list", without it having to be explicitly marked as such, etc.
What the author appears to be describing is simply an API mediated through HTML semantic elements. But if you have an API, you don't need a Large Language Model for automatic data access – a good old Python script using Beautiful Soup will do just fine. And it has the added benefit that it runs entirely locally.