|
ATTIVITÀ
:
Utilizzare
:
Software
:
Comunicazione
:
Mozilla
Mozilla
Software Libero, aggiornato frequentemente, compatibile e standard di riferimento, con qualche eccezione superabile ma fastidiosissima, dalla 1.4.x se non fosse per l'annoso problema della finestra di download che
monopolizza e rende inutilizzabile il programma ed un nostro errore esteso a tutto il sito...
Indice
- Fermi tutti, sto scaricando?! [Aggiornato]
- Perché con Mozilla il sito di Roam si vede così male?
- La soluzione
- Il vero problema
- Di peggio, di più
- In summa
- Perché con Mozilla il sito di Roam si vede così male? (2)
- Perché con Mozilla il sito di Roam si vede così male? (3)
- Perché con Mozilla il sito di Roam si vede così male? (4)
- Perché con Mozilla il sito di Roam si vede così male? (5) [Aggiornata]
- Perché con Mozilla il sito di Roam si vede così male? (6)
- Bibliografia & Link
- Copyright e Licenza
Fermi tutti, sto scaricando?! [Aggiornato]
Questo problema, notissimo in ambiente Mac, per cui se si lascia come ultima finestra aperta una finestra di download non si può fare altro finché questo non sia terminato, è stato risolto con
Mozilla 1.6, ma pochi ancora lo sanno. La soluzione è stata quella di lasciare sempre un'altra finestra aperta, fuori schermo, in modo che anche chiudendole tutte, resti sempre aperta. Con questo sistema,
ovviamente, anche la finestra di download non è l'unica aperta, e quindi il problema è risolto.
Il problema è che la finistra fuori schermo non è accessibile (eh, è fuori
schermo!), ed allora?!
Allora in questo ci aiuta il Mac OS X. Infatti, dovreste sapere ormai, è possibile navigare tra le finestre aperte di ogni applicazione con una combinazione di tasti, più esattamente MELA e > per la prossima o
< per la precedente. Se vi si dovesse presentare il problema della finistra di download, date una volta la combinazione (ovvero spostate il focus sulla finestra fuori schermo) e potete fare quello che
volete.
Per vedere la finestra invisibile, usate Exposé (ovvero il tasto F9) del Mac OS X. Oppure la vedete qui sotto:
ATTENZIONE: il problema è stato reintrodotto con Mozilla 1.7.5. Incredibile...
Perché con Mozilla il sito di Roam si vede così male?
Molti ce lo hanno chiesto, ma ora il problema non esiste più e dalla versione 1.2.x è stato definitivamente legato all'almost standards mode di cui alla (2). Per sapere quale fosse il problema di visualizzazione, riportiamo questa immagine...
La Soluzione
Coloro che non volessero sapere perché il problema si presenta, quale componente affligga e come si risolve, sappiano che la soluzione è mettere in CSS la seguente riga:
img { display: block;
}
che forza Mozilla a comportarsi da bravo mostriciattolo.
Il Vero Problema
Quondam, ah hunc locum perventum est... (c) Ora che ci siamo liberati degli sbrigativi, affrontiamo l'argomento partendo dal nocciolo: quale è il problema?
Voi direte, eh che lo hai
detto cento volte, c'è pure la foto...
Nossignore, io vi ho descritto il sintomo e non la malattia. La malattia è il rendering delle immagini nel motore di Mozilla. Il team di sviluppo di
Mozilla, ha reimplementato tutto il motore di rendering (il famoso Gecko), secondo le specifiche W3C.
Qui sorge il problema (ma dovrei dire I problemi...). Stando
infatti a quanto riportato dal responsabile per lo sviluppo del componente, come da mia richiesta http://bugzilla.mozilla.org/show_bug.cgi?id=156244, duplicata (secondo loro) di http://bugzilla.mozilla.org/show_bug.cgi?id=22774 e http://bugzilla.mozilla.org/show_bug.cgi?id=35666, questo modo
di visualizzare è una feature e non un BUG. Infatti, http://bugzilla.mozilla.org/show_bug.cgi?id=153032 si noterà che il
modo in cui si è DECISO di implementare il componente che cura in generale il rendering dello SPACE-AFTER, interpreta la lacuna nelle specifiche W3C come la necessità di prevedere e
provvedere di uno spazio di una "certa dimensione" un oggetto.
Un signorinello del team di sviluppo, a cavallo delle varie pagine che vi ho riportato, dice perfino che il problema si presenta con le immagini
piccole e non con quelle grandi.
Altri oltre me considerano:
- La feature un BUG (leggi almeno la e-Mail di un dipendente
.edu nel thread)
- L'interpretazione dello staff almeno discutibile.
Sulla seconda, almeno, non c'è dubbio: se una interpretazione porta ad una implementazione che disegna lo stesso oggetto diversamente a seconda delle sue dimensioni, deve aver pur qualche problema. e
stando che questo assunto (diverso comportamento per diverse dimensioni) è stato ammesso da uno dei responsabili dello sviluppo, addirittura come ascusante (di cosa, poi?!), io continuo a propendere per il
BUG.
Di Peggio Di Più
La soluzione ha un che di fascinoso.
img { display: block; }
Se infatti stiamo alle specifiche W3C dell'HTML (lasciate stare la versione
è un assunto assiomatico del linguaggio), gli elementi di una pagina HTML sono di DUE tipi: inline e block-level. La definizione, incredibilmente, è estremamente semplice:
- Inline - di oggetto che non ha spazio intorno a se
- Block - di oggetto che ha uno spazio sopra ed uno spazio sotto, a capo nel caso di testo.
Pensate, il problema dello spazio arbitrario dopo le immagini, si risolve forzando da CSS la visualizzazione delle immagini come elementi a blocco!
In Summa
Non vorrei dare una falsa idea della questione che ho sollevato qui e presso i Mozilli, ma devo dire che la soluzione (chiamatela pure "workaround"), NON è venuta dallo staff, ma da un qualcuno che
evidentemente deve averci sbroccato dei mesi come me, e deve essersi farcito i CSS di tutto combinato con tutto e permutato in tutti i modi, prima di giungere ad una soluzione cosi'.... assurda. Dal lato Staff, non
solo nessuno, dico nessuno, malgrado i duplicati noti o sospetti dello stesso BUG, si è scomodato a riportare la soluzione, ma addirittura ci si è limitati a stigmatizzare l'uso di table per formattare
le pagine, l'uso disinvolto dei COMMENTI, ed a ribadire (ciò che è più grave) che la loro implementazione RISPETTAVA (quando in realta' INTERPRETAVA) le specifiche e quindi noialtri imparassimo a
fare siti web.
Certo, non c'è dubbio che a chi fa quel che fa per passatempo nulla si possa rimporoverare, ma certo pure che con la spocchia lontano non si va.
 Perché con Mozilla il sito di Roam si vede così male? (2)
Questo problema di visualizzazione di Mozilla è era in fase di indagine da parte nostra, per escludere nostri errori prima di ricorrere a Bugzilla. Confermato ed eliminato con Mozilla 1.0.1.
Perché con Mozilla il sito di Roam si vede così male? (3)
Questo problema di visualizzazione di Mozilla compare se innalzate la versione da 1.0 a 1.1 e si risolve cancellando tutti i .rdf in User/Library/Mozilla/Nome_Utente e quindi reimpostando le
preferenze che purtroppo questa cancellazione vi fa perdere.
Perché con Mozilla il sito di Roam si vede così male? (4)
Questo problema di visualizzazione di Mozilla viene REINTRODOTTO nella 1.1 e NON si risolve. La 1.2 ne sembra immune. In breve il motore di rendering dei frames, con il solito arbitrio prorpio dei creatori di
Mozilla, stabilisce lo spessore dei frames PRIMA di disegnarli, dunque al livello del tag <FRAMESET>; siccome l'attributo BORDER del CSS entra in azione solo nel tag
<FRAME>, interno a <FRAMESET>, ovviamente, ed infine siccome il CSS non può operare l'override sul codice ma solo sulle definizioni di default, ne segue che i frame
vengono disegnati con il bordo anche se non lo volete.
Soluzioni? una sola: perdere la compatibilità e la validazione W3C dell'HTML 4.01 e ricorrere allo stratagemma di aggiungere BORDER="0"
nel <FRAMESET>. Tanto per cambiare il BUG è tristemente noto da 3 anni in Bugzilla e tanto per cambiare i responsabili del component considerano una cazzata perdere la compatibilità
verso gli standard. Bravi ragazzi e volenterosi, percarità, ma talvolta d'una ottusità più unica che rara...
 Perché con Mozilla il sito di Roam si vede così male? (5) [Aggiornata]
Questo problema di visualizzazione di Mozilla peril quale le form di Commenti e consigli escono dai bordi di destra del riquadro che le contiene è un nostro errore. Ad oggi le pagine del Roam sono
statiche, e quindi dovremmo cambiarle una ad una. Ce ne scusiamo.
Da bravi programmatori, notiamo due cose:
Primo la pagina è mal formata esteticamente ma perfettamente lecita dal punto di vista
dell'HTML, uno dei problemi della validazione automatica, ovvero quello che è formalmente corretto non sempre lo si dimostra praticamente.
Secondo, sapete che da tempo stiamo lavorando per portare il
contentuto del sito in un database.
Essendo detta importazione ancora lungi dall'essere fattibile con le caratteristiche che vorremmo darle, abiiamo due soluzioni:
La prima consiste nell'aspettare che
l'importazione vada a buon fine, applicare il nuovo modello di form che oltre ad essere validoquanto a codice HTML, è anche corretto esteticamente; e più leggero in termini di rendering e scaricamento
della pagina.
Due, potremmo usare una espressione regolare Perl attraverso BBEdit, per applicare le modifiche in batch a tutto il sito.
Ora, la prima ipotesi, richiederebbe che qualche volenteroso programmatore
4Dimension mi dia una mano a terminare la gestione delle pagine del sito. La seconda che un volenteroso utente di BBEdit mi aiuti a scrivere l'espressione che mi consenta il trova e e sostituisci in argomento.
Ah,
c'è anche la terza, ovvero aspettare pazientemente che lo faccia io. E lo farò, fosse...
 Perché con Mozilla il sito di Roam si vede così male? (6)
Questo problema di visualizzazione di Mozilla per il quale le celle di tabella assumono una dimensione minore di quella dichiarata, viene INTRODOTTO nella 1.5 e NON si risolve se non aspettando una versione che non
lo presenti. Viene evitato dando un Reload sulla pagina o sul frame che lo presenta, od eliminando il FRAMESET e visualizzando solo la pagina interessata. Ho provveduto ad informarne il team di sviluppo
: [BUG 225300]
Lo stesso problema genera questa visualizzazione in homepage:
Bibliografia & Link
- W3C World wide Web Consortium (EN)
- Netscape DevEDGE: Gecko "almost standards" Mode(US)
- Mozilla Developer: DOCTYPE sniffing (EN)
- [BUG 225300] [Mac OS X & Mozilla 1.5] - Table cells rendered with unpredicted results if in a FRAMESET (EN)
- Mozilla.org Customizing Mozilla (EN)
|
