Link alla notizia: http://www.hwupgrade.it/news/telefonia/notifiche-push-via-chrome-anche-su-android-ecco-i-primi-siti-compatibili_56936.html

Google ha rilasciato un nuovo comunicato in cui specifica nel dettaglio il funzionamento delle nuove notifiche push attraverso Chrome, che ci permetteranno di diminuire drasticamente la nostra dipendenza dalle app

Click sul link per visualizzare la notizia.

Considerata la diffusione di Chrome, è probabile che la funzionalità sarà abbracciata presto da molti altri servizi web, consentendo ai propri utenti di eliminare sullo smartphone parecchie applicazioni da decine di megabyte che utilizzano solo per ricevere le tanto agognate notifiche push.

Chrome come IE6, ancora e ancora

I browser stanno diventando sistema operativi. Sembra la storia di emacs. Non so voi, ma io con il browser navigo e scarico roba e basta.

Chrome come IE6, ancora e ancora

straquoto, ma quando la capiranno, sara' troppo tardi...

...sempre SE mai lo capiranno, perche' e' di google mica di MS, quindi e' figo, va' tutto bene

potete essere più chiari?

I browser stanno diventando sistema operativi. Sembra la storia di emacs. Non so voi, ma io con il browser navigo e scarico roba e basta.

Emacs è la cosa più bella che potessi conoscere nel panorama GNU. :D

Comunque è vero, Chrome sta diventando un piccolo sistema operativo.

Chrome come IE6, ancora e ancora
Vabbè dai almeno in questo caso, se non ho capito male Google sta utilizzando le Push API del W3C

potete essere più chiari?

la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)

la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Cromismo e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)

Non ci ho capito una mazza ma una cosa ho capito, Google fa come,.azzo gli pare comprese le schifezze che crea fuori standard.
Ma non era le la paladina dello standard W3C?

la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)

grazie della spiegazione..

io non faccio che spegnerle sulle app e c'é gente che vuole averle pure sul desktop le notifiche? Anche sul mac le ho disabilitate tutte.

la "colpa" di IE6, che ha causato la brutta fama di IE per gli anni a venire, è stata quella di aggiungere estensioni proprietarie, sfruttando la sua diffusione per forzare i siti a fare siti che funzionassero bene solo con IE (motivo per cui MS è stata multata e costretta a mostrare il ballot screen in Europa)

Chrome sta facendo la stessa cosa: estensioni proprietarie + grande diffusione + siti ottimizzati per chrome, e loro approfittano di questo per spingerlo ancora di più... un esempio a caso è WhatsApp Web, che all'inizio era presente solo su Chrome dato che sfruttava delle API non standard di esso

un altro esempio della "prepotenza" di Chrome si è avuto di recente con le API per i Pointer Event, API sviluppate da MS per Windows 8* e poi ratificate come raccomandazioni dal W3C: non solo Chrome si è ostinata a non implementarle (nonostante fosse la cosa più votata sul bug tracker di Chromium e ci fossero già pull request con implementazioni abbozzate), ma ha sviluppato la propria estensione ai Touch Event per i fatti suoi, raccomandando quello... alla fine hanno ceduto e (con l'aiuto di MS) li implementeranno

e la cosa si estende anche a webkit in generale: estensioni proprietarie e siti ottimizzati per browser basati su esso invece che sugli standard... paradossalmente adesso abbiamo Internet Explorer (insieme a FireFox) a difendere gli standard e WebKit (e fork vari, Blink incluso) che fanno un po' ciò che gli pare

PS: le estensioni proprietarie hanno motivo di esistere, ad esempio senza IE6 oggi non avremmo AJAX, e il W3C prevede anche un meccanismo per "separarle" dalle ufficiali, allo scopo di testarle per poi magari essere rifinite e inserite tra gli standard W3C: ad esempio WebKit potrebbe introdurre sperimentalmente un selettore CSS chiamato 'nino' (e definito quindi come -webkit-nino, o -ms-nino se introdotto da MS ad esempio)...
il problema è che gli sviluppatori web NON dovrebbero usare le estensioni sperimentali in siti in produzione (e invece lo fanno) e i browser dovrebbero aggiungere il supporto alla versione standard (quindi 'nino') una volta che l'estensione è stata approvata (e WebKit NON lo fa) e idealmente droppare la versione sperimentale ('-webkit-nino') e ovviamente non possono farlo visto che ci sono siti in produzione che le usano

il risultato è che i programmatroti web si lamentano che IE "non segue gli standard" perché non supporta i tag proprietari di webkit, e in questi casi ci sarebbe da inseguirli a colpi di tastiera sul cranio... infatti in Windows Phone 8.1 GDR1 MS è stata costretta ad aggiungere il supporto a roba -webkit-* e a cambiare l'user agent di IE per renderlo compatibile con certi siti scritti con i piedi...

* = (fondamentalmente permettono di gestire i dispositivi di puntamento indipendentemente dalla loro natura... in questo modo c'è un'unica API per gestire mouse, touch, penne, robe tipo leapmotion ecc ecc invece che un'api per il mouse, una per il touch ecc ecc)

Sbagli su diverse cose:

-MS con IE il problema non erano le "estensioni proprietarie" il codice HTML e CSS, quello "base," che veniva interpretato a modo suo, e questo rendeva impossibile realizzare facilmente siti compatibili con gli altri browser... quindi IE e Chrome hanno 2 problemi COMPLETAMENTE diversi
Se rispetti gli standard del W3C il sito si vede uguale in tutti i browser
Con IE se rispettavi gli standard del W3, lo vedevi bene negli altri browser, ma non vedevi una mazza

-Collegandomi a sopra: Le specifiche proprietarie le hanno TUTTI i browser, Da Chrome a Opera e da Mozilla Firefox a Microsoft IE... sono gli sviluppatori web che vanno presi a calci nel sedere che usano quelle supportate solo da 1 browser/engine... ma ripeto il problema non sono le estensioni proprietarie

-E qui distorci completamente la realtà dei fatti: I Touch Event (http://www.w3.org/TR/touch-events/) erano standard W3 (sviluppati dalla W3, Opera, Mozilla e Nokia, quindi Google non centra niente con la loro creazione) ed esistevano PARECCHIO PRIMA(Prima bozza 2011 (http://www.w3.org/TR/2011/WD-touch-events-20110505/) contro prima bozza 2012 (http://www.w3.org/TR/2012/WD-pointerevents-20121211/)) dei Pointer Event (http://www.w3.org/TR/pointerevents/) sviluppati da Microsoft e Mozilla, e diventati standard solo a febbraio 2015, quindi 2 mesi fa

-E qui distorci completamente la realtà dei fatti: I Touch Event (http://www.w3.org/TR/touch-events/) erano standard W3 (sviluppati dalla W3, Opera, Mozilla e Nokia, quindi Google non centra niente con la loro creazione) ed esistevano PARECCHIO PRIMA(Prima bozza 2011 (http://www.w3.org/TR/2011/WD-touch-events-20110505/) contro prima bozza 2012 (http://www.w3.org/TR/2012/WD-pointerevents-20121211/)) dei Pointer Event (http://www.w3.org/TR/pointerevents/) sviluppati da Microsoft e Mozilla, e diventati standard solo a febbraio 2015, quindi 2 mesi fa

Non tanto, i Pointer Events sono Candidate Recommendation dal 2013, considera che nei browser vediamo implementate API che sono anche in Working Draft...!
Ma la questione è che Google aveva espressamente e pubblicamente dichiarato che non avrebbe implementato i Pointer Events e che invece avrebbe esteso i Touch Events, nonostante all'epoca i Pointer Events erano già Candidate Recommendation (fase che prevede esplicitamente l'implementazione dell'API nei browser al fine di ricevere feedback al Working Group), fra l'altro adducendo motivazioni all'epoca poco convincenti.

Non tanto, i Pointer Events sono Candidate Recommendation dal 2013, considera che nei browser vediamo implementate API che sono anche in Working Draft...!

Sbagli: (Touch vs Pointer, gli ultimi 4 passaggi)

Candidate Reccomendation:
15 December 2011 (http://www.w3.org/TR/2011/CR-touch-events-20111215/) vs 9 May 2013 (http://www.w3.org/TR/2013/CR-pointerevents-20130509/)
Last Call Working Draft:
23 January 2013 (http://www.w3.org/TR/2013/WD-touch-events-20130124/) vs 13 Novembre 2014 (http://www.w3.org/TR/2014/WD-pointerevents-20141113/)
Proposed Reccomendation:
9 May 2013 (http://www.w3.org/TR/2013/PR-touch-events-20130509/) vs 16 December 2014 (http://www.w3.org/TR/2014/PR-pointerevents-20141216/)
Reccomendation:
10 Ottobre 2013 (http://www.w3.org/TR/touch-events/) vs 24 February 2015 (http://www.w3.org/TR/pointerevents/)

Quindi se i pointer erano in candidate reccomendation nel 2013, i touch già erano anche in proposed reccomendation in quel momento, ovvero ad un passo dall'approvazione finale

E soprattutto non è stato Google a realizzarli dopo che sono nati i touch event, come ha affermato falsamente unrealizer

Ma la questione è che Google aveva espressamente e pubblicamente dichiarato che non avrebbe implementato i Pointer Events e che invece avrebbe esteso i Touch Events, nonostante all'epoca i Pointer Events erano già Candidate Recommendation (fase che prevede esplicitamente l'implementazione dell'API nei browser al fine di ricevere feedback al Working Group), fra l'altro adducendo motivazioni all'epoca poco convincenti.

Cosi come, ad esempio, Mozilla ha dichiarato (https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/) di non voler implementare la File System Api(quella usata da Whatsapp per intenderci) creata da Google e Working Draft del W3 (ed anche qui Unrealizer ha affermato falsamente che è stata implementata successivamente da Firefox cosa non vera (https://developer.mozilla.org/en-US/docs/Web/API/File_System_API))

e come Microsoft non ha intenzione di implementare diversi standard, approvati e non, supportati da tutti gli altri o almeno Firefox, Chrome ed Opera
https://status.modern.ie/sharedwebworkers?iestatuses=notplanned&browserstatuses=implemented&browsers=chrome,firefox,opera&ieversion=11

Insomma il non voler implementare qualcosa in Working Draft(ed a volte anche delle Reccomendation) è qualcosa che fanno TUTTI e spesso, non solo Google o solo Mozilla o solo Microsoft, TUTTI

-Collegandomi a sopra: Le specifiche proprietarie le hanno TUTTI i browser, Da Chrome a Opera e da Mozilla Firefox a Microsoft IE... sono gli sviluppatori web che vanno presi a calci nel sedere che usano quelle supportate solo da 1 browser/engine... ma ripeto il problema non sono le estensioni proprietarie

che è esattamente ciò che ho detto nel post: che le estensioni proprietarie sono normali (ma non il loro abuso per aumentare la propria posizione) e che gli sviluppatori web vanno presi a colpi di tastiera :D

-E qui distorci completamente la realtà dei fatti: I Touch Event (http://www.w3.org/TR/touch-events/) erano standard W3 (sviluppati dalla W3, Opera, Mozilla e Nokia, quindi Google non centra niente con la loro creazione) ed esistevano PARECCHIO PRIMA(Prima bozza 2011 (http://www.w3.org/TR/2011/WD-touch-events-20110505/) contro prima bozza 2012 (http://www.w3.org/TR/2012/WD-pointerevents-20121211/)) dei Pointer Event (http://www.w3.org/TR/pointerevents/) sviluppati da Microsoft e Mozilla, e diventati standard solo a febbraio 2015, quindi 2 mesi fa

io parlavo dell'estensione ai Touch Event che ha sviluppato Google in risposta ai Pointer, non dei Touch "originali"



Cosi come, ad esempio, Mozilla ha dichiarato (https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/) di non voler implementare la File System Api(quella usata da Whatsapp per intenderci) creata da Google e Working Draft del W3 (ed anche qui Unrealizer ha affermato falsamente che è stata implementata successivamente da Firefox cosa non vera (https://developer.mozilla.org/en-US/docs/Web/API/File_System_API))

io dicevo che Chrome ha ceduto e implementerà i Pointer, non che Firefox implementerà le File System API :mbe:

che è esattamente ciò che ho detto nel post: che le estensioni proprietarie sono normali (ma non il loro abuso per aumentare la propria posizione) e che gli sviluppatori web vanno presi a colpi di tastiera :D

Sbagli sul fatto che le specifiche proprietarie non possono fare una benamata mazza per aumentare la propria posizione (cosa che invece facevano gli l'interpretazione di IE6-7-8-9)

e Whatsapp ne è la prova, ha implementato le API di Google Chrome e si è beccata un bel dito medio da tutti gli utenti e browser


io parlavo dell'estensione ai Touch Event che ha sviluppato Google in risposta ai Pointer, non dei Touch "originali"

Sarebbe? Mi invii qualche link di questa implementazione?

io dicevo che Chrome ha ceduto e implementerà i Pointer, non che Firefox implementerà le File System API :mbe:

In effetti no, chiedo venia ho fatto un briciolo di confusione su quella parte :stordita:

In ogni caso però il fatto che dopo Whatsapp abbia adottato metodi standard è la conferma che una implementazione proprietaria in Chrome non può né dettare standard né tirare acqua al suo mulino... visto che Whatsapp. come ho già detto sopra. è stato ignorato ed insultato

Sbagli: (Touch vs Pointer, gli ultimi 4 passaggi)

Candidate Reccomendation:
15 December 2011 (http://www.w3.org/TR/2011/CR-touch-events-20111215/) vs 9 May 2013 (http://www.w3.org/TR/2013/CR-pointerevents-20130509/)
Last Call Working Draft:
23 January 2013 (http://www.w3.org/TR/2013/WD-touch-events-20130124/) vs 13 Novembre 2014 (http://www.w3.org/TR/2014/WD-pointerevents-20141113/)
Proposed Reccomendation:
9 May 2013 (http://www.w3.org/TR/2013/PR-touch-events-20130509/) vs 16 December 2014 (http://www.w3.org/TR/2014/PR-pointerevents-20141216/)
Reccomendation:
10 Ottobre 2013 (http://www.w3.org/TR/touch-events/) vs 24 February 2015 (http://www.w3.org/TR/pointerevents/)

Quindi se i pointer erano in candidate reccomendation nel 2013, i touch già erano anche in proposed reccomendation in quel momento, ovvero ad un passo dall'approvazione finale

E soprattutto non è stato Google a realizzarli dopo che sono nati i touch event, come ha affermato falsamente unrealizer

Cosi come, ad esempio, Mozilla ha dichiarato (https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/) di non voler implementare la File System Api(quella usata da Whatsapp per intenderci) creata da Google e Working Draft del W3 (ed anche qui Unrealizer ha affermato falsamente che è stata implementata successivamente da Firefox cosa non vera (https://developer.mozilla.org/en-US/docs/Web/API/File_System_API))

e come Microsoft non ha intenzione di implementare diversi standard, approvati e non, supportati da tutti gli altri o almeno Firefox, Chrome ed Opera
https://status.modern.ie/sharedwebworkers?iestatuses=notplanned&browserstatuses=implemented&browsers=chrome,firefox,opera&ieversion=11

Insomma il non voler implementare qualcosa in Working Draft(ed a volte anche delle Reccomendation) è qualcosa che fanno TUTTI e spesso, non solo Google o solo Mozilla o solo Microsoft, TUTTI

Forse è bene che rileggi meglio i commenti prima di rispondere...

In ogni caso, non conosco bene questa vicenda, ma le motivazioni addotte dallo sviluppatore di Mozilla mi sembrano ragionevoli (sicuramente più ragionevoli di quelle che Google diede all'epoca riguardo i Pointer Events), riguardo le API che non sono attualmente in programma per IE: tanto per fare un esempio per WebRTC 1.0 poco importa, stanno già implementando le ORTC API for WebRTC (http://blogs.msdn.com/b/ie/archive/2014/10/27/bringing-interoperable-real-time-communications-to-the-web.aspx) che sono considerate le WebRTC 1.1.
Come vedi da questi esempi, il punto sono le motivazioni...

Forse è bene che rileggi meglio i commenti prima di rispondere...

Forse è bene che ti spieghi meglio anziché fare il vago...

In ogni caso, non conosco bene questa vicenda, ma le motivazioni addotte dallo sviluppatore di Mozilla mi sembrano ragionevoli (sicuramente più ragionevoli di quelle che Google diede all'epoca riguardo i Pointer Events),

Tra le motivazioni di Mozilla ci sta il fatto che sono già presenti implementazioni che fanno la stesso cosa ed anche in maniera migliore, che è anche una delle motivazioni date da mozilla, ovviamente si può essere d'accordo o meno con entrambe le dichiarazioni... è una cosa soggettiva

Personalmente non voglio entrare nel merito se è giusta o meno la dichiarazione di Google... avranno fatto le loro valutazioni e sono giusti alle loro conclusioni, che hanno prontamente cambiato quando l'implementazione è migliorata, punto

riguardo le API che non sono attualmente in programma per IE: tanto per fare un esempio per WebRTC 1.0 poco importa, stanno già implementando le ORTC API for WebRTC (http://blogs.msdn.com/b/ie/archive/2014/10/27/bringing-interoperable-real-time-communications-to-the-web.aspx) che sono considerate le WebRTC 1.1.
Come vedi da questi esempi, il punto sono le motivazioni...

Cito dal tuo collegamento...
This specification was published by the Object-RTC API Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

Non è uno standard e non è neanche sulla strada per diventarlo... quindi sono ben lontani da diventare standard, quindi direi che la MS farebbe bene ad implementare le WebRTC nel frattempo dato che ....

This document was published by the Web Real-Time Communications Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webrtc@w3.org (subscribe, archives). All comments are welcome.
http://www.w3.org/TR/webrtc/

In ogni caso però il fatto che dopo Whatsapp abbia adottato metodi standard è la conferma che una implementazione proprietaria in Chrome non può né dettare standard né tirare acqua al suo mulino... visto che Whatsapp. come ho già detto sopra. è stato ignorato ed insultato

Qui trovi una interessante discussione addirittura del 2012 dove si parla proprio del problema dei prefissi di WebKit (inizia dal paragrafo Vendor Prefixes): http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html

Qui c'è addirittura un appello del presidente del Working Group che si occupa della standardizzazione dei CSS: http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW
Dove chiede agli sviluppatori di siti web di evitare di realizzare siti -webkit-only

Sarebbe? Mi invii qualche link di questa implementazione?

ne avevo sentito parlare qui (http://blog.jquery.com/2015/02/24/getting-on-point/) sul blog di jQuery, in particolare

[...]but rather to try to extend Touch Events to have the power of Pointer Events. (https://code.google.com/p/chromium/issues/detail?id=404128)


In ogni caso però il fatto che dopo Whatsapp abbia adottato metodi standard è la conferma che una implementazione proprietaria in Chrome non può né dettare standard né tirare acqua al suo mulino... visto che Whatsapp. come ho già detto sopra. è stato ignorato ed insultato

il problema è che il comportamento di Google e altri, sviluppatroti (termine volutamente storpiato) inclusi rischia di trasformare il web in qualcosa di webkit-centrico in cui tutti gli altri engine rischiano di essere tagliati fuori... facendo l'esempio con IE, guarda cosa ha dovuto fare (http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx) il suo team in WP 8.1 GDR1

Non è uno standard e non è neanche sulla strada per diventarlo... quindi sono ben lontani da diventare standard, quindi direi che la MS farebbe bene ad implementare le WebRTC nel frattempo dato che ....
Certo che è uno standard (http://ortc.org/wp-content/uploads/2014/08/ortc.html), non sarà uno standard del W3C, ma è comunque uno standard open definito da un gruppo di sviluppatori / aziende, fra l'altro sempre all'interno del circuito W3C del quale i W3C Community Groups fanno comunque parte, la cui specifica è pubblica e che tutti possono implementare, senza necessariamente dover usare vendor prefix.

Certo che è uno standard (http://ortc.org/wp-content/uploads/2014/08/ortc.html), non sarà uno standard del W3C, ma è comunque uno standard open definito da un gruppo di sviluppatori / aziende, fra l'altro sempre all'interno del circuito W3C del quale i W3C Community Groups fanno comunque parte, la cui specifica è pubblica e che tutti possono implementare, senza necessariamente dover usare vendor prefix.

Vabbe qui stai dando i numeri.... se non è uno standard approvato del W3C, così come scrive il W3C stesso, significa che NON è ancora uno standard e ci vorrà ancora tempo prima che lo diventi

E' fatto da un community group e cito da questa pagina (https://www.w3.org/community/ortc/)
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

I community group ospitati dal W3C non rappresentato il W3C


Qui trovi una interessante discussione addirittura del 2012 dove si parla proprio del problema dei prefissi di WebKit (inizia dal paragrafo Vendor Prefixes): http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.html

Una conversazione che non mi pare porti a nessuna risoluzione riguardo la questione webkit ... o sbaglio? :)

Tra l'altro se noti il problema è prevalentemente su mobile il che significa che sono i prefissi di Apple Safari su iOS a creare problemi ;)

Anzi ti estraggo anche una frase
glazou: Simon said that Apple WebKit implemented -webkit-text-size adjust
for better experience on mobile.

Dulcis in fundo, come dici è una discussione del 2012 quando opera usava ancora Presto, e Chrome era ben lontano da avere le percentuali attuali, aveva circa il 36%, meno di Firefox , a conferma del fatto che non è Chrome il problema, specie in quel periodo
http://www.w3schools.com/browsers/browsers_stats.asp
Addirittura su NetMarketShare porta il 18% insieme a Firefox a percentuali simili ed Internet Explorer al 52%

Quindi di che parliamo? Monopolio al 18/36%? Ahahahahahaha :asd: Ripeto, Li si parla del mobile(e ci sta anche scritto diverse volte nella conversazione), precisamente di Safari per iOS

Dulcis in fundo bis....Blink l'engine di Chromium e Chrome(ed Opera), e la politica sui vendor prefixes
http://www.chromium.org/blink#vendor-prefixes
Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy and the W3C CSS WG formed a rough consensus around a complementary policy.

Giusto per chiudere la questione riguardo i vendor prefixes

Qui c'è addirittura un appello del presidente del Working Group che si occupa della standardizzazione dei CSS: http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW
Dove chiede agli sviluppatori di siti web di evitare di realizzare siti -webkit-only

Addirittura! Orca zozza! Ed io che pensavo che il W3 creasse gli standard per poi consigliare di usare gli standard proprietari ai web designer!!

E riporta il testo completo
WebKit, the rendering engine at the heart of Safari and Chrome, living in iPhones, iPads and Android devices, is now the over-dominant browser on the mobile Web and technically, the mobile Web is full of works-only-in-WebKit web sites while other browsers and their users are crying. Many sites are sniffing the browser's User-Agent string and filtering out non-WebKit browsers. As in the past with IE6, it's not a question of innovation but a question of hardware market dominance and software bundled with hardware. But there is an aspect of the problem we did not have during the IE6 era: these web sites are also WebKit-specific because they use only "experimental" CSS properties prefixed with -webkit-* and not their Mozilla, Microsoft or Opera counterparts. So even if the browser sniffing goes away, web sites will remain broken for non-WebKit browsers...

In many if not most cases, the -webkit-* properties WebKit-specific web sites are using do have -moz-*, -ms-*, -o-* equivalents. Gradients, Transforms, Transitions, Animations, border-radius, all interoperable enough to be browser-agnostic. Their web authors need only a few minutes to make the site compatible with Mozilla, Microsoft or Opera. But they never did it.

Ovvero dice di non usare la proprietà webkit DA SOLA, dato che "per molti, se non per la maggior parte dei casi" le stesse. dannate, identiche proprietà sono presenti anche in tutti gli altri, dannati, browser!

Quindi, nel post in questione, NON si attaccano le proprietà tipo la File System API o comunque funzionalità presenti in un solo browser, ma i webdesigner imbecilli... cosa che faccio anche io ampiamente

ne avevo sentito parlare qui (http://blog.jquery.com/2015/02/24/getting-on-point/) sul blog di jQuery, in particolare

Ti evidenzio una parte
We see no credible path to replacing TouchEvents completely on the web, and so rather than introduce a new largely-redundant model to blink, we'd like to work within the web standards community to improve the APIs we have in a compatible way.

Avevano in mente di migliorare lo standard già esistente in collaborazione con gli altri membri del W3


il problema è che il comportamento di Google e altri, sviluppatroti (termine volutamente storpiato) inclusi rischia di trasformare il web in qualcosa di webkit-centrico in cui tutti gli altri engine rischiano di essere tagliati fuori... facendo l'esempio con IE, guarda cosa ha dovuto fare (http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx) il suo team in WP 8.1 GDR1

Webkit non è solo Google, ma anche Apple Safari prima ed Opera dopo, se è arrivato a queste percentuali non ci è arrivato solo per Google Chrome, ed in ogni caso occhio al parte superiore del post, in risposta a damxxx, che ci sono altre risposte riguardo la questione