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

The Website Specification

specification.website

Post reply on HN
Print view View original

71–80 of 236 posts

Re: The Website Specification

#71

Post by rglullis »

yolo3000 wrote: post #51
neya wrote: post #46

Earlier quoted context omitted.

I swear to God. I just want to go back to the 2000s where everything was just plain HTML and some basic CSS, if at all any, by default you got responsive design out of the box, readable text and super user friendly GUI from the browser's own default stylesheet. Today you open any website. Everything is a fucking component. A simple dropdown with a finite list? Has its own loader and makes 10 fetch requests for no rea…

I interviewed someone once for a fullstack role, gave him a mockup of a screen we had to build and asked how he would do it, in short some things on top of other things. The only thing he managed to say was how he would divide everything into components. I thought man, so many devs don't even know how to use html/css anymore, but who's laughing now, you just need to prompt a coding agent.

Ha, and I flunked a "Fullstack Developer" interview some years ago because I didn't reach for npm or React to build a page that had a simple form to make a request to the backend.

Re: The Website Specification

#72

Post by xg15 »

mpetrovich wrote: post #68
xg15 wrote: post #62

Earlier quoted context omitted.

> don't have a form with just a login email and force the user to click to enter the password I was noticing that this kind of login forms seems to be proliferating, especially on "big tech" sites. (And personally, I also find it annoying) Always assumed there was some reason why sites are switching to this pattern, e.g. better bot protection. Does anyone know more about this?

I suspect they ask for email first in order to determine whether to log you in via SSO vs. require a password.

Ah, that would make sense.

Re: The Website Specification

#74

Post by jeroenhd »

selfhoster1312 wrote: post #12

This looks like slop from a slop factory. "SEO", "Agent-readiness". That's precisely what a good website doesn't do (to paraphrase the homepage). Oh yes, it's produced by a Wordpress "SEO" expert and private investor using Claude LLM. What a surprise. A man who built a fortune destroying the internet we loved with advertisement slop now working on destroying whatever's left with LLM slop.

The em dashes and word patterns ("it's not X, it's Y") and duplicate contents pretty much prove that this is AI to me.

Flagging "stable URLs" as "agent readiness" indicates to me that whoever wrote this cares more about AI than people. This domain is going on my blacklist, I can already see how this will make looking up any information about web development worse.

Re: The Website Specification

#75

Post by jeroenhd »

zophi wrote: post #5

Hmm wondering how common some of these are ... I'd love /.well-known/change-password but it looks like https://news.ycombinator.com/.well-known/change-password and google.com/.well-known/change-password don't seem to be implemented?

It works in Safari and Chrome it looks like: https://web.dev/articles/change-password-url

I've never heard of it actually being used, though.

Google's URL is on https://accounts.google.com/.well-known/change-password but not on their main domain.

Re: The Website Specification

#76

Post by fullstackchris »

k1m wrote: post #26
Gigachad wrote: post #24

Earlier quoted context omitted.

This is what reader mode is. It exists purely because most websites are unreadable.

Big fan of reader mode. For me, a direction better than llms.txt would be to encourage sites to improve their markup (think semantic web era) so agents could get the text version from that the way reader mode does. Would achieve the same thing - save tokens. This isn't difficult and I think the reason it hasn't been done is that publishers want clicks and ad views. Which begs the question: why would they start doing…

modern agents already do this via content negotiation and will attempt to retrieve the markdown version of a given site

https://www.sanity.io/learn/course/markdown-routes-with-next...

Re: The Website Specification

#77

Post by xg15 »

fmajid wrote: post #44

I'd love best practices around, say, login forms, e.g.: - use standard input field names password managers recognize - disable autocompletion and autocapitalization on the login field - if it's an email, use the correct HTML5 input type - don't have a form with just a login email and force the user to click to enter the password - follow NIST SP 800-53, e.g. no SMS 2FA and no arbitrary password rotation and compositi…

> Or how many sites that have a form with only one input don't automatically focus on it.

That's one example where the "web stack" expects every single website to implement things manually that were standard in native UI toolkits. Then of course the majority of websites will not deem it a priority or not realize it's a thing to consider at all - and we end up in a situation like this.

Re: The Website Specification

#78

Post by jeroenhd »

Kwpolska wrote: post #23

Let’s look at the Git history: https://github.com/jdevalk/specification.website/commits/mai... Yeah, mostly slop. I wonder why the slop slingers never disable Claude's self-attribution, and are too lazy to commit themselves, are they proud that they're delegating everything to a slop machine?

If you're going to slop something together, why not mark it as such? I appreciate marked slop much more than hidden slop.

Re: The Website Specification

#79

Post by 9dev »

mpetrovich wrote: post #68
xg15 wrote: post #62

Earlier quoted context omitted.

> don't have a form with just a login email and force the user to click to enter the password I was noticing that this kind of login forms seems to be proliferating, especially on "big tech" sites. (And personally, I also find it annoying) Always assumed there was some reason why sites are switching to this pattern, e.g. better bot protection. Does anyone know more about this?

I suspect they ask for email first in order to determine whether to log you in via SSO vs. require a password.

As someone who's built just that, can confirm. If users have SSO configured, or a Passkey, or any other policies apply, you first need to identify the account to be able to determine which options to offer - maybe they don't even have a password in the first place, so displaying the field would cause confusion. As a side effect, this also conveniently allows to check for blocked accounts.

Re: The Website Specification

#80

Post by cutler »

neya wrote: post #46
Latty wrote: post #11

"Agent Readiness" will likely age as well as "Web 4.0 Blockchain Integration" has. (To be entirely clear, not because agents won't be a relevant thing, although certainly I have my doubts, but because I believe even if they are a relevant thing, requiring special allowances from sites undermines the whole point, and such things will only end up used by bad actors to mismatch what agents see to what humans see, and so…

I swear to God. I just want to go back to the 2000s where everything was just plain HTML and some basic CSS, if at all any, by default you got responsive design out of the box, readable text and super user friendly GUI from the browser's own default stylesheet. Today you open any website. Everything is a fucking component. A simple dropdown with a finite list? Has its own loader and makes 10 fetch requests for no rea…

Responsive design out of the box? Were you actually there? Back in 2000 you could make a career out of scripting browser polyfills or "DHTML".
Post reply on HN