timothya

"Changelist".

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

> 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.

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.

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.