Live data from Hacker News

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

blog.logrocket.com

241–250 of 271 posts

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

#241
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?

Off the top of my head, for one, because my HTML sits on top of a REST API and links can't hit a DELETE endpoint. I've no idea what people expect right clicking a delete link to open in a new tab to do?

I don't care about minor cases like that. I'm talking about things like a CMS not letting you open a post in a new tab because they wanted to load the post via Ajax and failed to provide a fallback.

Really egregious examples even change the location so that I can copy the URL after clicking, new tab, paste, and hit back in the original, but I can't middle click for a new tab.

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

#242
post #38

Posted on Medium with a massive pointless image at the top and page loaded asynchronously using JS.

Ironically, a great illustration of why pictures are trash for explaining concepts outside of specific scenarios. What exactly is the picture trying to convey? How much time and how many bits did the picture take compared to the text? Thankfully, my eyesight works. But I’m sick and tired of designers pretending I’m illiterate and replacing text labels with inscruitable icons and graphics. Hey, remember when you could…

My guess is being utterly lazy with localization. They don't want to have some sort of font rendering or anything like that with fixed dimensions or having and then it got cargo-culted from there. Personally I find searchable text far more useful as Ctrl + F "Setting" highlights everything so much quicker especially on large pages.

I also loathe the unnecessary javascript everywhere.

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

#243
post #131
post #43

I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).

So how do you handle something like filters on a product listing? Make every filter option its own link?

[deleted]

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

#244
post #217

Earlier quoted context omitted.

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

Going "back" and showing the old information is accurate. I'm not reloading the prior URL. I'm viewing the last page I looked at. In fact maybe I don't even have network access at the moment (on a subway). I can always opt in to reload the page if I want to see refreshed data.

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

#245
post #219

Earlier quoted context omitted.

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

Not being able to click "back" out of a POST isn't broken, in my opinion. Basically, if the "back" button behaves differently than it would have behaved in a functionally similar web app in 1998, it's broken. Web apps in 1998 didn't let you click "back" out of a POST.

In 1998, wouldn't a well done POST have issued a 3xx redirect? in which case, going ba k would bring you back to the form or originating page, right through the POST. In which case, the browser may still show the now-deleted image until the user explicitly decides to refresh the page. IIRC the old Opera browser was good about this, to the point of remembering dynamic DOM content as it was.

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

#246
post #43

I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).

I noticed that one day while playing with lynx and now add regular links inside the on-click areas.

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

#247
post #206
post #153

Earlier quoted context omitted.

Sure, max-width will restore reflow, but now your code listings and images break out of their container: https://i.imgur.com/utCVxg1.png My point is that absolute positioning/pixel perfect designs are easy because they solve a simplified project "How to have my content look correct at a fixed size". But it breaks down once that fixed size is no longer reasonable for the target device.

Right, I agreed that what I did would not scale down to small screens. Nor will it work if you ever try and display on an apple watch or some such. The max-width would have just given you flowing text. I fully expect the visualization to be broken on small sizes. I contend that is just not a requirement for most things. This particular endeavor mine, included. So, what point are you arguing against? If it was that I…

Went ahead and flipped both of my "width" overrides to "max-width". Amusingly to me, the worst part of the pages, now, it seems is the MathJax stuff. That said, I'm not seeing an obvious difference in my mobile firefox, just chrome. Still not entirely sure how I would even want these to look there. If you have a good pointer for a site that styles code decently on mobile, I'd love to take a look and see about emulating/stealing.

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

#248
post #208

Earlier quoted context omitted.

> I've no idea what people expect right clicking a delete link to open in a new tab to do? I expect it to issue the delete, and then dump the response to the delete into a new tab rather than navigating away from the page that hosts the delete link. There might be ten other delete links on the original page, and I don't want to delete-back-delete-back-delete-back, when I can just open all of them in a new tab, then g…

That sounds like the right behaviour to me, although there is an arguably nasty non-idempotence. Click it the first time and you get a DELETE response. Click it the second time and you get a 404.

That is still idem potent. In both cases after the request is performed the resource is still deleted.

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

#249

Earlier quoted context omitted.

Off the top of my head, for one, because my HTML sits on top of a REST API and links can't hit a DELETE endpoint. I've no idea what people expect right clicking a delete link to open in a new tab to do?

Yes, but application developers have long faked it using GET .../thing?op=DELETE When you get sick of faking it you look into why there is no way to get browser to send real DELETEs and PUTs and w3c verbiage says "because application developers don't seem to need it" ... because they fake it ... because they have to fake it ... because browser don't do it ... because devs don't need it ...

I was gonna write a snarky comment about using a but apparently, the only methods allowed on a s and s are GET and POST.

I wonder why these limitations. Especially since you can get past this with an:

    button.addEventHandler('click', () => {
      fetch('/path/to/resource', { method: 'DELETE' })
    });
which seems way less accessible then to have the method there right there as an attribute.

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

#250
post #212
post #74

Earlier quoted context omitted.

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

I've always found Medium to only become readable once I use Firefox's reader mode. The interstitial, the aggravating headers and often footers, the utterly useless sidebar icons.

Their styling is unobtrusive, but the result is something that leaves me thinking a designer needs to be shot for working far too hard to justify their pay.

Post reply on HN