Multiculturalismo a Bruxelles
Ad
https://www.davidicke.com/article/513643/firemen-flee-attacked-migrant-youths-multicultural-molenbeek
“They call us for small fires and attack us while we want to help.”
☺
- Scritto da: altg
> E lo chiedi a me?
Quello che volevo farti notare è che stai usando un bug, una dimenticanza nella specifica dell'HTML4, come fosse una feature.
Il fatto che sia un bug lo capisci da due cose:
1) la prima è che se fosse vero che il Size indica la dimensione in pixel del TAG in questione allora non ci sarebbe ragione per l'attributo Width. Perciò Size e Width hanno significati diversi o uno dei due è di troppo.
2) la seconda è che questo bug è stato corretto nella versione successiva dell'HTML
> Chiedilo a quelli di firefox, per loro a quanto
> pare width non serve a nulla in quel
> caso.
Loro si limitano a fare quello che gli viene detto dal W3.
> Anche se poi un altro, in un altro thread, m'ha
> detto che a casa sua width riesce a rimpicciolire
> i selettori di file, ma non a
> ingrandirli.
In realtà se guardi con Firebug vedrai che in Firefox il Width funziona... infatti il TAG occupa più o meno spazio in base al suo Width. Tuttavia questo non ha alcun effetto grafico sul TAG stesso, semplicemente perché Firefox non sa come il width si comporta nel rendering dell'oggetto.
> Comunque, nella specifica HTML4 width e` tra gli
> attributi degli inputs nel rendering dei forms:
> anche degli inputs di tipo file. Per come la vedo
> io, cosi` come width si applica a un pulsante, a
> una checkbox, a una combo box, eccetera, si
> applica anche a un selettore di file. Passi che
> lo standard, obiettivamente troppo vago come loro
> stessi hanno riconosciuto poi, non specificasse a
> cosa si dovesse riferire la width in pixels
> (all'intero controllo o al solo campo contenente
> il valore, cioe` il percorso e il nome del file
> selezionato?), ma a qualcosa si riferiva. Per
> buon senso, non solo mio ma anche degli
> sviluppatori di Opera, IE, Chrome, width secondo
> loro si riferiva a tutto il controllo perche`
> come ho detto e` improbabile che a qualcuno
> piaccia appendere il bottone "browse" fuori dalla
> larghezza prevista. Non e` che ci volesse un
> genio ad arrivarci, ma io non credo che a firefox
> siano stati scemi, no... solo non lo
> consideravano
> importante.
>
> Prendiamo un altro esempietto, vuoi?
> Una bella checkbox.
> Vediamo cosa fa Opera e cosa fa Firefox.
>
> [img]http://anynowhere.com/personal/checkboxrender
>
> Oh guarda, Opera non solo gli applica width ed
> height producendo un gadget enorme, magari molto
> adatto agli ipovedenti e a quelli col tremolio
> nelle mani quando usano il mouse, ma addirittura
> colora lo sfondo.
>
>
> E la panda rossa?
> Nah, queste cose non si fanno. Cattivo cattivo
> cattivo.
> Ti pare possiamo starci a sbattere a implementare
> i nostri gadget della
> UI?
> Usiamo quelli di sistema cosi` come sono, va`...
Ripeto, Firefox si limita ad applicare le scelte del W3. Dove il W3 non ha proferito parola i browser fanno quello che gli pare, e Firefox ha scelto di non fare nulla.
Cmq, se la cosa ti infastidisce, puoi partecipare al bugzilla sia di Firefox che del W3. È l'unico modo per cambiare le cose.
> E lo chiedi a me?
Quello che volevo farti notare è che stai usando un bug, una dimenticanza nella specifica dell'HTML4, come fosse una feature.
Il fatto che sia un bug lo capisci da due cose:
1) la prima è che se fosse vero che il Size indica la dimensione in pixel del TAG in questione allora non ci sarebbe ragione per l'attributo Width. Perciò Size e Width hanno significati diversi o uno dei due è di troppo.
2) la seconda è che questo bug è stato corretto nella versione successiva dell'HTML
> Chiedilo a quelli di firefox, per loro a quanto
> pare width non serve a nulla in quel
> caso.
Loro si limitano a fare quello che gli viene detto dal W3.
> Anche se poi un altro, in un altro thread, m'ha
> detto che a casa sua width riesce a rimpicciolire
> i selettori di file, ma non a
> ingrandirli.
In realtà se guardi con Firebug vedrai che in Firefox il Width funziona... infatti il TAG occupa più o meno spazio in base al suo Width. Tuttavia questo non ha alcun effetto grafico sul TAG stesso, semplicemente perché Firefox non sa come il width si comporta nel rendering dell'oggetto.
> Comunque, nella specifica HTML4 width e` tra gli
> attributi degli inputs nel rendering dei forms:
> anche degli inputs di tipo file. Per come la vedo
> io, cosi` come width si applica a un pulsante, a
> una checkbox, a una combo box, eccetera, si
> applica anche a un selettore di file. Passi che
> lo standard, obiettivamente troppo vago come loro
> stessi hanno riconosciuto poi, non specificasse a
> cosa si dovesse riferire la width in pixels
> (all'intero controllo o al solo campo contenente
> il valore, cioe` il percorso e il nome del file
> selezionato?), ma a qualcosa si riferiva. Per
> buon senso, non solo mio ma anche degli
> sviluppatori di Opera, IE, Chrome, width secondo
> loro si riferiva a tutto il controllo perche`
> come ho detto e` improbabile che a qualcuno
> piaccia appendere il bottone "browse" fuori dalla
> larghezza prevista. Non e` che ci volesse un
> genio ad arrivarci, ma io non credo che a firefox
> siano stati scemi, no... solo non lo
> consideravano
> importante.
>
> Prendiamo un altro esempietto, vuoi?
> Una bella checkbox.
> Vediamo cosa fa Opera e cosa fa Firefox.
>
> [img]http://anynowhere.com/personal/checkboxrender
>
> Oh guarda, Opera non solo gli applica width ed
> height producendo un gadget enorme, magari molto
> adatto agli ipovedenti e a quelli col tremolio
> nelle mani quando usano il mouse, ma addirittura
> colora lo sfondo.
>
>
> E la panda rossa?
> Nah, queste cose non si fanno. Cattivo cattivo
> cattivo.
> Ti pare possiamo starci a sbattere a implementare
> i nostri gadget della
> UI?
> Usiamo quelli di sistema cosi` come sono, va`...
Ripeto, Firefox si limita ad applicare le scelte del W3. Dove il W3 non ha proferito parola i browser fanno quello che gli pare, e Firefox ha scelto di non fare nulla.
Cmq, se la cosa ti infastidisce, puoi partecipare al bugzilla sia di Firefox che del W3. È l'unico modo per cambiare le cose.
Quando sei parte di una minoranza in via d'estinzione
Ad
https://images2.imgbox.com/d3/da/AZxsgAEN_o.png
ma se vuoi difendere la tua etnia e le tue terre sei "razzista"
☺
- Scritto da: ::1
> Ammetti però che:
> a) non è l'esempio che ti avevo chiesto
Invece si. È un esempio di caratteristica HTML5 applicata retroattivamente a qualcosa che prima funzionava in HTML4 (in base alle preferenze del browser).
> b) html5 non è minimamente collegato alla
> questione
In HTML5, ciò che va o non va inviato al server, è dettagliato da un algoritmo del W3.
http://www.whatwg.org/specs/web-apps/current-work/...
Is this HTML5?
In short: Yes.
Sempre nella stessa pagina:
http://www.whatwg.org/specs/web-apps/current-work/...
Punto 3.7 che interrompe l'algoritmo prima di raggiungere il punto 4.
Questo "Form Submission Algorithm", prima dell'esistenza di HTML5, non esisteva. Ogni browser poteva implementarlo a piacere.
> Ammetti però che:
> a) non è l'esempio che ti avevo chiesto
Invece si. È un esempio di caratteristica HTML5 applicata retroattivamente a qualcosa che prima funzionava in HTML4 (in base alle preferenze del browser).
> b) html5 non è minimamente collegato alla
> questione
In HTML5, ciò che va o non va inviato al server, è dettagliato da un algoritmo del W3.
http://www.whatwg.org/specs/web-apps/current-work/...
Is this HTML5?
In short: Yes.
Sempre nella stessa pagina:
http://www.whatwg.org/specs/web-apps/current-work/...
Punto 3.7 che interrompe l'algoritmo prima di raggiungere il punto 4.
Questo "Form Submission Algorithm", prima dell'esistenza di HTML5, non esisteva. Ogni browser poteva implementarlo a piacere.
☺
- Scritto da: altg
> > Essendo l'HTML5 praticamente basato sull'HTML4
> > IMO non avrebbe alcun senso continuare a
> > supportare i comportamenti errati dell'HTML4
> > scelti a caso dai vari browser (come il
> > comportamento di SIZE nel caso INPUT FILE di
> > Alex, o l'invio della coppia nome-valore come
> per
> > qualsiasi altro INPUT anche per il tipo "image")
> > perché non dettagliati dalle specifiche
> > dell'HTML4.
>
> Invece era dettagliato.
> Vuoi che ti riproponga di nuovo la pagina?
> Cheppalle.
>
>
>
> size = cdata [CN]
> This attribute tells the user agent the initial
> width of the control. The width is given in
> pixels except when type attribute has the
> value "text" or "password". In that case, its
> value refers to the (integer) number of
> characters.
>
> type=file non e` ne` type=text ne`
> type=password
> Quindi il valore dell'attributo size per
> type=file e` in pixels, non in caratteri, nero su
> bianco.
>
> Se continui a spargere per il forum la tua
> versione, puo` anche darsi che diventi vera,
> chissa`.
>
Allora, se size si misura in pixel e indica la dimensione grafica del campo, spiegaci a che serve width e in che modo è diverso.
☺
- Scritto da: ::1
>
> - Scritto da: Daisuke Niwa
> > - Scritto da: ::1
> > > anche su ie8 (normale e modo compatibile) non
> > > invia il
> > > name.
> >
> > Appunto. In HTML4 potevi fare quel razzo che
> > volevi. IE (e credo Opera) non lo mandava,
> > Firefox e Chrome
> > si.
>
> Quindi ti lamenti di aver codificato una cosa
> sicuro del supporto di un vendor che ha cambiato
> idea? In un thread dove si parla di standard
> web??? GRANDISSIMA MICRO$OF- no aspè
>
>
È molto semplice, non l'ho fatto sul WEB, ma in una Intranet in cui IO controllavo ogni aspetto, incluso che browser usare. In realtà, usando sempre o Firefox o Chrome, non mi sono mai reso conto che la cosa non era supportata da IE (e credo Opera). D'altra parte non era nemmeno proibito dalle specifiche HTML4 perciò non mi sono nemmeno sognato che la cosa non funzionasse negli altri browser... ora lo so.
☺
- Scritto da: ::1
>
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da: ::1
> > >
> > > - Scritto da: Daisuke Niwa
> > > >
> > > > - Scritto da: ::1
> > > > > Dettaglia mettendo su pastebin un esempio
> di
> > > > > pagina che hai dovuto modificare
> nonostante
> > > > fosse
> > > > > html 4.01 valido, con doctype valido
> > > (strict),
> > > e
> > > > > che veniva mostrato sbagliato perché
> > > > interpretato
> > > > > html 5 o non ci
> > > > > credo.
> > > > >
> > > > > I doctype transitional e frameset non
> > valgono,
> > > > > sono almost standard e usano un parser
> > > > > differente.
> > > > >
> > > >
> > > > Crea l'esempio che ho indicato nell'altro
> > post.
> > > > Scrivici sopra il DOCTYPE di HTML4.
> > > > Aprilo con qalsiasi versione di Firefox <=
> 3.6
> > > > Poi aprilo con qualsiasi versione di Firefox
> > >=
> > > 4
> > > > Vedrai che la pagina, perfettamente
> > funzionante
> > > > in Firefox 3.6 e minori, sarà rotta in
> > Firefox
> > 4
> > > > e
> > > > maggiori.
> > > >
> > > > Poi vai su bugzilla, cerca il bug, e segui
> la
> > > > litigata che ne è seguita da parte di una
> > marea
> > > > di sviluppatori che si sono visti, da un
> > giorno
> > > > all'altro, le loro applicazioni Intranet
> > > > distrutte e le risposte che hanno ottenuto
> da
> > > > Firefox. Poi visto che ci sei vai anche sul
> > > > bugzilla del W3, e segui la litigata anche
> > > > lì.
> > >
> > > belink!
mica vuoi farmi cercare un post tra> > > mille
> > > dai!!!
> >
> >
> http://www.forumdeitroll.it/m.aspx?m_id=2621511&m_
> >
> > Questi giovinastri che vogliono avere sempre la
> > pappa pronta...
> >
>
> E' un caso limite, poi stai usando un immagine
> come fosse un submit, è semanticamente sbagliato,
> perché se ti interessano x e y del click hai il
> name dell'immy cliccata; se non ti interessano
> fai un input type=submit con l'immagine come
> sfondo, dimensione uguale all'immy e color:
> transparent per non vedere il testo del
> bottone.
>
> L'unico caso che non copri è quando hai due immy
> con lo stesso name e vuoi sapere le x e le y e il
> value dell'immy cliccata, ma dici che devi solo
> farci i bottoni: usa i
> bottoni
È un caso che mostra come gli algoritmi dell'HTML5 si applichino retroattivamente.
PRIMA non c'era scritto da nessuna parte che la coppia nome = valore non dovesse essere inviata nel caso di type = image e infatti browser diversi hanno implementato la cosa diversa.
Ora non è più così.
Se fosse vero che gli algoritmi dell'HTML5 si applicano SOLO dalla versione 5 in su, non ci sarebbe stato motivo per Firefox di cambiare il suo comportamento lì dove la specifica del documento era ancora la 4 in cui era lasciata libera scelta.
☺
- Scritto da:
> tanto metà delle specifiche sono ancora draft
>
> per esempio, ma non limitatamente a, i form
The HTML5 specification will not be considered finished before there are at least two complete implementations of the specification.
A test suite will be used to measure completeness of the implementations. This approach differs from previous versions of HTML, where the final specification would typically be approved by a committee before being actually implemented. The goal of this change is to ensure that the specification is implementable, and usable by authors once it is finished.
A differenza di prima la specifica dell'HTML5 sarà ritenuta completa solo quando ci saranno almeno due implementazioni complete e corrette della specifica. Cioè fra 30 anni.
☺
- Scritto da: ::1
>
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da: ::1
> > > Dettaglia mettendo su pastebin un esempio di
> > > pagina che hai dovuto modificare nonostante
> > fosse
> > > html 4.01 valido, con doctype valido
> (strict),
> e
> > > che veniva mostrato sbagliato perché
> > interpretato
> > > html 5 o non ci
> > > credo.
> > >
> > > I doctype transitional e frameset non valgono,
> > > sono almost standard e usano un parser
> > > differente.
> > >
> >
> > Crea l'esempio che ho indicato nell'altro post.
> > Scrivici sopra il DOCTYPE di HTML4.
> > Aprilo con qalsiasi versione di Firefox <= 3.6
> > Poi aprilo con qualsiasi versione di Firefox >=
> 4
> > Vedrai che la pagina, perfettamente funzionante
> > in Firefox 3.6 e minori, sarà rotta in Firefox 4
> > e
> > maggiori.
> >
> > Poi vai su bugzilla, cerca il bug, e segui la
> > litigata che ne è seguita da parte di una marea
> > di sviluppatori che si sono visti, da un giorno
> > all'altro, le loro applicazioni Intranet
> > distrutte e le risposte che hanno ottenuto da
> > Firefox. Poi visto che ci sei vai anche sul
> > bugzilla del W3, e segui la litigata anche
> > lì.
>
> belink!
mica vuoi farmi cercare un post tra> mille
> dai!!!
http://www.forumdeitroll.it/m.aspx?m_id=2621511&m_...
Questi giovinastri che vogliono avere sempre la pappa pronta...
☺
Proc di Catania
- Scritto da:
>
> > Ora, lasciamo da parte i dettagli della pagina e
> > concentriamoci sul
> > contenuto.
> >
> >
> [img]http://upload.wikimedia.org/wikipedia/commons
> >
> > Mathew Berger lo scopritore di questa nuova
> > razza. Dovrebbe avere 12 anni oggi
> >
>
>
> E per festeggiare la scoperta verra inculato da
> te ?
>
>
> Che bello
L'ho visto prima io, è inutile che fai il geloso.
☺
- Scritto da:
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da:
> > >
> > > - Scritto da: Daisuke Niwa
> > > >
> > > > - Scritto da:
> > > > >
> > > > > - Scritto da: Daisuke Niwa
> > > > > > Diverse cose sono cambiate, incluse
> alcune
> > > > > regole
> > > > > > che potrebbero rompere diversi
> > > > > > siti.
> > > > > >
> > > > > > Inizialmente pensavo fosse colpa di
> > Firefox.
> > > > > Dopo
> > > > > > aver litigato con loro è saltato fuori
> che
> > > > loro
> > > > > > non potevano farci nulla, perché il W3
> > aveva
> > > > > > deciso
> > > > > > diversamente.
> > > > > >
> > > > > > Sono quindi andato a litigare con quelli
> > del
> > > > W3
> > > > > e
> > > > > > mi è stato detto che l'HTML4 va
> > considerato
> > > > > > deprecato.
> > > > > >
> > > > > >
> > > > > > Diverse scelte in HTML4 erano scelte
> > > > frettolose,
> > > > > > incoerenti e mal pensate. Il tizio mi ha
> > > detto
> > > > > > che sono stati un sacco di tempo a tirar
> > > fuori
> > > > > le
> > > > > > specifiche dell'HTML5 _proprio_ perché
> > > > stavolta
> > > > > > non volevano cadere nell'errore fatto
> con
> > > > > > l'HTML4. In altre parole BISOGNA
> > considerare
> > > > le
> > > > > > specifiche dell'HTML5 come le specifiche
> > > > > GENERALI
> > > > > > dell'HTML. Anche se nel DocType c'è
> > scritto
> > > > > HTML4
> > > > > > il browser deve applicare le regole
> > > > dell'HTML5,
> > > > > > punto e basta. l'HTML4 è praticamente
> > > > deprecato
> > > > > e
> > > > > > i browser non sono più obbligati ad
> > > > > > implementarlo. Applicheranno invece di
> > > default
> > > > > le
> > > > > > regole
> > > > > > dell'HTML5.
> > > > >
> > > > > tutto molto bello
> > > > >
> > > > > adesso il w3c deve solo convincere tutti
> gli
> > > > > utenti internet del mondo a passare a
> > browser
> > > > > aggiornati ad html
> > > > > 5
> > > > >
> > > > >
> > > >
> > > > L'importante è che ci passino gli
> > sviluppatori,
> > > > gli utenti non potranno fare altro che
> > > > adattarsi... se vogliono vedere delle pagine
> > web
> > > > decenti.
> > >
> > > Se fosse così IE6 sarebbe scomparso da eoni.
> >
> > Guarda che IE6 esiste ancora solo lì dove
> > l'utente non può cambiarlo (perché magari ha un
> > SO vecchio per versioni successive, o perché
> così
> > facendo rompe applicazioni Intranet che gli
> > servono).
>
> Lascia perdere IE6 adesso, ma prima di far
> passare la gente a un browser successivo c'è
> voluta una vita. Figurati l'idea dei browser che
> in continuo si aggiornano per i cambiamenti
> dell'HTML5, è
> un'utopia.
È molto semplice in realtà:
non ti tieni aggiornato? libero per non farlo, ma non lamentarti se le pagine web che vedi sono rotte.
Cmq, a differenza di IE6, molti browser ora o si aggiornano da soli (come Chrome), oppure ti dicono "guarda che è uscita una nuova versione, vuoi installarla?". Perciò in realtà il processo di aggiornamento è molto più semplice e "proattivo" rispetto al funzionamento dei vecchi browser dove se non andavi tu a controllare il sito del produttore nessuno ti diceva che c'era una nuova versione in agguato.
Poi ovviamente avrai anche un certo numero di utonti che non saprebbero nemmeno cliccare sul pulsante "Aggiorna Adesso" che Firefox ti sbatte in faccia 6 millisecondi dopo che una nuova versione è disponibile...
Trova Wakanda!
Ad
https://imgoat.com/uploads/edebb6e872/182095.jpg
Solo il 5% riesce a trovarla! Provaci anche tu!!
☺
- Scritto da:
>
> - Scritto da: Daisuke Niwa
> > Non lo troverai scritto da nessuna parte, non
> > esplicitamente per lo meno, o almeno io non l'ho
> > trovato. Però è comprensibile che sia
> > così.
> >
>
>
Libero di non crederci, a me non interessa convincere proprio nessuno. Ci sbatterai il muso da solo.
☺
- Scritto da:
>
> - Scritto da: Daisuke Niwa
> >
> > - Scritto da:
> > >
> > > - Scritto da: Daisuke Niwa
> > > > Diverse cose sono cambiate, incluse alcune
> > > regole
> > > > che potrebbero rompere diversi
> > > > siti.
> > > >
> > > > Inizialmente pensavo fosse colpa di Firefox.
> > > Dopo
> > > > aver litigato con loro è saltato fuori che
> > loro
> > > > non potevano farci nulla, perché il W3 aveva
> > > > deciso
> > > > diversamente.
> > > >
> > > > Sono quindi andato a litigare con quelli del
> > W3
> > > e
> > > > mi è stato detto che l'HTML4 va considerato
> > > > deprecato.
> > > >
> > > >
> > > > Diverse scelte in HTML4 erano scelte
> > frettolose,
> > > > incoerenti e mal pensate. Il tizio mi ha
> detto
> > > > che sono stati un sacco di tempo a tirar
> fuori
> > > le
> > > > specifiche dell'HTML5 _proprio_ perché
> > stavolta
> > > > non volevano cadere nell'errore fatto con
> > > > l'HTML4. In altre parole BISOGNA considerare
> > le
> > > > specifiche dell'HTML5 come le specifiche
> > > GENERALI
> > > > dell'HTML. Anche se nel DocType c'è scritto
> > > HTML4
> > > > il browser deve applicare le regole
> > dell'HTML5,
> > > > punto e basta. l'HTML4 è praticamente
> > deprecato
> > > e
> > > > i browser non sono più obbligati ad
> > > > implementarlo. Applicheranno invece di
> default
> > > le
> > > > regole
> > > > dell'HTML5.
> > >
> > > tutto molto bello
> > >
> > > adesso il w3c deve solo convincere tutti gli
> > > utenti internet del mondo a passare a browser
> > > aggiornati ad html
> > > 5
> > >
> > >
> >
> > L'importante è che ci passino gli sviluppatori,
> > gli utenti non potranno fare altro che
> > adattarsi... se vogliono vedere delle pagine web
> > decenti.
>
> Se fosse così IE6 sarebbe scomparso da eoni.
Guarda che IE6 esiste ancora solo lì dove l'utente non può cambiarlo (perché magari ha un SO vecchio per versioni successive, o perché così facendo rompe applicazioni Intranet che gli servono).
☺
- Scritto da:
>
> - Scritto da: Daisuke Niwa
> > Diverse cose sono cambiate, incluse alcune
> regole
> > che potrebbero rompere diversi
> > siti.
> >
> > Inizialmente pensavo fosse colpa di Firefox.
> Dopo
> > aver litigato con loro è saltato fuori che loro
> > non potevano farci nulla, perché il W3 aveva
> > deciso
> > diversamente.
> >
> > Sono quindi andato a litigare con quelli del W3
> e
> > mi è stato detto che l'HTML4 va considerato
> > deprecato.
> >
> >
> > Diverse scelte in HTML4 erano scelte frettolose,
> > incoerenti e mal pensate. Il tizio mi ha detto
> > che sono stati un sacco di tempo a tirar fuori
> le
> > specifiche dell'HTML5 _proprio_ perché stavolta
> > non volevano cadere nell'errore fatto con
> > l'HTML4. In altre parole BISOGNA considerare le
> > specifiche dell'HTML5 come le specifiche
> GENERALI
> > dell'HTML. Anche se nel DocType c'è scritto
> HTML4
> > il browser deve applicare le regole dell'HTML5,
> > punto e basta. l'HTML4 è praticamente deprecato
> e
> > i browser non sono più obbligati ad
> > implementarlo. Applicheranno invece di default
> le
> > regole
> > dell'HTML5.
>
> tutto molto bello
>
> adesso il w3c deve solo convincere tutti gli
> utenti internet del mondo a passare a browser
> aggiornati ad html
> 5
>
>
L'importante è che ci passino gli sviluppatori, gli utenti non potranno fare altro che adattarsi... se vogliono vedere delle pagine web decenti.