Release Notes for Safari Technology Preview 81 | Hacker News Reader

Release Notes for Safari Technology Preview 81

webkit.org

50 pointsfeross19 comments

Disappointing... still no support for HTML5 date and time input types. Safari seems to be the last major hold out[0] keeping JavaScript-powered date pickers a (prudent) necessity.

[0]: https://caniuse.com/#feat=input-datetime

Those JS pickers are going to be needed for a long time still, because native widgets are a nightmare to style consistently. Apparently nothing has been learned from the <select> styling minefield of the past.

I don't think that everyone should be able to edit the style of native elements. I prefer a consistent behavior, and the select itself works fine everywhere for example.

But i sadly agree, JS stuff is going to be needed for a long time.

There are good arguments for styling native elements and against them. I don't think this is specific to the web, cross-platform GUI toolkits have had this challenge forever.

The current datepickers on the desktop are "consistent in the same browser across many sites". There is no native solution for "consistent in the same site across browsers", which makes a lot of designers and PHBs upset, doesn't always fit the overall look of the site, and makes it harder for developers because each browser brings its own quirks with formatting, localization, validation, etc.

Those native interfaces look so dull and out of place when having other input 'helpers' such as better 'select' with bootstrap themes, that I don't even consider them as existent and other third party date pickers are going to be around for quite a while.

Input type 'number' also gives you weird step helper which most of the time is unnecessary and there isn't even a simple way to disable it.

Somehow HTML stopped innovating for so long, the latest revision (HTML5) is just mostly fixing what sucked with HTML4 and adding stuff other third parties already did better.

"Added the privacy preserving Ad Click Attribution API as an experimental feature"

What is this?

They're using multiple names to refer to this feature. It's also known as "Link Click Analytics" or <a ping>.

> The goal of link click analytics is to report to a web server that a navigational link click happened and that the user is leaving the webpage. Such auditing can be used for first-party web analytics as well as third-party cross-site tracking. The latter is where ITP comes in.

https://webkit.org/blog/8821/link-click-analytics-and-privac...

I think that's different. <a ping> has been in Safari for years now, that article was only written because WebKit recently removed the ability to disable it.

I was hoping to see support for U2F. I prefer to use Safari but really enjoy Chrome's support for Yubikey.

Totally agreed. FWIW they do have Webauthn in experimental features.

Wasn’t that in the last tech preview? If so it wouldn’t be a new thing to list in this one?

Can anyone shed light on the “Privacy Preserving Ad Click Attribution” feature?

A quick glance at the changelog in Trac(!) and the commit on bugzilla(!) I just see changes to tests.

I believe it's the same as this feature: https://webkit.org/blog/8821/link-click-analytics-and-privac...

got it, thanks for the link!

So, they seem to be saying if we don’t support the ping element, adtech folks will use more malicious techniques?

I like that they are encouraging first-party analytics, and they are making small tweaks to respecting CSP, but something feels weird about this.

Content blockers (and their built in tracker prevention) both apply to ping elements, but there’s no extra javascript or weird redirect tracking.

It's not.

Just rewatched this talk on Monday from last year where Safari was called out for the rAF behavior that was fixed here. Cool to see this change.

https://m.youtube.com/watch?v=cCOL7MC4Pl0

The new request animation frame changes, are really exciting. Now RAF loops in safari are really synchronized

Still no promised VP8 support.

Reply on news.ycombinator.com