Then I read the bottom of the readme, and noticed safari was holding back webdev once again.
I've been casually following this for the last 5 years and it seems almost too convenient that safari is regularly behind on mission critical features.
Stop trying to give webpages control - any control at all - over the browser UI. The page gets to control just that (the page) and the framework around that page (the browser). Any violation of this a potential security problem. Any time the demarcation between "remote page" and "browser UI" is blurred, problems such as "phishing" attacks become easier.
If you want fancier UI than is possible from a web page, write a native app.
Any time the demarcation between "remote page" and
"browser UI" is blurred, problems such as "phishing"
attacks become easier.
Unfortunately, people whose training and experience exists only inside a browser either don't or can't see beyond those confines and the result is reimplementing perfectly adequate external functionality.
Sometimes I am doing something on the CLI and go back to the terminal and paste a text I copied from somewhere.
If the text is multiline my terminal will consume the lines without requiring an extra 'enter / return' key press.
Another possibility is copying something to web mail client without noticing there's something suspicious about it (JS isn't the concern here anymore nowadays, but loading stuff like images is a privacy concern).
However, this issue MUST be fixed at browser level. And when used without destroying user expectations / UX, this plugin is useful.
Malicious attacks are going to happen anyways if the browser permit such action to happen, so don't blame the plugin or the plugin writer. The browsers are broken. Ask the major browser developers to either never allow it to happen (like Safari does) or ask them to ask for permission (like for webcams) or add a confirmation modal.
A trivial compromise that would be even easier to use than the current javascript/selection stuff would be a "copy to clipboard" variant of the <button> tag. Something like this should satisfy the use-cases where this clipboard nonsense is occasionally useful:
<form>
<input name="copy_souce" type="text" value="xyzzy" />
<button type="clipboard" value="copy_source"
name="Copy To Clipboard" />
</form>
This could even be extended to allow copying of the various types of input tags, and if you wanted to get fancy, the button could reference an #id and copy that element's textContent (or innerHTML).
I know it's only existed on desktop computers since the Apple Lisa, and 30 years isn't very long for people to grasp the concept of copy and paste without a button to do it, but I have faith in people.
Maybe a small modal-like confirmation that can be placed anywhere on the viewport and is actually on top of everything natively (like Safari's copy/paste on iOS).
Of course, this modal-like confirmation must not be customized or its effect is useless.
Or let's just forget entirely and remove the functionality from the browsers.
The discussion really should focus on how well apps degrade, which is really reaffirming that progressive enhancement is still the best approach to building web apps. While only a small percentage of users have intentionally disabled JavaScript entirely, it's effectively disabled for everyone while it's downloading and a larger percentage of users (particularly on mobile) will have errors which prevent those downloads entirely. If you build a rich application which still has the core functionality working, you've done a much better job than the people who make sites which take minutes or don't even render when their shiny framework hits a non-perfect network connection.
Maybe there’s just a focus on different things between vendors: Google has tons of 20%-time engineers pushing new half-baked features in every direction (yes this is a bit of a caricature), while Apple is taking a more measured approach with a focus on performance and reliability.
Battery life it does have an advantage on, AFAIK this is widely understood and both Google and Mozilla are trying to address it (if they can, Apple does have nonpublic/undocumented APIs...). I'm surprised you find it outperforming Firefox wrt memory usage, though.
> on performance and reliability.
Good luck then trying to do anything complex with video and audio on iOS Safari. I've seen many weird quirks and bugs, strange limitations (videos always playing fullscreen on iPhone) and even browser crashes.
And considering reliability: wouldn't you agree that we would be better of using a native solution for clipboard access than the buggy and insecure Flash fallback that's needed for Safari?
It is in Apple's interest that people don't browse at all, and spend their time inside apps, where Apple has a much bigger chance of getting revenue sharing.
They are deprecating the browser, on purpose.
[Edit: this doesn't mean Apple is bad, they are just a rational company; it would be weird if they weren't doing it]
Any example of those pages that brings the computer to a crawl?
[0] http://thenextweb.com/apps/2015/08/20/chrome-is-finally-gett...
I'm sure there's some configuration setting or extension I could use to change this behavior. However, switching to Safari fixes it as well (and gets me improved battery life overall). I haven't really noticed any downsides to using Safari vs. Chrome.
The only thing that Safari is good at is memory footprint and batterly life.
An objective view: https://html5test.com/results/desktop.html
Safari is better then everything and all the rest doesn't come near. The features that it copied from Chrome made Safari worse and at they don't spy on me or sell me to advertisers.
Note: Apple has iAd and does the same, it just doesn't want Google to do it.
At least i wrote some pro's for Safari... And it's a live feature tester for HTML 5 according to the W3C HTML 5 specifications, and safari lags far behind. It runs all the test cases and the best browser comes on top. The worst browser falls behind.. In this "objective" test, Safari falls short and Chrome, Opera and Firefox are much better.
So yes, it is much more objective then your opinion ;-)
please, enlighten us.
[1] case in point: the misfeature we are discussing in this thread, which is just another addition to the big list of browser features that I have to go out of my way to disable to get a sane experience that minimises my exposure to the incompetence of web developers
That is (according to me) the true reason why Apple doesn't add features to Safari ;)
Safari is so behind even compared to IE.
Same as this project. DataTables filters out Safari for some of it's extension:
https://github.com/DataTables/Buttons/blob/master/js/buttons...
Safari is the new Internet Explorer.
Yup, all checks out.
Fun thing: the author of the Selection API draft works for Apple :-)
I have to ask though, what mission critical ratified features do you need that Safari lacks?
At this point I still don't buy that Apple is doing this to hold things back. Do you have other examples of when they've been behind on features with no clear explanation of why? It's okay if not - you said you were only casually following - but curious.
They wouldn't have very much to gain in my mind - none of their core business relies on locking in/out web development. They have an app market, and I guess you could argue they're trying to drive that, but they have implemented a lot of other features, and early extensions in many cases, that doesn't really align with them trying to hold web back.