4 ms·
Well, there's this and the fact that browser implementers all need to come to consensus over what features to add and that's an extremely difficult process to m
by mysteryDate 5y ago
Well, there's this and the fact that browser implementers all need to come to consensus over what features to add and that's an extremely difficult process to move forward. There also is one big browser implementer who doesn't really want the "playful web" to exist and would prefer that everyone live inside of apps.
Edit: To be clear, we all work together and mostly get along. It's a long and arduous process to reach consensus and not everyone's incentives are aligned and this can be frustrating.
- dmitriid 5y ago> There also is one big browser implementer who doesn't really _want_ the "playful web" to exist and would prefer that everyone live inside of apps. No. There's one humongous browser implementer who couldn't care less about consensus or what other browser vendors think. This vendors ships literally hundreds of new APIs every year and pretends they are now standards that everyone else must implement. Too bad developers believe them. BTW, it only took only 8 minutes for my countdown to reach zero: https://news.ycombinator.com/item?id=30555034 https://news.ycombinator.com/item?id=30555034
- dmitriid 5y agoSomeone linked "Request for position" on these APIs: https://github.com/mozilla/standards-positions/issues/519#issuecomment-859975125 https://github.com/mozilla/standards-positions/issues/519#is... Here's Mozilla's response: --- start quote --- 4x4 transforms: There are a bunch of implementation concerns here (and mentioned on that issue) with regards to availability on various native 2d backends... Needs more investigation SVG filter interface: We would really rather people use WebGL if you want fast/efficient filters. (I made a number of comments on that issue) As is, we're generally against this one for the time being --- end quote --- There's literally zero response on that from @mysteryDate who is now gaslighting Safari in the comment above, and presenting these API additions as fait accompli. Honestly, at this point any time I see any public Chrome person write anything I immediately assume it's a distortion of reality at best and a blatant lie at worst. And this is always the case. But sure. "Safari is the bad guy".
- mysteryDate 5y agoThere was a ton of work across browser vendors to make this a part of spec: https://html.spec.whatwg.org/multipage/canvas.html#the-canvas-element https://html.spec.whatwg.org/multipage/canvas.html#the-canva... It's all there. It's all official. That github page was just one part of reaching consensus. There's also TAG review: https://github.com/w3ctag/design-reviews/issues/627 https://github.com/w3ctag/design-reviews/issues/627 FWIW Mozilla and Safari signed off on all of these changes at some point in time somewhere, hence why it's allowed to be part of spec. There were some changes that were not allowed to be part of the new API because one of those two said no (like perspective transforms, conic curves). For jdashg's concerns on that thread, 4x4 matrices were cancelled, and you can follow up with much more debate from all parties on roundRect and filters: http://github.com/whatwg/html/pull/6763 http://github.com/whatwg/html/pull/6763 https://github.com/whatwg/html/pull/6765 https://github.com/whatwg/html/pull/6765 This is certainly not decided by fiat. Working to find consensus across browser implementers is just a ton of work.
- dmitriid 5y ago> It's all there. It's all official. > FWIW Mozilla and Safari signed off on all of these changes at some point in time That's a relief then. Too often these days "it's official it's in the spec" as presented by Chrome is anything but. > This is certainly not decided by fiat. There are too many cases when it's decided unilaterally by Chrome.
- rikroots 5y ago> We would really rather people use WebGL if you want fast/efficient filters. This one made me laugh. Yes, WebGL excels at pixel manipulations but it is possible to write fast and efficient filters to work in the 2D canvas environment. For a case-in-point, I struggled for a long time to find a decent, fast implementation of a gaussian blur filter for my canvas library. Then I stumbled upon a JS implementation[1] based on some very clever work done by Intel devs which blew all my previous attempts out of the water - so of course I stole it (even though I still don't understand the approach they take)[2]. > "Safari is the bad guy" As much as Safari often brings me to despair, I do like the work they've recently done to add color space support in CSS. They haven't yet pushed the functionality over to the canvas element, but I live in hope. For now, I have to emulate the calculations to get them working for my library[3]. [1] - https://github.com/nodeca/glur/blob/master/index.js https://github.com/nodeca/glur/blob/master/index.js [2] - https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEngine.html#section-54 https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEn... [3] - https://scrawl-v8.rikweb.org.uk/demo/canvas-059.html https://scrawl-v8.rikweb.org.uk/demo/canvas-059.html
- robertoandred 5y agoDon't you know? The "playful web" means websites getting access to your USB devices or being able to keep your screen from sleeping/locking!
- robertoandred 5y agoYour post implies that Google cares about browser consensus. For example, "This feature has been in Firefox for a while and we're finally making it part of the canvas spec." Google DOES NOT decide what the spec is. "You" don't make something part of the spec. The Chrome team's hubris is insulting to the web.