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

141–150 of 236 posts

Re: The Website Specification

#141

Post by neya »

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.

That's funny because the argument against tables was always that they added extra markup a.k.a lines of code, only to replace them with dozens of nested divs, half assed CSS layout ideologies (floats and clear's, for example) and barely functional JS that all somehow needed to work in sync which was almost never. That's how NPM was born.

Tables worked with 100% of the browsers. The alternatives needed polyfills and shims and ironically the whole thing needed easily 2x the number of integration time and lines of code compared to just slapping tables.

Re: The Website Specification

#142

Post by Kudos »

neya wrote: post #141
Kudos wrote: post #69

Earlier quoted context omitted.

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

That's funny because the argument against tables was always that they added extra markup a.k.a lines of code, only to replace them with dozens of nested divs, half assed CSS layout ideologies (floats and clear's, for example) and barely functional JS that all somehow needed to work in sync which was almost never. That's how NPM was born. Tables worked with 100% of the browsers. The alternatives needed polyfills and s…

The argument was for markup to have semantic meaning, not number of lines. Also, NPM was not born for browser JS.

Re: The Website Specification

#143

Post by neya »

Kudos wrote: post #142
neya wrote: post #141

Earlier quoted context omitted.

That's funny because the argument against tables was always that they added extra markup a.k.a lines of code, only to replace them with dozens of nested divs, half assed CSS layout ideologies (floats and clear's, for example) and barely functional JS that all somehow needed to work in sync which was almost never. That's how NPM was born. Tables worked with 100% of the browsers. The alternatives needed polyfills and s…

The argument was for markup to have semantic meaning, not number of lines. Also, NPM was not born for browser JS.

No, npm ultimately enabled the exact kind of accidental complexity I'm talking about where you need a massive node_modules folder and Babel just to generate client-side code

Re: The Website Specification

#144

Post by est »

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…

> just plain HTML and some basic CSS

Or even better. XML + XLST.

True separation of representation and data.

Is thousands of nested really a good idea?

Re: The Website Specification

#145

Post by rafram »

nozzlegear wrote: post #125
Alifatisk wrote: post #63

Earlier quoted context omitted.

Its apparently pure ai slop, I use https://tropes.fyi/vetter

I tried this just now on a landing page for an app that I wrote over a decade ago and it told me it was pure AI slop lol

I tried it on my personal website, which I wrote without any AI whatsoever, and it decided it's "pure AI slop" based on "tricolon abuse" alone. I would be less mad if the examples it flagged were actually tricolons, but only a couple of them were! Most were lists with more than three things in them.

The slop detector, alas, is slop.

Re: The Website Specification

#146

Post by extra88 »

luckylion wrote: post #126
extra88 wrote: post #123

Earlier quoted context omitted.

There is no pair for the enterprise users signing in with their company's SSO or those using Passkey. I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.

Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?

How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.

Re: The Website Specification

#147

Post by 8organicbits »

extra88 wrote: post #146
luckylion wrote: post #126

Earlier quoted context omitted.

Aren't you leaking that there's an account with that email that has a non-password auth method if you treat them differently?

How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.

If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist.

Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts.

It's very low on my list of concerns though, usually there's much worse problems when I pentest.

Re: The Website Specification

#148

Post by xp84 »

marginalia_nu wrote: post #111
Kudos wrote: post #69

Earlier quoted context omitted.

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 th…

Re: photoshop html table export

Marketing email is still produced in this exact same way at some companies - ask me how I know!

(If anyone isn’t familiar with this, it’s because for security reasons we’ve all decided email should use an intentionally gimped de facto (non-)standard which only supports a few little dabs of CSS - 90% of email is formatted with strictly 90s technology.

And by “we” I mean that’s what Google and MS allow in their clients, so it’s very pointless to try to go beyond that given their combined usage share.

Re: The Website Specification

#149

Post by woodpanel »

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.

3 by 3 iframe layout with the center one displaying the actual content.

Re: The Website Specification

#150

Post by Hunpeter »

jfengel wrote: post #130
marginalia_nu wrote: post #111

Earlier quoted context omitted.

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 th…

also how easy they were to parse programatically or with a text-based browser. Or even a regular expression.

But what if Tony the Pony comes?
Post reply on HN