I'm betting on HTML

by catskull • 3 years ago

968 446 3 years ago

pbohun• 3 years ago

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.

jackvalentine• 3 years ago

Might seem elitist but we’ve seen what ‘normal people’ looks like on the internet and perhaps we do want places where there is a barrier to entry.

ivolimmen• 3 years ago

This reminds me that I really need to re-evaluate the stuff I already know and keep it all updated.

leetrout• 3 years ago

I am lost in CSS these days since letting my skills atrophy over the past ~decade

nathansherburn2• 3 years ago

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.

nzoschke• 3 years ago

Great read and interactive demo.

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.

nathansherburn2• 3 years ago

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.

resonious• 3 years ago

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.

andai6• 3 years ago

My build system is cat!

irrational3• 3 years ago

Now move to the next level and have no build system.

bingemaker3• 3 years ago

Exporting to web using Flutter is a nightmare I believe. When I checked last time, rendering happens on a canvas. There is no markup at all

satvikpendem3• 3 years ago

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.

Alifatisk3• 3 years ago

rendering happens on a canvas

flutter run --web-renderer=html

cloked• 3 years ago

yup, Astro and "islands architecture" is such a joy to work with.

juancampa2• 3 years ago

Can you help me understand the utility of Daisy UI? Seems like it's the good old classes+stylesheet with extra steps (tailwind)

gbalduzzi2• 3 years ago

Well, instead of writing this for every button in your web app:

<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

kapitanjakc• 3 years ago

HTML is that nerd who's rich now.

Give me HTML,CSS,JS combo any day over some complex js library or platform.

netapy• 3 years ago

Used to work with that combo only – it's a mess as soon as you need to make reusable components. Svelte strikes a pretty good balance there !

satvikpendem3• 3 years ago

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.

klabb35• 3 years ago

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.

anyfactor4• 3 years ago

Tangent.

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

billforsternz2• 3 years ago

The misspelling of grammer instead of grammar is a little ironic in this context. Sorry:-)

anyfactor4• 3 years ago

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.

simonw• 3 years ago

That was deliberate - if you view the source:

    ... then GPT-4 fixed my <span class="typo">grammer</span> and spelling

p-e-w2• 3 years ago

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.

[1] https://github.com/languagetool-org/languagetool

xvilka• 3 years ago

If only it didn't require Java to run. Then integration with lightweight setups like NeoVim or Emacs would be so much better and easier.

latexr2• 3 years ago

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:

Can by styled quite aggressively.

anyfactor4• 3 years ago

Original 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.

klardotsh5• 3 years ago

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)

jamamp• 3 years ago

You might like this: http://youmightnotneedjs.com/

klabb35• 3 years ago

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.

lelanthran• 3 years ago

There's a scroll indicator!

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).

teaearlgraycold• 3 years ago

A good resource for developers targeting the tor browser set to secure mode.

liam_ja• 3 years ago

You might not need JS, but you will need a SCSS transpiler.

toastal2• 3 years ago

Beware: some of these are effectively hacks possibly messing up the browser history or introducing accessibility issues for screen readers, keyboard users, or otherwise.

flagrant_taco8• 3 years ago

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.

vanarok• 3 years ago

https://qutebrowser.org

klardotsh5• 3 years ago

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.

Gigachad2• 3 years ago

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.

rado4• 3 years ago

<progress>, <dialog>, <details> etc can be themed

Dalewyn• 3 years ago

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.

Sjeiti2• 3 years ago

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?

klardotsh5• 3 years ago

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.)

zelphirkalt5• 3 years ago

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".

laurels-marts• 3 years ago

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.

renegade-otter• 3 years ago

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.

It just seems... abandoned.

iamflimflam12• 3 years ago

That's the problem with most of these things, half assed implementations that just tick the box of "compliant with a standard".

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.

datagram2• 3 years ago

You can't style it with CSS.

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.

tannhaeuser2• 3 years ago

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.

[1] https://sgmljs.net/docs/html200129.html

mattmanser• 3 years ago

Most of them don't work properly and/or look terrible by default in all browsers.

So no-one uses them, so lots of people don't know about them.

didntcheck• 3 years ago

<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

noelwelsh• 3 years ago

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).

EspressoGPT• 3 years ago

I had heard of almost none of these HTML elements, and that's such a shame

I guess, that's on you – if you're a web developer, you definitely 100% need to know these elements. They're not new.

cratermoon4• 3 years ago

The <i> vs. <em> thing, how did I never realize that before? I guess I'd never thought about them having a semantic meaning.

lmm3• 3 years ago

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).

cratermoon4• 3 years ago

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.

xp84• 3 years ago

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.”

voydik• 3 years ago

Now I want to listen to King Gizzard.

NovaDudely2• 3 years ago

Eeyup! Whooo! reverb noise

catskull3• 3 years ago

Also check out Gizzhead.org - my site for tracking their live sets!

flobosg• 3 years ago

I went to one of their concerts during the “Infest the Rats’ Nest” tour. It was… wilder than expected. (In a good way!)

mkl95• 3 years ago

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?

robotresearcher• 3 years ago

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.

sham1• 3 years ago

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.

politelemon• 3 years ago

Yep you can style it with background color: https://jsfiddle.net/wezkth43/

enriquto• 3 years ago

I don't know if it's exactly the same color.

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.

ezekiel68• 3 years ago

<iframe>
Just kidding.

Worth the price of admission!

devjab3• 3 years ago

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.

klardotsh5• 3 years ago

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?

devjab3• 3 years ago

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.

waihtis• 3 years ago

I'm personally betting on HTMX

https://htmx.org/

klabb35• 3 years ago

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.

catskull3• 3 years ago

If I had to architect a front end today, I'd start with HTMX. Very curious how far a HTMX+Deno stack could get you.

infogulch4• 3 years ago

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.

guggle5• 3 years ago

I also like htmx. But one day someone pointed me to unpoly, which I find better. So I’ll spread the word here: https://unpoly.com/

re-thc• 3 years ago

Time for HTML6!?

tannhaeuser2• 3 years ago

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).

[1] https://sgmljs.net/blog/blog2303.html

zmmmmm• 3 years ago

Oh man, there's a <dialog> element?!

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.

troupo7• 3 years ago

Oh man, there's a <dialog> element?!

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.

p-e-w2• 3 years ago

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.

mmahemoff3• 3 years ago

Valid point. Ironically the main benefit of semantic markup is now an abstraction to help the human developers effect styling and control.

jraph• 3 years ago

Isn't the main benefit of semantic markup still accessibility?

theteapot• 3 years ago

ChatGPT (and its future offspring) can navigate regular websites the same way humans do. They don't need us to hold their hand.

It can?! It does that?

jack_pp• 3 years ago

In its current form, not as far as I know. Even the OpenAI tutorial on this matter scrapes first and uses only normal text.

https://github.com/openai/openai-cookbook/blob/main/apps/web...

andai6• 3 years ago

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).

kennyloginz• 3 years ago

You don’t need a good old Python script using Beautiful soup, you can use an LLM with the added benefit of not dealing with that cruft.

selfhoster11• 3 years ago

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.

wruza7• 3 years ago

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”.

delusional• 3 years ago

“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.

kevinstubbs2• 3 years ago

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.

3cats-in-a-coat• 3 years ago

LLM would find it easier to browse through a browser. Like us. Implying image model linked.

tyingq• 3 years ago

"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.

datagram2• 3 years ago

There's already companies working on this: https://axiom.ai/

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.

fauigerzigerk2• 3 years ago

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.

abwizz3• 3 years ago

They know when a sequence of paragraphs constitutes a "list", without it having to be explicitly marked as such, etc.

that's the thing; they don't know - they guess

circuit10• 3 years ago

Humans do the same, it’s usually obvious from the context

rezonant2• 3 years ago

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.

bob10293• 3 years ago

This seems reductive to me.

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?

feitingen• 3 years ago

Lots of websites already present a machine friendly site to google-bot and some other spiders.

I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.

yellowapple• 3 years ago

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?

    <div id="reactElement420" class="wangularClass69"><div class="25-long red" visibility="hidden"/><div class="50-long yellow" visibility="hidden"/><div class="75-long green"/></div>

    <progress max="100" value="69">69%</progress>

The first example is hyperbolic, sure, but only slightly.

fennecfoxy• 3 years ago

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).

ric2b• 3 years ago

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).

delta_p_delta_x2• 3 years ago

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!

[1] https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...

catskull3• 3 years ago

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?

delta_p_delta_x2• 3 years ago

It looks like they do! Maybe there's some option to select it. I haven't bought it yet, so I can't test it...

irrational3• 3 years ago

Thank you! I was wondering why the font looked so wonky. It looks much better now.

bingemaker3• 3 years ago

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.

flagrant_taco8• 3 years ago

Section and article really don't add any value, but header and footer elements are used as landmarks by adjustive technologies like screen readers

troupo7• 3 years ago

Section and article really don't add any value

They are nice hints to assistive technologies and reader mode.

koito17• 3 years ago

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.

spondyl• 3 years ago

I assume <summary> was not explicitly mentioned because it generally only appears as a child of <details>.

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...

shantanujoshi• 3 years ago

So down for this. Feels intuitive. JS is dead. Superconductors at room temp. WERE BACK

marcus_holmes• 3 years ago

I use <details> a lot for debugging Go html templates.

    {{if .DevMode}}
    <details>
    <summary>Data</summary>
    {{.}}
    </details>
    {{end}}

It's nicely unobtrusive when collapsed, doesn't mess up the page completely. Then expands to the full glory when needed.

dgb23• 3 years ago

You can use it for all sorts of things on web pages, including collapsible menues and such.

Github markdown lets you use it too. People use it for examples and inline explanations.

birracerveza• 3 years ago

I abuse the <details> element when I can. It's so neat, I don't know why it's not used more often.

Knee_Pain• 3 years ago

As always, people almost never RTFM. When I see webdevs implement a hamburger menu with pure CSS I almost shed a tear.

For the love if god, study your tools! (and not from SEO spam articles)

aitchnyu• 3 years ago

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?

Conscat• 3 years ago

Most websites I enter don't work well on mobile, but this one does!

adamredwoods• 3 years ago

> Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time.

Why do I want to make my website AI-accessible? It, or some mega-rich company will reap the rewards, not me.

jcotton42• 3 years ago

Machine-readable here also means screenreader-readable

rado4• 3 years ago

Yes, always bet on HTML. I made the chart here in semantic HTML with a definition list, which is also keyboard accessible, and overlaid by a canvas: https://www.skrill.com/en/currency-converter/ – no libraries needed.

rado4• 3 years ago

Recently replaced 13 lines of inline SVG by a single <progress> element.

inopinatus• 3 years ago

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.

nicbou• 3 years ago

Gov.uk recommends against them. This should be enough to discourage most people.

petepete• 3 years ago

There are some situations where date pickers do make sense, like when booking an appointment in the future - being able to see the day is useful. Being able to overlay the date picker with other information like days where you're free or when appointment slots are available makes them unbeatable.

But, when asking for a date people know, like their date of birth, date pickers just slow people down and confuse them. User research has shown this repeatedly.

https://github.com/alphagov/govuk-design-system-backlog/issu...

jillesvangurp• 3 years ago

The point of walled garden is that they are very tempting to stay inside off for users. Their power comes from most users not resisting that temptation.

Becoming the equivalent of a digital hermit and living in a hole in the ground outside these walls, which is what I would characterize this as, is not going to result on a lot of people stepping outside those walls. If you've ever watched Life of Brian, you'll have a good mental picture here.

It's a variation of brutalist web development (let's not call it design) that just doesn't really appeal to the masses. It never has. The history of the web is endless attempts to pimp it with Applets, Flash, Shockwave, Silverlight, etc. The latest incarnation of that is web assembly. This basically allows you to use anything native that works elsewhere (desktop, mobile, game consoles, AR/VR, etc.) in a browser as well.

Of course there's a severe risk of this to disappear into more walled gardens. But I don't think sitting in a dusty old hole in the middle of nowhere while shaking your fists at progress does much to change that.

beej712• 3 years ago

I think there's a middle ground here where we're building good-looking web pages with a sub-10 MB weight. Unfortunately, it makes no business sense to do so.

andai6• 3 years ago

Sub 10MB? That's a whole YouTube video!

zelphirkalt5• 3 years ago

Sometimes though, that dusty hole in the middle of nowhere seems to be the most progressive in terms of using standards, when the person sitting in it adopts new HTML elements, immediately having accessibility, while their JS-based rivals still struggle with restoring the functionality of the back button and adding routes in their SPA to get back something resembling normal linking behavior. In a way that is a much deeper dusty hole in the ground to dig for oneself.

Anyway, it is questionable, how much progress there is in moving into walled gardens and throwing multi megabyte websites at visitors, when we can have the same functionality with less.

barrenko• 3 years ago

Kinda beautiful. More resources that focus solo on "modern" HTML + CSS?

vermilingua• 3 years ago

Amusingly, the MDN guidance [0] on <em> vs <i> is exactly backwards from the example they give a paragraph below:

The <em> element represents stress emphasis of its contents, while the <i> element represents text that is set off from the normal prose, such as... when the text refers to the definition of a word instead of representing its semantic meaning.

And then [1]:

    <p>
      In HTML 5, what was previously called
      <em>block-level</em> content is now called <em>flow</em> content.
    </p>

...which would be an exemplar case of when to use <i>.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/em...

andai6• 3 years ago

I thought <em> was semantic ("emphasis") and <i> is stylistic ("italics")? And last I heard (when <em> came out) you weren't supposed to use <i> anymore because it's bad form to use HTML for styling! Much like <center>.

Timwi• 3 years ago

Yes, that was the mantra some 15–20 years ago. Then HTML 5 came out, in which <center> was indeed obsoleted, but <i>/<b>/<u> weren't and instead got a semantic meaning. (A semantic meaning which, admittedly, is subtle, borderline esoteric, so it's very rarely used as intended.)

komali2• 3 years ago

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!

So, did I miss something in the article?

nsonha• 3 years ago

The very first sentence:

"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.

kabes• 3 years ago

There's lots of reasons I think using semantic html is important, but making it more easily scrapable by chatGPT isn't one of them.

backtoyoujim• 3 years ago

If you don't want rounded corners then what's this all been about ? What am I working toward ?

lord5et• 3 years ago

Two questions: 1. How easy styling of these elements is? 2. What about browser support. Do all major browsers support them?

PlatinumBench• 3 years ago

For any given feature, you can check https://caniuse.com/ to see the browser compatibility

rado4• 3 years ago

It's very easy and they are widely supported. Example: https://radogado.github.io/n-modal/

inktype• 3 years ago

No more datepickers please!

Don't be surprised that people don't use native date pickers when they can't be configured to display ISO dates

azangru• 3 years ago

With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever.

It's odd: I remember seeing an argument recently, though can't remember where exactly (perhaps [0]?), that LLMs make semantic HTML obsolete, because they "understand" the text anyway.

After all, humans didn't need html to be semantic in order to be able to read it — machines did. And if machines are approaching humans' capability to read texts, then doesn't this put the whole semantic html exercise into question?

0 – https://shkspr.mobi/blog/2023/05/does-ai-mean-we-dont-need-t...

fauigerzigerk2• 3 years ago

Humans interpret text as rendered by the browser. That includes a lot of visual information and even text that only becomes visible in response to user interaction.

For an LLM (or an AI in general) to do what humans do, it would have to process the rendered output and interact with the site like we do (such as clicking on a dropdown to make the available options visible).

The same information represented as semantic HTML (i.e text) is far cheaper to process for an AI. I think cost is a key consideration in everything AI. If it's too expensive then it won't happen, even if it could theoretically be done.

nologic012• 3 years ago

HTML is one of these technologies that (still) feels pregnant with infinite possibilities. But we can't really project meaningfully what can / should happen to the web platform (and the role of HTML in it) without considering the tortured trajectory it already has traversed, e.g., the major XHTML vs HTML5 (or W3C vs WHATWG) battles, its more recent "annihilation" in the hands of SPA and JS frameworks and the multiple roles it can play. In a sense HTML is too powerful for its own good. So prevailing interests will always try to tame it towards their own needs.

HTML is the conduit and enabler of at least three distinct functionalities that are made available by a decentralized internet comprising clusters of server and client machines:

* transmitting the information to implement hypertext (=the simplest implementation of linked textual documents). This transmission of linked natural language data has changed the world already and is sufficient to support e.g., a planet of interconnected bloggers. HTML purists (like the OP) focus on this angle but this is very limiting and will never unlock all the positive potential of the web.

* transmitting semantically annotated non-text data of all types (numerical, graphical, objects etc). This vision has never really materialized in either its XHTML or SVG guises. Today the only hint that HTML is capable of transmitting such data is the table element. Yet it has enough in-principle semantics to transmit any JSON object.

* transmitting UI elements. Why do we need UI elements at all and are they intrinsically evil? The core function of UI elements, both the semantic aspect (hierarchical relations) and the geometric aspect (i.e. CSS and mapping stuff to a 2D screen) are essential and entirely benign. They simply help organize more complex patterns. HTML ultras that avoid CSS essentially rely on default such mappings.

Imho an alternative vision to the degenerate web of today that is simply the funnel that gets you to the walled gardens built by adtech (actually humanity grinding machines) must stop being naive, simplistic and Luddite. In all these web technologies of yesterday you can trace battles that were lost, paths not taken.

The web we want is an empowering, democratic, decentralized platform that respects and elevates individuals in the digital realm. This web is not tech-phobic. It is confident and develops / adopts any and all technologies that fit is values.

[1] https://en.wikipedia.org/wiki/WHATWG

irrational3• 3 years ago

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.

yieldcrv• 3 years ago

I already knew this was going to be some minimal and ugly website that consciously rejects all modern UI conventions

Congratulations, it passed pagerank and was readable.

robobro• 3 years ago

I only recently stumbled across <details> and I have to say, it's cool to have that available in vanilla HTML.

SoraNoTenshi• 3 years ago

Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.

What was also surprising is that there is a Slider as well as Color picker element.

Fair enough i am not much of a web person myself, but i know that a lot of webpages have their own custom JavaScript implementation of those elements (if needed).

zelphirkalt5• 3 years ago

Very surprising to me was that there is a semantic difference in <i> and <em> (the same is also the case with <b> and <strong>) apparently, also PDA readers for e.g., blind people are also aware of this semantic difference.

It is in the names:

<em> = emphasized, as in "this part of the text should be emphasized in whatever way the styling dictates

<i> = italic, just a way to style directly

<strong> = strongly emphasized

<b> = bold, just a way to style directly

<i> and <b> do not make a statement about semantics, they are for styling, and probably not much used in modern valid HTML, or at least should not, if you have CSS available. <em> and <strong> make statements about importance of a part of text, in whatever way you want to style that. It just happens, that the default styling for those is italic and bold.

rapnie2• 3 years ago

Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2]

Quoting from the doc here's the stack:

    - WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being actively extended with features such as WasmGC.
    - WebGPU provides an API (to JavaScript) that exposes a modern computation and rendering pipeline.
    - Accessible Rich Internet Applications (ARIA) provides an ontology for enabling accessibility of arbitrary content.
    - WebHID provides an API (to JavaScript) that exposes the underlying input devices on the device.

    This document proposes to enable browsers to render web pages that are served not as HTML files, but as Wasm files, skipping the need for HTML, JS, and CSS parsing in the rendering of the page, by having the WebGPU, ARIA, and WebHID APIs exposed directly to Wasm.

[0] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...

[1] https://news.ycombinator.com/item?id=36968263

[2] https://news.ycombinator.com/item?id=34612696

troupo7• 3 years ago

On its HN submission (referencing the wrong URL) he defends against criticism [1]

And it's a very weak defence. There are great rebuttals to whatever he writes in there.

I mean, he rants that HTML failed, and then literally proposes "By providing low-level primitives instead, applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures, enabling a much richer set of interactions and custom experiences with much less effort on the part of the developer."

Has he tried to implement any of those from scratch using only low-level primitives? How is it "much less effort on the developer"?

In general it just reads like a justification for Flutter:

"This API alone is not useful for application developers, since it provides no high-level primitives. However, as with other platforms, powerful frameworks will be developed to target this set of APIs. A proof of concept already exists in Flutter"

Why not provide high-level powerful primitives out of the box? Oh, then Flutter wouldn't have a reason to exist.

---

As a side note: WebHID is a Chrome-only non-standard. They literally dumped a non-spec onto other browser vendors, shipped it to prod, and then "updated" the spec later: https://github.com/mozilla/standards-positions/issues/459

rapnie2• 3 years ago

Ah, that is enlightening, thank you. I knew he works for Flutter, but I know very little about Flutter and the standards it uses. That WebHID I hadn't heard of till this doc, so figures if this is a non-standard. More Google worrying power play then, similar to the web integrity bomb under the open web.

mike_hearn3• 3 years ago

So what are these great rebuttals? "Why not provide high-level powerful primitives out of the box?" <- the browser is a 30 year effort to do that and has always failed at it. This thread is full of people complaining that the browser implementations of even basic widgets aren't usable, of course any higher level or more complex features are often missing, and that's with web tech relying heavily on patrons that have budgets the size of the Sun.

So in practice most devs bypasses them and write their own high level primitives anyway, relying on the browser only for low level APIs. That's the point the article is making. Hixie is merely observing that this situation exists, has always existed and probably always will, so browser makers may as well embrace it. And if you see the discussion thread, that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy. And then just tell web devs to adopt a high level framework that isn't HTML.

teekert• 3 years ago

Yeah do we need that disclaimer?

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.

broodbucket• 3 years ago

I don't see it as confessing their sins, more like "FYI, I used X tool to help me with Y" like you'd see "Page generated by Z" in a footer except in a header since it's related to the content itself. Unless you're writing an assignment for an English class I don't think anyone would feel lied to if they found out you had help from an AI translator.

jll29• 3 years ago

HTML was designed as an SGML application for networked hypertext.

As an alternative to what the original post posits, we could leave it for that purpose, and design another (now XML) application for user interfaces: windows, buttons, scroll bars (if desired), text controls (no I'm not talking about textarea for CGI), the kind of controls that Windows or X11+MOTIF provide, expressed as tags in a UIML (User Interface Markup Language). This would have the advantage that we could start from a clean slate, and the open source interpreter for this technology could be integrated into all Web browsers, so behavior would be identical.

UIML would be designed as an XML application for networked software applications' user interfaces.

Of course, you could execute them locally, too. There could be graphical UI designer of the types that already exist, e.g. Visual Studio would just write out a UIML as a new export format.

Crazy idea? Actually, it's just applying the "Do one thing, and do it well." mantra to XML <-> XHTML + UIML instead of packing everything possible into one now-bloated markup language it was never designed to do. So if this comment had a title, it would be "I'm betting on Internet standards" (plural).

Zen1th• 3 years ago

Wouldn't that be XUL[1] ? It's been there since 1997 and never took off outside of Mozilla, so it was deprecated and removed in 2017. It wasn't meant for use in the wen directly as replacing an entire ecosystem with a completely different way of doing UIs would be close to impossible, all for small benefits.

[1] https://wiki.mozilla.org/XUL:Home_Page

pravus• 3 years ago

XML <-> XHTML + UIML

I agree with this idea. We need a toolkit standard for the web and to stop shoving application code into a document model. What's strange to me is that so many people have been trying so hard to either resist or deny this.

The proposed solution is a non-starter, though. Anything involving XML is probably DOA for the web. I know I don't want to touch it. But something needs to fill this space because UI on the web is so god-awfully atrocious.

mike_hearn3• 3 years ago

It's been done many times. Mozilla had XUL. Internet Explorer had XBAPs (XAML Browser Apps) [1]. Android has an XML UI language. Java has FXML, which IMHO is the cleanest and nicest of the lot.

It never works. Same reason as to why adding non-JS languages never works: because making a GUI toolkit or implementing a language is a huge amount of work, other browser makers refuse to get on board because it'd mean they're playing catchup. Then web devs refuse to use it, because not every browser supports it. The only acceptable way forward is to gradually glue lots of small things onto HTML, and see which ones get implemented by the others. Because this is such an incremental and random process you end up with a pretty inconsistent platform that lacks a lot of stuff you'd intuitively expect.

[1] https://learn.microsoft.com/en-us/dotnet/desktop/wpf/app-dev...

SPBS• 3 years ago

ugh I was so excited to see pure HTML modals were a thing with <dialog> only to find out there's no way of triggering them without JavaScript. Using pure HTML you can only dismiss them, not trigger them.

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.

Kiro• 3 years ago

I don't see the higher purpose of "HTML only" if that means we need to extend HTML with scripting capabilities. In that case I rather just use JavaScript.

pbhjpbhj• 3 years ago

Users might prefer, say, that 99% of the time a data selection widget behaves the same whenever accessed by their browser. When devs choose a JS UI library then that's usually what users get. Wouldn't it be good to have all tables have the same features (sort, collapse, column-select, data export), rather than only having rich features if the dev implemented them, duplicating the effort of millions of other devs.

There's a sliding scale here, with html at one end and each page ships a parser and libraries at the other - why have an img tag, just let the page developer implement a JS based interpreter?

contravariant2• 3 years ago

You can show or hide it depending on the current hash. Though admittedly that does require CSS.

aaviator42• 3 years ago

You can implement modals without JS, with HTML and CSS.

For an example, click on '?' in the top right corner here: https://aavi.xyz/proj/colors/

ovao• 3 years ago

There are useful tricks to changing CSS properties via checkbox state and pseudo-selectors to implement simple modals (which won’t be accessible), but you can’t open a modal <dialog> element without JS.

Weirdly, you can close them with a form submission, but you can’t open them with one.

clairity3• 3 years ago

yah, would be nice if it were baked into html itself, but at least the javascript isn't complicated, and can be put in an `onclick` attribute:

  <button onclick="document.querySelector('#my-dialog').showModal();">open my dialog</button>

divan2• 3 years ago

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.

contravariant2• 3 years ago

And the old timers will look upon the WASM mangled unreadable mess that webpages have become with equal horror.

divan2• 3 years ago

Web pages can still be in HTML. It's a bad choice for UI apps.

(With current state of web ecosystem it's hard to tell the difference between what is page and what is an app, of course. But imagine we had a real choice on the outset of web.)

grumbel• 3 years ago

I would care more about markup if the browser would actually be able to do anything interesting with it, but for most part markup is a just a default style for an element, the semantic meaning is ignored. The <time> tag is about the last one I can think of that actually made a difference from the users perspective.

There is also a lot of markup for really common tasks still missing, I'd like to see an <advertisment> and something to handle pagination at the browser level (rel="next" has been around for decades, but browser don't care). And more broadly, I'd really like to see much better support for long-form documents in HTML or at the very least native ePub support in the browser.

DigitalSea• 3 years ago

The real solution is Web Components.

cassepipe4• 3 years ago

I really want to believe in the semantic web, I really want to believe in the ability of the browser to provide me with good default modules with a good default styling, but for now I just have to accept this is not the case. The fact that I have to think about labeling a input (why is this not an attribute ?), not being sure if I should use it as a wrapper of as a sibling with the `for=` attribute... and this is just the tip of the iceberg. For each tag, I have to learn the whole history of its development and make an inquiry about what's the right way to do it nowadays.

We could have had nice things.

Ssssshhh, calm down, let go.

flagrant_taco8• 3 years ago

(I don't know what tools you use so this isn't a comment directed at you specifically)

If web developers spent a fraction of the time required to learn react, tailwind, etc on learning HTML the web would be in a much better spot.

There are definitely quirks and rough edges, but if every web devs knew how to get the most out of semantic HTML we'd likely have a lot less JS in the browser, fewer accessibility bugs, and more eyes on when specs could use an update to fix our replace some of these quirks.

berkes10• 3 years ago

on learning HTML

Anecdote. Was recently freelancing at a web-agency. They build complex web-apps. Lot's of senior and experienced web-devs there: react, mui, typescript, tailwind, and a large host of backend frameworks under the belt.

But when I built a quick PoC using `<template>` a few lines of JS and some of the elements used in the article (meter, dialog, details) they were flabbergasted. This was a whole team of experienced developers doing web-ui development for their job, 40+ hours a week. And they didn't know, not even realized, that HTML had them covered for loads of use-cases.

Edit: I am no frontend-dev, so I have to look up everything anyway. Which is probably why I come across those "new" things easier.

cassepipe4• 3 years ago

I am using svelte as it seems the best of both world, I can actually pretend I am just writing html and js where related pieces are colocated with a module system enough that it is actually readable while also harnessing my html and js/ts knowledge.

And since js has to be minified there's a "compilation" step anyways.

Didn't find a better solution so far. The web is almost nice to write code for.

d357r0y3r2• 3 years ago

I think if the web apps we were working on were marketing landing pages, you'd be right.

For any real application that software engineers are hired to work on, "learning HTML" would do very little. Most high-level front-end engineers do know HTML. There's not that much to know.

The web today is basically a universal desktop client. Apps like Figma, Slack, Airtable, and thousands of others are not really websites, they're hosted applications that have a mind boggling amount of interactivity.

idoubtit• 3 years ago

I have to think about labeling a input (why is this not an attribute ?)

If input labels were html attributes, forms would be much less versatile. It would merge 2 visual elements into one, which would make it hard to adjust the display (think of inputs with right-aligned labels to their left, or checkboxes with labels to their right). And a "label" attribute would mean a plain text content... Seems awfully restrictive to me.

Granted, HTML has a complex history and several layers, like anything that's been in use for decades. But it hasn't changed much recently, and (thanks, MDN) it's easy to learn learn enough to identify what is possible with HTML5 and dig later if necessary.

cassepipe4• 3 years ago

I don't understand the following. Would you be kind enough to elaborate ?

And a "label" attribute would mean a plain text content.

jmull• 3 years ago

For each tag, I have to learn the whole history of its development and make an inquiry about what's the right way to do it nowadays.

That you have to learn the semantics of the tags is inherent in any semantic tagging system. If you don't like that idea then you fundamentally disagree with the idea of the semantic web.

Of course, with any publishing system -- or any system at all -- you're going to need to learn how to use the primitives it provides to use it effectively, so this isn't really about the semantic web.

parasti• 3 years ago

For what it's worth, I've found that I almost always want to put the label tag after the input tag. That enables me to select and style the label based on the input state via CSS pseudoclasses.

marcosdumay• 3 years ago

One more hack created by the lack of the :has selector. And yet browsers won't prioritize it.

aviavinash• 3 years ago

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?

asim• 3 years ago

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.

gryfft• 3 years ago

Wow, thanks for the nightmares.

klaplume• 3 years ago

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!

merdaverse2• 3 years ago

The problem I see with sematic web is that no matter how easy it gets, developers refuse to use it properly. I have been looking closely at the <main> tag since a browser extension of mine uses it, and although it is extremely clear what it should do in the MDN documentation (the documentation itself is a good example usage of <main>, <aside> etc.), very little sites use it properly. Even the fancy professional sites wrap all the page content, including navigation, footers and the like inside the <main> tag, which should only be for the main content of the page.

If such a simple element can't be used properly, I have no hope for all the others.

berkes10• 3 years ago

simple element can't be used properly, I have no hope for all the others.

The first solution that comes to mind, is stricter validation. Where the browser would just refuse to render a <footer> properly unless it's structure is correct.

But we had that. Anything before HTML4 really. And it sucked even more.

So maybe browser dev-tooling that throws warning or errors when devs are Doing It Wrong?

merdaverse2• 3 years ago

The browser approach is best effort at rendering, rather than enforcing conventions.

And I doubt that tooling can help with all the complicated ways in which HTML is generated (React, SSR etc). I was actually surprised at how underbaked editor support for CSS is in VSCode (the most widely used frontend editor). If the most modern tooling can't understand that a CSS variable is declared in a different file and autocomplete it for me in a .vue file, I get the impression that tooling is severely lagging behind the frameworks.

johnnyworker3• 3 years ago

Give me an incentive to use it. If it looks exactly the same and behaves exactly the same, "div" is half the characters of "footer" so it wins.

Personally, the argument that search engines will do nice things with semantic HTML didn't convince me back then, and I don't even see it brought up today, because search, like fish, stinks from the head, and we stopped pretending otherwise.

So that leaves accessibility. Is there a way to visualize what screen readers to with a page? I know about the tools that check for missing ARIA roles and whatnot, but that still doesn't catch me using a div when I should have used aside. And I know I won't try to navigate and use every aspect of things I make by actually using a screenreader. Call me lazy, but that's just not going to happen. But I also don't want to just give up and make it the problem of other people, either. I wanna meet halfway if possible. Any tips or tools or ideas welcome.

jcpst• 3 years ago

I would love to just flip a switch in the browser dev tools and see html validation errors.

mkoubaa• 3 years ago

The same developers who misuse http verbs, no less.

We shouldn't pretend that these things are contracts

gbalduzzi2• 3 years ago

There simply is no incentive whatsoever of using them correctly. I try to use them correctly but aside from the time spent in deciding what each element should be there were no differences at all

krainboltgreene3• 3 years ago

developers refuse to use it properly

literally every developer who has ever used a `<p>` tag for paragraph has used it properly. An `class="card"`. A `<link>`.

How are so many tech literate people in this thread bemoaning the "uselessness" or "failure" of semantic web? It's like if you told me "Man I wish motorvehicles were successful, it'd sure be nice to travel long distances!"

DrStartup• 3 years ago

I think SEO is dead and the Semantic web will soon take over as search transitions to LLMS. If your data is better digested with minimal work by the LLM trainers, does your content perform better?

And maybe search isn’t the killer feature of the semantic web, maybe it will be agents?

sourcecodeplz2• 3 years ago

What's wrong with <iframe>? I find it quite useful.

qwerty4561272• 3 years ago

Some social networks used to offer rich page customization with Wiki or markup or something like that. And that essentially was the HTML wheel reinvented. Some even offer in-app apps, some even lock whole life oof the whole population in them (e.g. China).

A social network with (or without) this essentially is reinventing the wheel of the whole Internet which is made of HTML pages (which are replaced by personal pages on a social network), RSS/ATOM (which is replaced with in-app notifications), e-mail (which is replaced with in-app direct messages), Usenet (which is replaced with in-app groups) etc. Everyone theoretically could just have a personal www page on their own domain instead of a social network account.

Oh, and HTML never needed CSS to be not ugly - that's the browser default settings which make unstyled (styled with default styles) HTML pages look this way. We always could just change the default fonts/colors or apply a userstyle for more complex things.

Once general population joined to the Internet (where in the past there were only nerds) the demand emerged for it to become much easier and prettier and the corporations responded offering the features pople want taking their freedom, privacy and independence in exchange (which an average person doesn't mind, all they ace about is that being "for free"). We could just build better apps (browsers with sensible defaults, intuitive e-mail and Usenet clients and web servers), but we still lack them because nobody wants do serious work for free and make great products which would suit everybody ather than themselves.

sourcecodeplz2• 3 years ago

You don't use CSS just to make pages pretty. It is useful for accessibility and user experience as well. Not to mention personalization. Not every page needs to have a carbon copy style of others. CSS is so useful it is almost ridiculous to say HTML never needed it.

nologic012• 3 years ago

Not sure why people are banging against css. Its just fundamental separation of content logic from content representation which is best practice (see e.g grammar of graphics)

I think people are just burning out from the oppresive tech environment, the endless hypes, the lack of a feel-good factor. All these negatively experienced developmemts are taking their toll. This forces people into all sorts of extreme corners, like the gemini protocol or css-less sites.

qwerty4561272• 3 years ago

CSS is so useful it is almost ridiculous to say HTML never needed it

I didn't mean CSS is useless, I meant it is not necessary for every website to define their own CSS to look nice and not ugly. The problem is almost no ordinary user knows they can define their own defaults (fonts, background - in browser settings, more complex - in user CSS).

sensanaty• 3 years ago

If proper semantic HTML helps companies like ChatGPT, I'll make sure to try as hard as humanly possible to fuck with it with horrible HTML, then.

lancesells• 3 years ago

So people want to make it easier for LLMs to ingest their work? I'm all for HTML but this article is confusing to me.

sebastianconcpt• 3 years ago

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.

onion-soup• 3 years ago

Rumble about nothing

rchaud• 3 years ago

I'm aware of all these HTML elements, I use them for my personal digital garden website that just uses CSS grid to align everything, no external scripts or styles.

Guess what? It still looks bad! The <summary><details> element for instance is hard to style with CSS, things don't work the way you'd expect. Frankly that element was leapfrogged in terms of usability and customization by pretty much any jQuery accordion script from 2009.

YLYvYkHeB2NRNT• 3 years ago

the AI disclaimer put me off from reading it. I want to hear your words, not ChatGPT

chickenfeed3• 3 years ago

I don't want to totally neg on web dev. But it does suck donkey balls. I've been doing it for years. From writing raw html,to using scripting langs, frameworks and what not. And the amount of time it takes to do not a lot I figure is just a colossal brain drain. We just went on holiday, and all I wanted to do was look up places to go eat and drink, or visit for the day, and most of the sites sucked. Or were out of date. Not updated or whatnot. There's still lots of fire once and forget sites. Probably because budgets are tight and people can't afford updates. Or the updates are just technically too difficult for people to grok.

The complexity of sites is paralysing. What could be a few simple pages of texts and images is totally over-engineered for no good reason and is burning a stupid amount of CPU cycles. Probably built on a hacked off-the-shelf CMS that could do with security updates.

CMS and frameworks are being used, because there wasn't a good alternative to something as neat as frames.

A site I'm working on at the moment has quite a pretty design, but pull the CSS and it's just a mess.

I was looking at going to the cinema recently and the local picture house made it practically impossible to just scan the handful of films that were playing that week. I realised you could pretty much shove it all in a spreadsheet and it would read better. Heck, I downloaded the JSON from their API, and it was easier to read.

Most of it is all tiresome lipstick on a pig.

Facebook was a success for a few reasons, one was the easy on-boarding (which uses nefarious privacy trade-offs), the other is that you could actually share photos easily. Also see: Whatsapp and Instagram. Publishing needs to be easy. And despite a simple FTP being easy, there's a weird disconnect in the usability process that makes this tricky for mere mortals. People want to drag and drop, or upload, fire and forget and edit easily. And those wanting to consume data, really just want the bare essentials: The data.

Technotroll• 3 years ago

Part of this is the ever increasing amount of tags and elements in HTML files. Instead of being a document markup, it's a page markup, and it's difficult to discern where one stops and the other begins, although the W3C has tried with the addition of article and section elements. But then I suppose the raw HTML code was never meant to be read by other than devs in the first place, so there's that.

chickenfeed3• 3 years ago

There was that small window of niceness, where the html diminished in size. Now it's just all pseudo inline styles painted by class names with lashings of scripts. Always surprised when you peek under pretty much a bereft page of nothing and it's a whole heap of code.

I'm one of those annoying people that just uses reader mode anyway - not that it always works. Because I get fed up of zooming in and out, inflating text size etc etc.

mmsimanga• 3 years ago

You hit the nail on the head when you mentioned WhatsApp. In my country in Africa WhatsApp is so popular so much so that mobile network providers even sell WhatsApp data bundles. If I want to find something, like wire fencing I start by asking WhatsApp groups I am in. Family, neighborhood and even high school friends. Typically I get a few numbers and then I WhatsApp the service provider and I get up to date information. The service providers can't afford up to date web sites. WhatsApp also has a feature to include a catalogue in your profile. This is for business accounts which are also free.

taylodl• 3 years ago

That's why I suggest for most small business to use Wix. Does your site tend to look like everybody else's? Yes - and that's not necessarily a bad thing, and since it's so easy-to-use and update, customers will appreciate having the up-to-date information they need.

What I'd like to see (maybe it exists, I haven't looked in a while) is something I would market as "Wix Widgets." These would be data-connected widgets where there's some customization to wire-in a REST service call and map the data points to the widget display. This would go a long way to handling the needs for internal-facing web sites every company has these days.

We really need simple solutions for the 90%-95% of web pages out there.

jklinger410• 3 years ago

It's funny how I hear that web platforms are the best and most consistent cross-platform GUI systems, but then building on that system is awful.

So I'm wondering if maybe this is just the nature of GUI. Where you have to give every single instruction, eat up a bunch of cycles, or it simply won't function as cross-platform.

oneeyedpigeon6• 3 years ago

I don't think it's that funny, given that "best" and "most consistent" are both highly subjective.

I am a huge fan of the HTML/CSS/JS stack—it's far, far easier to knock up simple GUI-based apps using those technologies than, for example, the Visual Basic / Delphi tools that we were all using beforehand. And, remember, apps are not really what HTML was ever intended for, so any kind of 'app' support is a big bonus.

jrm4• 3 years ago

I do, and I teach it. It's a lot of ridiculous garbage.

I think an aggressive defense of e.g. what "reader mode" does is incredibly important, to the point that I'd support e.g. legislation.

OOPMan• 3 years ago

I spent some time recently working on a C++ application for Windows using Qt for the UI and general application framework.

I was surprised at how easy it is to achieve useful things with C++ and Qt in this day and age.

When I used it back in the early 2000s it was a lot more painful but both C++ and Qt have come a looking way.

Honestly, to paraphrase Hayao Miyazaki...the web was a mistake.

It's almost a classic example of worse is better.

ethbr0• 3 years ago

And those wanting to consume data, really just want the bare essentials: The data.

I don't think they do. The average HN reader, probably; but not the average person.

What they want is a well styled and usable webpage. Unfortunately, there aren't enough effective and talented UX designers (or stakeholders at companies with decent UX intuition).

This leads to the current situation where the average person would be better served by bare essential data, even if it's not their preference, because it's still better than the kludgy UX average design a company is able to afford.

{bad UX} << {raw data} < {good UX}

The end run around this is what WordPress realized: create professional styles/themes and allow users to purchase and apply them. But that can't solve bad stakeholder taste.

Which brings me back to Facebook, which I would argue succeeded because it standardized and mandated a professional UX.

{data from people} + {professional, standardized UX} = {winning}

You can dislike the original Facebook UX, but I don't think anyone would claim it was amateur level work. Which is what everyone's perception of MySpace/Geocities et al. was.

tambourine_man• 3 years ago

Or the updates are just technically too difficult for people to grok.

Or because they forget to. And almost no one visit their site anyway.

Unfortunately, Facebook and Instagram took that place. Where is it, phone number, what time is it open, some pretty pictures. Done.

bobajeff• 3 years ago

This is why I want a browser where I can use Reader Mode on everything. Not just articles and blogs but also forums, q&a sites, online stores, image galleries, video sites.

Because of this I don't bet on the web because it's really designed to be an app framework now (admittedly the best one) not for being a simple client that sends and receives data (like XMPP, SIP, IRC, SMTP, IMAP and NNTP).

omgmajk2• 3 years ago

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.

boredumb3• 3 years ago

I'm not javascript free, but i've been actively pursueing building useful things with as little if any javascript and have been impressed with what I can get done with forms and html templating.

A few years ago moving to a new area I was trying to find a CPA and saw simple brochure sites are loading 10+ mb of resources and 10+ JS snippets and realized how bad things have really gotten, even with an adblocker on these days a 3g network is hardly enough to browse a massive portion of the web.

omgmajk2• 3 years ago

Always been fascinated with this type of development. I come from the era where JS was typically frowned upon, later learned to like it during ES6 because I had to use it a lot but now I mostly use it for Node and not the frontend anyways.

happythebob• 3 years ago

Upvote for King Gizzard

renegat0x0• 3 years ago

This page is missing verbose RSS link.

maxfurman• 3 years ago

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.

intrasight• 3 years ago

I've been doing web dev for over 20 years and just discovered and used datalist

skeeter2020• 3 years ago

> ... semantic HTML is more important now than ever

Except... semantic HTML has never been important. Forget about implementation and adoption, even the abstraction falls apart after about 30 seconds of critique. It's a weird mix of structure-like tags that seem to solely serve the newspaper industry from 25 years ago, half-baked UI elements and a handful of directives. The non-semantic elements have to make up more than 99.9% of the internet today. It seems the author missed the of XML and transforms if this is what they wanted.

btbuildem• 3 years ago

What is the author suggesting? That instead of "social" networks, people will rush to building their own online presence from first principles?

I can't see that working, for so many reasons:

- most people are passive consumers of content, maybe interact a little, enough to tweak their feeds

- a small minority creates content on the large networks / aggregators, and (I think) a large portion of that is spurred on by monetization

- the "internet" and all the devices that access it have become so "user friendly" that the people who have come online in the last decade or so are effectively technically illiterate; you cannot count on them building anything from scratch, only to arrange the big duplo pieces already provided

multicast• 3 years ago

You have just highlighted the main fact about the www that so many technical skilled people are missing to see. Most consumers have little to no knowledge about anything technical, which is not bad at all since there is no reason why they should care. Now imagine telling those people that everyone should have their own website instead of a social media account. What a horrible and illogical thought in my opinion. Digital consumers only change behavior if something is 10x better. So from a consumer perspective, who cares about things like decentralized networks? Or Duckduckgo.com for example is probably for 99% of the www users some chinese russian inbreed virus. People started using ChatGPT besides google because it is simply 10x better for many cases, and not because it promoted with more privacy feature and less ads than google.

jerf4• 3 years ago

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever."

I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it. As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out. Eventually in principle both the semantic web and that pile of heuristics are entirely replaced by AI.

(Note also my replacement of LLM with the general term AI after my first usage of LLM. LLMs are not the whole of "AI". They are merely a hot branch right now, but they are not the last hot branch. It is not a good idea to project out the next several decades on the assumption that LLMs will be the last word in AI.)

tomlue• 3 years ago

agree so much. Projects that aim to build a data resource and then let AI use that resource are missing the point. The AI is the data resource.

Some projects claim that knowledge graphs or other data assets can help the AI retrieve 'true' knowledge. Personally, I believe that the better approach is to develop methods that allow AIs to create their own data assets, the weights in their networks is one of those assets.

The question of truth is still a very hard one. How do you tell an AI that some knowledge is more trustworthy than other knowledge? People have this issue too though.

__loam• 3 years ago

If you're relying on a stochastic process like network weights to encode truth then I have some oil to sell you.

jerf4• 3 years ago

While the issue of "truth" is interesting and important, it is also fairly orthogonal to the task of simply extracting what a given page or bit of content claims. (Perhaps not 100% orthogonal in the absolute limit, but generally so.)

As absolutely hard as I have gone against the semantic web community at times over the post few years, I do not in the slightest hold a failure to "determine truth" against them. I consider them to have been tilting at windmills as it is, criticizing them for failing to conquer that windmill, which humanity has been jousting with since the dawn of recorded history (and probably beyond), would be a degree of cruel I couldn't entertain. :)

spothedog1• 3 years ago

what projects are trying to use knowledge graphs to retrieve truth? i've been playing around with that approach. how do you encode your own "truth" that may be different from anothers?

chickenfeed3• 3 years ago

AIs are magic to me. The pattern recognition feature of human I've always thought pretty unique and hard to replicate. We use it when scanning the slop on websites to do some kind of data extraction. I was part of the semantic web camp in my brain, but you are right, if machines can seemingly make sense of the slop then why bother?

zagrebian3• 3 years ago

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

jerf4• 3 years ago

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for.

I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though, I bet they could do it, or get very close.

bschne• 3 years ago

If semantic HTML is important for accessibility and for software to be better able to parse information out of it, and AI solves the latter, semantic HTML is now less important because some of the use cases that needed it previously no longer need it. If you take "less important" as a moral/value statement instead of in terms of total utility provided, and assume that AI will have zero accessibility benefits, it will merely be as important as today, which is still at odds with the assertion of the original article that it would become more important. N.B. this seems doubtful, given how e.g. you can now past a bunch of code into an LLM and ask it questions quite naturally -- something I can easily see adapted to e.g. better navigating apps using only voice and screenreaders.

miki123211• 3 years ago

This has been tried and doesn't work, which doesn't mean it will never work in the future! There are a few companies offering solutions in this space, but they don't work, are often worse than the problems they're trying to solve and are a privacy disaster. The companies peddling them often engage in shady business practices, like falsely claiming that their overlays can protect you from ADA lawsuits[1], while actually suing the people who expose their lies[2]. Most accessibility practitioners and disabled users themselves are warning the public to avoid those tools[3].

[1] https://adrianroselli.com/2020/06/accessibe-will-get-you-sue... [2] https://adrianroselli.com/2023/05/audioeye-is-suing-me.html [3] https://overlayfactsheet.com

jpochtar• 3 years ago

AI will solve web accessibility by screen readers that summarize visual content, ignoring ARIA and making it irrelevant. Multimodal GPT-4 can take a screenshot jpeg and answer questions about what’s in it (buttons, links, ads, headers, etc). The future of accessibility is rendering DOM to jpeg and asking GPT to be your eyes; we’ll look back on semantic markup as a failed idea that was never going to work

moritzwarhier2• 3 years ago

The semantic web has failed and what replaced it was Google spending a crap ton of money

Aren't schema.org and Wikidata/Wikipedia still powering most of Google's rich search results?

I heard them announce the new result page with bard but I probably didn't see it because of ad-blindness or it's not yet releases in my location, have to look this up...

coldtea4• 3 years ago

Aren't schema.org and Wikidata/Wikipedia still powering most of Google's rich search results?

Were they ever?

krainboltgreene3• 3 years ago

The semantic web has failed

literally by no metric is this true other than tech bros saying it on HN. The entire internet is powered by websites using semantic markup and clients querying it.

asdfgeoff• 3 years ago

I am curious about what post-LLM SEO is going to look like.

The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of heuristics equipped with best-of-breed-at-the-time AI behind it.

Arguably, there were insufficient incentives to fully adopt semantic HTML, if your goal was just to have the most relevant parts of your content indexed well enough to get ranked.

As AI improves, it improves its ability to extract information from any ol' slop, and if "any ol' slop" is enough, it's all the effort people are going to put out.

If the goalpost shifts from “getting ranked” to “enabling LLMs to maximally extract the nuance and texture of your content”, perhaps there will be greater incentive to use elements like <details> or <progress>. Websites which do so, will have more influence over the outputs of LLMs.

Feels like the difference between being loud enough to be heard vs. being clear enough to be understood.

the_king• 3 years ago

One question is: "How easy is HTML to read for humans." Everyone who has spent more than a few months writing software will be familiar with the idea. But for someone who has never seen it - is the concept intuitive? Do bright 8th graders get it if shown it for the first time on a test?

I used to think the answer was "pretty difficult," but I haven't come up with anything better. Maybe there is something to be done with indentation - but that has it's own challenges.

giardini• 3 years ago

Author and posters both are equivocating: the term "semantic HTML" is the OP author's term and is not clearly defined. In contrast the "semantic web" IS well-defined.

tl;dr - this article and discussion is a confused waste of time.

beders• 3 years ago

Where's the modern equivalent of xforms?

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.

kerkeslager• 3 years ago

I believe we now have virtually a complete set of all UI elements needed to build any modern web application.

This is pretty far from the case. Three examples:

* Dropdown menu. This is a superset of selects, which can only contain options: a dropdown can contain anything in its dropdown, including a nav which contains links displayed as icons, for example.

* Carousels/slideshows.

* Tab areas.

I've got a library of these kinds of elements implemented as CustomElements, but they're pretty geared toward the websites I've worked on in the last year, so I want to spend more time making them extensible before I release them as open source--I don't want people depending on my work until they are better-designed.

That said, HTML by default has gotten a lot more powerful than a lot of web devs know about. In particular, there's a lot of custom data lists and date pickers out there which are less powerful than the built-in HTML datalist and input type='date'

willio58• 3 years ago

<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.

vvpan• 3 years ago

The argument of the piece completely eludes me. How would HTML disenfranchise walled data gardens?

pphysch• 3 years ago

I think the #1 issue with HTML (and CSS) is that it is portrayed as being trivial, easy, "not a programming language". Someone who has written a few `<td>` "knows HTML". It's not respected. Consequently, people don't invest time in learning to use it well and keeping up with new features. And then they use it poorly, or run into awful examples of it, and come to the wrong conclusions about it.

While the idea of a markup/styling language is pretty simple, HTML+CSS deal heavily with difficult concepts like ontologies, cascading and non-imperative behavior, balancing UX & machine interpretability (accessibility), etc. Add in HTTP and browser APIs. Web dev is distributed computing par excellence, and is extraordinary deep and challenging, yet it's also viewed as among the lowest forms of programming. That's a big mismatch.

dbbr• 3 years ago

I see a King Gizzard reference in the wild, I upvote.

Gila!

gyudin• 3 years ago

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.

7373737373• 3 years ago

A while ago there was this VR program called JanusVR where rooms were specified using custom HTML tags (https://janusxr.org/docs/build/introtojml/index.html)

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

jacksongalan• 3 years ago

What's with the spelling error in your disclaimer, grammer [sic]? Is that pedantic, or is it a joke? Or did you mean "'grammer"?

coldtea4• 3 years ago

In fact, recently I’ve become acutely aware of reader mode. All time spent on styling will be obliterated by reader mode, and that’s a great thing!

Reader mode is mostly for longer text. Doesn't help with WPAs as much.

Moreover, proper tagging is extremely descriptive in a machine-readable format. This is likely a more compelling reason for adopting modern HTML than saving design time. The shift from primary data interfaces to secondary interfaces is already underway. RSS refuses to die. ChatGPT-like interfaces are likely the future of human data access. We’re going back to the beginning. Advertisers may be scared, but I’m not! Let’s start the revolution and set the world on fire with modern HTML.

Not sure what this (the most important part) attempts to say.

What does the advent of ChatGPT-like interfaces have to do with "adopting modern HTML" and "proper tagging"? If anything ChatGPT-like interfaces would require less tagging, and can do the "figuring out what the text is" part of semantic web without sementic metadata (and they can do it directly on the actual text, whereas the metadata would more likely be abused and misleading for SEO).

dahwolf• 3 years ago

Not quite getting this article.

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.

nektro• 3 years ago

literally the worst reason to use semantic html. which is sad because there are so many good ones

mmwako• 3 years ago

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.

tfcwebdesign• 3 years ago

You misspelled grammar. I only say this because you said you used AI for proofing and then you edited your doc.

jitbit• 3 years ago

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.

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.

orenmizr• 3 years ago

everything good in development makes it eventually(!) into the "Elementals" HTML+JS+CSS.

BUT still PUG > HTML any day of the week.

I'm betting on HTML

Related Stories