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.
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
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.
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.
> 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.
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.
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.
> 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.
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)
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'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.
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.
<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.
>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.
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
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.
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.
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.
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.
* 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.
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 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.
> 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).
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.)
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.
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.
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.
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.
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
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.
> 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.
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.
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.
<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.
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).
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.
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.”
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!
> 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 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 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!
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).
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.
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.
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).
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.
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.
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.
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.
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.
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).
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.
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.
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.
> 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.
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.
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)
"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.
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.
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.
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.
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.
> 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?
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).
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?
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.
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.
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?
457 comments
[ 4.2 ms ] story [ 312 ms ] threadEasier? 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
There’s no point in removing stuff from CSS. The only thing that would do is break old websites.
If only 5% is truly powerful you can easily and happily use only that 5%
It’s also become deeper at the same time though - so it might be easier to do the same thing and harder to know it all.
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.
the tutorial is gone, but the download still exists referenced here: https://stackoverflow.com/a/39681911
the downside is that i don't know how to update this to newer versions or add extensions.
it might also be possible to create a new version of this using aurelia-cli, but i haven't yet figured out how.
Except, you know, accessibility.
> just get up in arms about the web that does not happen with other technologies.
And for a good reason.
This all breaks the browser’s in page search function though! Long standing bug with no fix yet.
[0] https://docs.flutter.dev/accessibility-and-localization/acce...
flutter run --web-renderer=html
<button class="bg-indigo-600 px-4 py-3 text-center text-sm font-semibold inline-block text-white cursor-pointer uppercase transition duration-200 ease-in-out rounded-md hover:bg-indigo-700 focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-indigo-600 focus-visible:ring-offset-2 active:scale-95"> Button </button>
You can write this:
<button class="btn btn-primary"> Button </button>
The utility is pretty clear to me
Give me HTML,CSS,JS combo any day over some complex js library or platform.
I really hope this becomes standardized at some point. Would be great to have consensus around.
> 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.
Feel free to try it out: https://github.com/anyfactor/Chatgpt_grammar_checker
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.
[1] https://github.com/languagetool-org/languagetool
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:
> Can by styled quite aggressively.
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.
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.
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)
- 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.
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).
You can un-hide that bar permanently, but when you do, it always covers the edge of the webpage.
# scrollbar fixes
user_pref("widget.non-native-theme.scrollbar.style", 1);
user_pref("layout.testing.overlay-scrollbars.always-visible", true);
I literally cannot see the benefit in hiding the scrollbar. It sounds like an edge case made primary.
Still better than the Borg, at least you can fix it.
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
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.
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.
Beyond that, QtWebEngine is about the polar opposite of the type of engine I described in one key area: resource usage.
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.
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.
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 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.
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.
Could you elaborate a bit? How is the flat look benefitting users over site owners? (Is this regarding lists of trackers?)
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
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.
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.
* Lets you enter nonexistent dates like 31/2
* 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.
(Entire list checked on desktop)
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.
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".
https://en.m.wikipedia.org/wiki/Metric_system
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?
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.
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).
(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 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.
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.
You can compose most HTML elements including <select> easily:
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.
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.
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
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.
It just seems... abandoned.
There's a reason why we have all these frameworks built on top of HTML - it's because the browser manufacturers have not done their jobs.
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.
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.
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.
[1]: https://sgmljs.net/docs/html200129.html
So no-one uses them, so lots of people don't know about them.
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.
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
I guess, that's on you – if you're a web developer, you definitely 100% need to know these elements. They're not new.
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!
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?
A blind reader can configure their client to speak highlights.
Semantic markdown and CSS should ideally be seen as complementary and be used as such.
Why would you care? As long as it appears highlighted it is alright. Let people chose their own highlight colors, and text fonts, and everything.
> Just kidding.
Worth the price of admission!
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.
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'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.
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”.
https://htmx.org/
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.
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.
The proposal is that Locality of Behavior > Separation of Concerns. Maybe its true! We'll see. :)
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!
[1]: https://sgmljs.net/blog/blog2303.html
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.
> 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.
It can?! It does that?
https://github.com/openai/openai-cookbook/blob/main/apps/web...
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.
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”.
The LLM will look at any .exe and determine if it halts.
At that point you'd need an AGI that can figure out something we can't.
Edit: but yeah, sarcasm. Nowadays I can't even tell sometimes.
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.
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.
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.
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.
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.
So, no, you can not construct a machine for every conceivable input without imposing an artificial constraint on the input size.
Put another way: For every tape you construct and analyse, there is a tape one segment longer that might contain a symbol that can alter the outcome.
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?
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.
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..
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.
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.
Why would it be extremely useful?
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.
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 halt IF "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.
Decidable or undecidable is about maths, not practice.
If the .exe connects to a service that runs on something more powerful than finite-state machine, though, I don't know.
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.
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.
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.
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.
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”?
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.
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.
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)
I don't know how much deeper it goes, but it does have some context:
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.
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.
that's the thing; they don't know - they guess
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.
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?
I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.
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
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.
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 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?
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.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
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.
Can you explain this?
There are a few sites I impersonate Googlebot to, they're much more usable that way.
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?
The first example is hyperbolic, sure, but only slightly.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).
[1]: https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...
They are nice hints to assistive technologies and reader mode.
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.
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.
It's not intended to be used in the same way as say; <article> to my knowledge
> A <summary> element may only be used as the first child of a <details> element
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/su...
Github markdown lets you use it too. People use it for examples and inline explanations.
For the love if god, study your tools! (and not from SEO spam articles)
I also feel multivalued tag inputs also require JS widgets. Is there a pure HTML version?