Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> (Native buttons also went out of vogue, for some reason.)

Ah, I still remember native buttons being introduced. Good times, back when browsers could introduce features that seem so obvious in retrospect - such as spell check in text boxes. Feels like all the low-hanging fruit has been picked by now. (Or is it? Firefox's integrating a password manager feels pretty similar.)

Great overview, though. I feel like my history with the web has been almost the same as the author's, and this brought back a lot of good and not-so-good memories.



Browsers still lose my 15 minutes of typing when something goes bad and I'm returning back to page. I understand that it's usually caused by websites forbidding caching, so browsers have to reload page, but they still could save that data somewhere and present me an option to restore it, at least for some time. Something like auto-complete.


> Browsers still lose my 15 minutes of typing when something goes bad

It’s not browsers but poorly-designed JavaScript: if you use a standard HTML form all browsers will preserve state and resubmit it for you on retries. The problem is when you have JavaScript altering the form but not reimplementing the standard state management, and since few sites do more than casual testing these days it tends to require a number of user reports before that’s prioritized since it’s so easy for lazy developers to blame the error condition rather than accept that handling it is part of the job.


It's a specific case of a larger symptom: when you implement something in JavaScript that replaces default browser functionality, you also have to re-implement all of the related error handling, edge cases, etc., and can't rely on the work that has already been put into making things work correctly in the browser. But in practice, JavaScript developers never fully re-implement the features that they replace, which means all that work on the browser has gone to waste.


For this reason I attempt to develop a habit to type every comment or post in vim first. This loss of typed text happens maybe once in 2-3 months but it's extremely annoying.


Exactly! Sometimes I wonder why browsers have no hook for launching external editor for textbox input, like EDITOR env in shell? This could also solve the need for RichTextbox with JS based controls for bold/italic/bullets etc.


Yes, I would want to have more user commands for many things such as:

- External editor for textbox input

- Save form data to a local disk file

- Recall form data from a disk file (on the same or a different webpage than it was saved from)

- Replace scripts in the document

- Document/application mode switch

- Disable rich text editing

- Specify a remote filename when uploading files using forms


> - Replace scripts in the document

You might be interested in https://decentraleyes.org/


That would be good for replacing jQuery and so on, but I would want to be able to replace inline scripts too sometimes. (And also some sites have their own copy of jQuery; I will still want to substitute my own if their own copy is otherwise unmodified.)


Back before Firefox Quantum, the Vimperator addon had this. Mine was setup to launch gvim from any (focused) text field when I hit ctrl+i.

I consider this the biggest loss in that transition.


With Tridactyl for Firefox it is still possible to launch external editor by typing Ctrl-I in textboxes and text inputs.


I wouldn’t fancy random ad networks throwing arbitrary payloads at my editor. Which I’m sure they would at least try.


Tridactyl for Firefox can launch external editor (vim) by typing Ctrl-I in textboxes and text inputs.


One of the few add-ons I've installed that's been worth its weight in gold has been "Form History Control (II)", which passively saves every comment as I type it. It's saved me no end of grief in these scenarios.


For a moment browsers were pretty good at this because pages were still static enough that browsers could keep track of elements over page reload. But now that everything is dynamically generated by a few megabytes of opaque javascript? It's a much trickier problem. But "luckily" there's LocalStorage these days so website devs can just go and reimplement the feature…


Oh, and to add to the author's list of upcoming CSS changes: apparently some people are very excited about Houdini: https://developer.mozilla.org/en-US/docs/Web/Houdini


Interesting. And it looks like it's already supported in Chrome and Edge.

https://caniuse.com/#search=houdini


Oh man, I think there's so much low hanging fruit left. Browser native components for autocomplete, infinite scroll, an actual rich text editor, scroll / zoom controls, etc. would all be very welcome.


Absolutely, in terms of things that should be added to the standards and then supported by browsers, there's plenty left to do. I was mainly referring to things browsers could add on their own accord, though, like spell check, or a password manager.

(Just though of another example: Picture in Picture video playback, like Firefox recently added and Chrome and Safari have technically already had for a while.)


Sadly the native dialog element was axed.


>> (Native buttons also went out of vogue, for some reason.)

They’re back now for mobile with react and ionic. In a weird what comes around way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: