211–220 of 236 posts
Earlier quoted context omitted.
True. We have a product website (1) built entirely with tables and HTML 4.01 (2) in 2026. Works as expected everywhere. 1. https://www.tirreno.com 2. https://validator.w3.org/check?uri=https://www.tirreno.com/&...
I mean, it doesn't even render properly on my default samsung android phone...
Earlier quoted context omitted.
The 2000s, the golden age of web design, when people built inaccessible IE6-only mystery-meat navigation websites with Flash and HTML tables that dynamically loaded JS using iframes.
Can't upvote this enough. People have very selective memory of how the 2000s web worked. Every other website requires Flash just to show you a carousel of images. "Serious" business websites implemented in slow, buggy Java applets. iframes everywhere. Incredibly fucked up tables with no semantic meanings in your HTML just to do what modern flexbox now does in two lines. No one cared about accessibility of anything. C…
I'm not dunking on your whole argument, but as for this specific point: as someone who finds the mouse difficult to use and requires the keyboard a lot, the web definitely used to be a lot more accessible in this regard. There's no keyboard navigability anymore. And it would be so simple, just put an accesskey attribute on your buttons and textboxes. Nobody does it, anywhere.
"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…
If anyone thinks the site is overall a good idea but doesn't want the ai/blockchain nonsense, you should know checklists like these are fairly common. My favorite for a few years now has been this https://frontendchecklist.io/rules
https://github.com/thedaviddias/Front-End-Checklist/blob/mai...
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…
With Google's quest for "zero click" search results I am not sure if there is still any pressure applied on site creators. Does SEO matter anymore when my first "organic" result is below AI overview and sponsored links? Why should anyone help third parties to rip content from their website?
"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…
> "Agent Readiness" will likely age as well as "Web 4.0 Blockchain Integration" has. I was going to counter that, but thinking some more, I actually agree, but for slightly different reasons. > not because agents won't be a relevant thing, (...) but because (...) 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…
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…
> don't have a form with just a login email and force the user to click to enter the password This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.
I don't know what the magic is here. If I had to guess they have both fields in the DOM but one is visually hidden. Then if your email is marked as SSO it is just never read.
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…
The cause is businesses are putting emphasis on showing their brand on the site. Every dropdown has to look and feel like their product. In short almost everyone wants their website to be a video game.
Earlier quoted context omitted.
> don't have a form with just a login email and force the user to click to enter the password This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.
This is true but some sites handle it well. My browser auto-fills the email and password properly even though they are on separate "steps". Other sites the email field doesn't auto-complete in any way (but the password later usually does). I don't know what the magic is here. If I had to guess they have both fields in the DOM but one is visually hidden. Then if your email is marked as SSO it is just never read.
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…
That can be valid, but often it will also cause screen reader users to miss context.