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

The easiest way to keep your web apps accessible: Just use text

blog.logrocket.com

Post reply on HN
Print view View original

211–220 of 271 posts

Re: The easiest way to keep your web apps accessible: Just use text

#211

Post by adrianratnapala »

astura wrote: post #147
lhorie wrote: post #104

Earlier quoted context omitted.

I recall reading a story about someone who had implemented some sort of table using links for actions. At some point the app data mysteriously got wiped out. Turned out a user had Alexa toolbar installed and it crawled the "delete" links on each row (as well as all the pagination links)...

This is what happens when you use a HTTP GET to perform an "unsafe" action. HTTP GET links should always be safe to crawl... Always... It's in the spec for a reason. Seen people make mistakes like this before... Even using a POST when it should be a GET can cause funny behavior. Funny, but not dangerous behavior like using GET instead of POST. Whenever I bring a new web dev aboard this is my first lesson to them, and…

> This is what happens when you use a HTTP GET to perform an "unsafe" action

Yes, I agree it sucks. But there are also no great alternatives without JS.

Re: The easiest way to keep your web apps accessible: Just use text

#212

Post by lmm »

Kalium wrote: post #74
lmm wrote: post #24

Earlier quoted context omitted.

People use Medium because it's the easiest way to write some plain text and have what you wrote look decent in the browser. That's all it comes down to.

Really? I always figured that plain text looked pretty damn awesome in a browser. Example: https://motherfuckingwebsite.com/ I'm honestly curious how Medium is an improvement over that. Are you referring to the technical challenges of hosting content, perhaps?

> Really? I always figured that plain text looked pretty damn awesome in a browser. Example: https://motherfuckingwebsite.com/

That's not plain text, it's HTML. It's a total fiddle to write by hand (lots of angle brackets), and as you say you then have to find somewhere to host it.

But it also doesn't look as good as Medium. If browser makers were willing to be progressive and act as user agents, like they were originally intended to, then the two would look very similar. Unfortunately web browser text sizes haven't kept up with increasing screen density and so we have point-size inflation instead; the complete lack of margin also makes for a struggle when reading (though I do think Medium has gone too far in the other direction lately). Medium's link styling is less obtrusive; conversely code blocks on motherfuckingwebsite-style sites aren't visible enough. Image sizing on motherfuckingwebsite-like sites is also all wrong (they're sized to pixels rather than to anything meaningful). A lot of sites look worse than motherfuckingwebsite, but Medium is an improvement IMO.

Re: The easiest way to keep your web apps accessible: Just use text

#213

Post by vthriller »

ddebernardy wrote: post #179
rayiner wrote: post #52

Earlier quoted context omitted.

So that's why that happens. Why on earth would you break one of the most foundational aspects of HTML that way?

By the same token, why reinvent things like scrolling, break the back button, or throw font sizes so small at your readers that they need to zoom to read? (To say nothing about top and bottom bars that follow you around on your 13" laptop screen.) Humble suggestion: design fads. My own question would be whether this gets taught anywhere. Because if it does, a few someones need to get fired.

> throw font sizes so small at your readers that they need to zoom to read

My problem is usually the opposite: I constantly stumble upon websites that use ridiculously large fonts like I'm a grandma that tries to read something on an overkillishly-retina display from meters away. However it doesn't usually bother me when I'm browsing from my desktop 'cause I have options to zoom out; however most of mobile layouts feature something like (edit: also mentioned in the article albeit in a bit different context), which makes me choose between intensive vertical scrolling in regular mode and constant horizontal scrolling if I "request desktop site". (Yeah, I know, "reader mode"; it's a reasonable hack but I'm not quite satisfied with any of implementations either, and it only works for whatever browser thinks the main body of the page is.)

Re: The easiest way to keep your web apps accessible: Just use text

#214

Post by dragonwriter »

adrianratnapala wrote: post #211
astura wrote: post #147

Earlier quoted context omitted.

This is what happens when you use a HTTP GET to perform an "unsafe" action. HTTP GET links should always be safe to crawl... Always... It's in the spec for a reason. Seen people make mistakes like this before... Even using a POST when it should be a GET can cause funny behavior. Funny, but not dangerous behavior like using GET instead of POST. Whenever I bring a new web dev aboard this is my first lesson to them, and…

> This is what happens when you use a HTTP GET to perform an "unsafe" action Yes, I agree it sucks. But there are also no great alternatives without JS.

Using buttons that trigger POST methods is a great alternative to using links for non-safe actions, and doesn't require JS.

Re: The easiest way to keep your web apps accessible: Just use text

#216

Post by msla »

Tomte wrote: post #35
caymanjim wrote: post #31

Earlier quoted context omitted.

For some reason, font sizes have shot through the roof in the past few years. Medium is one of the biggest offenders. You get maybe 2-3 paragraphs per page now, when entire articles would fit on a single screen page with normal-sized fonts.

People started to listen to typographers. It's a good thing.

Yep. That's also how we got oceans of empty, wasted space on each side, necessitating scrolling.

Skimming? Since when does a literate person skim? Just read it, you lazy so-and-so, like you just read a book! A book with gigantic margins, like all books ever!

/s

Re: The easiest way to keep your web apps accessible: Just use text

#217

Post by msla »

oneeyedpigeon wrote: post #175
tomjakubowski wrote: post #152

Earlier quoted context omitted.

> if it breaks the back button of the browser Good luck getting a group of people to agree on what "non-broken" back button behavior is.

All those cases where pressing back repeatedly doesn't actually go back ? They're broken. We may not be able to define 'broken' perfectly, nor catch every case, but we can definitely spot the worst! Unless you mash the back button really quickly ...

Your back button is "broken" every time your last transition from the previous page to the current page changed information on the server, and that information change isn't reflected in the cached version of the previous page your browser helpfully shows you when you hit back.

Cache invalidation is a technical solution, and it could conceivably be done with header magic or something, but the real problem is people thinking the back button undoes history and the server (and, possibly, reality) disagreeing.

Re: The easiest way to keep your web apps accessible: Just use text

#218

Post by dylan604 »

beat wrote: post #142
ergothus wrote: post #87

Earlier quoted context omitted.

But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.

The problem is that it might take a half-dozen clicks to realize it's not worth reading the other 24, then you need to click back a half-dozen times (worse if there are page reloads during that).

Or, use another built-in feature of the browser's back button. Click-and-hold the back button so that you can see a contextual menu with the steps you can go back to quickly. If I click back more than twice, the third is a click-and-hold.

Re: The easiest way to keep your web apps accessible: Just use text

#219

Post by vkou »

vanderZwan wrote: post #64
rpeden wrote: post #60

Earlier quoted context omitted.

Breaking it is completely unnecessary too, even with single page apps. It's not all that hard to build a React or Angular apps that use proper links along with the browser history API. Designed properly, the apps should be able to load their state and render correctly even when deep-linked to somewhere other than the app's top level. This isn't a new concern - I remember paying attention to this back in the old days…

It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.

> It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design.

What if state should be destroyed when you press the back button? What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page.

Should clicking the back button return me to a page containing the image? A page containing 'this image has been deleted'? The website I was on before I was on the photo app?

Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront?

What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state?

It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app.

Re: The easiest way to keep your web apps accessible: Just use text

#220

Post by stockkid »

I like the content of the article but did not appreciate the out-of-place call to action to try their service right in the middle of the body ("LogRocket is working on ... Click to check it out.").

In my opinion, those call to actions are helpful when in the similar context with the content itself, or when placed outside of the content. Otherwise they are just intrusive.

Post reply on HN