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).<p>> ChatGPT-like interfaces are likely the future of human data access.<p>And the whole point of artificial intelligence systems is that they <i>don't require</i> 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.<p>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.
Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever."<p>I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is <i>less</i> 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.<p>(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.)
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).<p>I'm starting to think my dream browser might be something like visurf <a href="https://sr.ht/~sircmpwn/visurf/" rel="nofollow noreferrer">https://sr.ht/~sircmpwn/visurf/</a> 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:<p>1. is more accessible (in the "doesn't break screenreaders, system theming, keybinds, etc" way)<p>2. could be made to use way fewer resources than these heavy JS contraptions these elements can replace<p>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)
I <i>really</i> want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case.
The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is just the tip of the iceberg. For each tag, I have to learn the whole history of its development and make an inquiry about what's the <i>right</i> way to do it <i>nowadays</i>.<p>We could have had nice things.<p><i>Ssssshhh, calm down, let go.</i>
I use <details> a lot for debugging Go html templates.<p><pre><code> {{if .DevMode}}
<details>
<summary>Data</summary>
{{.}}
</details>
{{end}}
</code></pre>
It's nicely unobtrusive when collapsed, doesn't mess up the page completely. Then expands to the full glory when needed.
Great read and interactive demo.<p>After a few years of dabbling with Flutter I just came back to the same conclusion: bet on HTML.<p>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.<p>The result is simple sane HTML files that look and work great on desktop web browser and and mobile wrapped web view.<p>My app is basically static so it caches in a CDN, works offline, and view source makes it easy to debug.
The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the <main> tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of <main>, <aside> etc.), very little sites use it properly. Even the fancy professional sites wrap all the page content, including navigation, footers and the like inside the <main> tag, which should only be for the main content of the page.<p>If such a simple element can't be used properly, I have no hope for all the others.
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.<p>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.<p>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 don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of date. Not updated or whatnot. There's still lots of fire once and forget sites. Probably because budgets are tight and people can't afford updates. Or the updates are just technically too difficult for people to grok.<p>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.<p>CMS and frameworks are being used, because there wasn't a good alternative to something as neat as frames.<p>A site I'm working on at the moment has quite a pretty design, but pull the CSS and it's just a mess.<p>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.<p>Most of it is all tiresome lipstick on a pig.<p>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.
<i>ugh</i> I was so excited to see pure HTML modals were a thing with <dialog> only to find out there's no way of triggering them <i>without</i> JavaScript. Using pure HTML you can only dismiss them, not trigger them.<p><a href="https://github.com/whatwg/html/issues/3567">https://github.com/whatwg/html/issues/3567</a><p>> 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.<p>> It'd be great if there was a way to make a <a> or a <button> elements capable of opening dialogs.<p>> Precident already exists for page interactivity baked into HTML - for example <a href="#.."> can already scroll the page, and <details> elements are capable of hiding elements behind interactivity, so I think it stands to reason <dialog> elements could be opened by other page elements.
I didn't realize some of these elements existed. Neat!
However, I think if we want an open/federated system to win, we need to make it compelling to normal people. That means making it fun and entertaining. I've found that no argument about freedom, privacy, or anything actually important will work.
The point of walled garden is that they are very tempting to stay inside off for users. Their power comes from most users not resisting that temptation.<p>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.<p>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.<p>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.
I would care more about markup if the browser would actually be able to do anything interesting with it, but for most part markup is a just a default style for an element, the semantic meaning is ignored. The <time> tag is about the last one I can think of that actually made a difference from the users perspective.<p>There is also a lot of markup for really common tasks still missing, I'd like to see an <advertisment> and something to handle pagination at the browser level (rel="next" has been around for decades, but browser don't care). And more broadly, I'd really like to see much better support for long-form documents in HTML or at the very least native ePub support in the browser.
What is the author suggesting? That instead of "social" networks, people will rush to building their own online presence from first principles?<p>I can't see that working, for so many reasons:<p>- most people are passive consumers of content, maybe interact a little, enough to tweak their feeds<p>- a small minority creates content on the large networks / aggregators, and (I think) a large portion of that is spurred on by monetization<p>- 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
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!<p>[1]: <a href="https://cdn.berkeleygraphics.com/static/typefaces/berkeley-mono/datasheet/DX-102-10.pdf" rel="nofollow noreferrer">https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...</a>
Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2]<p>Quoting from the doc here's the stack:<p><pre><code> - 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.
</code></pre>
[0] <a href="https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC3KVdAlLGOsK6gFoEOD0/edit?resourcekey=0-bPajpoo9IBZpG__-uCBE6w#heading=h.s6balucy11bi" rel="nofollow noreferrer">https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...</a><p>[1] <a href="https://news.ycombinator.com/item?id=36968263">https://news.ycombinator.com/item?id=36968263</a><p>[2] <a href="https://news.ycombinator.com/item?id=34612696">https://news.ycombinator.com/item?id=34612696</a>
Tangent.<p>> I wrote this post and then GPT-4 fixed my grammer and spelling<p>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.<p>Feel free to try it out: <a href="https://github.com/anyfactor/Chatgpt_grammar_checker">https://github.com/anyfactor/Chatgpt_grammar_checker</a>
In a world where pages takes x10 more time to load than to render some hyperrealistic scenes in AAA games on some Unreal Engine 5 with 140 fps?
Yup, I’m betting too on a front-end stacks that change every 6-12 months but only lead to more and more poorly optimized websites.
Half of the times even mobile apps are useless, when they can’t download a freaking JSON response in areas with poor network coverage.
> Pretty much you can highlight text. By default Safari shows a yellow highlight. I like it!<p>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?
Some social networks used to offer rich page customization with Wiki or markup or something like that. And that essentially was the HTML wheel reinvented. Some even offer in-app apps, some even lock whole life oof the whole population in them (e.g. China).<p>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.<p>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.<p>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.
I'm aware of all these HTML elements, I use them for my personal digital garden website that just uses CSS grid to align everything, no external scripts or styles.<p>Guess what? It still looks bad! The <summary><details> element for instance is hard to style with CSS, things don't work the way you'd expect. Frankly that element was leapfrogged in terms of usability and customization by pretty much any jQuery accordion script from 2009.
HTML was designed as an SGML application for networked hypertext.<p>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.<p>UIML would be designed as an XML application for networked software applications' user interfaces.<p>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.<p>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).
I'd argue that the modern markup elements you're showing are still way off from what the Semantic Web (as Tim Berners-Lee proposed) would enable. Image the possibilities of an 'AI' if it could understand the relationships between data and not just be a statistical parrot like LLMs are.
Combined with something like Solidproject, that give users back control over their data, THAT would be a major leap!
I've been doing web development full-time for nearly a decade now, and I didn't know about all of these. I think I failed a job interview last month because I didn't know about <datalist>. Sigh.
> No more datepickers please!<p>Don't be surprised that people don't use native date pickers when they can't be configured to display ISO dates
Yes, always bet on HTML. I made the chart here in semantic HTML with a definition list, which is also keyboard accessible, and overlaid by a canvas: <a href="https://www.skrill.com/en/currency-converter/" rel="nofollow noreferrer">https://www.skrill.com/en/currency-converter/</a> – no libraries needed.
> With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever.<p>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.<p>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?<p>0 – <a href="https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-need-the-semantic-web/" rel="nofollow noreferrer">https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-need-t...</a>
>> 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.<p>Why do I want to make my website AI-accessible? It, or some mega-rich company will reap the rewards, not me.
><i>In fact, recently I’ve become acutely aware of reader mode. All time spent on styling will be obliterated by reader mode, and that’s a great thing!</i><p>Reader mode is mostly for longer text. Doesn't help with WPAs as much.<p>><i>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.</i><p>Not sure what this (the most important part) attempts to say.<p>What does the advent of ChatGPT-like interfaces have to do with "adopting modern HTML" and "proper tagging"? If anything ChatGPT-like interfaces would require less tagging, and can do the "figuring out what the text is" part of semantic web without sementic metadata (and they can do it directly on the actual text, whereas the metadata would more likely be abused and misleading for SEO).
I noticed <details> made the list but not <summary>. Is the latter a well-known tag compared to the former? In any case, semantic HTML is nice because they usually have good accessibility attributes by default.<p>In general, <summary>, <details>, <aside>, <main>, <nav>, and <dialog> prove to be highly useful for quickly hacking together a personal site without having to write much JavaScript, if at all.
Amusingly, the MDN guidance [0] on <em> vs <i> is exactly backwards from the example they give a paragraph below:<p>> 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.<p>And then [1]:<p><pre><code> <p>
In HTML 5, what was previously called
<em>block-level</em> content is now called <em>flow</em> content.
</p>
</code></pre>
...which would be an exemplar case of when to use <i>.<p>[0] <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em#i_vs._em" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...</a><p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em#examples" rel="nofollow noreferrer">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...</a>
A while ago there was this VR program called JanusVR where rooms were specified using custom HTML tags (<a href="https://janusxr.org/docs/build/introtojml/index.html" rel="nofollow noreferrer">https://janusxr.org/docs/build/introtojml/index.html</a>)<p>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": <a href="https://youtu.be/jYQtAcQddRg?t=48" rel="nofollow noreferrer">https://youtu.be/jYQtAcQddRg?t=48</a><p>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!<p>It's a great alternative to the walled gardens
> I believe we now have virtually a complete set of all UI elements needed to build any modern web application.<p>This is pretty far from the case. Three examples:<p>* 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.<p>* Carousels/slideshows.<p>* Tab areas.<p>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.<p>That said, HTML by default has gotten a lot more powerful than a lot of web devs know about. In particular, there's a lot of custom data lists and date pickers out there which are less powerful than the built-in HTML datalist and input type='date'
I think the #1 issue with HTML (and CSS) is that it is portrayed as being trivial, easy, "not a programming language". Someone who has written a few `<td>` "knows HTML". It's not respected. Consequently, people don't invest time in learning to use it well and keeping up with new features. And then they use it poorly, or run into awful examples of it, and come to the wrong conclusions about it.<p>While the idea of a markup/styling language is pretty simple, HTML+CSS deal heavily with <i>difficult</i> 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.
Oh man, there's a <dialog> element?!<p>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's about structuring text with a consensual function as every tag has an intention implied. Creating sites and webapps using this, results in a less contradictory foundation of the text and elements exposed in the UI.
I've been meaning to build some utility websites like a simple forum and a simple pastebin and the like for a while just entirely without javascript, kind of like the old days. I want a simpler web with less bloat.
Mostly agree, but datepickers are still a problem. The range of user experiences is so broad, and sometimes so counterintuitive (fuck you in particular, Android), that I still hesitate to suggest a native date input.
HTML is one of these technologies that (still) feels pregnant with infinite possibilities. But we can't really project meaningfully what can / should happen to the web platform (and the role of HTML in it) without considering the tortured trajectory it already has traversed, e.g., the major XHTML vs HTML5 (or W3C vs WHATWG) battles, its more recent "annihilation" in the hands of SPA and JS frameworks and the multiple roles it can play. In a sense HTML is too powerful for its own good. So prevailing interests will always try to tame it towards their own needs.<p>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:<p>* 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 <i>very limiting</i> and will never unlock all the positive potential of the web.<p>* transmitting semantically annotated non-text <i>data</i> 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.<p>* 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.<p>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.<p>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.<p>[1] <a href="https://en.wikipedia.org/wiki/WHATWG" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/WHATWG</a>
>> ... semantic HTML is more important now than ever<p>Except... semantic HTML has <i>never</i> 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.
Every time I decide it's finally time to use HTML5 native inputs like `<input type="date">` instead of JS-datepickers, I stumble on so many problems.<p>No "placeholder" attribute support, no "show picker on focus" functionality, etc.<p>You end up including so many JS/CSS hacks and workarounds that you're back to having a huge datepicker.js file.
One question is: "How easy is HTML to read for humans." Everyone who has spent more than a few months writing software will be familiar with the idea. But for someone who has never seen it - is the concept intuitive? Do bright 8th graders get it if shown it for the first time on a test?<p>I used to think the answer was "pretty difficult," but I haven't come up with anything better. Maybe there is something to be done with indentation - but that has it's own challenges.
Honestly, what we need is a new browser. I think everyone is sort of done with the URL bar, point click GUIs and we're going to see the need to transform things as LLMs become a more dominant query medium. It means the starting point is a search interface, it means much of what we want is automatically rendered as an embedded app in the page and it probably means we stop "browsing" and start consuming information on the web in a slightly different way.
I'm not clear from reading the article twice on how HTML helps solve issues interopping with sites like Facebook, Twitter, or reddit. I've scraped these sites before and they render in html but either do obsfucation or detect that you're scraping and block you. Actually html was worse than the previous reddit thing that used to exist, where you could add `.json` to basically any reddit url and get back the page in json format. So easy!<p>So, did I miss something in the article?
Not quite getting this article.<p>When you semantically describe your HTML, indeed the intent and meaning of your data becomes easily machine-readable.<p>That's not a solution, it's the entire problem. In today's ecosystem it means somebody takes your shit and runs with it. That's why the walled gardens are getting ever higher walls. "Open data" is an existential threat if you're the one paying for the creation/hosting of that data.
Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.<p>What was also surprising is that there is a Slider as well as Color picker element.<p>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).
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?<p>I also feel multivalued tag inputs also require JS widgets. Is there a pure HTML version?
<datalist> is so close to being perfect but I know the people I work for would want it to show the full list always and just float the selected value or closest spelled value to the top. Right now if you select a value on chrome and then click the list again it just shows that one value until you delete your entry.
Yeah do we need that disclaimer?<p>If I (non native English speaker) write a blog post it will be shit English and won’t read “smoothly”. Then ChatGPT makes it nice and smooth. I check if my intentions are left unaltered and then post. For professional stuff I used to ask my American colleague, now I don’t have to bother her anymore.
I think SEO is dead and the Semantic web will soon take over as search transitions to LLMS. If your data is better digested with minimal work by the LLM trainers, does your content perform better?<p>And maybe search isn’t the killer feature of the semantic web, maybe it will be agents?
Author and posters both are equivocating: the term "semantic HTML" is the OP author's term and is not clearly defined. In contrast the "semantic web" IS well-defined.<p>tl;dr - this article and discussion is a confused waste of time.
Where's the modern equivalent of xforms?<p>It is very telling that you still can't build more sophisticated forms declaratively in HTML/CSS.<p>After decades everyone seems to be cranking out their own custom made forms with various levels of JavaScript added.
The very first sentence:<p>"With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever"<p>No it's not, LLM basically invalidates the entire concept of semantic web, which never worked anyway.
The main thing I want added to the html spec is a spreadsheet element. It could be an enhancement to the table element. I want it to support sorting, filtering, pagination out of the box. And be responsive to boot.
When browsers finally have full and first-class WASM ecosystem integrated (and ecosystem developed), we'll be looking back on this "pretend-that-HTML-is-an-UI-framework" thing with genuine horror.
I would really really like to see a full-blown retro-looking social network (say, a Twitter/X clone), that works solely with pure HTML. It would be really amazing.
I've been using `dialog` and `details` of late, and couldn't be happier. At the same time, `section`, `article`, `header` and `footer` confuse me a lot. I've stopped using them.
If proper semantic HTML <i>helps</i> companies like ChatGPT, I'll make sure to try as hard as humanly possible to fuck with it with horrible HTML, then.
I already knew this was going to be some minimal and ugly website that consciously rejects all modern UI conventions<p>Congratulations, it passed pagerank and was readable.
this article's making me think. In this AI-driven landscape, the focus on semantic structure totally makes sense. But, is it really the remedy for the social media interoperability problem? Are we underestimating the appeal of decentralized platforms? And, do people genuinely not care about these alternatives?
As always, people almost never RTFM. When I see webdevs implement a hamburger menu with pure CSS I almost shed a tear.<p>For the love if god, study your tools! (and not from SEO spam articles)