timothya

See: https://developer.chrome.com/blog/autoplay

tl;dr: The browser attempts to learn your preference for each site automatically based on how you interact with videos. You can see what it's calculated by visiting chrome://media-engagement

See also Rowan Atkinson’s standup routine from the early 90s: https://youtu.be/uw8dW9Hyno0

See: https://webmasters.googleblog.com/2018/01/using-page-speed-i...

> Users can still put obnoxious annotations up.

No, annotations are deprecated, you can't add them to videos anymore. [0]

[0]: https://youtube-creators.googleblog.com/2017/03/keep-fans-en...

"Changelist".

Similar words are commit, diff, patch, etc. (though sometimes those other words have other implications)

The Google Home definitely supports Chromecast now [0].

My favorite related thing to say is "Hey Google, play House of Cards on my TV", and it will turn on my TV and then start playing the next episode from Netflix. Perfect for when I'm walking over to the TV with my dinner.

[0]: https://blog.google/products/home/google-home-holidays/

> All this is over-engineered IMO.

It's complicated in order to provide a lower-level API so that libraries can take advantage of different features and provide more opinionated ways of creating custom elements. Polymer is an example of a library which provides a simpler (but slightly more opinionated) API on top of custom elements.

> The value of shadow DOM is also quite doubtful to be honest. It is shadowed from whom and for what purpose? User don't care about DOM structure ... Programmers? They are OK with that.

The Shadow DOM provides style isolation, which is convenient to developers mixing-and-matching components, and can also be a performance boost as browsers can optimize for the fact that styles don't cross the shadow boundary. It also provides a bit more isolation for when you are writing code to discourage components from reaching into each others' private implementation.

I think the official documentation is what's found in the help center; this page contains a lot more information about using a custom passphrase for your sync data: https://support.google.com/chrome/answer/1181035?hl=en (top result when searching for "chrome sync encrypted").

To be fair, Chrome has exactly that feature to, and let's the user choose what they want.

Context is king.

Yeah, and please also don't send me any messages where you chose autocompletions for the words, or messages where your phone autocorrected the spelling of. Heck, don't even send messages where you pressed the keyboard buttons to spell out the words, it's far to impersonal and dehumanizing to be limited to the options your phone presents; people should communicate like they were meant to: by talking to each other face-to-face.

---

With Smart Replies (as with other communication-helping technology), meaning comes from how and when you choose to use them, and there's no reason you shouldn't choose to use them when it communicates what you were intending. If I was going to say "Yes!" and that's a Smart Reply option, why shouldn't I save the time and choose it? It was still my action that sent that message, still my choice to send it, still the meaning that I wanted to communicate. Smart Replies save time for the simple stuff, so you can better spend your time on other messages that you might write manually.

It says on Revolv's website that they're giving full refunds to current customers:

"If you're a current Revolv customer, please email us at help@revolv.com so we can help you out during this transition and provide you with a refund of the purchase price of your Revolv hub." - http://revolv.com/

They're giving full refunds to all their customers, so it's more like those customers got to use the device for "free" while it was available.

It's nice to see WebKit adopt this approach too. Chrome and Firefox have already had a policy against new CSS properties with vendor prefixes for over three years, so with Safari onboard too now it's becoming easier to imagine a future where web developers won't have to worry about writing code with prefixes anymore. The only potential reason to use them will be compatibility with older browser versions.

There's another interactive widget when you search for "bubble level" (only on mobile). Handy!

If you're not on mobile, this article has some screenshots of the widget: http://www.androidpolice.com/2015/12/23/searching-bubble-lev...

According to the pre-match interview[0], the AlphaGo project is about two years old, and started out as a collaboration between two members of DeepMind and a member of the Google Brain team (Google's deep learning team which pre-dates the DeepMind acquisition by several years, according to Wikipedia). So really, AlphaGo is a combined effort that was always a part of Google, and I think it's pretty clear that resources provided by Google (money, equipment, and tooling) in addition to the techniques developed by both Google and DeepMind made this project a reality. I think they both deserve a lot of credit, certainly, but I wouldn't say that the credit is all that misplaced here.

[0]: https://youtu.be/qUAmTYHEyM8?t=1201

For the record, Chrome's sync data can also be an encrypted blob that Google can't decrypt[0].

[0]: https://support.google.com/chrome/answer/1181035?hl=en

> For some time, Google has been convinced that the semiautonomous systems that others champion (which include various features like collision prevention, self-parking, and lane control on highways) are actually more dangerous than the so-called Level Four degree of control, where the car needs no human intervention. The company is convinced that with cars that almost but don’t drive themselves, humans will be lulled into devoting attention elsewhere and unable to take quick control in an emergency.

I think this is a really good perspective. Considering how often drivers are already doing things like using smartphones behind the wheel of non-self-driving cars, I think that sort of activity is only magnified by partial autonomy - which is very dangerous! Humans get distracted or bored easily, especially when completing routine tasks. I'm glad that Google is choosing to build a car that never needs human intervention rather than rushing to market with a partial solution.

Here's a video where you can see what distracted teen drivers look like. Terrifying. http://youtu.be/SDWmwxQ_NnY

While you're right that it's up to the browser to fix, that can be a very time consuming process (especially for something as tricky as video). YouTube doesn't want to wait around for browser vendors to fix things, so they work around it themselves (just like happened in the opposite direction for this bug).

Finding workarounds for browser bugs is a common theme for the work that web developers do. Yes, browser vendors should fix the bugs, but in the meantime, there's no reason to have a bad user experience.

> The poor way in which YouTube does feature detection (via user agent string) is almost as appalling.

If you could provide a better alternative, I'm sure they'd be all ears.

That sort of feature detection is likely not sufficient for detecting if a video will play well or correctly. There's been a number of bugs in MSE in the past which means that YouTube has to fall back on browser version checks to avoid a bad user experience.

Reading the comments on that bug, it looks like it was only a small subset of Firefox users who experienced this bug. Not really a big story.

> the only way to monetize on youtube right now is via ads

That's not true, you can also set up a channel where users have to pay to purchase or rent your videos (or pay a subscription to see all of your videos). More information is here: https://support.google.com/youtube/answer/3249127?hl=en

The Closure Compiler supports compiling ES6 code already, and can also do transpilation down to ES3/ES5. [1][2]

Google also has the Traceur Compiler which does transpilation of new JS features (ES6, ES7 proposals, and a couple of features that aren't in either) into older versions. [3]

[1]: https://github.com/google/closure-compiler/wiki/Releases#oct...

[2]: https://github.com/google/closure-compiler/wiki/ECMAScript6#... (might be a bit out of date, since there have been releases since that document was last edited)

[3]: https://github.com/google/traceur-compiler

That shouldn't happen in Safari or Chrome anymore - videos don't autoplay until you actually open the tab for the first time.

I don't really see how that's relevant; you're talking about a system from years ago. It's not like they could easily just go back to that, especially with so many comments stored in the new system.

Furthermore, the G+-powered comments section brought about many new features that I imagine they wouldn't want to get rid of, like threaded replies, text formatting, improved ranking and spam detection, moderation tools, and probably more.

From the YouTube Help Center:

"You'll soon be able to comment, upload, and create channels without Google+. The comments you make on YouTube will appear only on YouTube and not also on Google+ (and vice versa). Check out our blog post for more information and keep an eye on this article for updates."

Building a comment system at the scale of YouTube (while preserving the existing set of comments), along with creating a new identity system for it is likely not a small amount of work. I'd guess that they're still working on making it a reality.

It works if you log out.

Or watch the version on YouTube: https://www.youtube.com/watch?v=u4IsqmMqCEo

I regret using the word "just", sorry for seeming negative. I only meant to clarify that this doesn't expose any information that YouTube isn't purposefully providing as part of the search API. I apologize for the confusion!

Good on you, it's definitely pretty neat! Sorry, I didn't mean to imply that this was simple or anything! At first I interpreted it as a security / privacy bug where you were exposing what your neighbors were uploading, so my comment was just meant to clarify that this is an intentional behavior of the YouTube API.