by catskull on 8/2/23, 3:31 AM with 446 comments
by p-e-w on 8/2/23, 5:16 AM
> 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.
by jerf on 8/2/23, 3:23 PM
I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it. As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out. Eventually in principle both the semantic web and that pile of heuristics are entirely replaced by AI.
(Note also my replacement of LLM with the general term AI after my first usage of LLM. LLMs are not the whole of "AI". They are merely a hot branch right now, but they are not the last hot branch. It is not a good idea to project out the next several decades on the assumption that LLMs will be the last word in AI.)
by klardotsh on 8/2/23, 4:46 AM
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)
by cassepipe on 8/2/23, 10:52 AM
We could have had nice things.
Ssssshhh, calm down, let go.
by marcus_holmes on 8/2/23, 5:43 AM
{{if .DevMode}}
<details>
<summary>Data</summary>
{{.}}
</details>
{{end}}
by nzoschke on 8/2/23, 4:32 AM
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.
by merdaverse on 8/2/23, 11:27 AM
If such a simple element can't be used properly, I have no hope for all the others.
by devjab on 8/2/23, 5:03 AM
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.
by chickenfeed on 8/2/23, 12:37 PM
The complexity of sites is paralysing. What could be a few simple pages of texts and images is totally over-engineered for no good reason and is burning a stupid amount of CPU cycles. Probably built on a hacked off-the-shelf CMS that could do with security updates.
CMS and frameworks are being used, because there wasn't a good alternative to something as neat as frames.
A site I'm working on at the moment has quite a pretty design, but pull the CSS and it's just a mess.
I was looking at going to the cinema recently and the local picture house made it practically impossible to just scan the handful of films that were playing that week. I realised you could pretty much shove it all in a spreadsheet and it would read better. Heck, I downloaded the JSON from their API, and it was easier to read.
Most of it is all tiresome lipstick on a pig.
Facebook was a success for a few reasons, one was the easy on-boarding (which uses nefarious privacy trade-offs), the other is that you could actually share photos easily. Also see: Whatsapp and Instagram. Publishing needs to be easy. And despite a simple FTP being easy, there's a weird disconnect in the usability process that makes this tricky for mere mortals. People want to drag and drop, or upload, fire and forget and edit easily. And those wanting to consume data, really just want the bare essentials: The data.
by SPBS on 8/2/23, 8:43 AM
https://github.com/whatwg/html/issues/3567
> dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a <dialog> you need to use JavaScript to set the open attribute.
> It'd be great if there was a way to make a <a> or a <button> elements capable of opening dialogs.
> Precident already exists for page interactivity baked into HTML - for example <a href="#.."> can already scroll the page, and <details> elements are capable of hiding elements behind interactivity, so I think it stands to reason <dialog> elements could be opened by other page elements.
by pbohun on 8/2/23, 4:26 AM
by jillesvangurp on 8/2/23, 6:31 AM
Becoming the equivalent of a digital hermit and living in a hole in the ground outside these walls, which is what I would characterize this as, is not going to result on a lot of people stepping outside those walls. If you've ever watched Life of Brian, you'll have a good mental picture here.
It's a variation of brutalist web development (let's not call it design) that just doesn't really appeal to the masses. It never has. The history of the web is endless attempts to pimp it with Applets, Flash, Shockwave, Silverlight, etc. The latest incarnation of that is web assembly. This basically allows you to use anything native that works elsewhere (desktop, mobile, game consoles, AR/VR, etc.) in a browser as well.
Of course there's a severe risk of this to disappear into more walled gardens. But I don't think sitting in a dusty old hole in the middle of nowhere while shaking your fists at progress does much to change that.
by grumbel on 8/2/23, 9:55 AM
There is also a lot of markup for really common tasks still missing, I'd like to see an <advertisment> and something to handle pagination at the browser level (rel="next" has been around for decades, but browser don't care). And more broadly, I'd really like to see much better support for long-form documents in HTML or at the very least native ePub support in the browser.
by btbuildem on 8/2/23, 2:05 PM
I can't see that working, for so many reasons:
- most people are passive consumers of content, maybe interact a little, enough to tweak their feeds
- a small minority creates content on the large networks / aggregators, and (I think) a large portion of that is spurred on by monetization
- the "internet" and all the devices that access it have become so "user friendly" that the people who have come online in the last decade or so are effectively technically illiterate; you cannot count on them building anything from scratch, only to arrange the big duplo pieces already provided
by delta_p_delta_x on 8/2/23, 5:16 AM
[1]: https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...
by rapnie on 8/2/23, 7:58 AM
Quoting from the doc here's the stack:
- WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being actively extended with features such as WasmGC.
- WebGPU provides an API (to JavaScript) that exposes a modern computation and rendering pipeline.
- Accessible Rich Internet Applications (ARIA) provides an ontology for enabling accessibility of arbitrary content.
- WebHID provides an API (to JavaScript) that exposes the underlying input devices on the device.
This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.
by anyfactor on 8/2/23, 4:45 AM
> 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
by gyudin on 8/2/23, 6:08 PM
by mkl95 on 8/2/23, 4:49 AM
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?
by waihtis on 8/2/23, 5:03 AM
by qwerty456127 on 8/2/23, 11:45 AM
A social network with (or without) this essentially is reinventing the wheel of the whole Internet which is made of HTML pages (which are replaced by personal pages on a social network), RSS/ATOM (which is replaced with in-app notifications), e-mail (which is replaced with in-app direct messages), Usenet (which is replaced with in-app groups) etc. Everyone theoretically could just have a personal www page on their own domain instead of a social network account.
Oh, and HTML never needed CSS to be not ugly - that's the browser default settings which make unstyled (styled with default styles) HTML pages look this way. We always could just change the default fonts/colors or apply a userstyle for more complex things.
Once general population joined to the Internet (where in the past there were only nerds) the demand emerged for it to become much easier and prettier and the corporations responded offering the features pople want taking their freedom, privacy and independence in exchange (which an average person doesn't mind, all they ace about is that being "for free"). We could just build better apps (browsers with sensible defaults, intuitive e-mail and Usenet clients and web servers), but we still lack them because nobody wants do serious work for free and make great products which would suit everybody ather than themselves.
by rchaud on 8/2/23, 12:30 PM
Guess what? It still looks bad! The <summary><details> element for instance is hard to style with CSS, things don't work the way you'd expect. Frankly that element was leapfrogged in terms of usability and customization by pretty much any jQuery accordion script from 2009.
by jll29 on 8/2/23, 8:18 AM
As an alternative to what the original post posits, we could leave it for that purpose, and design another (now XML) application for user interfaces: windows, buttons, scroll bars (if desired), text controls (no I'm not talking about textarea for CGI), the kind of controls that Windows or X11+MOTIF provide, expressed as tags in a UIML (User Interface Markup Language). This would have the advantage that we could start from a clean slate, and the open source interpreter for this technology could be integrated into all Web browsers, so behavior would be identical.
UIML would be designed as an XML application for networked software applications' user interfaces.
Of course, you could execute them locally, too. There could be graphical UI designer of the types that already exist, e.g. Visual Studio would just write out a UIML as a new export format.
Crazy idea? Actually, it's just applying the "Do one thing, and do it well." mantra to XML <-> XHTML + UIML instead of packing everything possible into one now-bloated markup language it was never designed to do. So if this comment had a title, it would be "I'm betting on Internet standards" (plural).
by klaplume on 8/2/23, 11:23 AM
by maxfurman on 8/2/23, 1:49 PM
by inktype on 8/2/23, 7:09 AM
Don't be surprised that people don't use native date pickers when they can't be configured to display ISO dates
by kabes on 8/2/23, 6:46 AM
by rado on 8/2/23, 6:08 AM
by azangru on 8/2/23, 7:19 AM
It's odd: I remember seeing an argument recently, though can't remember where exactly (perhaps [0]?), that LLMs make semantic HTML obsolete, because they "understand" the text anyway.
After all, humans didn't need html to be semantic in order to be able to read it — machines did. And if machines are approaching humans' capability to read texts, then doesn't this put the whole semantic html exercise into question?
0 – https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-need-t...
by adamredwoods on 8/2/23, 6:04 AM
Why do I want to make my website AI-accessible? It, or some mega-rich company will reap the rewards, not me.
by ivolimmen on 8/2/23, 4:28 AM
by coldtea on 8/2/23, 9:41 PM
Reader mode is mostly for longer text. Doesn't help with WPAs as much.
>Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time. The shift from primary data interfaces to secondary interfaces is already underway. RSS refuses to die. ChatGPT-like interfaces are likely the future of human data access. We’re going back to the beginning. Advertisers may be scared, but I’m not! Let’s start the revolution and set the world on fire with modern HTML.
Not sure what this (the most important part) attempts to say.
What does the advent of ChatGPT-like interfaces have to do with "adopting modern HTML" and "proper tagging"? If anything ChatGPT-like interfaces would require less tagging, and can do the "figuring out what the text is" part of semantic web without sementic metadata (and they can do it directly on the actual text, whereas the metadata would more likely be abused and misleading for SEO).
by koito17 on 8/2/23, 5:31 AM
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.
by vermilingua on 8/2/23, 6:38 AM
> The <em> element represents stress emphasis of its contents, while the <i> element represents text that is set off from the normal prose, such as... when the text refers to the definition of a word instead of representing its semantic meaning.
And then [1]:
<p>
In HTML 5, what was previously called
<em>block-level</em> content is now called <em>flow</em> content.
</p>
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...
by 7373737373 on 8/2/23, 6:34 PM
Links are represented as portals, and unlike in VRChat you can just walk straight through them like in the Portal games - allowing one to "walk through the web": https://youtu.be/jYQtAcQddRg?t=48
Now, language models can generate HTML, and I feel this may be an opportunity to revive it again. To generate VRChat rooms, you have to learn Unity, which is heavy and has a steep learning curve. But if you can go from a text description to HTML, then you just need a text file!
It's a great alternative to the walled gardens
by kerkeslager on 8/2/23, 4:04 PM
This is pretty far from the case. Three examples:
* Dropdown menu. This is a superset of selects, which can only contain options: a dropdown can contain anything in its dropdown, including a nav which contains links displayed as icons, for example.
* Carousels/slideshows.
* Tab areas.
I've got a library of these kinds of elements implemented as CustomElements, but they're pretty geared toward the websites I've worked on in the last year, so I want to spend more time making them extensible before I release them as open source--I don't want people depending on my work until they are better-designed.
That said, HTML by default has gotten a lot more powerful than a lot of web devs know about. In particular, there's a lot of custom data lists and date pickers out there which are less powerful than the built-in HTML datalist and input type='date'
by pphysch on 8/2/23, 4:50 PM
While the idea of a markup/styling language is pretty simple, HTML+CSS deal heavily with difficult concepts like ontologies, cascading and non-imperative behavior, balancing UX & machine interpretability (accessibility), etc. Add in HTTP and browser APIs. Web dev is distributed computing par excellence, and is extraordinary deep and challenging, yet it's also viewed as among the lowest forms of programming. That's a big mismatch.
by kapitanjakc on 8/2/23, 4:37 AM
Give me HTML,CSS,JS combo any day over some complex js library or platform.
by zmmmmm on 8/2/23, 5:14 AM
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.
by sebastianconcpt on 8/2/23, 12:09 PM
by omgmajk on 8/2/23, 12:41 PM
by inopinatus on 8/2/23, 6:19 AM
by nologic01 on 8/2/23, 7:31 AM
HTML is the conduit and enabler of at least three distinct functionalities that are made available by a decentralized internet comprising clusters of server and client machines:
* transmitting the information to implement hypertext (=the simplest implementation of linked textual documents). This transmission of linked natural language data has changed the world already and is sufficient to support e.g., a planet of interconnected bloggers. HTML purists (like the OP) focus on this angle but this is very limiting and will never unlock all the positive potential of the web.
* transmitting semantically annotated non-text data of all types (numerical, graphical, objects etc). This vision has never really materialized in either its XHTML or SVG guises. Today the only hint that HTML is capable of transmitting such data is the table element. Yet it has enough in-principle semantics to transmit any JSON object.
* transmitting UI elements. Why do we need UI elements at all and are they intrinsically evil? The core function of UI elements, both the semantic aspect (hierarchical relations) and the geometric aspect (i.e. CSS and mapping stuff to a 2D screen) are essential and entirely benign. They simply help organize more complex patterns. HTML ultras that avoid CSS essentially rely on default such mappings.
Imho an alternative vision to the degenerate web of today that is simply the funnel that gets you to the walled gardens built by adtech (actually humanity grinding machines) must stop being naive, simplistic and Luddite. In all these web technologies of yesterday you can trace battles that were lost, paths not taken.
The web we want is an empowering, democratic, decentralized platform that respects and elevates individuals in the digital realm. This web is not tech-phobic. It is confident and develops / adopts any and all technologies that fit is values.
by skeeter2020 on 8/2/23, 1:51 PM
Except... semantic HTML has never been important. Forget about implementation and adoption, even the abstraction falls apart after about 30 seconds of critique. It's a weird mix of structure-like tags that seem to solely serve the newspaper industry from 25 years ago, half-baked UI elements and a handful of directives. The non-semantic elements have to make up more than 99.9% of the internet today. It seems the author missed the of XML and transforms if this is what they wanted.
by jitbit on 8/5/23, 9:12 AM
No "placeholder" attribute support, no "show picker on focus" functionality, etc.
You end up including so many JS/CSS hacks and workarounds that you're back to having a huge datepicker.js file.
by the_king on 8/2/23, 3:24 PM
I used to think the answer was "pretty difficult," but I haven't come up with anything better. Maybe there is something to be done with indentation - but that has it's own challenges.
by asim on 8/2/23, 11:16 AM
by komali2 on 8/2/23, 6:42 AM
So, did I miss something in the article?
by dahwolf on 8/2/23, 9:42 PM
When you semantically describe your HTML, indeed the intent and meaning of your data becomes easily machine-readable.
That's not a solution, it's the entire problem. In today's ecosystem it means somebody takes your shit and runs with it. That's why the walled gardens are getting ever higher walls. "Open data" is an existential threat if you're the one paying for the creation/hosting of that data.
by SoraNoTenshi on 8/2/23, 7:57 AM
What was also surprising is that there is a Slider as well as Color picker element.
Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation of those elements (if needed).
by aitchnyu on 8/2/23, 5:50 AM
I also feel multivalued tag inputs also require JS widgets. Is there a pure HTML version?
by willio58 on 8/2/23, 4:26 PM
by teekert on 8/2/23, 8:13 AM
If I (non native English speaker) write a blog post it will be shit English and won’t read “smoothly”. Then ChatGPT makes it nice and smooth. I check if my intentions are left unaltered and then post. For professional stuff I used to ask my American colleague, now I don’t have to bother her anymore.
by DrStartup on 8/2/23, 11:41 AM
And maybe search isn’t the killer feature of the semantic web, maybe it will be agents?
by voydik on 8/2/23, 4:49 AM
by giardini on 8/2/23, 3:33 PM
tl;dr - this article and discussion is a confused waste of time.
by beders on 8/2/23, 3:36 PM
It is very telling that you still can't build more sophisticated forms declaratively in HTML/CSS.
After decades everyone seems to be cranking out their own custom made forms with various levels of JavaScript added.
by ezekiel68 on 8/2/23, 4:49 AM
> Just kidding.
Worth the price of admission!
by nsonha on 8/2/23, 6:46 AM
"With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever"
No it's not, LLM basically invalidates the entire concept of semantic web, which never worked anyway.
by barrenko on 8/2/23, 6:37 AM
by irrational on 8/2/23, 7:32 AM
by divan on 8/2/23, 9:14 AM
by Conscat on 8/2/23, 5:52 AM
by mmwako on 8/3/23, 12:13 PM
by bingemaker on 8/2/23, 5:16 AM
by sensanaty on 8/2/23, 11:52 AM
by jacksongalan on 8/2/23, 6:53 PM
by yieldcrv on 8/2/23, 7:33 AM
Congratulations, it passed pagerank and was readable.
by cratermoon on 8/2/23, 4:47 AM
by tfcwebdesign on 8/3/23, 8:15 PM
by lancesells on 8/2/23, 11:59 AM
by lord5et on 8/2/23, 7:03 AM
by robobro on 8/2/23, 7:56 AM
by aviavinash on 8/2/23, 11:09 AM
by backtoyoujim on 8/2/23, 6:47 AM
by vvpan on 8/2/23, 4:32 PM
by shantanujoshi on 8/2/23, 5:33 AM
by rado on 8/2/23, 6:10 AM
by orenmizr on 8/5/23, 2:17 PM
BUT still PUG > HTML any day of the week.
by sourcecodeplz on 8/2/23, 11:42 AM
by dbbr on 8/2/23, 5:27 PM
Gila!
by nektro on 8/3/23, 3:39 AM
by renegat0x0 on 8/2/23, 12:50 PM
by YLYvYkHeB2NRNT on 8/2/23, 12:36 PM
by onion-soup on 8/2/23, 12:22 PM
by happythebob on 8/2/23, 12:43 PM
by re-thc on 8/2/23, 5:09 AM
by DigitalSea on 8/2/23, 10:18 AM
by Knee_Pain on 8/2/23, 5:49 AM
For the love if god, study your tools! (and not from SEO spam articles)