Hacker News Reader

Comment by eschaton | Hacker News Reader

A web page’s behavior should be independent of any particular styling of the hierarchical elements used to represent the document it’s presenting.

Just like any web page should work perfectly with JavaScript disabled, it should work perfectly with a user-supplied style sheet.

If you’re making a web page that has this problem, what you’re making should not be a web page, and you should feel bad about the choices that led you to that point in your life.

It will take a while to fix this problem in our industry since we’ve waited so long on it, but the best time to start is now.

View on HN

Yes, the user should ultimately have the final say about what colors, fonts, and sizes are used by their browser. We've handed way too much control over to the web developers. Web sites don't have to be pixel perfect. If I want to render text using Comic Sans by default, that shouldn't "break" anything.

> We've handed way too much control over to the web developers.

We lost this battle by 1999. And again when we started to deliver full web applications instead of documents.

I wish we had a second protocol that was more document and information focused. Something that gave zero control over programming or layout to providers.

I just want to exchange information P2P in a dense swarm approximating modern social media. I want to use my own client configured how I like it to choose what to ingest and how to flag it and present it.

>Something that gave zero control over programming or layout to providers.

Without layout or programming (functionality)...is that not just json??

And if you consider "structure" to be "layout"...then...a txt file?

Unf I don't see the point here. You're basically just describing an api endpoint and a custom client.

I'm describing email, RSS, bittorrent, IRC, etc. Protocols.

we do have such protocols. gopher and more recently gemini are the most popular competing standards

Who are we kidding. With those as our choices, it's no wonder most people just use the face book.

Hyper scale businesses captured most of the internet's value and humans and turned tech into a series of walled gardens for eyeball attention doom scroll maximization. Retweeting the for you page is what some committee of product managers decided was best for us all. Who are we to question the architectures of power?

It almost sounds like a perverse weird utopia to imagine a world where we controlled all of the information flows ourselves. I can't think why we should have all the power.

the internet has become more accessible both to consumers and people trying to sell a product. it has become crowded in "the market" you refer to. but all the good things all still there, and are doing much better than they were. i still use all of those protocols and a bunch of newer ones.

https://en.wikipedia.org/wiki/Gopher_(protocol)

I remember when the web came out, I said "This is just a prettier gopher." Seeing the end result of 30 years of web development, I kind of wish it stayed just a prettier gopher.

> If I want to render text using Comic Sans by default, that shouldn't "break" anything

Not sure how we could expect users to switch between whatever font they want, and things not breaking.

Different fonts both appear and have different sizes, so what might look perfect with one font (a button where the text is aligned in the center vertically/horizontally), can look massively different with another (say the font's characters are wider, so now the text either overflows or breaks into two parts, making the button "broken").

Pixel-perfect alignment shouldn't be a goal. The web is for documents.

What I'm talking about isn't just "pixel perfectness" but layout of said document which breaks depending on the characteristics of the font.

the point is that there should be no layout to be broken in the first place.

The rest of the world has decided that the web is for applications at least as much as it is for documents.

The fix is called reset.css. Allows you to skip headlines like subj and only emotionally react to the "but you already have an app platform, it's web, shtupid" and "you should feel bad about your choices" split around your practical needs.

Awful thing. You can recognize sites using it by missing margins in lists etc.

"you should feel bad about the choices that led you to that point in your life" - I suggest you find help to deal with the bitterness you have inside of you.

I suggest you examine the state of the industry and the garbage that’s passed off as reasonable these days and ask yourself whether what you perceive in my comments is bitterness.

The garbage that dominates the web has everything to do with centralization of power, and nothing with HTML vs JS. The former is a people problem and the latter is just tech.

And what is your proposed alternative? A bunch of native apps? Qt?

Definitely, even though Web + distributed computing pays the bills, I rather have apps + distributed computing when given the option.

It worked perfectly fine until browser companies decided they wanted more than to be renders for hypertext documents.

Yes, apps, which web pages aren’t no matter how much web designers want to pretend they are.

For many places where apps would previously be accepted users don't want native applications anymore.

For work other than some very industry specific high performance software most businesses software is web based, and users ( those paying the bills anyways ) want them to be web based because it is much more portable and easy to deploy.

They actually are though, in reality. Your point is what should they be, not what they actually are. The truth of the situation is that webpages _actually are_ applications now, due to the new features the browsers have added to facilitate that

I actually work at Qt and many of our new products are web apps

Web pages mostly aren't applications though. Like people will sometimes post links to corporate engineering blogs here that require javascript (Uber comes to mind). It's purely a document; there's no interactivity at all. Making it an "application" is just incompetence (it's more expensive to develop and gives a worse user experience).

It might be true that applications actually are web pages now (e.g. Slack, WebEx), but I almost never encounter web pages that are actually applications.

That’s too bad, but not unexpected given that Qt’s itself a non-native toolkit anywhere other than Linux that developers on those other platforms shouldn’t touch.

Okay so you actually have no cross platform suggestion??

Cross-platform frameworks are inevitably crap. If you really need to run an application on multiple platforms, write a cross-platform core and implement the human interface atop it for each platform using each platform’s native frameworks and languages.

The result is always a better product with happier users. If you don’t want to invest in that, you should at minimum be willing to admit to yourself that you’re OK with giving your users something subpar because it’s to your advantage to do so.

HTML + CSS + JS :^)

> Just like any web page should work perfectly with JavaScript disabled

And the problem is neither of those things are true in reality. So in real life a change like this can cost the economy millions of dollars.

Sure they are, they’re just not sexy. And making this change will ultimately save orders of magnitude more than the cost.

I got stuck trying that. To facilitate non JS by default my products are checkboxes and the checkout button submits the form (it is a spa). This works well but navigating back the user is presented with an "error" page asking if they want to submit the form again. Is there a solution for that?

I have done this in projects with POST forms: ”To avoid the resubmit warning when hitting back, use the Post/Redirect/Get pattern: after a POST, redirect with a 303 to a normal GET page. The browser skips saving the POST in history, so back just takes you to the form without complaining.”

I thought that was the normal pattern, either rendering the form again when there's an error or redirect to the correct page in case of success.

Yeah, it's just been a while so I felt sketchy advicing something that might have changed.

The usual way to deal with it is to respond to form submissions with an HTTP redirect to another page. The user can still hit the back button, but the scary popup won't occur.

However, you run the risk of the user re-submitting the form anyway. Since this is involving orders and money, you may want the order confirmation / submit page to have a nonce or temporary ID representing the checkout session in the URL such that, upon revisiting that page, you can lookup the order status on the backend and redirect them to the order success page again.

This will prevent re-submission but still be confusing for the user. Why even allow submitting when navigating back? If the order has been submitted already, the submit button should be greyed out with a message saying that the order has been submitted already.

The original task was to do this without JS, so my first guess would be: Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server.

This is why I suggested the URL for the submission page be unique- having a session nonce / token or similar. That way, once the user checks out you invalidate the checkout session, and if the user hits the back button you redirect them to the appropriate page.

I specifically called out the issue of re-submitting certain forms and proposed the above solution. I don't think relying on cache headers is going to be sufficiently reliable.

I'm not arguing against a re-submission check. You'll need that anyway to prevent attackers from bypassing the browser and messing up your data.

But even with a nonce and a re-submission check, the cache headers are essential to make sure that when the user presses the back button, they'll see a greyed-out submit button. If the browser does not reload that page, the button will still be clickable. It won't work correctly because the re-submission check will fail, but a clickable and guaranteed non-functional button is very bad UI.

The latter is one of the main reasons that we have so much JS/SPAs. Sure, you can build an application without it that is somewhat functional, but the UI will be low-quality -- even if this particular example might be fixable with cacheability headers.

There is no re-submission check. When the user hits the back button, and requests the HTML from the server, the serve responds with a redirect. The user never sees the expired cart.

> Instruct the browser to re-load the page upon navigating back (cacheability headers), identify the order using an ID in the URL, then when reloading detect its already-submitted state on the server

And how would one do that without using JS?

Which part exactly?

Re-loading the page on navigating back would be done using cacheability headers. This is the most shaky part, and I'm not sure if it is possible today. If this does indeed not work, then this would be one of the "things that Javascript has solved that the non-JS web is still stuck with" I meantioned in my other post, i.e. one of the reasons that JS is more popular than non-JS pages today.

Identifying the order using an ID in the URL is standard practice everywhere.

When the order page gets requested, the server would take that ID, look the order up in the database and see that it is already submitted, responding with a page that has its submit button disabled.

The must have js part for me starts where one can open the store in multiple tabs then add and remove things on the first two and check out on the 3rd tab.

The user you’re replying to thinks the web is the wrong tool for any app

There are real websites people rely on that don’t work without JavaScript - and ones that depend on the h1 size too.

And that’s a bad thing, and the people involved in making those sites should feel bad and do something about their mistakes rather than just shrug. And we should call them what they are: Mistakes, abuses of the web.

You have now stated that "those people should feel bad" for the second time. Personal attacks will hardly bring any change into this world. I'd instead suggest that you propose actual ways to solve the same problems that Javascript-based SPAs have solved which the non-JS web is still stuck with.

Just add a matter of precision, personal attacks won't generally improve the world on the overwhole aftermaths. But they do generally change the world into a less pleasant place to live in.

Sure, the people making these things should feel bad about it, and ideally change their choices... But if 5% of Firefox users can't use your page, and your page is important, they'll consider Firefox broken and go use something else.

Firefox isn't doing so well on market share, and appearing to be broken isn't going to help.

I made a web game that's simply not possible without js. Is it your contention the it simply shouldn't exist? Lots of people seem to enjoy it and I think they'd be disappointed.

And you are failing to observe a difference between what should happen and what has actually happened.

Changing the latter costs money - time from people’s lives.

> And that’s a bad thing

Why?

You’ve given no argument that this actually is “abuse”

At a certain point in your career you start realizing how little that is.

Actually the more I’ve gone in my career the more I’ve realized we underestimate the cost of changes. Getting vendors to change a single line of code can be incredible amounts of money.

> If you’re making a web page that has this problem, what you’re making should not be a web page, and you should feel bad about the choices that led you to that point in your life.

The web is explicitly and intentionally a software distribution platform. JavaScript is a web standard and is no less “part of the web” than HTML and CSS. You’re f

Nah.

Should Gmail never have been created as a web page? How about Google Maps?

Reply on news.ycombinator.com