Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML Can Do That

chrisburnell.com

Post reply on HN
Print view View original

221–230 of 249 posts

Re: HTML Can Do That

#221

Post by edgyquant »

chmod775 wrote: post #219
alwillis wrote: post #156

Earlier quoted context omitted.

> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet… It doesn’t have to be that way. You could create a Skill [1] that tells the agent to use modern css; the newer models like Opus 5 are probably much better with modern css. Google released a set of skills at I/O called Modern Web Guidance [2] that steer coding agents to use modern css and best prac…

Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides. Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis. But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files"…

Skill is the terminology the industry has adopted.

Re: HTML Can Do That

#222

Post by CrimsonRain »

wild_egg wrote: post #37
hk__2 wrote: post #20

Related to this, I’d love that HTML natively support sortable tables. This is a common need but every single time I have to reimplement it.

You want client side table sorting? It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.

It's not as fast.

It is far more resources hungry when dealing with beyond 50 rows or more.

Puts needless pressure on backend.

It is not a good idea when sending whole dataset to client is feasible/better choice.

Re: HTML Can Do That

#223

Post by lo_fye »

gunalx wrote: post #33
jamescun wrote: post #5

I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web. Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances. I don't often have to write frontend code, but when I do, there is very little in terms of…

Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.

I remember when it was considered ridiculous to have a page take more than 250ms to complete its loading. Now nobody bats an eye at a 25MB page that takes over 30 seconds to load. I'm sticking with the old ways, thank you very much.

Re: HTML Can Do That

#224

Post by waltbosz »

extra88 wrote: post #164
waltbosz wrote: post #133

The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/ Firefox uses the native OS color picker, which in Windows 11 still looks unchanged from Windows 95.

That's fine, everything doesn't have to look the same everywhere. It does matter when there's functionality a site relies on but it's not available in one out more browser/OS combinations.

Yes, I agree that using the native OS UI is the right choice. Imagine if every web browser had a different file picker dialog, it would be a pain to have to reorient yourself just for that product.

However, I do lament the antiquated Windows 95 color picker. It seems less functional than others that I've used.

Re: HTML Can Do That

#225

Post by ptx »

peesem wrote: post #97

once again, i will ask: why do people care so much about only having one element open at a time? let me see what i want to see!

When a form has two sets of mutually exclusive options it might be appropriate? But I find the user experience confusing. It's hard to tell what happened when all the elements moved around, at least without animations.

Re: HTML Can Do That

#226

Post by chmod775 »

edgyquant wrote: post #221
chmod775 wrote: post #219

Earlier quoted context omitted.

Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides. Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis. But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files"…

Skill is the terminology the industry has adopted.

And people once called radio "the wireless", vacuum tubes "valve", and computer processors "the mill".

Some terms and ideas are just shit, especially in the early stages of something new.

Re: HTML Can Do That

#227

Post by lionkor »

knadh wrote: post #190

I'm currently in the process of taking a lot of risk rewriting a large-ish app that I maintain to fully eliminate the use of frontend frameworks (and the larger JS ecosystem in general) and to switch to simple SSR + semantic HTML and CSS. Using this tiny lib [2: shameless plug] I wrote specifically incorporating the "HTML Can Do That"-style realisations going into the big rewrite. [1] - https://github.com/knadh/listm…

Oat.ink is very cool, thanks for sharing!

Re: HTML Can Do That

#228

Post by doodlesdev »

hollowturtle wrote: post #201
doodlesdev wrote: post #181

Earlier quoted context omitted.

There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced). Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-ren…

You can have programmatic apis for accessibility, SEO pages can be dom based, performance of figma is better than if implemented via the dom api, developer experience? you just get the best and stop pretending you have capable people that spend a day on discussing effects in react. > My web browser is my agent It's very likely not anymore, otherwise Chrome wouldn't have pushed for manifest v3 > I wish Figma and Googl…

   > stop pretending you have capable people that spend a day on discussing effects in react.
Figma uses React for the UI panels. Google Docs uses the DOM extensively too.

   > have pushed for manifest v3
I don't use Google Chrome.

   > since we have decided app distribution to be web based
No one has decided this, it just happened because web browsers were in the right place at the right time. It's not set in stone and developer tooling for the desktop could easily revert this trend in a decade or so.

Re: HTML Can Do That

#229

Post by dspillett »

account42 wrote: post #217
dspillett wrote: post #47

Earlier quoted context omitted.

It won't be an intended use case, but it might be a convenient place to put poisoned content for the “benefit” of scrapers… Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards. Also before using it I'd want to check what old UAs i…

What would be the advantage of using this attribute compared to the various ways to permanently hide elements?

> compared to the various ways to permanently hide elements?

That it might look more like it is intended for human consumption where the others might get their content filtered out due to looking like an obvious trap? More so in the case of the detail tag. Of course they might not be filtering on that sort of thing at all, after all there are many cases of content for humans being hidden that way until activated by script and they won't want to be filtering those out, so it doesn't actually matter and the key will be not showing the otherwise pointless content to human viewers.

Re: HTML Can Do That

#230

Post by theandrewbailey »

account42 wrote: post #216
theandrewbailey wrote: post #158

Earlier quoted context omitted.

I find using with and is more flexible, particularly with multiple image formats (AVIF and JPG in my case).

I wish both srcset and elements wouldn't be so redundantly verbose by forcing you to specify the full (relative) URL for each image when they usually only differ by a small part specifying the resolution or format. Sure, transfer-encoding will mostly nullify the overhead but it's still annoying when editing the HTML manually.

Ah, don't edit the HTML manually. Name your images brain-dead predictably, and use a script with some regex.

My blog has some code that searches for tags just after markdown conversion, then uses the src to find similarly named images (image×1.jpg, image×2.jpg, etc.) to use in tags.

https://github.com/theandrewbailey/gram/blob/master/gram/src...

https://github.com/theandrewbailey/gram/blob/master/gram/src...

Post reply on HN