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.

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

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

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

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.