Notifiche push via Chrome anche su Android: ecco i primi siti compatibili

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.

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

Candidate Reccomendation:
15 December 2011 vs 9 May 2013
Last Call Working Draft:
23 January 2013 vs 13 Novembre 2014
Proposed Reccomendation:
9 May 2013 vs 16 December 2014
Reccomendation:
10 Ottobre 2013 vs 24 February 2015

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

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/sharedwebw...mp;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

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



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



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

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




Sarebbe? Mi invii qualche link di questa implementazione?



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

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

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 che sono considerate le WebRTC 1.1.
Come vedi da questi esempi, il punto sono le motivazioni...

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



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



Cito dal tuo collegamento...


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


http://www.w3.org/TR/webrtc/

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...12Feb/0313.html

Qui c'è addirittura un appello del presidente del Working Group che si occupa della standardizzazione dei CSS: http://www.glazman.org/weblog/dotcl...B-NEEDS-YOU-NOW
Dove chiede agli sviluppatori di siti web di evitare di realizzare siti -webkit-only

ne avevo sentito parlare qui sul blog di jQuery, in particolare






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 il suo team in WP 8.1 GDR1

Certo che è uno standard, 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


I community group ospitati dal W3C non rappresentato il W3C




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


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


Giusto per chiudere la questione riguardo i vendor prefixes



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


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



Ti evidenzio una parte


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




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