Hacker News Reader

Comment by EdSharkey | Hacker News Reader

This feels a bit like how Esc was nerfed over the years in Firefox and others until it essentially did nothing. It used to mean STOP. All sockets were closed, the page stopped loading, and I think way waaay back, even animated gifs stopped cycling and JavaScript timeouts and intervals were cancelled.

Single-page webapps were the death of Esc, it was too confusing to users to have a page suddenly hang because they pressed Esc for some reason and all the XHR connections silently closed. "Stopping" just no longer made sense.

Just going to need to train the old timers on the new key strokes. It is sad though when convenient controls are taken away.

View on HN

Is there any replacement for that Esc=STOP functionality? Every now and again I run into a site that will display some content, and then 1-2 seconds later, cover it up with a full-page ad or signup modal or whatever. I wish I could just refresh and hit "Esc" really quick, like the good old days.

At the time that Firefox killed off Esc, I was part of the old school crowd that complained.

After the smoke cleared, I came to the conclusion that Firefox had crossed a threshold and transformed from being a networked document display application to being an operating environment that was a platform for applications. Javascript, the DOM and CSS had advanced to the point where keyboard controls biased towards convenient document browsing no longer made sense.

I'd be all for Firefox removing the Backspace default keybinding even though it would slightly inconvenience me since that's the key I use to go back.

I either leave the website immediately or use adblock to remove their modal stuff, adblock has the advantage of being somewhat persistent

Or maybe, it is well past time for browsers to have two concepts: “page” and “application” windows.

That way, web sites that are really trying to be applications can have one set of logical keystrokes, default security models, etc. and plain web pages can have another set. They could be further distinguished by some kind of difference in window frame.

I like this idea, but I feel like it would be hard to make sense of in practice. Many things that people would think of as "plain web pages" might have to be classified as applications just because they have some AJAX components. That would satisfy some curmudgeons who don't like what JavaScript has done to the Web, but it would be confusing to the point of worthlessness for everyone else. The alternative is to be extremely liberal about what you classify as a "page," which seems like it would basically be the status quo.

That could be true but consider that on the desktop we have had “files” and “applications” for years without much of a problem. In fact, any time a document tried to do too much (ahem Adobe Reader) it turned into a bloated mess and we preferred simpler formats.

I would like that kind of distinction to be made too somehow for battery life and security/privacy reasons.

I suppose your concept is partially implemented by the "Reader" mode that Safari introduced which I took was an attempt at "zen-ifying" the browser.

I think Reader Mode is largely a flop because 1) it is confusing in that it isn't always on offer by the browser/is context sensitive, which seems like an odd choice, and 2) some pages don't/can't always render sensibly in reader mode for absolute positioning/layout reasons.

My solution to this problem is to give content creators and web application developers better tools to separate between the "page" and "application" use cases.

For "page" content creators, it would be great if they had a framework that poured their content into the browser in an automatically screen-reader accessible way AND was formatted prettily. It's my personal theory that an optimally readable site also happens to read well to a screen-reader, so we can kill two birds with one stone if we abstract the content delivery a bit and force it to be rendered accessibly.

For "application" developers, it would be good to have the framework provide more/better standardized widgets than what the stock HTML5 offers. I'm thinking twisty trees, multi-select lists, streaming infinite scrolls tied to data sources, etc. These widgets would be screen-reader accessible and standard hotkey-enabled where the hotkeys would function the same from site-to-site (mandated by ToS or license).

Finally, the "application" side of this framework would include widgets to display inline "page" content where the user could toggle the "page" content to go full window or full screen and provide that zen reading experience.

I think this is an idea worth exploring and I wish I'd thought of that :-)

> Just going to need to train the old timers on the new key strokes.

Ironically, that's probably the reverse of reality. Looking at the comments here, for starters, we have people espousing views that things have "always" been this way, and quoting their experiences of "the past ten years". It's the young people who are having problems and need to be re-trained here.

The "old timers" will, conversely, have experienced data entry on terminals or in MS-DOS programs like (say) Borland Paradox, where of course things like a backspace key will at most have moved from field to field on a single page, if indeed it caused inter-field motion at all. (The CUA Guidelines give no indication that autotab applies to backspacing from the first field position, i.e. auto back tab. There's a COMPSEC83 paper that talks about it, though.) Backspace certainly didn't switch forms.

Very interesting history perspective on backspace, thank you.

what does esc do nowadays? can't remember the last time I hit it

Reply on news.ycombinator.com