http://arstechnica.com/information-technology/2010/10/ie9-pr...
This entire episode is just a rinse and repeat of what MSFT did years ago in response to negative developer sentiment.
That (Safari adopting "developer previews" now) doesn't mean much regarding whether Safari is the new IE. When people say that phrase they don't mean their both trying (or having tried) developer previews. They mean whether Safari is as backwards and holding the web back as IE6 was for ages.
Which is not. IE9 was years behind Safari at the time you talk about (6 years ago) --and really first version of IE that started to really compete at all for the modern web--, while Safari was, and still is (the preview) at the top of the heap regarding ES6 compliance, etc.
And while much smaller in userbase, Safari grew along with the modern web, introducing major new features that IE hasn't done since 2000 or so (Canvas, CSS animations, etc), being the basis for Chrome, and getting the JIT treatment right along the 2 other modern browsers (Chrome, FF).
As for the mobile space, Safari has been lagging in some features (compared to desktop browsers), but was always ahead of the pack in lots of areas, to the point one cannot say mobile Chrome is that better. In fact, maybe the opposite:
https://blog.runspired.com/2016/03/25/the-chrome-distortion-...
In that respect, it's much more like Chrome's Dev Channel or Canary, or Firefox's Developer Edition, then like these old preview builds.
Edit: Again, I write a very unpopular opinion. Yet there are hundreds of regressions that have bit developers. Some of those bugs require workarounds that would be otherwise unnecessary on any normal environment with rapid updates - like Chrome or Firefox. That increases developer effort, and there have been cases that Apple have entirely missed their update and so folks wait for 6 or more months for a fix!
People can be unhappy with my comment (the score is bouncing up and down like a yo-yo!), I really don't care - but having been one of quite a few website maintainers that have had to work around Apple's bugs, it's very frustrating for both the end user and the developer.
OP posited: “Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction.”
You basically responded, “They're still not as good as I want them to be!” It's a point that has nothing to do with the original comment, which was about improvement, not perfection, and about how seriously they take Safari/Webkit development, not about their release process (which remains roughly the same as it has been for the past many years).
Additionally, regarding the workarounds you mention: they are unnecessary in a “normal environment with rapid updates” only when those developers decide to fix your bug. Again: rapid updates are only useful if your bug is being addressed. I've got workarounds in my code for issues in Firefox that probably won't be fixed anytime soon, and features that Firefox and Chrome support poorly that they won't support well for a while, etc, etc.
I'm not saying Apple couldn't be releasing bug fixes for Safari on any platform faster—they certainly could. But you made an unrelated complaint as a reply to a specific comment, and your argument seems suspect to boot.
So? There are open bugs, including VERY annoying/visible ones, for Chrome that languish for half a decade on its bug page, despite tons of votes...
These features aren't really part of HTML5 though. And while some web apps really need these features, most would not use them at all. So I'm curious why this in particular is your litmus test.
I think an even wider range of web apps will benefit from our IndexedDB revamp, Shadow DOM, ES6, fast tap, font-feature-settings, picture element, CSS Variables, and other cool stuff we shipped recently or have in the works.
Chrome was using WebKit a long time, Blink is a WebKit fork. Both run on Windows.
---
:'( - So much pain erased in a single stroke!
https://bugs.webkit.org/show_bug.cgi?id=66630
https://bugs.chromium.org/p/chromium/issues/detail?id=346613
I've been dealing with this stuff for the last week.
Edit: added webkit reference
https://developer.mozilla.org/en-US/docs/Web/API/ClipboardEv...
Clipboard events are already supported by safari (which the page you've linked to notes) and they've got nothing to do with execCommand, they are about hooking and reacting to user-triggered clipboard operations e.g. the user pastes (via contextual menu or shortcut), the software can know about it and alter the content before it's pasted.
execCommand is about programmatically triggering clipboard events e.g. the user clicks a button in the page and the application translates that to a copy or paste event.
Bummed to not see WebRTC on here though.
That the STP bears the "Safari" name and will be updated through MAS[0] and is featured on their developer site and has access to all the cloud features and shit from standard Safari is a much, much stronger signal as to what future version of Safari will contain.
It looks very much like an apple-official dev channel (chrome) or developer edition (firefox) for Safari, TFA even claims an update frequency about halfway between the Chrome Dev Channel (0.5/1 week) and the Firefox Developer Edition (6 weeks)
[0] despite not even being installed through MAS
As an end user, I really don't want the result of following a link to a website (or 'web app' if you must, because app all the things) to be a progressive web app that a) consumes 100s of MB of my mobile device storage, b) runs in the background draining my battery and using my limited cell data plan, and c) send who know what information to god knows where. All because I clicked on a link and hit OK on an innocuous prompt...
Some of the capabilities presumed by service workers aren't even available to native apps on iOS because of these very same issues - why would Apple grant them to random websites?
I've always felt the WebKit/Safari team is just understaffed. IIRC there was graph posted here a while back showing the number of contributors on the major open source browser platforms and Google has a frightening amount of developers working on Chrome.
On the other hand, i18n API support: http://kangax.github.io/compat-table/esintl/ not done yet, but at >90% it's way better than Safari's 50% and most of the failures seem to be accepting values it should throw errors for in i18n API.
WebKit nightly builds run your system version of Safari with an updated version of the WebKit frameworks. This means that the application you're running is your normal version of Safari. The WebKit nightlies do some shenanigans to convince the system to do things like display a different Dock icon, for instance, but for the most part they just let Safari be Safari.
It's weird lapse for Safari to lag in certain situations. I hope they continue to iteratively improve the performance of the general UI and improve the general behavior of the developer tools in addition to adding these new techs.
I just wish one thing: that it would remember the zoom level on a per website basis.
It's incredible that it's still impossible to do so. Don't the devs use Safari? Or maybe they all have perfect vision and the most expensive displays.
http://www.cerimorgan.com/products/zoombysite/ https://safari-extensions.apple.com/details/?id=com.stefanvd...
Also, chrome gives you a 5px^2 area of "chrome" to drag the window around which is seriously annoying.
Edge(nee IE) and Firefox are committed to support and active in the standards discussions, and I believe allocating people to work on it, if not working on it already. Support across all the major browsers will arrive before we know it.
We also have polyfills for Shadow DOM and the other Web Components standards, and are updating them for the v1 spec: https://github.com/webcomponents/webcomponentsjs
The Shadow DOM polyfill is a bit slow, but soon it'll only be necessary on older browsers, so some properties might be able to adopt full Shadow DOM within the year.
If you use Polymer, we have a fast Shadow DOM-like shim called Shadey DOM, and you can pretty seamlessly opt-in to full Shadow DOM where available.
Firefox -> Firefox Developer Edition
Safari -> Safari Technology Preview
Am I getting that right? What about Edge?
Chrome -> Chrome Dev Channel. Chromium is a different product than Chrome.
> What about Edge?
Edge Previews? https://developer.microsoft.com/en-us/microsoft-edge/platfor...
fetch("...");
Promise {status: "rejected", result: "Fetch is not yet implemented"} = $1
It has somewhat more restrictive CORS requirements than other browsers which not every 360 player has addressed. There's also the issue that Safari on iPhone can't play 360 videos because of the media player taking over fullscreen playback.
Wow, this is huge.
If you want that, you might as well keep using WebKit Nightly, which reuses your Safari stuff.
I know the expectation is that most Macs are up to date but if you can't install it on Yosemite, they should let people know.
https://developer.apple.com/safari/download/
"Compatible with OS X 10.11.4 or later"
Edit: As it is now, it doesn't look very different from what already existed as OSX-side-loadable Webkit Nightlies https://webkit.org/nightly/ or building from source (which even supports iOS simulator!) https://webkit.org/building-webkit/
> You may already be familiar with the WebKit Nightly, which serves a purpose similar to that of Safari Technology Preview. For most people, we think Safari Technology Preview is a more convenient and stable way to live on recent WebKit changes. Unlike the nightlies, Safari Technology Preview supports the full set of iCloud-based Safari features, including iCloud History and iCloud Tabs. And we’ll use the time between Safari Technology Preview releases to curate and test updates to a point where we think developers will find it practical to use as their primary browser.
I shouldn't have to wait for 3 months for awful rendering issues that entirely prevent me from viewing important websites to be fixed!
Obviously it's unpopular to complain about Apple and their dreadful fix timeframes, but there are often thousands of affected websites and often Apple have a fix already checked in and tested. But Apple being Apple, they consider web rendering bugs to be part of their iOS update process, and not just an issue with an app so we all must wait for three months for them to roll it into a major update.
I'm seriously considering setting up a seperate website to track iOS bugs. Apple are hardly willing to be open and transparent about bugs, so perhaps it should be taken from their hands?
I'll keep commenting on their three month timeframe on relevant stories. I don't mind that you don't like me making the point that it's unreasonable. Especially as you agree!
Edit: I'll review my comment history:
* The comment you are responding to, I feel is relevant
* I write a reply to this comment that says that Apple's Safari development is getting better, to which I disagree - https://news.ycombinator.com/item?id=11391186
Entirely relevant to that thread. It's funny watching my comment scores bounce up and down though. I'm not the only one annoyed with Apple I see, there appear to be as many people who agree with me as who are annoyed I point out Apple's Safari issues :-)
Don't assume that just because you think I'm unreasonable that I am unreasonable. My comments are downvoted and you are annoyed with my seeming unreasonableness, but plenty feel the opposite.
I guess all these developers would disagree with you: