Forum libero

- Scritto da: Daisuke Niwa
> Il Width funziona.
>
> Prova 1:
>
>
> Prova 2 (con un width maggiore):
>
>
> Come Prova 2 ma con Firebug che mostra il box
> dell'INPUT di tipo
> FILE:
>
>
> Il width dunque riguarda l'intero oggetto.

sì l'ho notato da tempo anche io

> Tuttavia, ciò che non è possibile specificare, è
> il width dei componenti INTERNI. In particolare
> del pulsante e dell'input testuale. Per questo
> non esiste alcuna specifica CSS che dica come si
> può accedere alle componenti
> interne.
> Firefox quindi non ignora il width del componente
> in sé, ma non sa come regolare le dimensioni dei
> componenti interni perché nessuno glie l'ha detto
> e non è possibile dirglielo perché non esiste
> alcun comando CSS per
> farlo.
>
> È per esempio possibile allineare il contenuto a
> destra, sinistra e centro con text-align, è
> persino possibile allargarlo modificando il
> letter-spacing... ma non potendo riferirsi ai
> singoli elementi interni che compongono l'INPUT
> di tipo FILE non è possibile stilarli
> direttamente.
>
> Se si segue il discorso su bugzilla si vede che
> semplicemente non si sa come procedere. Il CSS
> non ne parla, il W3 non dice che fare, d'altra
> parte non si vuole introdurre concetti che poi
> risultino sbagliati quando il W3 prenderà una
> posizione in
> merito.
>
> La soluzione migliore probabilmente è quella di
> sostituire completamente l'elemento di tipo FILE
> con
> questo
> [img]http://www.w3.org/TR/xforms/images/ui-upload.
> generalizzato però a tutti i tipi di file.
>
> In questo modo si evita di dover parlare di
> componenti interne agli oggetti base HTML visto
> che, probabilmente (non mi vengono in mente altri
> componenti simili), l'INPUT di tipo FILE è
> l'unico componente che, per ragioni storiche, è
> un componente composto e forse non si vuole
> inventarsi uno standard solo per
> questo.

uno a caso: select

visto che sei così informato, ti è arrivato alle orecchie qualcosa riguardo a bug del elect in html5?

> In questo modo si evita di dover parlare di
> componenti interne agli oggetti base HTML

E allora non parliamone.
Consideriamolo un unico oggetto.
A me sembra una questione di lana caprina, specie visto che...

> visto
> che, probabilmente (non mi vengono in mente altri
> componenti simili), l'INPUT di tipo FILE è
> l'unico componente che, per ragioni storiche, è
> un componente composto e forse non si vuole
> inventarsi uno standard solo per
> questo.

...e` l'unico del suo genere.
Che ci vuole a estenderlo o ridurlo graficamente fino a coprire le dimensioni specificate, come fanno molti altri poveri browser che sono partiti dalle stesse considerazioni e dalle stesse specifiche?

Appunto, "che ci vuole": dopo tutto 'sto battibecco in termini molto astratti, permango dell'opinione che all'atto pratico le difficolta` di firefox nel cambiare l'aspetto dei gadgets della UI sono dovute alla sua impostazione generale che aveva deciso a suo tempo, e che a tutt'oggi continua a decidere, di ereditare dal sistema ospite. Una scelta tutto sommato conveniente, che hanno fatto anche altri, comoda sia per gli sviluppatori che per gli utenti, ma controproducente quando si tratta di intervenire sui gadgets. Firefox non e` in grado, e nessuno ha voglia di renderlo in grado perche` non lo considera importante, di applicare informazioni di stile ai gadgets dell'interfaccia. Non sono "suoi" e ne ha un controllo limitato, specialmente sull'aspetto visivo. Opera ha una soluzione diversa: implementa i suoi, li skinna come gli pare, per default in base al tema grafico applicato al browser, e poi perfino permettendone la gestione via CSS di quasi tutti gli aspetti (un'eccezione qui per esempio e` il text-shadow applicato a uno string gadget, cioe` a quello che l'HTML chiama un input di tipo text; evidentemente neanche Opera ci riesce, pazienza, ma almeno si e` impegnato decisamente di piu`).

Niente di grave, ma se cosi` fosse, tutti questi discorsi sulla natura composta di questi selettori di file sono scuse: supercazzole prematurate come se fosse antani composto per due.

Se cosi` non fosse, per il caso delle checkbox come si giustificherebbero? Quelle non sono composte, sono una bella scatolina di tot x tot pixels. Quella con cui si scontra firefox (e anche altri si sono scontrati prima di lui, eccetto che poi in tutto o in parte ne sono usciti un po' meglio) e` una difficolta` puramente tecnica, non teorica, che nessuno ha avuto voglia di risolvere neanche nell'arco di 11 anni.

E` una mancanza del browser, non un errore dello standard, al quale posso riconoscere la vaghezza nel non distinguere i due componenti del selettore di file o la promiscuita` in cui trattava l'interpretazione dell'attributo "size". Ma nonostante questi problemi, coi quali anche gli altri motori di rendering si sono confrontati, i gadgets della UI quando diventano elementi della pagina, come tali dovrebbero essere trattati, e quindi resi graficamente coerenti alle indicazioni del foglio di stile.

La questione e` vecchia e stantia, si riallaccia al discorso sulla colorazione delle scrollbars che a suo tempo era stata cassata sostenendo che non facevano parte della pagina. Dal versante HTML+CSS questo e` vero, perche` la scrollbar non esiste come elemento, e` solo un accessorio automaticamente chiamato in causa da determinate circostanze che richiedono di scorrere i contenuti in un modo attualmente molto diffuso. Ma per quanto vero, io ci vedo solo la prima di una lunga arrampicata sugli specchi. Alla fine, comunque, la classificazione del "bug" #52500 e` onesta: e` considerato "poco importante" e basta. Non ne vale la pena? Perfetto, basta saperlo una volta per tutte e con sincerita`.