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

111–120 of 236 posts

Re: The Website Specification

#111

Post by marginalia_nu »

Kudos wrote: post #69
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…

In the 2000s wasn't everything just misused/abused table layouts? Maybe we frequented different places, but that's how I remember it.

Table designs were kinda brilliant though, both in how easy they were to create[1], but also how easy they were to parse programatically or with a text-based browser. Given context of the table in front of you, you can generally piece together where on the screen the information goes without rendering anything.

You can generally do a lot of the same things with CSS grid layouts, but it's 100x more complicated, and the layout information is generally in the CSS file rather than the document itself making parsing the layout a Hard problem demanding the implementation of a partial CSS engine (and a sometimes JS engine too).

[1] A totally viable workflow was to draw your website in something like photoshop, cut boxes where the content would go, and then export it to an HTML table.

Re: The Website Specification

#112

Post by qup »

blks wrote: post #67
ex-leper wrote: post #59

Earlier quoted context omitted.

IE6 was early 2000s, I remember it not being so great. CSS was starting to be supported but it was a minefield of un-supported features. It was bad enough I swore off front end work and made a pact with myself to focus only on backend or embedded, for my own mental health :-)

IE6 was the most popular browser still during like 2006-2010. There was a point when Opera, Firefox, Chrome were already a thing, and they supported proper standard CSS and HTML, but 90%+ of users still used IE6 and you had to use tricks to support both standard and IE6 fuckery. I do miss those times.

I was still supporting ie6 in at least 2014 for a couple of clients.

I miss those times, too, but not the IE6 bullshit.

Re: The Website Specification

#113

Post by qup »

singpolyma3 wrote: post #99
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…

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

So what if we don't know? We can find out at the same time.

We're trying to authenticate a pair: user/pass.

Re: The Website Specification

#114

Post by marcosdumay »

franze wrote: post #33
glimmung wrote: post #21

Earlier quoted context omitted.

"The Unreasonable Effectiveness of Checklists" ( https://rs.io/unreasonable-effectiveness-of-checklists/ ) comes to mind. When I was younger I would have though the same. Now that I have more humility and less working memory, I think differently.

but in a checklist you include what actually you need to check, not everything and especially not stuff that is harmful l and/or has negative gain

Think of those public, generic lists as checklist's checklists. You should look at those items asking "will adding this to my checklist help achieving my goals?", and answer with a heavy bias towards "no".

You won't find generic lists that are well suited to your case, and you certainly won't find any flawless one. If you don't know the details about one of those items, you either go with "no" or learn them. But there is a lot of value on getting a list you can look at and discover something that you forgot.

Re: The Website Specification

#115

Post by npc73x »

Apart from this, we need standards in what features the website should have for it's domain. for example the hospital website should have a Doctors timings, portal to register and track the ticket, Address with google map link for it's branches, building's schematic for basic navigation, and track the registrations. the Glassy UI comes next before the basic features

Re: The Website Specification

#116

Post by TeMPOraL »

locknitpicker wrote: post #25
kijin wrote: post #18

Earlier quoted context omitted.

Yeah, the entire suite of proposed "standards" catering to agents looks like a temporary measure to duct-tape over the limitations and token costs of today's agents. They'll churn as quickly as Anthropic, Google, OpenAI et al. can release new versions of their frontier models.

> Yeah, the entire suite of proposed "standards" catering to agents looks like a temporary measure to duct-tape over the limitations and token costs of today's agents. That's fine. We need a fix for today's problems today.

Let's just not get blinded by this to the true nature of the problem. The web being hard for agents isn't an accident - it was done on purpose. More specifically, it's a consequence of the web evolving to defeat automation and limit access.

Most websites are exist to make money from specific audiences in specific ways, often defined in contracts between hundreds of business entities, and none of them want you to be able to automate access, or interact with the website in any way other than the one that spins the money-making machine. Consider that the flip side of "basic tabular interface" is "skip website entirely, access underlying database"; the flip side of "screen readers" is "ad blockers"; the flip side of APIs is "competitors can scrape my listings and use them against me", etc.

Agents are hot right now, the whole business side is still blinded by hype, so things like MCP and .md endpoints are not just getting a pass, but are even pursued by the business people ("we have to do something with AI!"). This won't last long, though - they'll soon realize their mistake, close off access, and enshittify the web some more.

Just like they did in the past - e.g. when APIs and mashups briefly became a hot thing, then went away as businesses realized this defeats the very thing that makes them money: total control over platform/user channel.

--

[0] - Even your most basic blog showing some ads creates a money-making chain, made up of dozens or hundreds of business entities, bound by actual contracts, and the "blog author that just wants to show some ads" is merely one party at the end of that chain.

Re: The Website Specification

#118

Post by npc73x »

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…

yes. The moment when I see the interception of the scroll to show some overlay content. my brains either switching to admire the aesthetics or get's irritated by that. In the mean time I totally forgot the reason of this website visit.

Re: The Website Specification

#120

Post by TeMPOraL »

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…

> "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 humans see, and so will be intentionally ignored.

My perspective is that I see web as adversarial, and from my perspective most of the parties operating web sites are themselves bad actors. Mismatching what humans and agents see is something that we'll see intentionally used by websites, same as they do to search engines.

No, I think "Agent Readiness" won't age well because website operators will soon remember that "agents" are just "access automation", i.e. the very thing they're continuously at war against, as this threatens their ability to make money.

Post reply on HN