Discussioni MediaWiki:Common.css

Prime segnalazioni

Ho modificato la classe preftoc commentando l'ultima riga

#preftoc {
   float: left;
   margin: 1em 1em 1em 1em;
   width: 13em;
}

perché le linguette delle preferenze si incolonnavano tutte a sinistra secondo la disposizione di MediaWiki standard, mentre da noi vanno a scorrere in alto perché la casella con le preferenze vere e proprie occupa tutta la larghezza della pagina.

Ci sono ancora delle cose da sistemare, come la differente altezza delle linguette selezionate. In altri progetti (ad es. it.Wikiquote) hanno eliminato direttamente tutta la sezione, per cui forse possiamo farlo anche noi.

--Lp ↤ 15:48, 6 apr 2006 (CEST)

---

• Aggiunta la classe allpagesredirect (redirect in corsivo su "tutte le voci"):

/* Makes redirects appear in italics on Special:Allpages */
.allpagesredirect {
    font-style: italic;
}

• Modificato il colore del bordo delle linguette delle preferenze, da verificare perché quella selezionata "scende"
• Corretto un refuso

--Lp 20:50, 23 apr 2006 (CEST)

---

Aggiunto un blocco di stili per la gestone di Wikipedia:CommonsTicker. Per la sperimentazione sono stati copiati da de.wiki, invito a valutare modifiche e miglioramenti nella relativa discussione. --Lp ↤ 16:32, 31 mag 2006 (CEST)

Richieste

qualcuno può per favore aggiungere il testo seguente?

/* make the list of references look smaller */
ol.references {
   font-size: 100%;
}

.references-small { font-size: 90%;}

Mi è stato suggerito qui. Grazie! --Daĉjo^почта 20:59, 6 dic 2006 (CET)

Fatto, vediamo che effetto fa, se crea problemi torniamo pure indietro. --Lp ↤ 21:32, 6 dic 2006 (CET)

Special:Preferences

Ho visto un po' di roba che credo riguardi Special:Preferences nel common.css (e non ho trovato niente nel monobook.css). Solo io (Safari) vedo una schifezza nel tab "Ricerca" delle preferenze? --.anaconda 22:29, 22 gen 2007 (CET)

Per la cronaca, si parla di questa. --.anaconda 05:34, 29 mar 2007 (CEST)

Ho fatto sparire tutte le personalizzazioni relative alle preferenze, che mascheravano le modifiche più recenti alla pagina e creavano qualche problema agli utenti Safari. Grazie per la segnalazione, mi spiace di non essere stati più tempestivi. Se ci sono effetti collaterali, segnalateli pure qui. --Lp ↤ 15:34, 8 mag 2007 (CEST)

aggiunta classe audiolink

Ho aggiunto la classe audiolink per fare i link con l'altoparlantino copiandola da en.wiki. Prossimamento vedrò anche di renderla non stampabile (e di spostare qui la sezione relativa al non print). Gvf 12:40, 11 mar 2007 (CET)

aggiungere classi Geo

Ho proposto di aggiungere le classi Geo in questa discussione Wikipedia:Bar/Discussioni/Uso massivo del template coord e fratelli. Per dettagli tecnici si può guardare en:Geo (microformat), en:MediaWiki_talk:Common.css#Geo-related classes--wiso 18:56, 16 apr 2007 (CEST)

Ma perché quel template ha bisogno di classi "speciali"? --ChemicalBit - scrivimi 17:56, 22 apr 2007 (CEST)

Per impostare un output di default per tutti, che così risulta personalizzabile. --wiso 18:40, 22 apr 2007 (CEST)

Classi per template sinottici

Ho aggiunto una serie di classi che dovrebbero servire per rendere un po' più omogenei e personalizzabili i template sinottici. Appena concluse le prove prometto di scrivere un po' di documentazione. Gvf 23:53, 22 ago 2007 (CEST)

hiddenStructure

Anche se ad alcuni non piacciono, sono abbondantemente usate nei template. Le ho copiate qui per correggere la visualizzazione con gli skin diversi da monobook.css. Gvf 13:50, 17 set 2007 (CEST)

Form per cancellazione trasparente

Ciao, ho notato che quando si cancella negli altri namespace il box del motivo della cancellazione ha lo sfondo bianco, mentre lo sfondo del namespace rimane di un altro colore. Esempio del problema: [1]. Ho trovato il modo di rimediare a ciò:

#deleteconfirm, #deleteconfirm>table {
    background: transparent;
}

L'ho testato sul mio monobook.css e va. Posso inserire il codice nel CSS generale? --Pietrodn · «zitto e parla!» 21:10, 30 nov 2007 (CET)

Nessuno mi ha risposto... vabbè, ho inserito il codice. --Pietrodn · «zitto e parla!» 17:34, 5 mar 2008 (CET)

Cassetti

Questa modifica corregge l'errore segnalato qui. --Nemo 11:38, 3 ago 2008 (CEST)

importo classi ca common.css di en.wiki

Sto importando alcune classi en:MediaWiki:Common.css al fine di correggere il comportamento di alcuni template importati senza curarsi delle classi utilizzate. Gvf 13:02, 25 nov 2008 (CET)

Sinottici

In template:Libro hanno osservato che viene un po' stretto. In effetti ho controllato alcuni sinottici comuni che non usano ancora la classe (template:Film, template:Comune, template:Stato...) e sono tutti un po' più larghi. Ok a aumentare un po' la larghezza? --Bultro (m) 01:29, 25 feb 2009 (CET)

Padding di wikitable e prettytable

Ora è:

table.wikitable th, table.wikitable td,
table.prettytable th, table.prettytable td {
  border: 1px #aaa solid;
  padding: 0.2em;
}

Non si potrebbe cambiare in:

  padding: 0.2em 0.5em;

??? al fine di evitare il ricorso a   per spaziare tra testo e bordo.
-- Codicorumus  « msg 12:11, 26 ago 2009 (CEST)

Allineamento per colonne nelle tabelle

Sulla falsariga del sistema adoperato per alternare il colore di background nelle talk in fr:wiki, si potrebbero usare delle classi per allineare il testo per colonne, evitando di dover inserire il codice di allineamento in ogni cella.
Nel cassetto, un esempio di codice che funziona per le prime 9 colonne.

Regole CSS per l'allineamento delle colonne

/*********************************************************
 **  Classi per l'allineamento del testo nelle tabelle  **
 **      - consentono l'allineamento per colonne -      **
 *********************************************************
*/

table.col-1-align-left tr td:first-child,
table.col-2-align-left tr td:first-child + td,
table.col-3-align-left tr td:first-child + td + td,
table.col-4-align-left tr td:first-child + td + td + td,
table.col-5-align-left tr td:first-child + td + td + td + td,
table.col-6-align-left tr td:first-child + td + td + td + td + td,
table.col-7-align-left tr td:first-child + td + td + td + td + td + td,
table.col-8-align-left tr td:first-child + td + td + td + td + td + td + td,
table.col-9-align-left tr td:first-child + td + td + td + td + td + td + td + td
{ text-align: left; }

table.col-1-align-right tr td:first-child,
table.col-2-align-right tr td:first-child + td,
table.col-3-align-right tr td:first-child + td + td,
table.col-4-align-right tr td:first-child + td + td + td,
table.col-5-align-right tr td:first-child + td + td + td + td,
table.col-6-align-right tr td:first-child + td + td + td + td + td,
table.col-7-align-right tr td:first-child + td + td + td + td + td + td,
table.col-8-align-right tr td:first-child + td + td + td + td + td + td + td,
table.col-9-align-right tr td:first-child + td + td + td + td + td + td + td + td
{ text-align: right; }

table.col-1-align-center tr td:first-child,
table.col-2-align-center tr td:first-child + td,
table.col-3-align-center tr td:first-child + td + td,
table.col-4-align-center tr td:first-child + td + td + td,
table.col-5-align-center tr td:first-child + td + td + td + td,
table.col-6-align-center tr td:first-child + td + td + td + td + td,
table.col-7-align-center tr td:first-child + td + td + td + td + td + td,
table.col-8-align-center tr td:first-child + td + td + td + td + td + td + td,
table.col-9-align-center tr td:first-child + td + td + td + td + td + td + td + td
{ text-align: center; }

table.col-1-align-justify tr td:first-child,
table.col-2-align-justify tr td:first-child + td,
table.col-3-align-justify tr td:first-child + td + td,
table.col-4-align-justify tr td:first-child + td + td + td,
table.col-5-align-justify tr td:first-child + td + td + td + td,
table.col-6-align-justify tr td:first-child + td + td + td + td + td,
table.col-7-align-justify tr td:first-child + td + td + td + td + td + td,
table.col-8-align-justify tr td:first-child + td + td + td + td + td + td + td,
table.col-9-align-justify tr td:first-child + td + td + td + td + td + td + td + td
{ text-align: justify; }

-- Codicorumus  « msg 12:40, 26 ago 2009 (CEST)

A me vanno bene, ma preferisco lasciare un messaggio anche a Gvf, più esperto riguardo al common.css Jalo 20:36, 2 set 2009 (CEST)

@Codicorumus: saresti così gentile da mettere un'esempio di utilizzo delle classi che proponi? Gvf 22:49, 2 set 2009 (CEST)

Ho messo due esempi nel cassetto qui sotto.

Esempio di tabelle allineate tramite classi

Questa sotto è la prima tabella che ho trovato cercando align=center, viene da Serie A 2006-2007#Classifica finale (ho preso solo le prime sei righe, tolta la centratura ed eliminati i ref).

		Classifica finale 2006-2007	Pt	G	V	N	P	GF	GS
15px	1.	Inter	97	38	30	7	1	80	34
15px	2.	Roma	75	38	22	9	7	74	34
15px	3.	Lazio	62	38	18	11	9	59	33
15px	4.	Milan	61	38	19	12	7	57	36
13px	5.	Palermo	58	38	16	10	12	58	51
13px	6.	Fiorentina	58	38	21	10	7	62	31

Questa sotto, come sarebbe con le classi di allineamento.

		Classifica finale 2006-2007	Pt	G	V	N	P	GF	GS
15px	1.	Inter	97	38	30	7	1	80	34
15px	2.	Roma	75	38	22	9	7	74	34
15px	3.	Lazio	62	38	18	11	9	59	33
15px	4.	Milan	61	38	19	12	7	57	36
13px	5.	Palermo	58	38	16	10	12	58	51
13px	6.	Fiorentina	58	38	21	10	7	62	31

Avendo le regole attivate, io le vedo uguali. Ho eliminato uno style="text-align:left;"| da ogni riga, rendendo la tabella più breve e più leggibile. Ho eliminato anche gli align=center di riga (che erano comunque eliminabili), per evidenziare il meccanismo di assegnazione dell'allineamento principale nello style="..." e degli allineamenti minoritari in class="...".
Ovviamente il beneficio è tanto maggiore quante più sono le colonne che si differenziano dall'allineamento principale.
Tra l'altro, questo meccanismo renderebbe molto più agevole il ricorso all'allineamento anche per chi sia meno versato nell'uso di markup complesso.

Qui sotto, il caso più tipico (testo a sinistra e numeri a destra), tratto da Città sudafricane#Elenco di città; ho estrapolato le prime 4 righe e tolto un ref.

Città del Sudafrica

	Città	Numero di abitanti				Provincia
		Dati 1991	Dati 1996	Stima 2005	Stima 2009
1.	Città del Capo	1.891.092	2.415.408	3.433.441	3.569.359	Capo Occidentale
2.	Durban	1.764.605	2.117.700	3.120.282	3.409.081	KwaZulu-Natal
3.	Johannesburg	-	1.480.530	2.026.469	2.023.456	Gauteng
4.	Soweto	885.421	1.098.094	1.695.047	1.755.247	Gauteng

Che diventa:

Città del Sudafrica

	Città	Numero di abitanti				Provincia
		Dati 1991	Dati 1996	Stima 2005	Stima 2009
1.	Città del Capo	1.891.092	2.415.408	3.433.441	3.569.359	Capo Occidentale
2.	Durban	1.764.605	2.117.700	3.120.282	3.409.081	KwaZulu-Natal
3.	Johannesburg	-	1.480.530	2.026.469	2.023.456	Gauteng
4.	Soweto	885.421	1.098.094	1.695.047	1.755.247	Gauteng

Ho eliminato 4 align="right" | per riga, anche se una formattazione più efficiente avrebbe avuto solo due align="left" | . Il template {{Prettytable}} non è compatibile (o sovrascrive class o viceversa), al limite vi si potrebbe forse integrare il supporto di queste classi. Nota la colonna "Stima 2009" non allineata nell'originale, probabilmente per la difficoltà di inserire il codice.

-- Codicorumus  « msg 14:57, 3 set 2009 (CEST)

Il template Prettytable sarebbe da evitare preferendo l'uso delle classi. Relativamente alle classi proposte, vedrò di darci un occhiata appena ho un po' di tempo. Gvf 20:41, 8 set 2009 (CEST)

Fai pure con comodo, la proposta (come quella che la precede) non appartiene certo al dominio delle urgenze :) -- Codicorumus  « msg 01:07, 10 set 2009 (CEST)

Icona puzzle

Sulla pagina principale non appare più l'icona del puzzle perché è stata cancellata su it.wiki. È necessario quindi ripristinarla o modificare il CSS per puntare all'indirizzo dell'immagine su Commons. --Incola (posta) 12:24, 5 feb 2010 (CET)

Ripristinata, grazie. --.anaconda (msg) 12:54, 5 feb 2010 (CET)

Margine esterno per tright e tleft

Segnalo Aiuto:Sportello informazioni#Allineamento foto, dove c'è stata la richiesta di azzerare il margine esterno. -- Codicorumus  « msg 20:09, 15 feb 2010 (CET)

Fatto vd.

--M/ 22:53, 10 mar 2010 (CET)

Rimozioni righe inutili nel CSS

Ci sarebbero da rimuovere le seguenti righe dal css:

/* immagine di sfondo nei template Album, Canzone e Gruppo */
.intestazionemusica {
  background: url('http://upload.wikimedia.org/wikipedia/commons/e/ee/Picto_infobox_music_long.png') no-repeat top right
}

perché in seguito a questa discussione (linkata anche al Bar) si è deciso di non utilizzare la classe intestazionemusica nel template {{Artista musicale}} (che era l'unico che la utilizzava), quindi dopo aver modificato il template quelle righe di CSS sono superflue. --Una giornata uggiosa '94 · E poi, di che parliamo? 23:15, 14 mag 2010 (CEST)

Fatto vd.

--M/ 23:21, 14 mag 2010 (CEST)

Vector

(segnalo anche qui) Linko questa discussione al Bar: dato che la skin Vector tra non molto verrà impostata come skin di default anche qui su it.wiki, bisognerebbe importare i CSS e javascript del Monobook nelle pagine Mediawiki:Vector.css e Mediawiki:Vector.js, facendo magari le opportune correzioni dovute alle differenze tra le skin. Qualcuno se ne occupa? --Una giornata uggiosa '94 · E poi, di che parliamo? 22:26, 15 mag 2010 (CEST)

Wikipedia:Bar/Discussioni/Perché non funziona?

Tratto da WP:RA:
Potreste gentilmente modificare MediaWiki:Common.css aggiungendo il codice nella pagina linkata? Grazie, --★ → Airon Ĉ 17:27, 6 ago 2010 (CEST)

Fatto da Superchilum --★ → Airon Ĉ 11:44, 7 ago 2010 (CEST)

Navbox

Segnalo questa discussione in cui si chiede di modificare il CSS. --Martin Mystère 6.0 ^(msg) 12:16, 24 ago 2010 (CEST)

Il consenso mi pare tutt'altro che definito. --Brownout^(msg) 12:23, 24 ago 2010 (CEST)

Aspettiamo pure ancora un po', ma mi pare che nessuno abbia espresso pareri negativi. --Martin Mystère 6.0 ^(msg) 15:36, 24 ago 2010 (CEST)

Ora c'è il consenso. Procediamo? --Martin Mystère 6.0 ^(msg) 17:59, 26 ago 2010 (CEST)

Qualcuno potrebbe inserire il codice CSS presente in questa discussione? --Martin Mystère ^(msg) 10:46, 1 set 2010 (CEST)

Se copi qui il codice da inserire faccio io Jalo 10:58, 1 set 2010 (CEST)

Ecco a te:

table.navbox + table.navbox {  /* Single pixel border between adjacent navboxes */
  margin-top: -1px;            /* (doesn't work for IE6, but that's okay) */
}

Grazie --Martin Mystère ^(msg) 12:48, 1 set 2010 (CEST)

Vedo che esiste già, nella sezione "classi legate al template navbox generic" Jalo 13:01, 1 set 2010 (CEST)

L'ha messo Gvf, ma mi pare che non funzioni. --Martin Mystère ^(msg) 13:07, 1 set 2010 (CEST)

Allora probabilmente, essendo una copia sputata, non funzionerebbe neanche questo. Non è che hai un css personalizzato che modificava quest'impostazione? Jalo 15:17, 1 set 2010 (CEST)

Su en.wiki tutti navbox si traducono in HTML con "table" di classe "navbox", per questo gli funziona la regola. Da noi sono dinamici. In Dida sono di classe "navbox collapsible autocollapse nowraplinks noprint", in Unione europea sono di classe "navbox collapsible collapsed nowraplinks noprint", ecc.

Quando si chiede una modifica ad una pagina così importante come il monobook condiviso, il codice dovrebbe essere ben testato. Guardando la discussione mi sembrava di averlo visto funzionare, e invece era tutta una fregatura Jalo 15:34, 1 set 2010 (CEST)

Comunque non dovrebbe venire così, questa era una proposta che non è stata accettata, ma così. Cosa si può fare per farlo funzionare? --Martin Mystère ^(msg) 15:54, 1 set 2010 (CEST)

Riorganizzare tutte le classi navbox del nostro monobook. Non so perché le nostre siano diverse da quelle inglesi. Bisognerebbe chiedere a chi le ha inserite/modificiate Jalo 16:33, 1 set 2010 (CEST)

Questo è il codice nel template:

<table class="navbox collapsible {{{state|autocollapse}}} nowraplinks noprint" style="margin:auto; width:100%; clear:both; border: 1px solid #aaa; padding: 2px; {{{style|}}}{{{bodystyle|}}}">

A parte i due parametri per gli stili opzionali e il padding: 2px;, il resto di style è una replica di quanto impostato nel CSS dal selettore table.navbox. Se non c'è qualche motivo specifico per tenerli, gli elementi duplicati nel template andrebbero levati.
In particolare, margin:auto;, impostato come stile di elemento, ha la precedenza su quelli nel CSS e ne inibisce il funzionamento, bloccando anche margin-top: -1px;

-- Codicorumus  « msg 20:50, 1 set 2010 (CEST)

Ieri ho scritto un po' di fretta ed ho mancato di evidenziare che, quindi, Common.css è a posto, è sul template che bisogna agire. -- Codicorumus  « msg 16:40, 2 set 2010 (CEST)

Sfondo tabelle

Si potrebbe gentilmente rimuovere il codice:

/* table standards */
table {
    background-color:#FFFFFF;   /* bianco opaco, per evitare sovrapp. con le linee dei titoli di sezione */
}

Questo perché nelle preferenze fa apparire dei rettangoloni bianchi sullo sfondo grigio e ciò è antiestetico. Grazie! --Pietrodn · «Outlaw Pete» 19:20, 7 mar 2011 (CET)

Fatto Salvatore Ingala (conversami) 21:00, 7 mar 2011 (CET)

Fix all'aspetto delle gallery

Dato che l'aspetto grafico del <gallery> attualmente non è proprio il massimo, propongo di inserire nel Common.css queste due regole per rendere la sua grafica più pulita e leggera:

/* Gallery */
 
li.gallerybox div.thumb div { border: none; }
 
li.gallerybox div.thumb div img { border: none; }

Qui un confronto tra come è ora e come verrebbe se la modifica fosse implementata.

PS: mi sono accorto che con l'ultimo aggiornamento di Mediawiki le gallery non mostrano più un numero fisso di immagini per riga, ma adattano automaticamente tale numero alla larghezza della finestra. Aggiungiamo questi lacrimoni che sono lenzuola a quelli (di felicità) versati per la modifica alle categorie ;) --Una giornata uggiosa '94 · E poi, di che parliamo? 02:17, 4 apr 2011 (CEST)

Visto il tuo esempio non vedo motivo al mondo per non implementarlo --Larry Yuma (msg) 07:51, 4 apr 2011 (CEST)

Non ho capito perché si dovrebbero versare lacrimoni, la modifica mi pare migliorativa (maggiore flessibilità, in funzione della dimensione della finestra, la quale immagino dipenda anche dalla risoluzione dello schermo; quindi una migliore visualizzazione senza pretendere che l'utente veda in un certo modo).

Quanto alla modifica proposta, +1. --Archiegoodwinit (msg) 08:23, 4 apr 2011 (CEST)

• Favorevole --Vajotwo (posta) 12:46, 4 apr 2011 (CEST)

Anche a me piace la modifica proposta Jalo 13:20, 4 apr 2011 (CEST)

• Favorevole, anche se neanche a me vengono i lacrimoni :) --Tenebroso (msg) 14:10, 4 apr 2011 (CEST)

@Archiegoodwinit e Tenebroso: ero ironico, intendevo lacrimoni di felicità (o per la commozione), come qualcuno aveva già scritto in quest'altra occasione ;) --Una giornata uggiosa '94 · E poi, di che parliamo? 14:37, 4 apr 2011 (CEST)

Non so Archiegoodwinit, ma anch'io ero ironico se non te ne sei accorto.--Tenebroso (msg) 15:01, 4 apr 2011 (CEST)

• Favorevole. Ci pensavo da molto tempo. --Martin Mystère ^(msg) 14:55, 4 apr 2011 (CEST)

Fatto, fermiamo questo tsunami di approvazioni :) Salvatore Ingala (conversami) 16:27, 4 apr 2011 (CEST)

Segnalo questo scissionista: Utente:Lepido/sandbox/4. :P --Pequod (talk76) 10:53, 5 apr 2011 (CEST)

Ti riferisci al template {{Gallery}}? Lo noto solo ora, e credo che dopo questo aggiornamento a Mediawiki non sia più necessario, parliamone di là. --Una giornata uggiosa '94 · E poi, di che parliamo? 21:37, 5 apr 2011 (CEST)

• Commento su che browser/os è stato fatto il test? chiedo perché magari l'aspetto orribile dei bordi si nota solamente in determinati ambienti (dato che io non vedo le gallerie come in quell'immagine) --valepert 21:46, 5 apr 2011 (CEST)

Lo screenshot è stato fatto con Firefox 4 su Win XP. Devo essere sincero, non ho fatto test particolari perché lo davo per scontato, ma mi sembra di ricordare abbastanza bene che prima dell'implementazione si vedeva lo stesso effetto anche su e su Chrome (sicuramente), Opera e IE8 (ma di questi ultimi mi ricordo meno bene). Con "non vedo le gallerie come in quell'immagine" intendi adesso (cioè dopo la modifica, il che sarebbe normale) o intendi anche prima? --Una giornata uggiosa '94 · E poi, di che parliamo? 23:38, 5 apr 2011 (CEST)

Wikitables contenenti tabelle non wikitable

Segnalo discussione. --LoStrangolatore dimmi 02:46, 4 giu 2011 (CEST)

Modifica alla pagina di confronto delle revisioni

La discussione seguente è chiusa e può essere archiviata: Discussione superata dall'introduzione di MediaWiki 1.20, vedi sotto

---

Dato che il design della pagina del confronto delle revisioni (diff) mi sembra decisamente poco adatto ed efficace nel facilitare il lavoro degli utenti, ho pensato di inserire nel mio CSS personale delle modifiche per rendere l'aspetto della pagina più user-friendly; ormai credo che queste modifiche siano sufficientemente mature e testate per poter essere usate come default, quindi vorrei sottoporle al giudizio della comunità.

L'aspetto cambia da così (attuale) a così (proposto). Riassumendo, le modifiche sono queste:

• Migliore leggibilità del testo: è stata aumentata la dimensione (per poter leggere anche senza aver bisogno di lenti d'ingrandimento) e il carattere è diventato di tipo monospace (lo stesso utilizzato per mostrare il wiki-codice anche quando si modifica una pagina; questo permette di individuare con maggiore facilità caratteri "piccoli" come virgole, punti, apostrofi, eccetera)
• Le parole modificate non sono più evidenziate in grassetto rosso, ma in grassetto nero con un colore di sfondo: questo rende più immediata l'individuazione delle parti del testo che sono cambiate (scovare modifiche come l'inserimento o la rimozione di una virgola, con il sistema attuale, è come trovare un ago in un pagliaio; la presenza di un colore di sfondo, invece, permette di trovarla anche con una rapida occhiata)
• I link "Differenza successiva" e "precedente" sono stati posizionati all'estrema sinistra/destra della pagina, mentre "Segna questa modifica come verificata" non è più sulla stessa riga ma va a capo; questo permette di andare avanti/indietro di più modifiche cliccando sempre sullo stesso punto, senza dover spostare il mouse o rischiare di cliccare per sbaglio un altro link. Per dargli una maggiore enfasi rispetto agli altri link, gli ho applicato una formattazione che richiama quella dei pulsanti nelle finestre di dialogo della skin Vector.

Questo è il codice che lo fa funzionare:

Codice andrebbe aggiornato con gli esiti della discussione e modificato per la compatibilità su tutti i browser

/* Diff */

table.diff { border-radius: 8px; -moz-border-radius: 8px; -webkit-border-radius: 8px; }

td.diff-lineno, td.diff-marker, td.diff-context, td.diff-deletedline, td.diff-addedline { font-family: monospace; font-size: 120% !important; }

td.diff-lineno { vertical-align: bottom; height: 60px }

.diffchange { padding: 2px 1px; color: black !important }

td.diff-deletedline .diffchange { background-color: #DFDF00; }

td.diff-addedline .diffchange { background-color: #00D96C; }

td.diff-context { color: #5F5F5F; }

div#mw-diff-otitle4 { text-align: left; line-height: 2.5em; }

div#mw-diff-ntitle4 { text-align: right; line-height: 2.5em; }

div#mw-diff-ntitle4 span.patrollink { display: block; text-align: center; }

a#differences-prevlink, a#differences-nextlink { color: #2779AA; border: 1px solid #A6A6A6; cursor: pointer; border-radius: 4px 4px 4px 4px; margin-right: 0px; padding: 5px; background-color: #DDDDDD; background-image: -moz-linear-gradient(top, #F2F2F2, #CFCFCF); background-image: -ms-linear-gradient(top, #F2F2F2, #CFCFCF); background-image: -o-linear-gradient(top, #F2F2F2, #CFCFCF); background-image: -webkit-gradient(linear, left top, left bottom, from(#F2F2F2), to(#CFCFCF));

--Una giornata uggiosa '94 · E poi, di che parliamo? 16:07, 20 nov 2011 (CET)

• Favorevole - Se passa, Lepido e i suoi occhiacci marci ti saranno debitori per l'eternità --Lepido (msg) 16:17, 20 nov 2011 (CET)

Se in questo modo si può vedere l'aggiunta di uno spazio allora sono Favorevole --Martin Mystère ^(msg) 16:18, 20 nov 2011 (CET)

Purtroppo lo spazio no: era una delle cose che volevo rendere possibili, ma mi sono reso conto che quando viene aggiunto o rimosso solo uno spazio, MediaWiki non gli applica classe "diffchange" che permette di evidenziarlo (attualmente con un colore rosso, nella mia proposta con uno sfondo); quindi, finché gli sviluppatori non risolveranno il problema, le aggiunte/rimozioni di spazi, nei diff, rimarranno "invisibili" :( --Una giornata uggiosa '94 · E poi, di che parliamo? 16:28, 20 nov 2011 (CET)

• Favorevole Decisamente meglio. --αStar msg 16:21, 20 nov 2011 (CET)
• Neutrale, a me non cambia molto. --Martin Mystère ^(msg) 16:34, 20 nov 2011 (CET)
• Commento: Suggerirei di aggiungere a table.diff anche il parametro white-space: pre; in modo da evidenziare di più se è stato modificato il numero degli spazi. Non ho provato, ma dovrebbe funzionare. --Lepido (msg) 16:51, 20 nov 2011 (CET)

  L'idea è buona; non risolve completamente il problema evidenziato da Martin Mystère (perché comunque gli spazi non vengono evidenziati), ma almeno ti accorgi se l'utente ha inserito/rimosso una grossa quantità di spazi, e poi è più fedele a come il codice è realmente. Però c'è un problema: i blocchi di testo non vanno più a capo e, se sono molto lunghi, compare una scrollbar orizzontale. Come si potrebbe risolvere? --Una giornata uggiosa '94 · E poi, di che parliamo? 17:19, 20 nov 2011 (CET)

  Intanto, per farlo vedere a tutti, l'effetto è questo dove mi sembra ben visibile lo spazio eliminato. Per le barre, non so, ma comunque avere tanti spazi consecutivi è una situazione anomala e così verrebbe ulteriormente segnalata. --Lepido (msg) 17:34, 20 nov 2011 (CET)

  Credo di aver trovato la soluzione: con white-space: pre-wrap; si salvano capra e cavoli. --Una giornata uggiosa '94 · E poi, di che parliamo? 19:39, 20 nov 2011 (CET)

• tendenzialmente Favorevole per via della migliore leggibilità, anche se preferirei che "differenza successiva" ecc. rimanessero al centro della pagina. Una domanda: dove finirebbe il tasto [rollback] per chi ce l'ha? --Mark91it's my world 16:53, 20 nov 2011 (CET)

A fianco di "blocca", leggermente spaziato: (Discussione | contributi | blocca)    [rollback] --Lepido (msg) 17:05, 20 nov 2011 (CET)

• Commento: eviterei di inserire l'aumento della dimensione del testo nel css globale. il problema del "font piccolo" è una caratteristica di Vector (già lamentata più volte al bar). aumentare indiscriminatamente il size del font nel "common" aumenterebbe la dimensione dei diff anche per tutte quelle skin in cui è correttamente impostato ad una dimensione "leggibile" (uno tra tutti, il caro vecchio monobook...). --valepert 17:25, 20 nov 2011 (CET)

  (conflittato) In pratica basterebbe inserire il cambio di dimensione (font-size: 120% !important;) in MediaWiki:Vector.css invece che in MediaWiki:Common.css, (ho visto che mettere il font al 100% sarebbe già sufficiente, forse come dice qui sotto LikeLifer, metterlo al 120% è troppo grande) --Lepido (msg) 18:24, 20 nov 2011 (CET)

  Veramente, anche con monobook io lo vedo con la stessa identica dimensione... Possibile che sia una questione di browser/OS? Io sono su Firefox 8 con Windows 7. --Una giornata uggiosa '94 · E poi, di che parliamo? 19:04, 20 nov 2011 (CET)

Cioè in quell'immagine, che dimensione hai settato? Non ho fatto un'analisi approfondita, ma credo che forse il font "monospace" appare di dimensione diversa del font standard, cioè anche se è piccolo come il font standard è più chiaro. --Lepido (msg) 19:15, 20 nov 2011 (CET)

Quell'immagine è come appare il diff con la skin monobook e i CSS di default (cioè senza nessuna delle modifiche proposte), e la dimensione del font mi sembra esattamente uguale a quella che si ha con Vector senza le modifiche proposte. Poi ho provato ad applicare le modifiche proposte, usando monobook, ed il risultato è questo: effettivamente risulta più grande rispetto a quando le modifiche si applicano a Vector. Vacci a capire qualcosa... :/ --Una giornata uggiosa '94 · E poi, di che parliamo? 19:36, 20 nov 2011 (CET)

Se ho capito bne la faccenda, è proprio quello che diceva Valepert: lo skin Vector ha comportato da qualche parte un rimpicciolimento dei font, che vale però soltanto per quello skin. Se tu ingrandisci globalmente i font (quindi in tutti gli skin) alla fine Vector andrà bene, ma gli altri avranno i caratteri troppo grandi. La soluzione è quello che io dicevo, cioè occorre ridimensionare il font solo nel css di Vector, mentre tutte le altre modifiche possono essere globali. --Lepido (msg) 20:14, 20 nov 2011 (CET)

Contrario ad ingrandire il testo, IMHO è leggibile anche così.

Favorevole ad evidenziare meglio le parti modificate.

Contrario a spostare agli estremi i link di navigazione. Favorevole però a mantenere il link per verificare una modifica su una nuova riga.

--LikeLifer (msg) 18:20, 20 nov 2011 (CET)

Beh, questo mi sembra tutt'altro che leggibile (e lo dico io che ho 17 anni, figuriamoci cosa potrebbe dire chi è più avanti con l'età!). Possibilmente Wikipedia dovrebbe poter essere usata al massimo delle sue possibilità da parte di tutti: se per qualcuno il testo è troppo piccolo questa cosa potrebbe costituire un serio ostacolo, mentre se per qualcuno è troppo grande no, al massimo gli occupa un po' di spazio in più. Le impostazioni generali, di default, dovrebbero essere quelle adatte per tutti gli utenti, di qualsiasi età o gusti; poi per personalizzare si possono usare i fogli di stile utente. Comunque la dimensione proposta mi sembra giusta anche perché che in questo modo il testo viene portato ad una grandezza pari a quella del resto della pagina (e mi sembra il minimo, considerando che nella pagina delle differenze tra le revisioni la parte più importante è proprio quella del confronto!)

Per quanto riguarda i link di navigazione, posizionarli a destra e a sinistra IMHO aiuta a far intuire all'utente a cosa servono (l'associazione sinistra = vai indietro e destra = vai avanti funziona sempre, e non vedo perché non sfruttarla). Ti assicuro che è tutta una questione di abitudine ;-) --Una giornata uggiosa '94 · E poi, di che parliamo? 19:04, 20 nov 2011 (CET)

Il testo deve essere più piccolo per forza, i diff sono il confronto tra 2 pagine affiancate, non puoi tenerle alla loro grandezza originale. Il testo così piccolo IMHO è leggibilissimo. Renderlo più grande farebbe diventare le pagine più lunghe e quindi più scomode. Posso però capire che qualcuno possa avere qualche difficoltà ma visto che non si è mai lamentato nessuno, almeno credo, se lo si deve ingrandire, lo si faccia di poco. Per quanto riguarda il posizionamento dei link di navigazione oltre a trovarli orribili con quella grafica, li trovo anche scomodi, così lontani dagli altri.--LikeLifer (msg) 20:11, 20 nov 2011 (CET)

(Rientro) Allora, per venire incontro a tutte le opinioni, si potrebbe

• Modificare il font e i colori delle evidenziazioni
• Aggiungere la modifica per la visualizzazione di tutti gli spazi
• NON modificare la dimensione del font e
• NON modificare la posizione dei link

Mi pare infatti che l'utilità principale di tutte queste modifiche sia la diversa evidenziazione delle diff, che sarebbe un vero peccato non implementare. Poi ovviamente ciascuno di voi è libero di modificare il proprio CSS aggiungendo le caratteristiche che non verranno implementate (io l'ho già fatto) --Lepido (msg) 20:20, 20 nov 2011 (CET)

(conflittato) Se è così leggibile come dici, perché il testo delle voci è scritto in un carattere più grande? Riducendolo le voci sarebbero più corte e quindi più comode da consultare, non pensi? :D Provocazioni a parte, rimango della mia idea che portare il testo dei diff alla stessa grandezza di quello normale sia la scelta giusta: non vedo perché il carattere dei diff debba essere più piccolo di quello delle voci, e quindi avere una leggibilità minore: nei diff sarebbe necessaria una leggibilità addirittura maggiore che nelle voci (se leggendo una voce salti una virgola non finisce il mondo, ma se in un diff non te ne accorgi le conseguenze potrebbero essere più importanti), ma parificarle andrebbe già benissimo. E il fatto che, su 5 utenti che si sono espressi, 3 siano favorevoli all'aumento delle dimensioni, uno neutrale e uno contrario significa che il problema della leggibilità c'è ed è abbastanza sentito. Se la situazione rimane questa mi sembrerebbe più logico che questa modifica venga applicata come default, e che i pochi che non la gradiscono usino il loro CSS personalizzato per "annullarla". E poi, ripeto, un testo troppo piccolo da leggere è un serio ostacolo, un testo troppo grande al massimo dà fastidio perché ingombrante: ragionando in generale, credo sia preferibile correre il rischio meno grave (il secondo).

Per quanto riguarda l'aspetto dei link avanti-indietro, gli ho semplicemente applicato la formattazione già in uso per i pulsanti delle finestre di dialogo; capisco che possa non piacere, ma dargliene una diversa mi sembrerebbe inopportuno per una questione di uniformità. Il problema della distanza onestamente non lo vedo, ma se insisti possiamo anche riportarli in posizione centrale (certamente non era una questione fondamentale). --Una giornata uggiosa '94 · E poi, di che parliamo? 21:52, 20 nov 2011 (CET)

Ahia...! La modifica che avevo proposto e che mi piaceva tanto, white-space: pre;, non va bene su FireFox. Ho provato ora e ho capito cosa intendeva Una giornata uggiosa quando parlava di scrollbar e credo che purtroppo sia improponibile. Per coloro che usano Chrome, la modifica è caldamente consigliata (ma deve essere inserita nel proprio vector.css) --Lepido (msg) 22:37, 20 nov 2011 (CET)

Mi sa che non hai letto quello che ho scritto qui: da una rapida occhiata in quel modo dovrebbe andare bene, se hai tempo provalo meglio :) --Una giornata uggiosa '94 · E poi, di che parliamo? 22:48, 20 nov 2011 (CET)

Mi sa che hai ragione, sia per la soluzione, sia per il fatto che mi era sfuggita. Certificazione per IE, FF, e Chrome --Lepido (msg) 22:57, 20 nov 2011 (CET)

(rientro) Visto che voi siete proprio tanti... fai, che te devo dì. Per quanto riguarda i link di navigazione a me sembrerebbe inopportuno dargli l'aspetto da te creato. Il motivo sarebbe uniformità? Con vector? IMHO quella modifica non ha proprio senso, se ti piacciono tanto tienili nel tuo CSS ma a me proprio non piacciono e non essendoci un motivo serio per cambiarli non vedo perchè lo si debba fare.--LikeLifer (msg) 23:51, 20 nov 2011 (CET)

Per i link di navigazione il ragionamento è stato questo: dato che a mio parere erano poco visibili, e si perdevano un po' tra gli altri link (quello per verificare la modifica, quello che collega alla pagina utente e alla discussione di chi ha fatto la modifica, ecc.) ho pensato che fosse necessario evidenziarli in qualche modo (ad esempio con un bordo e/o con un colore di sfondo); la motivazione di fondo della modifica, quindi, è questa. A questo punto ho pensato che, invece di scegliere un bordo/un colore di sfondo arbitrari, avrei potuto utilizzare lo stesso formato che viene già usato in Wikipedia per i pulsanti delle finestre di dialogo, in maniera che nel sito si mantenga una certa uniformità di stili. Non vorrei insistere perché dei gusti non si discute, ma dato che questo stile è già presente su Wikipedia la scelta è stata un po' obbligata, e poi se dovessimo sentire i pareri di tutti non troveremmo mai un accordo... comunque, se hai qualche proposta alternativa per la formattazione che ti farebbe diventare favorevole, falla pure, sono pronto ad accettarla. --Una giornata uggiosa '94 · E poi, di che parliamo? 08:36, 21 nov 2011 (CET)

Ho già detto che mi piacerebbe se rimanesse come sono ora, spostando il link per la verifica a capo.--LikeLifer (msg) 22:19, 23 nov 2011 (CET)

Questo l'ho capito, ma se continuiamo a ragionare in termini di "a me piace così" o "per me è meglio così" non arriviamo da nessuna parte: siamo qui per decidere razionalmente cosa sia meglio per tutti; poi certamente ognuno ha i suoi gusti personali, ma la soggettività andrebbe lasciata quanto più possibile da parte. Il problema, lo ripeto, è che quei link rischiano di essere poco visibili in mezzo agli altri, mentre IMHO dovrebbero risaltare perché rispetto agli altri hanno una funzione diversa; applicargli una formattazione di qualche tipo per evidenziarli IMHO aiuterebbe. --Una giornata uggiosa '94 · E poi, di che parliamo? 20:24, 25 nov 2011 (CET)

Intanto provo a riassumere il problema linkando di nuovo la discussione al Bar per sentire altri pareri. --Una giornata uggiosa '94 · E poi, di che parliamo? 16:27, 26 nov 2011 (CET)

Il testo è piccolo anche con monobook. Il ragionamento di UGU imho è perfetto: se per consultare una voce ho bisogno del carattere di dimensioni n, perché mai per il diff mi dovrebbe andare meglio n-1? Per avere una visuale a volo d'uccello? E a che mi servirebbe, se non sono capace di leggere quello che vedohttp://it.wikipedia.org/w/index.php?title=Discussioni_MediaWiki:Common.css&action=submit? Io intanto mi sa che mi piazzo al volo il CSS nuovo, ma spero che venga reso di default. Si consideri anche che i periodici online usano un font più grandicello del nostro. Ha molto più criterio ottimizzare la schermata con il font al 100%, poi se uno vuole avere una visione più d'insieme dà un colpo di CTRL e meno. --Pequod76^(talk) 19:09, 26 nov 2011 (CET)

Consultazione del Bar

Tra le modifiche che ho proposto per la pagina del confronto delle revisioni (diff), ce n'è una su cui non si è riusciti a trovare consenso: l'applicazione di una formattazione (la stessa già in uso per i pulsanti nelle finestre di dialogo della toolbar di modifica) ai link "Differenza precedente" e "Differenza successiva"; questo è l'aspetto attuale e quest'altro quello proposto [attenzione, nel secondo screenshot ignorate il cambiamento di allineamento dei suddetti link: rimarranno al centro, così come sono adesso].

La motivazione è che IMHO, allo stato attuale, quei due link sono poco visibili, e si perdono un po' tra gli altri link (quello per verificare la modifica, quello che collega alla pagina utente e alla discussione di chi ha fatto la modifica, ecc.); applicargli una formattazione (un bordo e/o un colore di sfondo) secondo me aiuterebbe a renderli più facilmente individuabili. Invece di scegliere un bordo/un colore di sfondo arbitrari, ho preferito proporre lo stesso formato già usato in Wikipedia per i pulsanti delle finestre di dialogo, in maniera che si mantenga una certa uniformità di stili; comunque se proprio non piace se ne possono anche scegliere altri.

Siete favorevoli o contrari a questa modifica? --Una giornata uggiosa '94 · E poi, di che parliamo? 16:27, 26 nov 2011 (CET)

Favorevole, mi sembra una bella soluzione. --CavalloRazzo (talk) 19:05, 26 nov 2011 (CET)

Favorevole, ma i pulsanti mi sembrano troppo grossi in altezza. Adottare le dimensioni che hanno i pulsanti, ad es., al progetto:astronomia? --Pequod76^(talk) 19:09, 26 nov 2011 (CET)

Contrario (confl.), a me sembra che la nuova modifica li faccia risaltare fin troppo e stilisticamente quei pulsantoni non mi sembra stiano così bene con lo stile usato nel resto della pagina. Detto dell'estatica, dal punto di vista pratico non credo che cambi niente: alla fine quei pulsanti sono usati praticamente solo da utenti già un po' esperti.--Sandro_bt (scrivimi) 19:11, 26 nov 2011 (CET) P.S. Sono favorevole alle altre modifiche proposte.

• gli stili diff mi piacciono, ottimo tutto, solo non capisco perché rendere pulsanti quei due link. Sono link, non buttons, non parte niente se li clicco quindi mi pare un po' fuorviante. Sarei per quadrottarli in un altro colore, quale che sia purché si noti --Fantasma (msg - 111.004) 21:24, 26 nov 2011 (CET)

i bottoni non mi piaciono molto, preferisco i link. Inoltre mi sembra che in pratica la questione verta su dove mettere il "Segna come verificata": a mio parere andrebbe spostato sulla prima linea al pari di "(modifca)" "(annulla)" giacchè si tratta di una possibile azione inerente la versione.--Ysogo (msg) 16:25, 27 nov 2011 (CET)

La verifica va isolata! È un'azione irreversibile, ci manca che la mettiamo in mezzo ad altre per ragioni di analogia e ci clicchiamo per contrazione involontaria dei muscoli, un po' di buonsenso! :) --Pequod76^(talk) 17:29, 27 nov 2011 (CET)

I link rimangano link, non pulsanti; per il resto direi che può andare. Magari da pubblicare come "gadget" opzionale per chi voglia adottarlo, piuttosto che come modifica urbi et orbi. --Pap3rinik (msg) 14:35, 28 nov 2011 (CET)

Rimozione classe transferlist

Qui è stata concordata la rimozione della transferlist.js, pertanto ora è possibile rimuovere la classe .AvvisoTrasferito che non serve più? (era usata percolorare il box che riportava la motivazione di trasferimento)

.AvvisoTrasferito
{
    background-color: #EEF8FF;
    border: 1px solid black;
    margin: 5px;
    padding: 5px;
}

--LoStrangolatore (discussione) 16:49, 8 mag 2012 (CEST)

MediaWiki 1.20

Lo "stile" dei diff di it.wiki, da quando è stata aggiornata a MediaWiki 1.20wmf1, fa davvero ridere i polli. Per carità qualcuno tolga l'obsoleto stile locale, che è ormai inutile e davvero orrendo in sovrapposizione a quello nuovo. --Nemo 03:03, 5 ago 2012 (CEST)

Cioè questo? Per me è indifferente, aspettiamo qualche parere perché qui mi sembra una questione de gustibus... --Bultro (m) 13:43, 5 ago 2012 (CEST)

Non è una questione di gusti, il nuovo diff è stato implementato apposta per sostituire la "soluzione francese" in tutti i progetti e renderla superflua, non certo per sovrapporsi alla stessa: avere il verdino circondato dall'azzurro o il rosso su sfondo rosino in campo giallo è banalmente una mostruosità, non parliamo poi dei poveri daltonici. --Nemo 15:03, 5 ago 2012 (CEST)

Mi sembra molto più leggibile questo rispetto a questo. L'azzurrino su verdino è quasi invisibile sul mio monitor. -- Basilicofresco (msg) 14:58, 8 ago 2012 (CEST)

Come Basilico.--Nickanc ♪♫@ 15:36, 8 ago 2012 (CEST)

Quasi? Sei sicuro che ci sia? Anche aguzzando gli occhi non c'è verso di vederlo, qui da me (e non ho problemi di vista). Che desolazione, Nemo 21:26, 10 ago 2012 (CEST)

classe tabelle per colorare le righe dispari

Potremmo inerire qualcosa tipo:

/* colora le righe dispari delle tabelle */
table.colore_alternato tr:nth-child(odd){
background-color:gainsboro;
}

per evidenziare le righe delle tabelle, che dite?--LikeLifer (msg) 14:07, 5 set 2012 (CEST)

Sembra una buona idea Jalo 15:56, 5 set 2012 (CEST)

A parte che è meglio applicare le regole alla class "wikitable" e non a tutte le tabelle indiscriminatamente, per raggiungere lo scopo non è la soluzione migliore. Qualche anno fa avevo letto su www.html.it un articolo che presentava uno studio e mostrava che un gruppo di utenti impiegava mediamente lo stesso tempo nell'estrarre informazioni da tabelle senza formattazione e tabelle a colori alterni; invece la soluzione che faceva calare maggiormente il tempo impiegato e riduceva gli errori di lettura era quella di far cambiare colore alla riga al passaggio del mouse. Per cui sarei più favorevole a implementare quest'ultima soluzione. --Una giornata uggiosa '94 · E poi, di che parliamo? 18:12, 1 ott 2012 (CEST)

Allego il codice che già da tempo uso nel mio CSS per ottenere l'evidenziazione al passaggio del mouse:

/* Riga evidenziata al passaggio del mouse nelle tabelle */

.wikitable tr:hover, .prettytable tr:hover {
    color: white;
    background-color: #0066FF;
}

L'effetto prodotto è il seguente (la terza riga è quella su cui nell'esempio si è fermato il mouse):

LOL	ROTFL
Lorem	Ipsum
Dolor	Sit amet
Lorem	Ipsum

--Una giornata uggiosa '94 · E poi, di che parliamo? 20:43, 1 ott 2012 (CEST)

+1 a Una giornata uggiosa --Bultro (m) 22:36, 1 ott 2012 (CEST)

-1, sorry... se mi si evidenzia una riga al passaggio del mouse, mi aspetto che la riga sia "attiva" e che cliccandoci sopra succeda qualcosa. Questo comportamento è un po' uno standard nel Web: l'area attiva viene evidenziata al passaggio del mouse. So perfettamente che l'evidenziazione di una riga potrebbe aiutare la lettura, ma manderebbe un "segnale" forviante che non segue le convenzioni. --Lepido (msg) 07:31, 2 ott 2012 (CEST)

Namespace Module

Per migliorare la leggibilità del namespace Module (esempio) propongo di aggiungere la classe pre.lua.source-lua alla regola font-family: monospace, Courier !important;. --Incola (posta) 20:47, 21 mar 2013 (CET)

Ma che diavolo è il namespace module? :) Lo scopro solo adesso Jalo 08:36, 22 mar 2013 (CET)

Fino ad ora non ha riscosso un grande successo. :) È il namespace in cui è contenuto il codice sorgente necessario per creare dei template con il linguaggio di programmazione Lua: vedi questo post. --Incola (posta) 08:53, 22 mar 2013 (CET)

Ho fatto la modifica, ma non sembra essere cambiato nulla. Sicuro del codice? Non è che magari deve essere solo pre.source-lua come il javascript? Jalo 10:50, 22 mar 2013 (CET)

Inizialmente non funzionava neanche a me, ma ora mi sembra tutto a posto. Forse è solo un problema di cache? --Incola (posta) 11:00, 22 mar 2013 (CET)

Vero, adesso funziona Jalo 13:06, 22 mar 2013 (CET)

Nascondere/Mostrare testo in stampa

Dato che al momento la generazione dei pdf è buggata (quando si genera la versione printabile di una pagina non richiama la versione "Stampa" dei template ma continua a richiamare la versione normale), la visualizzazione dei link della sezione interprogetto non funziona, vorrei provare a risolvere temporaneamente la cosa generando i link per il video e quelli per la stampa e nascondendoli mediante istruzioni css. C'è qualche classe nel commons.css che si può usare o devo fare prove con del codice online ?--Moroboshi ^scrivimi 21:12, 24 giu 2013 (CEST)

Non ho capito esattamente cosa tu voglia fare, comunque i 3 link della sezione strumenti si chiamano rispettivamente: "coll-create_a_book", "coll-download-as-rl" e "t-print".

Non so come si possa (via CSS) aggiungere nuovi link Jalo 09:13, 25 giu 2013 (CEST)

Non voglio aggiungere nuovi link, l'idea sarebbe inserire i link sia per i link sia per la visualizzazione video che quelli per la visualizzazione stampa e a seconda se stia visualizzandoli a video o generando la versione stampa mostrare i link "versione video" e nascondere i link "versione stampa" nella visualizzazione video e fare il contrario (nascondere i link "versione video" e visualizzare i video "versione stampa") nella versione stampa. La cosa è possibile mediante css ?--Moroboshi ^scrivimi 09:50, 25 giu 2013 (CEST)

Non vedo il link "versione video", per questo non capisco. In più se clicco "versione stampabile" me la mostra senza i link da parte, per cui non saprei cosa nascondere/mostrare :/ Jalo 12:27, 25 giu 2013 (CEST)

In ogni caso non credo che possiamo modificare la versione stampabile Jalo 12:27, 25 giu 2013 (CEST)

Per "versione video" intendo la normale voce mostrata a video, per versione stampabile quella mostrata quando si richiede la versione stampabile della voce. Non voglio modificare la colonna di sinistra ma la sezione "Interprogetto" del corpo della voce, mi pare che sia possibile a livello di css definire delle regole di visualizzuazione secondo il mezzo con cui viene vista la pagina web.--Moroboshi ^scrivimi 14:28, 25 giu 2013 (CEST)

Adesso ho capito :) Domani provo a studiare la cosa, nel frattempo puoi provare a chiedere a Codicorumus che ne sa :) Jalo 16:35, 25 giu 2013 (CEST)

Aggiungere classe "infobox"

Gentilmente chiedo se si può aggiungere. Grazie. --Tener (msg) 18:40, 8 ott 2013 (CEST)

Per cosa? Su it.wiki si utilizza la classe "sinottico" --Bultro (m) 12:29, 9 ott 2013 (CEST)

Sto lavorando sull'importazione di alcuni modelli da en:wiki per il disegno di tracciati ferroviari. In particolare la classe "infobox" è usata nel Template:BS-map. Ho provato, grazie alla tua imbeccata, a sostituire nel codice sorgente preso pari pari da en:wiki "infobox" con "sinottico" e, più giù, "navbar" con "Tnavbar".

I risultati sono accettabili, ma, per esempio nel Template:Legenda linea ferroviaria, che ho tradotto da en:wiki e che si basa su BS-map per la resa grafica, noto che le righe vanno a capo, mentre in en:wiki la tabella si ridimensiona in base alla riga di maggior lunghezza. --Tener (msg) 13:19, 9 ott 2013 (CEST)

"Su it.wiki su usa ..." è una frase che per queste questioni deve avere una puntuale verifica di consenso. Dove è ? Dove sono state condivise queste decisioni, che al contrario io vedo sempre controverse ogni volta che si prova a discuterle ? Se vi è una richiesta di miglioramento, non può esserci nessuna "regola" non scritta e non condivisa con la comunità che la blocchi basata su frasi "su it.wiki si fa così". Io direi per intanto di aggiungere la classe, consentire le sperimentazioni e solo dopo eventualmente "vietare" - dopo opportuno dibattito e verifica - l'utilizzo. Se qualcuno si sta offrendo volontario per un lavoro, perchè frustrarlo ? Al limite va solo avvisato che esistono delle "spinte da certi utenti per una standardizzazione estrema" e quindi rischia di vedersi cancellato il lavoro, ma a parte una avvertenza del genere, non vedo perché non vada accontentato. --EH¹⁰¹{posta} 14:10, 9 ott 2013 (CEST)

EH101 piantala con le solite polemiche. Non era stata fatta nessuna "richiesta di miglioramento", ha detto solo che voleva la classe infobox, la classe infobox salvo diversamente specificato serve per fare gli infobox, e da noi tale classe si chiama sinottico.

Tener: abbiamo già dei modelli per le linee ferroviarie, come il Template:Percorso fer, esiste un Progetto:Trasporti che ha prodotto le linee guida Progetto:Trasporti/Linee guida diagrammi ferroviari, prima di importare di sana pianta nuovi sistemi dovresti perlomeno consultarli. --Bultro (m) 14:30, 9 ott 2013 (CEST)

Non è da ieri che mi occupo di rivedere i tracciati già presenti in Wikipedia (ho creato anche nuove icone per Commons), e quindi so bene che "abbiamo già dei modelli per le linee ferroviarie" (altrimenti come sarebbero fatte quelle esistenti?). Non saprei dire per quale ragione "storica", ma quasi tutti i tracciati presenti sulle pagine di it:wiki sono realizzati usando template come Template:Percorso fer, Template:Percorso fer2 e Template:Percorso fer5, limitati e abbandonati a sé stessi (in una parola: obsoleti: li adoperiamo solo noi e - in pochissime pagine - i giapponesi!). Essi corrispondono in pratica agli omologhi template BS diffusi in tutte le wiki, solo che sono "fermi" alle relative versioni di sei anni fa.

Pochissime pagine su it:wiki si servono di template della famiglia Template:BS, più aggiornati e che hanno il vantaggio, rispetto ai precedenti, di consentire icone sovrapposte o testo ai due lati del percorso (è il caso di Template:BS-2, Template:BS2-2 ecc.), dando quindi un indubbio vantaggio in termini di flessibilità.

Ritengo quindi utile mantenere e possibilmente sviluppare i template BS (penso a creare alcuni BSx con x>5), affiancandoli ai "tradizionali" Percorso fer quando siano richiesti tracciati più elaborati. --Tener (msg) 16:48, 9 ott 2013 (CEST)

Questo è un discorso da fare al progetto trasporti, non qui --Bultro (m) 17:18, 9 ott 2013 (CEST)

Ho solo dato una risposta alla tua osservazione in cui mi dicevi di consultare le linee guida ecc., motivando l'implementazione di un sistema che non ho "importato di sana pianta" perché c'era già ma sto solo cercando, se possibile, di migliorare.

Comunque sia, se non si può aggiungere questa classe amen, vedrò di arrangiarmi con quello che c'è. --Tener (msg) 21:40, 9 ott 2013 (CEST)

Non ho detto che non si può, discutiamo al progetto cosa vogliamo ottenere e poi si aggiungerà quanto necessario. --Bultro (m) 18:05, 10 ott 2013 (CEST)

SI e VE

Questo semplice codice nasconde il pulsante "modifica" di VisualEditor nello Sportello Informazioni:

.page-Aiuto_Sportello_informazioni #ca-ve-edit{
	display:none;
}

Testato con Vector e Monobook (le altre skin non supportano VisualEditor). Non sarebbe più necessario l'avviso creato per far fronte provvisoriamente al problema (discusso qui). --Ricordisamoa 22:22, 13 mar 2014 (CET)

Fatto prego di verificare che sia tutto a posto, grazie. --Lucas ✉ 05:48, 14 mar 2014 (CET)

Funziona come previsto, grazie. --Ricordisamoa 15:30, 14 mar 2014 (CET)

Bene per la rimozione del "Modifica" in cima alla pagina. Restano però quelli delle singole sezioni. --109.55.8.155 (msg) 11:17, 19 mar 2014 (CET)

Inserisco questo codice:

.page-Aiuto_Sportello_informazioni .mw-editsection-visualeditor{
	display:none;
}
.page-Aiuto_Sportello_informazioni .mw-editsection-divider{
	display:none;
}

che dovrebbe eliminare il link al VE anche nelle sezioni. Fatemi sapere. --Lepido (msg) 14:20, 19 mar 2014 (CET)

External links icons removed

Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo 11:45, 10 apr 2014 (CEST)

Immagini di sfondo inesistenti

"Immagini di sfondo" contiene diverse immagini che sono state cancellate anche cinque anni fa, potete toglierle? File:HP_search.png, File:BGzoom.png, File:Sfum.png. Vabbè, faccio la lista completa, ci sono anche File:BG_azzurro.jpg, File:BGalpha.png, File:Obliquo.gif. Questi invece esistono:

• 
• 
• 
• 
• File:BGorange1.jpg
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

--Nemo 09:24, 14 giu 2014 (CEST)

Non so se sapevano cosa facevano quando le hanno cancellate... La motivazione è "orfana" ma è normale, gli utilizzi tramite CSS non risultano nei PuntanoQui. Bisognerebbe verificare, forse con un EGO, se sono effettivamente usate le rispettive classi (anche delle immagini esistenti).

Quelle del portale astronomia sono usate, ma non è possibile inserirle direttamente tramite wikicodice? Si appesantisce il CSS che devono scaricare tutti solo per quella pagina --Bultro (m) 14:52, 14 giu 2014 (CEST)

Risoluzione del logo

In seguito ad un test da me effettuato con esito negativo e alla cortese richiesta di Adamanttt, vorrei sapere se vi sono problemi ad apportare la modifica ricavata da enwiki per utilizzare il logo ad una risoluzione maggiore.

/* [[MediaZilla:35337]] */
@media (-webkit-min-device-pixel-ratio: 1.5), (min-resolution: 1.5dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/9/90/Wikipedia-logo-v2-it.svg/204px-Wikipedia-logo-v2-it.svg.png") !important;
                background-size: 136px auto;
        }
}
@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 2dppx) {
        #p-logo a {
                background-image: url("//upload.wikimedia.org/wikipedia/commons/thumb/9/90/Wikipedia-logo-v2-it.svg/270px-Wikipedia-logo-v2-it.svg.png") !important;
                background-size: 135px auto;
        }
}

Grazie, M/ 21:20, 20 set 2014 (CEST)

Il logo logo ha uno standard di dimensioni per cui va usato quello (135 × 155). Per evitare lo sgranamento (Bugzilla:35337) enwiki ha inserito questo codice nel css. Per cui ho eliminato #p-logo che è nel css da anni per usare quello di default che ho riportato alle dimensioni originali e ho inserito il codice nel css. Magari con calma va fatta una versione a miglior risoluzione in 135 × 155 (che se non ricordo male deve essere in png) artendo da File:Wikipedia-logo-v2-it.svg --Melos ^(msg) 04:00, 21 set 2014 (CEST)

Ho preferito reinserire #p-logo per usare wiki.png dal momento che storicamente si è sempre usato quello locale --Melos ^(msg) 04:30, 21 set 2014 (CEST)

Io su Windows 7 con una risoluzione di 1920x1080 e DPI scaling al 125% carico la versione a 204px (che è esattamente ciò che volevo per me e per tutti). Qualcuno con risoluzioni inferiori dovrebbe caricare la vecchia versione a 135px? Comunque le versioni .png di File:Wikipedia-logo-v2-it.svg esistono già e sono direttamente accessibili dalla pagina del file accanto alla scritta "Altre risoluzioni" (la versione che sto usando, quella a 204px, è proprio una di quelle, anche se non è tra quelle standard da 209px, 418px etc.). --Adamanttt ^{(mandami un messaggio)} 12:43, 21 set 2014 (CEST)

Mi rispondo da solo: ho provato su un portatile con la classica 1366x768 e lì viene caricata la vecchia Wiki.png. Forse è meglio rimuoverla come fanno su en.wiki (contando che c'è già il downscaling automatico)? --Adamanttt ^{(mandami un messaggio)} 11:44, 22 set 2014 (CEST)

Da qui si può misurare la propria dppx (punti per pixel) che determina quale versione del logo viene caricata. La mia è proprio di 1.5, ecco perché carico la versione a 204px. --Adamanttt ^{(mandami un messaggio)} 15:37, 22 set 2014 (CEST)

thumb

propongo di sostituire, tramite l'uso del selettore > (compatibile con IE7 e opera7):

.thumbinner {
    min-width: 100px;
}
 
div.thumb {
    margin: 0.5em;
    text-align: center;
    width: auto;
}
div.thumb div {
    border: 1px solid #888888;
    background-color: #f7f7f7;
    padding: 2px;
    font-size: 94%;
    text-align: center;
    overflow: hidden;
}
div.thumb div * {
    border: none;
    background: none;
}
div.thumb img {
    border:1px solid #888888;
    margin-bottom:3px;
    background:#FFFFFF;
}
div.thumbcaption,
div.thumbcaption * {
    border: none !important;
    background: none !important;
}
div.thumbcaption {
    padding: 0.2em 0 0.2em 0 !important;
    text-align: left !important;
}

con:

.thumbinner {
    min-width: 100px;
    text-align: center;
}
 
div.thumb {
    margin: 0.5em;
    text-align: center;
    width: auto;
}

div.thumb > div {
    border: 1px solid #888888;
    background-color: #f7f7f7;
    padding: 2px;
    font-size: 94%;
    overflow: hidden;
}

div.thumb img {
    border:1px solid #888888;
    margin-bottom:3px;
    background:#FFFFFF;
}

div.thumbcaption {
    padding: 0.2em 0 0.2em 0;
    text-align: left;
}

è una pulizia del codice che aiuterebbe anche a creare e modificare template come {{immagine multipla}}, che hanno vari div all'interno del div.thumb. --ppong (msg) 10:57, 6 ott 2014 (CEST)

Premettendo che l'attuale Common.css globale è un enorme caos (sarebbe utile che chi ci ha lavorato in questi anni tornasse a rimuovere ciò che non serve più) e che quando si richiede una modifica sarebbe opportuno dare una propria spiegazione per i vari cambiamenti, ti chiedo: hai provato a guardare cosa c'è nei fogli di stile di MediaWiki stesso e a guardare la data di inserimento di questa parte dei thumb nel nostro Common.css? Perché magari è una parte obsoleta, che non serve più... --Rotpunkt (msg) 11:36, 6 ott 2014 (CEST)

alla fine ho scoperto che, rispetto al css default quello che cambia è:

• la dimensione minima del thumbinner (vale per le immagini molto piccole, per cui non sarebbe altrimenti possibile scrivere una didascalia)
• il margin del tright che varia leggermente: diventa .5em 0 1.3em 1.4em (stesso vale per il tleft)
• i colori del thumbinner (attribuiti piuttosto al selettore "div.thumb div") che sono meno tenui; li ha modificati Paginazero nel 2006 ([2])

la prima cosa è utile, tutte le altre indicazioni possono essere eliminate. se si vuole conservare i nostri colori dovrebbero essere assegnati al thumbinner, così:

.thumbinner {
    min-width: 100px;
    border: 1px solid #888888;
    background-color: #f7f7f7;
}

div.thumb img {
    border:1px solid #888888;
}

comunque tu controlla perché è facile che mi sia confuso. --ppong (msg) 15:37, 6 ott 2014 (CEST)

I fogli di stile principali da studiare dovrebbero essere quelli in queste due cartelle:

• https://git.wikimedia.org/tree/mediawiki%2Fcore/HEAD/resources%2Fsrc%2Fmediawiki.legacy
• https://git.wikimedia.org/tree/mediawiki%2Fcore/HEAD/resources%2Fsrc%2Fmediawiki.skinning

--Rotpunkt (msg) 16:17, 6 ott 2014 (CEST)

grazie per la dritta. confermo tutto: basta in effetti guardare in fondo a questo css. --ppong (msg) 17:05, 6 ott 2014 (CEST)

preciso: loro non scrivono "div.thumb img" ma "html .thumbimage". sarebbe giusto adeguarsi casomai. --ppong (msg) 17:09, 6 ott 2014 (CEST)

Io i bordi non li andrei più a toccare, toglierei tutta la sezione thumbnails, con le dovute prove, e lascerei solo come su en.wiki (gallery a parte):

/* Minimum thumb width */
.thumbinner {
    min-width: 100px;
}

/* Makes the background of a framed image white instead of gray.
   Only visible with transparent images. */
div.thumb .thumbimage {
    background-color: #fff;
}

Si può usare en.wiki per fare dei test, mettendo in una sandbox su it.wiki e in una su en.wiki la stessa pagina di prova e vedendo il differente risultato. --Rotpunkt (msg) 18:35, 6 ott 2014 (CEST)

sennò una wikipedia senza css, ad esempio ve: (la prima combinazione di caratteri che mi è venuta in mente). qualcuno però potrebbe dire che preferisce i colori come sono adesso. per me è uguale, tanto belli non sono comunque. --ppong (msg) 21:48, 6 ott 2014 (CEST)

Ho eliminato tutta la parte di css che riguardava le thumb utilizzando quelle del core e indroducendo la modifica proposta. I colori ho preferito eliminarli dal momento che spesso è consigliato avvicinarsi il più possibile al core che è costantemente aggiornato (nome delle classi che in fase di sviluppo possono cambiare, usability etc.). Ciò non toglie che se ci sono particolari problemi possono essere reinserite come proposto da ppong che ringrazio per i suggerimenti --Melos ^(msg) 18:04, 10 ott 2014 (CEST)

Ottimo. --Rotpunkt (msg) 11:33, 11 ott 2014 (CEST)

pulizia

ecco alcune cose che si possono eliminare dall'attuale stato di questo foglio di stile, perché sono già presenti in questo qui:

/* Print-specific things to hide */
.printfooter {
        display: none;
}

/* Riduce l'altezza della riga per <sup> e <sub> (es.: note) */
sup, sub {
    line-height: 1em;
}

l'indicazione è assoluta piuttosto che in em (non so bene cosa implichi)

img.tex { vertical-align: middle; }
span.texhtml { font-family: serif; }

.error {
	color: red;
	font-size: larger;
}

il colore però è #cc0000 piuttosto che il rosso vivo (#ff0000).

in quest'altro c'è già:

/* use this instead of #toc for page content */
.toccolours {
    border:1px solid #aaaaaa;
    background-color:#f9f9f9;
    padding:5px;
    font-size: 95%;
}

e qui c'é:

/* small for tables and similar */
.small, .small * { font-size: 94%; }
table.small { font-size: 100% }

con l'importante differenza che la prima proprietà è attribuita solo a .small e non ai suoi figli. --ppong (msg) 10:48, 7 ott 2014 (CEST)

note

in questa mia sandbox ho inserito molti esempi, che si possono trovare in tutta l'enciclopedia, di note inserite in un punto del testo dove risultano di dimensioni o stile diversi da quello consueto. l'effetto, soprattutto all'interno di una voce con altre note tutte omogenee, è davvero brutto. propongo di inseguire la seguente linea al css per risolvere il problema:

.reference {font-weight: normal; font-size: 11px; font-family: sans-serif;}

in particolare la specifica della famiglia di caratteri serve a evitare il brutto effetto di numeri discendenti (come quelli del georgia e mi pare anche del libertine) all'interno di parentesi quadre. --ppong (msg) 10:25, 22 nov 2014 (CET)

il richiamo (<ref></ref>) non dovrebbe stare mai in titolo sezione, comunque con questa linea dovrebbe superare il grassetto imposto dall'h2, h3, etc, giusto? se così per me ok e grazie :-) -- g · ℵ (msg) 23:52, 22 nov 2014 (CET)

+1 ma il valore 11 da dove viene? --Bultro (m) 15:19, 23 nov 2014 (CET)

allora, per provare voi stessi la modifica potete, come per tutto, aggiungere la riga sopra al vostro css personale, così è come la vedo io. se si evita di usare le note per i titoli di sezione basta anche il primo comando (.reference {font-weight: normal;}) per tutti i problemi del tipo note dentro le intestazioni delle tabelle ecc. per quelle nei titoli serviva una dimensione fissa, in px o a parole (small/x-small). 11px mi è sembrata una buona misura, ma a seconda di come varia la dimensione del resto del testo (impostato su 0.875em) può esserci un cambiamento di resa delle note ordinarie rispetto a come voi le vedete oggi. --ppong (msg) 17:28, 23 nov 2014 (CET)

Personalmente, nelle css sono contrario all'uso di misure assolute per la dimensione dei font: la resa di omogeneità non è garantita, specie su schermi piccoli o in caso di ricorso a set di caratteri di default/css diversi da quelli standard. Senza dimenticare che gli "11px" di Firefox, per quanto la cosa possa sembrare paradossale, vengono resi con una dimensione diversa (tipicamente più piccola) rispetto agli "11px" di Chrome/Safari che a loro volta sono ancora diversi dagli "11px" di IE, così come vengono resi in modo diverso tra un display di PC Windows e un display di OS X. Penso sia meglio basarsi sul rapporto relativo tra la dimensione del carattere dei titoli rispetto alla dimensione del carattere usato per la nota referenziale. --L736E^{l'adminalcolico} 17:53, 24 nov 2014 (CET)

da questo punto di vista l'html fa acqua da tutte le parti, px, em o quale che sia l'unità di misura, non è un caso però se la maggior parte dei siti utilizza i pixel e non le emme per dimensionare il testo. riflettendoci però penso che valga la pena adottare i rem casomai: se usate un browser che non li supporta pace, vedrete le note della stessa solita grandezza, e non ci saranno problemi per nessun'altro. il codice sarebbe piuttosto questo: .reference {font-weight: normal; font-size: 0.7rem; font-family: sans-serif;} --ppong (msg) 12:34, 26 nov 2014 (CET)

Stili per babel

Domanda. Sono davvero necessari gli stili custom qui definiti e utilizzati dai vari Template Babel o sono sufficienti quelli definiti di default da mediawiki (e.g. mw-babel-header, mw-babel-box, mw-babel-box-N, mw-babel-box-4 ... 0, ecc.)? --Andyrom75 (discussioni) 12:05, 8 dic 2014 (CET)

Metto qui di seguito i due approcci per un miglior confronto e analisi delle classi:

it-0 Questo utente non è in grado di comunicare in italiano (o lo capisce solo con notevole difficoltà). it-1 Questo utente può contribuire con un livello elementare in italiano. it-2 Questo utente può contribuire con un livello intermedio in italiano. it-3 Questo utente può contribuire con un livello avanzato in italiano. it-4 Questo utente può contribuire con un livello quasi madrelingua in italiano. it-N Questo utente può contribuire con un livello madrelingua in italiano.

Babel utente it-0 Questo utente non è in grado di comunicare in italiano (o lo capisce solo con notevole difficoltà). it-1 Questo utente può contribuire con un livello elementare in italiano. it-2 Questo utente può contribuire con un livello intermedio in italiano. it-3 Questo utente può contribuire con un livello avanzato in italiano. it-4 Questo utente può contribuire con un livello quasi madrelingua in italiano. it-N Questo utente può contribuire con un livello madrelingua in italiano. Utenti per lingua

--Andyrom75 (discussioni) 16:08, 8 dic 2014 (CET)

Per me possiamo usare quelli di default. Precisiamo: gli stili determinano solo tipo di carattere e margini di ogni casella, non il testo o la cornice bianca. Dipende sempre se si usano i template Babel o la funzione #babel --Bultro (m) 01:38, 9 dic 2014 (CET)

Bultro, sai per certo se quelle classi sono utilizzate solo dai Template Babel? In caso negativo andrebbe fatta per scrupolo una ricerca tra i vari template/script. --Andyrom75 (discussioni) 09:04, 9 dic 2014 (CET)

Per certo no, ma si può chiedere un EGO --Bultro (m) 13:06, 10 dic 2014 (CET)

Favorevole ad eliminare gli stili custom di it-wiki, inoltre sarebbe il caso di convertire il template affinchè usi l'estensione.--LikeLifer (msg) 17:22, 10 dic 2014 (CET)

Babel utente
it-0 Questo utente non è in grado di comunicare in italiano (o lo capisce solo con notevole difficoltà).
Utenti per lingua

Premesso che andrebbe comunque richiesto un EGO per esser certi che tali non vengano usate altrove, direi che il riutilizzo dell'estensione è sicuramente la soluzione più veloce e pulita. Qui accanto il risultato del {{Utente it-0/Sandbox}} ma per ottenere il risultato finale va abbinato alla definizione del seguente stile (che impatta il template ma non l'estensione):

.babel-plain .mw-babel-header, .babel-plain .mw-babel-footer { display:none; }

[@ Bultro, LikeLifer], che ne pensate? --Andyrom75 (discussioni) 00:51, 13 dic 2014 (CET)

Il template:Babel si può sostituire con #babel ed è sufficiente, a quel punto i singoli template come Utente it-0 non vengono utilizzati.

I singoli template Utente xx-N servono solo se chiamati direttamente da soli. Il tuo trucco di fargli chiamare #babel e poi nascondere la cornice non è il massimo... e si toglierebbero schifezze dal css solo per mettercene altre. Piuttosto, forse si possono eliminare del tutto, se vediamo che non vengono quasi mai chiamati direttamente da soli--Bultro (m) 00:29, 15 dic 2014 (CET)

[@ Bultro], le pagine che richiamano direttamente tali template sono diverse migliaia. Giusto una precisazione; modificando il CSS il riquadro compare già con la sua visualizzazione finale e non è che "poi si nasconde" header & footer.

Sostituire direttamente (e.g. via bot) il template per l'estensione creerebbe problemi grafici ad alcune pagine utente che li utilizzano "impilandoli". Prendi ad esempio queste due: Utente:Kormoran o Utente:Domcuo. --Andyrom75 (discussioni) 09:14, 15 dic 2014 (CET)

@Andyrom75 Faccio solo una considerazione generale: mi sembra che il "problema" sia nato col fatto che l'estensione Babel è nata relativamente tardi (2011), quando tutte le Wiki avevano già creato i propri template per i Babel, e quindi ora il passaggio all'estensione non è così immediato come magari auspicavi che fosse. Anche le altre wikipedia (en, fr, de, ...) mi pare stiano ancora usando i template (vedi anche en:Wikipedia_talk:Babel#Babel_templates). Bisognerebbe segnalare eventuali mancanze di personalizzazione dell'estensione, per favorire il passaggio ad essa. --Rotpunkt (msg) 11:34, 15 dic 2014 (CET)

[@ Rotpunkt] concordo con te che l'avere nell'estensione uno o due parametri atti al nascondere header & footer sarebbe la soluzione migliore, ma giorni fa avevo visto che anni addietro la richiesta era già stata avanzata senza avere seguito, quindi la soluzione di ripiego è quella di nasconderli col CSS. Niente vieta che si può aprire una nuova richiesta su Phabricator, ma non prevedo tempi brevi.

Questa soluzione, sebbene sub-ottima, avrebbe il vantaggio quantomeno di far diminuire i CSS su common e di allineare l'output di questi template all'estensione ufficiale.

Se non si volesse perseguire questa strada, si potrebbe riscrivere tali template (in linea a come sono stati sviluppati) modificando gli stili adottati, ma mi sembra un po' laborioso. --Andyrom75 (discussioni) 11:58, 15 dic 2014 (CET)

Il ticket già esiste: phabricator:T33309 (visto c'ero ho aggiunto un commento nella speranza di risollevarlo dall'annoso torpore...) e la vecchia discussione è questa. --Andyrom75 (discussioni) 12:06, 15 dic 2014 (CET)

Su meta hanno implementato questo template basato sulla patch css sopra menzionata, quindi si può vedere anche come funziona la patch (vedi ad esempio m:User:Galadrien). Tuttavia userei la bozza di template che ho messo in sandbox, perchè è più facilmente modificabile "se e quando" modificheranno l'estensione (basta cancellare il div), mentre nel breve si avrebbero i vantaggi di cui sopra. --Andyrom75 (discussioni) 12:18, 15 dic 2014 (CET)

[@ Rotpunkt, Bultro], [@ Ricordisamoa] ha appena sottomesso una patch per il bug sopramenzionato (grazie). Essendo la modifica semplice, son fiducioso che andrà a buon fine. Dopo di che possiamo decidere se modificare i singoli template o sostituire direttamente le loro chiamate per poi cancellarli. --Andyrom75 (discussioni) 00:08, 16 dic 2014 (CET)

Io ho parlato di sostituire il template:Babel con la funzione #babel (anche senza toccare le pagine, basta fare in modo che il template richiami la funzione), che c'entrano Kormoran e Domcuo che non usano il template?

Per i templatini singoli allora aspettiamo fiduciosi l'aggiornamento del sw... --Bultro (m) 12:28, 17 dic 2014 (CET)

[@ Bultro] quello puoi modificarlo da subito, ma per rimuovere le classi dal common.css vanno rivisti tutti i template che le usano. Hai già richiesto l'EGO di cui parlavi sopra? --Andyrom75 (discussioni) 23:52, 17 dic 2014 (CET)

[@ Rotpunkt, Bultro] vi ho preparato Template:Babel/Sandbox per poterlo sostituire a Template:Babel. Bultro mi fai un fischio quando è pronto l'EGO? --Andyrom75 (discussioni) 02:08, 28 dic 2014 (CET)

[@ Rotpunkt, Bultro] ping. --Andyrom75 (discussioni) 09:48, 14 gen 2015 (CET)

Ho scoperto che basta fare questa ricerca. Purtroppo sono davvero molti anche gli usi diretti della classe senza template. A meno che non si possa sostituire via bot con la classe predefinita, ce la dobbiamo tenere... --Bultro (m) 15:14, 14 gen 2015 (CET)

[@ Bultro] carino il metodo di ricerca, non lo conoscevo. Molto più veloce della scansione di un bot!

Per gli usi inline della classe, che ne pensi di sostituire l'intero blocco con un template e non solo la classe? Successivamente diverrebbe tutto più gestibile. --Andyrom75 (discussioni) 17:31, 14 gen 2015 (CET)

Esistono già Template:SchedaBabelfish e Template:Userbox (probabilmente da unire). Non so però se si riesca a inserirli via bot. Cambiare solo il nome della classe invece dovrebbe essere facile --Bultro (m) 22:10, 14 gen 2015 (CET)

Ho fatto un po' di prove cambiando la sola classe, ma non sono arrivato a nulla. Penso che sia più semplice cambiare Template:SchedaBabelfish e poi applicare quello. Chiaramente un bot non riuscirà a modificare il 100% delle casistiche ma almeno gli si darebbe una sgrossata. PS L'importante è che te e Ricordisamoa vi trovate d'accordo con questo benedetto parametro "plain" :-D --Andyrom75 (discussioni) 09:22, 16 gen 2015 (CET)

references-small

Propongo di eliminare questa classe, anche se risulta usata in centinaia di pagine. Ha solo l'effetto di ridurre la dimensione del carattere, ma non trovo giusto rimpicciolire le fonti, anche se sono molte è giusto che siano leggibili e si prendano tutto lo spazio che gli serve. Le note poi sono già un po' più piccole del testo normale, e l'effetto della classe è cumulativo --Bultro (m) 00:22, 16 gen 2015 (CET)

Bultro, occhio che quella classe, contrariamente al suo nome, è utilizzata nei modi più disparatim non solo nelle note. Tuttavia concordo con te che l'uso <div class="references-small"><references/></div> (o similari) andrebbero corretti nei singoli articoli con un bot. --Andyrom75 (discussioni) 09:18, 16 gen 2015 (CET)

Possiamo toglierlo via bot, ma comunque eliminerei il problema alla radice. Scorrerò i namespace importanti per vedere se c'è qualche uso improprio ma necessario, e ci metterò il font a 90% con i metodi normali. --Bultro (m) 17:53, 16 gen 2015 (CET)

Accorpamento stili

Suggerisco di modificare

.itwiki_template_babel {
  float:left;
  width:20em;
  background:#e0e8ff;
  border:solid #99b3ff 1px;
  margin:1px 1px 1px 0;
}
.itwiki_template_babel .sigla {
  background:#99b3ff;
  text-align:center;
  font-size:1.2em;
  font-weight:bold;
}
.itwiki_template_babel2 {
  float:left;
  width:20em;
  background:#c5fcdc;
  border:solid #6ef7a7 1px;
  margin:1px 1px 1px 0;
}
.itwiki_template_babel2 .sigla {
  background:#6ef7a7;
  text-align:center;
  font-size:1.2em;
  font-weight:bold;
}
.itwiki_template_babel .sigla,
.itwiki_template_babel2 .sigla {
  width:4em;
}

in

.itwiki_template_babel {
  background:#e0e8ff;
  border:solid #99b3ff 1px;
}
.itwiki_template_babel2 {
  background:#c5fcdc;
  border:solid #6ef7a7 1px;
}
.itwiki_template_babel,
.itwiki_template_babel2 {
  float:left;
  width:20em;
  margin:1px 1px 1px 0;
}
.itwiki_template_babel .sigla {
  background:#99b3ff;
}
.itwiki_template_babel2 .sigla {
  background:#6ef7a7;
}
.itwiki_template_babel .sigla,
.itwiki_template_babel2 .sigla {
  text-align:center;
  font-size:1.2em;
  font-weight:bold;
  width:4em;
}

o in

.itwiki_template_babel {
  background:#e0e8ff;
  border:solid #99b3ff 1px;
  float:left;
  width:20em;
  margin:1px 1px 1px 0;
}
.itwiki_template_babel2 {
  background:#c5fcdc;
  border:solid #6ef7a7 1px;
  float:left;
  width:20em;
  margin:1px 1px 1px 0;
}
.itwiki_template_babel .sigla {
  background:#99b3ff;
  text-align:center;
  font-size:1.2em;
  font-weight:bold;
  width:4em;
}
.itwiki_template_babel2 .sigla {
  background:#6ef7a7;
  text-align:center;
  font-size:1.2em;
  font-weight:bold;
  width:4em;
}

La versione attuale non è né carne né pesce. :) --Andyrom75 (discussioni) 12:42, 22 gen 2015 (CET)

tabelle con dati numerici

è abbastanza ragionevole, quando si compilano delle tabelle con di dati numerici, allineare questi a destra piuttosto che a sinistra, così da poter confrontare a un primo sguardo le cifre dello stesso ordine (decine, unità...) di numeri diversi. questo, per esempio, è il comportamento automatico predefinito di microsoft excell. qui un esempio:

nome	valore
a	456
b	56
c	6833
d	12
e	6310

ho aggiunto a questa tabella la classe "seconda-colonna-numerica", aggiungendo al common.css la proprietà .seconda-colonna-numerica tr > td:nth-child(2) {text-align: right;} la tabella diventerà molto più ordinata, ovviamente creerei anche una classe "terza-colonna-numerica" e così via.

scopro adesso peraltro che questo tema era già stato affrontato qua sopra alla discussione #Allineamento per colonne nelle tabelle. in maniera un po' più generica e con un css meno aggiornato. credo si tratti di un'implementazione utile. --ppong (msg) 13:09, 1 apr 2015 (CEST)

[@ Ppong.it] Io vedo la tabella allineata a sinistra. Comunque concordo con l'allineamento a destra.--MidBi 14:27, 1 apr 2015 (CEST)

eh sì. bisogna fare la modifica al css per avere i numeri a destra. questa è un'anteprima del risultato:

nome	valore
a	456
b	56
c	6833
d	12
e	6310

la modifica dovrebbe riguardare solo le celle semplici e non quelle di intestazione (cioè quelle che si aprono con punti esclamativi piuttosto che con barre verticali). --ppong (msg) 14:32, 1 apr 2015 (CEST)

[@ Ppong.it] nel caso che siano presenti anche i numeri decimali si riesce però ad allineare in base alla virgola? Altrimenti il problema resterebbe inalterato. --Fullerene (msg) 16:28, 1 apr 2015 (CEST)

Sarebbe utile, anche per allineamenti al centro; allo stato attuale dover ripetere text-align in ogni riga è una vera rottura. Solo che la proprietà nth-child non è ancora supportatissima dai browser --Bultro (m) 17:21, 1 apr 2015 (CEST)

sai che pensavo fosse molto più supportata? la soluzione sarebbe usare un codice come quello proposto nella discussione precedente. --ppong (msg) 16:39, 7 apr 2015 (CEST)

Fullerene, con numeri decimali prima di utilizzare questa classe sarebbe opportuno aggiungere zeri sufficienti ad ogni numero in modo che abbiano la stessa quantità di cifre decimali. --ppong (msg) 16:41, 7 apr 2015 (CEST)

[@ Ppong.it] giusto. Comunque concordo con l'allineamento a destra, sicuramente più logico. --Fullerene (msg) 21:51, 7 apr 2015 (CEST)

s'ha procedere? anche con gli altri tipi di allineamento, se si vuole. --ppong (msg) 13:25, 26 mag 2015 (CEST)

Cimeli

Segnalo queste vecchie classi poco usate che potrebbero essere sostituite ed eliminate per fare un po' di pulizia. Ne abbiamo fatta parecchia nei mesi passati, ma non fa mai male.

• itwiki_template_avviso_v (usi)
• itwiki_template_disclaimer (usi)
• itwiki_template_copyright (usi)
• HopContent 30 (usi) - tipo il cassetto ma al passaggio del mouse, preferisco il più accessibile "mostra"
• PPcornerTop (usi) - un obbrobrio che usava delle immagini per simulare i bordi arrotondati. dovrebbe essere sostituibile con border-radius

Poi ci sono numerose righe sotto "Immagini di sfondo" che vengono utilizzate da pochissime pagine se non addirittura da una. Tecnicamente non è possibile mettere gli sfondi con gli stili in linea, ci vuole per forza il CSS, ma valuterei se vale la pena di affollarlo per dei fronzoli locali. --Bultro (m) 16:02, 14 apr 2015 (CEST)

Favorevole a semplificare il più possibile il css comune, anche rinunciando a qualche decorazione/sfondo.--LikeLifer (msg) 19:21, 16 apr 2015 (CEST)

l'HopContent è comunque potenzialmente utile e infattibile senza css, solo varrebbe la pena di aggiungerci una durata di transizione. --ppong (msg) 19:29, 16 apr 2015 (CEST)

avviso-testo e avviso-immagine

per questo template pensavo di usare le due classi nel titolo, le cui proprietà però sono espresse solo all'interno di una table.avviso, che mi sembra una restrizione inutile. cambierei:

table.avviso th.avviso-testo, table.avviso td.avviso-testo {      /* Corpo del messaggio */
  padding: 0.25em 0.5em;                   /* 0.5em sinistra/destra */
  width: 100%;                             /* Rende tutti i template della stessa lunghezza nonostante il testo interno */
}
table.avviso td.avviso-immagine {          /* Stile dell'immagine a sinistra */
  padding: 2px 0px 2px 0.5em;              /* 0.5em sinistra, 0px destra */
  text-align: center; 
}
table.avviso td.avviso-immaginedestra {    /* Stile dell'immagine a destra */
  padding: 2px 4px 2px 0px;                /* 0px sinistra, 4px destra */
  text-align: center; 
}

con:

.avviso-testo {             /* Corpo del messaggio */
  padding: 0.25em 0.5em;
  width: 100%;                             /* Rende tutti i template della stessa lunghezza nonostante il testo interno */
}
.avviso-immagine {          /* Stile dell'immagine a sinistra */
  padding: 2px 0px 2px 0.5em;
  text-align: center;
}
.avviso-immaginedestra {    /* Stile dell'immagine a destra */
  padding: 2px 4px 2px 0px;
  text-align: center;
}

i commenti che ho tolto mi sembrano superflui. --ppong (msg) 17:42, 16 giu 2015 (CEST)

beh? nessuna risposta? farebbe comodo questa modifica. --ppong (msg) 15:26, 28 giu 2015 (CEST)

Hai fatto qualche prova che non ci siano effetti collaterali sui template esistenti? --Bultro (m) 14:41, 29 giu 2015 (CEST)

nessun effetto sui template esistenti. --ppong (msg) 15:29, 29 giu 2015 (CEST)

grazie per la modifica. --ppong (msg) 17:12, 29 giu 2015 (CEST)

Nuovo selettore per nota con citazione a-capo

--Valerio Bozzolan (msg) 16:37, 24 lug 2017 (CEST)

Bugghino in registrazione utente

Monitorato su Phabricator
Task T143923

Segnalo che siccome il nostro testo in MediaWiki:Createacct-helpusername è un po' lunghino, può capitare qualche artefatto grafico durante la registrazione utente (screenshot su Phabricator). Se non vengono in mente idee migliori, per ora applicherei questa patch qui... --Valerio Bozzolan (msg) 00:23, 19 dic 2017 (CET)

IMHO non ne vale la pena. Il commento di Aklapper inquadra bene la situazione. Anche se sistemassimo noi questa piccola imperfezione grafica, probabilmente ce ne sarebbero cento altre e diverse per ogni vecchia versione.--Sakretsu (炸裂) 00:37, 19 dic 2017 (CET)

In verità più che di assurde retro-compatibilità forse sarebbe una correzione di accessibilità :| Alcuni aumentano di proposito il testo per leggere meglio (non io, io sono un aquila). --Valerio Bozzolan (msg) 02:03, 19 dic 2017 (CET)

Facciamolo più corto: (nomi da evitare) --Bultro (m) 14:17, 21 dic 2017 (CET)

+1--Sakretsu (炸裂) 15:19, 21 dic 2017 (CET)

Chapeau. +1 --Valerio Bozzolan (msg) 02:26, 22 dic 2017 (CET)

Disabilitare link

Scrivo qui per maggiore visibilità, ma in realtà riguarda mobile.css. Prendendo spunto da dp:Biografie/Varie#Situazione_ricorrente_bio_di_vescovi/cardinali, poiché i wikilink nei titoli di sezione danno problemi concreti in versione mobile, c'è modo di disabilitarli tramite css? In teoria è possibile con l'attributo pointer-events: none;, poi però anche l'apertura del cassetto non funziona più? --Bultro (m) 23:43, 24 set 2018 (CEST)

Non dovrebbe essere un problema. La proprietà va imposta solo sul collegamento ipertestuale (es. .collapsible-heading .mw-headline > a { pointer-events: none }), non sull'intero cassetto.--Sakretsu (炸裂) 01:32, 25 set 2018 (CEST)

Rimozione classe navbox

In merito alla modifica di utente:Sakretsu: I navbox ci sono in metà delle voci di Wikipedia, mi sembra il caso di lasciare la definizione della classe qui, dove è anche più facile trovarla e personalizzarla. Sennò sta pagina tanto vale eliminarla... --Bultro (m) 16:57, 9 ott 2018 (CEST)

Se poi ci tocca anche fare questa roba, è un regresso --Bultro (m) 17:02, 9 ott 2018 (CEST)

Tocca ribadire che la maggior parte delle classi che ho inizialmente cancellato erano inutilizzate, il che non è una sorpresa visto che più cose diverse si mettono insieme più è difficile fare un resoconto della situazione. Del resto anche caricare il CSS necessario in metà delle voci e non nell'altra significa migliorare notevolmente la performance del sito. È questione di metodo, introdotto appositamente con TemplateStyles e da applicarsi a tutti i template ove possibile. Nel caso della classe navbox c'erano solo 30 anomalie senza Template:Navbox, dovute ad aspetti radicalmente differenti dall'unico realmente associato alla classe. L'esempio che porti è per l'appunto l'opposto di un regresso. Significa caricare il minimo indispensabile invece del doppio (in parte sovrascritto) per uno dei pochi template di navigazione che hanno in realtà più propriamente bisogno di uno stile a sé come capita per i template non di navigazione.--Sakretsu (炸裂) 20:03, 9 ott 2018 (CEST)

Non sta scritto in nessun pilastro "dovete per forza usare TemplateStyles" e in questo caso non sono d'accordo, come non sarei d'accordo per sinottico e poco altro. Anche su en.wiki la classe navbox è ancora tranquillamente nel css infatti. Se nessun altro si esprime non c'è consenso per cambiare lo status quo --Bultro (m) 16:49, 13 ott 2018 (CEST)

(m2c) La modifica di Sakretsu sarebbe corretta solo se la classe navbox fosse usata esclusivamente dal template:Navbox, ma mi pare di capire che così non è. Sono sempre d'accordo con la modularizzazione, ma non quando si va a creare del codice duplicato. --Horcrux (msg) 17:19, 13 ott 2018 (CEST)

Non vedo cosa c'entri en.wiki che sta esportando le sue classi altrove via TemplateStyles in base alle proprie opportunità. @Horcrux nel CSS il codice duplicato si genera quando indichi a un browser di caricare una classe e successivamente di sovrascriverne metà delle proprietà. Non solo: nell'esempio di Bultro (il famoso "questa roba") non c'è nemmeno l'elemento th a cui la classe navbox fa riferimento. E allora perché invocare una classe se si sta facendo tutt'altro? Solo il template Navbox la invocava correttamente, se non fosse che poi la riscriveva una seconda volta con stili in linea (...). Prima di procedere ho controllato i pochi (ab)usi senza template Navbox (lista), ho ricostruito la situazione nel CSS generale e quella nel modulo. Non so se [@ Valerio Bozzolan] abbia il tempo di fare lo stesso e dare un parere sulle mie modifiche, ma comunque se nel frattempo volete ripristinare lo "status quo", prego. P.S. non si tratta di modularizzazione, solo di CSS e dove/come deve essere caricato.--Sakretsu (炸裂) 19:23, 13 ott 2018 (CEST)

Personalmente concordo con l'utilità dell'operazione, per vari motivi. Il primo e principale è che se un template usa la classe navbox, ma poi la sovrascrive a suo piacimento, allora tanto vale che non la usi. Al massimo, gli si può creare una classe specifica e inserirla nel suo TemplateStyles. Inoltre, così sappiamo per certo che la classe navbox viene usata solo dai navbox (nomen omen, come è giusto che sia) e la si può modificare senza aver paura che ciò possa rompere altri template che la usano. Infine, trattandosi di così pochi template, sembrano davvero dei "casi particolari", delle eccezioni che non c'è motivo di mantenere. --Daimona Eaytoy (Scrivimi!) 20:19, 13 ott 2018 (CEST)

Sono molto d'accordo con la migrazione a templatestyle e grazie a [@ Sakretsu] per lo sbattone che sta facendo per le suddette motivazioni, fermo restando che il common.css rimarrà utilissimo per modifiche globali o per modifiche all'interfaccia, fuori dallo scope del #bodyContent. Detto ciò condivido la perplessità di [@ Bultro] e ci tengo a dire a Sakretsu che se vuole un bacino doveva piazzare un templatestyle pure qui Speciale:Diff/100163166 :D E ora via a mandare in tendenza #chiToglieInlineCSSÈUnaBravaPersona #IlCommonÈAncoraUtilissimoMaOraÈInadattoPerTemplate! asd --Valerio Bozzolan (msg) 23:16, 13 ott 2018 (CEST)

Certamente avrei dovuto piazzare un tag templatestyle pure lì, ma nell'immediato ho cominciato a farlo solo da qualche parte e poi ho dovuto accelerare i tempi andando di inline con indicazioni nel campo oggetto. Se mi ricordo li sistemo nei prossimi giorni. In ogni caso, è come dice Valerio: il Common serve ancora, ma non per i navbox, né per la classe sinottico. Non c'è nessun obbligo di usare TemplateStyles, ma nemmeno di non fare le cose nel migliore dei modi con gli strumenti che abbiamo a disposizione.--Sakretsu (炸裂) 23:59, 13 ott 2018 (CEST)

Forse ho compreso male i motivi dello scorporo, ma con "codice duplicato" non mi riferivo a quello generato dinamicamente, ma a quello salvato sul server (esempio: [3][4][5]). Quindi non ne facevo una questione di prestazioni, bensì di manutenibilità del codice (ridondanza, rischio di disomogeneità nel lungo periodo, ecc.). Ma se ciò non è un problema (tanto sono solo "casi particolari"), ok così. --Horcrux (msg) 01:26, 14 ott 2018 (CEST)

Io lo trovo un problema, ma se ho ben capito è possibile fare così per richiamare quella stessa navbox, definita in un posto unico anche se non è il common.css, in qualunque template.

Che succede però alla possibilità di personalizzare i navbox a livello di skin o di utente? --Bultro (m) 19:10, 16 ott 2018 (CEST)

Premesso che ho rivisto il CSS sempre in maniera tale che fosse retrocompatibile, l'unica differenza è che si introduce un netto miglioramento grazie al passaggio da stili inline (es. style="xxxxxx") a foglio di stile esterno (cioè la pagina .css caricata). In sostanza mentre gli stili inline sono direttamenti annessi all'elemento cui si riferiscono, con l'uso di classi ad hoc e in generale di CSS non inline si può personalizzare ogni aspetto dei template giocando di specificità (in precedenza senza questa comodità sorgevano invece limiti/difficoltà ed era anche necessario l'uso di !important). In particolare per ogni navbox ho attivato un ID unico e automatico che può essere sfruttato sia con TemplateStyles (esempio di qualcosa che prima non era possibile: cambiare il colore dei link come "mostra/nascondi") sia con il CSS personale e delle skin.--Sakretsu (炸裂) 20:18, 16 ott 2018 (CEST)

Io sto parlando di Aiuto:Stile utente. Se uno volesse personalizzare l'aspetto generale dei navbox tramite Speciale:MiaPagina/common.css, non viene scavalcato da TemplateStyles?

(tra parentesi, possibile o no, non bisogna cambiare il colore dei link. blu = pagina esistente, rosso = pagina inesistente, cambiarlo va contro l'accessibilità solo per un vezzo) --Bultro (m) 00:52, 18 ott 2018 (CEST)

La risposta è quella; forse qui è più chiaro. Non è scavalcato se, come è previsto che sia, si gioca di specificità. Quanto al colore dei link, non è una mia novità e richiederebbe una discussione a parte.--Sakretsu (炸裂) 18:25, 18 ott 2018 (CEST)

TemplateStyles

Alcune regole CSS sono usate solo da alcuni template in un piccolo numero di pagine. Grazie all'estensione TemplateStyles adesso è possibile inserire delle regole aggiuntive solo quando quei template sono caricati, così da ridurre il codice che viene caricato per ogni pagina vista; vedi phab:T228604. Un primo esempio con {{TOClimit}} consiste in:

• spostare il codice da MediaWiki:Commons.css a una sottopagina del template;
• se il template è protetto, dare alla sottopagina lo stesso livello di protezione;
• richiamare i CSS dal template.

C'è un po' di codice che può fare la stessa fine. - Laurentius^(rispondimi) 15:37, 14 ago 2019 (CEST)

Con un po' di ripulitura (grazie anche a Daimona Eaytoy) se n'è andato circa un quarto del codice. C'è ancora qualcosa che si può fare, ma buona parte di quello che c'è adesso non può essere fatto altrimenti oppure richiede di modificare un po' più di pagine:

• la personalizzazione di Aiuto:Sportello informazioni non può essere fatta tramite TemplateStyles perché non riguarda il contenuto delle voci ma l'interfaccia, seppur per una sola pagina;
• IPA e polytonic sono usate anche in namespace principale e soprattutto in MediaWiki:Edittools, su cui TemplateStyles non funziona;
• le classi per i template sinottici e gli avvisi sono usate da {{Infobox}} e {{Avviso}}, presenti rispettivamente nel 50% e nell'80% delle voci, quindi ha senso tenerli qui;
• le classi dei babelbox sono usate direttamente in parecchie pagine;
• un tot sono usate sia in template che direttamente (es. messagebox);
• altre regole riguardano elementi dell'interfaccia o standard, e quindi devono stare qui. - Laurentius^(rispondimi) 19:46, 25 ago 2019 (CEST)

[@ Laurentius] Grazie a te! Unica cosa, mi chiedo se la modifica relativa al {{Coord}} non sia "eccessiva": essendo il template vastamente usato, mi pareva che fosse da evitare per quanto scritto su T228604, ma magari ho capito male. Per il resto direi che concordo con i punti qui sopra, tranne forse lo sportello informazioni: magari si potrebbe spostare la testata in ns10 e caricare il CSS da lì. --Daimona Eaytoy (Scrivimi!) 19:56, 25 ago 2019 (CEST)

Finché ci si assicura che non si rompa nulla ed è normale che una classe sia usata solo dal relativo template, è meglio TemplateStyles. Common.css non è caricato solo nel namespace 0, ma in tutte le pagine del sito. Quanto allo sportello informazioni, cambiare namespace non influisce. TemplateStyles prende di mira solo il contenuto delle pagine via classe mw-parser-output--Sakretsu (炸裂) 21:22, 25 ago 2019 (CEST)

[@ Daimona Eaytoy] durante quel "Clean up party" all'hackathon ho chiesto allo sviluppatore che l'ha organizzato quale fosse la soglia; la risposta è che le performance dipendono da un po' di fattori non prevedibili, ma che si può considerare il 50%. Sto tenendo buona quell'indicazione: il modulo Coord è usato circa nel 20% delle pagine del namespace principale, che sono molte ma comunque una minoranza. Per quanto riguarda lo sportello informazioni, è come dice Sakretsu: nonostante l'estensione si chiami TemplateStyles, si applica a tutte le pagine, i template non sono trattati in modo speciale. - Laurentius^(rispondimi) 22:15, 25 ago 2019 (CEST)

[@ Laurentius] Ecco l'informazione che mi mancava :-) Ad esser sincero pensavo (a naso) che il coord lo usassero più voci, ma stanti così le cose, ottimo! [@ Sakretsu] Mannaggia, non ci avevo pensato (e non mi ero neanche posto il problema che potesse funzionare fuori dal ns10). È un po' "triste" che quel pezzo di css, usato da una sola pagina, venga caricato in tutte. Però a quanto pare non c'è davvero alternativa. Neanche configurando VE nelle impostazioni del sito lo si può fare, si può solo disattivare da tutto il ns. Pazienza... --Daimona Eaytoy (Scrivimi!) 09:49, 26 ago 2019 (CEST)

Aggiunta stile liste note

Salve. Come è possibile notare in questo esempio nella mia sandbox, attualmente non vi è continuità tra gli stili di note indicati nel parametro ref e quello references. Infatti, se in ref metto come gruppo lower-alpha, a lato della nota compare la lettera a, ma questa non compare nella lista note a fine pagina, creando confusione nel lettore. Non sono un esperto, ma penso vada copiata dal CSS di en.wiki questa linea di codice per il parametro references:

list-style-type: inherit;  /* Enable custom list style types */

Se qualcuno è in grado di risolvere questo problema, per favore lo faccia. Grazie.--TheVampire (msg) 18:01, 26 mag 2020 (CEST)

Non sarebbe sufficiente. Su en.wiki usano il template Reflist per generare le note. È quello che manipola nel concreto il tipo di elenco. Qui ci siamo sempre tenuti sul semplice col tag references. Il problema andrebbe risolto a monte rimediando in phab:T198021 a una pessima scelta che ha reso simili incongruenze possibili.--Sakretsu (炸裂) 20:41, 29 mag 2020 (CEST)

Proposta sfoltimento, edizione 2022

Il common.css è ancora troppo lungo, e parecchi pezzi potrebbero essere spostati altrove o rimossi (non gratuitamente però). Segue una lista di proposte di modifiche:

• Classi "IPA" e "polytonic": rimuovere. Sono workaround per IE6, la cui ultima versione risale al 2008. Se qualcuno lo usa ancora ha problemi ben più grandi della visualizzazione dell'IPA. Il software MediaWiki stesso non supporta ufficialmente IE6 dal 2014 (ref).
• Classi "arabo", "farsi" e "curdo": se sono utilizzate dai rispettivi template come scritto, spostare in templatestyles.
• Idealmente le classi per i sinottici dovrebbero usare templatestyles, ma c'è un'enormità di template che le usa e al momento mi pare difficile da risolvere.
• Classi template di avviso: spostare in templatestyles per {{Avviso}}, usare quest'ultimo nei pochi casi in cui la classe viene applicata manualmente.
• Classi dei babel: spostare in templatestyles per {{SchedaBabelfish}}, {{Babel}} e affini (valutare esattamente quali e dove). Questa è tosta perché parecchie PU usano queste classi manualmente, ma è anche vero che sono stili irrilevanti per le voci dell'enciclopedia ed è assolutamente inutile caricarli ovunque.
• Classe "itwiki_template_avviso": non è chiara la sua funzione. Al momento, di fatto, ha circa 19000 utilizzi di cui 16000 nelle PDC, parecchi insieme alla classe toccolours (che è definita da MW, ma servirebbe per l'indice). Idealmente proporrei di apporre {{FineCanc}} e analoghi via bot, ma sarebbe un lavoraccio e probabilmente non ne vale la pena.
• Classe "itwiki_template_toc": usata in tantissimi modi diversi, e niente a che vedere con l'indice mi pare. Sostituirei con classi il cui utilizzo sia più chiaro, da inserire direttamente nei template dove servono via templatestyles.
• Regola div.cassetto .mw-collapsible-toggle: non basterebbe metterla in un templatestyles per il {{Cassetto}}?
• Regola responsive-columns per vecchie versioni di firefox: toglierei. Firefox 27 è del 2014, e non più supportato da MediaWiki.

Suggerimenti, pareri? --Daimona Eaytoy (Scrivimi!) 20:25, 4 giu 2022 (CEST)

La classe Sinottico è usata in due terzi delle voci, la classe Avviso anche di più. Dato che praticamente tutti le vedono, non è giusto dopotutto che stiano nel css generale? Senza contare le difficoltà pratiche, siamo sicuri che far caricare a quasi tutti un templatestyles in più è meglio che avere un Common un po' più lungo?

Il resto mi pare tutto fattibile, è solo questione di dare la caccia a tutti gli usi fantasiosi che sono stati fatti delle classi. I vari itwiki_template_eccetera avevo già provato a smaltirli molti anni fa ma è complicato. Con i babel bisognerebbe prendere la decisione (magari al bar) di sacrificare le vecchie pagine utente che non usano i template.

Aggiungo quella parte sullo sportello informazioni: è così grave se qualcuno lo apre con VE? hanno provato a eliminarla in passato ma serviva non so quale consenso --Bultro (m) 22:11, 7 giu 2022 (CEST)

Giusto, in effetti non consideravo il discorso della quantità di voci che usano determinati stili. Ricordo che ci era stato dato il suggerimento di continuare a usare il common.css in quei casi anziché templatestyles, ma non so se ciò sia sempre vero. Dei babel utente sto provando a occuparmene, di pagine che usano le classi manualmente ce ne sono migliaia, e sarebbe un peccato sacrificarle tutte. Sto passando col bot a sostituire tutto con gli appositi template, ma ci vorrà del tempo considerando che la fantasia del wikipediano medio è inversamente proporzionale alla sua capacità di scrivere HTML valido. Riguardo allo sportello informazioni, effettivamente non capisco quale sia il problema se qualcuno usa VE; tanto più che la pagina è fatta appositamente per utenti alle prime armi, che dunque più probabilmente useranno VE. --Daimona Eaytoy (Scrivimi!) 01:03, 8 giu 2022 (CEST)

Come scritto più su, bisogna considerare tutte le pagine dell'enciclopedia e non solo le voci. Nella maggior parte delle pagine quegli stili non servono. Usare TemplateStyles per avvisi e sinottici estenderebbe anche a tutti i sysop il diritto di modifica. Il problema degli stili caricati per una sola pagina come quelli dello sportello informazioni si potrà invece risolvere una volta che sarà completato il task T63007. Non so quanto senso abbia nascondere solo il VE, ma è garantito che nessun niubbo firmerà mai i suoi interventi se lo usa. I nuovi form Rispondi e Aggiungi argomento sono di gran lunga meglio della modifica del wikitesto, figuriamoci del VE che non è fatto per le discussioni. Nonostante questo, possiamo provare a mostrare di nuovo il pulsante del VE confidando che passerà inosservato e che non causerà chissà che effetti indesiderati quelle poche volte che sarà usato --Sakretsu (炸裂) 13:11, 9 giu 2022 (CEST)

[@ Sakretsu] Sul considerare tutte le pagine hai ragione, però penso che le ottimizzazioni di questo tipo debbano sempre favorire le voci, per questo mi chiedevo se spostandole in templatestyles ci sarebbero effetti avversi. L'estensione dei diritti di modifica a tutti i sysop in effetti non l'avevo considerata, potrebbe essere un punto a favore. Comunque per il momento procedo alla rimozione di stili per browser antidiluviani e della regola per VE sullo sportello informazioni, anche in virtù del DiscussionTools a cui non avevo pensato. --Daimona Eaytoy (Scrivimi!) 15:10, 10 giu 2022 (CEST)

Grazie Daimona. Sul coso del cassetto sono perfettamente d'accordo. Forse sono l'ultimo che ha toccato quel coso nel Common.css solo perché non c'era templatestyle. --Valerio Bozzolan (msg) 18:43, 10 giu 2022 (CEST)

Usare TemplateStyles probabilmente non conviene per i template che possono essere transclusi anche un gran numero di volte (200+) nella stessa pagina. È questo il caso dei template Cita e forse anche dei template Arabo, Farsi e Curdo. Le dimensioni post-espansione aumentano di parecchio a causa dei tag link. Altro non mi viene in mente. Sentiamo anche @Valerio Bozzolan già che ci siamo --Sakretsu (炸裂) 14:39, 11 giu 2022 (CEST)

Questo è vero, anche se mi pare una cosa che forse andrebbe risolta direttamente nell'estensione TemplateStyles. A margine o forse no, una cosa del genere succederà alle pagine utente con i babel. IMHO però non è un problema perché il numero di babel non è mai elevato (in media saranno sui 5-10, il massimo che ho visto sarà attorno a una cinquantina ma sono pochissime pagine), e perché si tratta pur sempre di pagine utente, quindi non importa che funzionino alla perfezione. --Daimona Eaytoy (Scrivimi!) 16:32, 11 giu 2022 (CEST)

Le considerazioni di Sakretsu sono valide ma la manutenibilità che permette l'estensione TemplateStyles secondo me supera di gran lunga questo svantaggio (la possibilità di non dover modificare il Common.css vince contro le attuali n righe in più nel DOM se hai n fonti) e sono d'accordo con Daimona che sia una cosa sensata da poter tenere conto e da poter risolvere nell'estensione (anche dopo la conversione). --Valerio Bozzolan (msg) 12:52, 14 giu 2022 (CEST)

[← Rientro] Dovrei aver finalmente concluso con le classi dei babel. Adesso tutte le PU usano gli appositi template, e lo stesso vale per alcune (relativamente poche) pagine in altri ns. Rimangono 203 utilizzi delle classi (tutti fuori dal ns2) ma si tratta solo di discussioni, e non mi pare il caso di toccarli. Domani provvedo allo spostamento degli stili da qui al templatestyles. --Daimona Eaytoy (Scrivimi!) 01:58, 15 giu 2022 (CEST)

Ho spostato le classi dei babel nei rispettivi templatestyles e dato una ripulita. Ho anche spostato la regola per il cassetto (cannando l'oggetto), essendoci già Template:Cassetto/styles.css. Ora sto dando un'occhiata al resto. Tra le altre cose ho notato che gli stili per {{Div col}} e {{Note strette}} erano stati spostati in Template:Div col/styles.css nel 2019, ma la modifica era stata annullata per questa discussione. Effettivamente le regole con prefissi specifici non si possono usare in templatestyles. Da qui risulta che i prefissi sono necessari per FF <= 49 (2016), Chrome <= 49 (2016), Safari <= 8 (2014) e iOS Safari <= 8.4 (2014). Sono tutti browser abbastanza vecchi, ma quelle versioni di FF e Chrome sono ancora supportate dal software MediaWiki (in categoria "basic"). A occhio mi sembra che la percentuale di richieste da quei browser sia molto bassa, ma suppongo che si possano tenere le regole nel common.css ancora per un po'. --Daimona Eaytoy (Scrivimi!) 14:02, 15 giu 2022 (CEST)

Prepare for T314318

Hi,

Can someone make this forward / backwards compatible edit in preparation for enabling changes to how media is rendered?

https://it.wikipedia.org/wiki/Speciale:ComparaPagine?page1=MediaWiki%3ACommon.css&rev1=&page2=Utente%3AArlolra%2Fsandbox%2FMediaWiki%3ACommon.css&rev2=&action=&unhide=

There's some explanation of the reason for this change at mw:Parsoid/Parser_Unification/Media_structure/FAQ

Thanks, Arlolra (msg) 21:03, 27 ott 2022 (CEST)

Done --Sakretsu (炸裂) 23:05, 27 ott 2022 (CEST)

Grazie --Arlolra (msg) 23:09, 27 ott 2022 (CEST)

Aggiunta plainrowheaders

Buonasera. Volevo chiedervi se fosse possibile aggiungere questo pezzo di codice: .wikitable.plainrowheaders th[scope=row], .wikitable.plainrowheaders th[scope=rowgroup] { font-weight: normal; /* @noflip */ text-align: left; }

che consente alle tabelle che usano la classe plainrowheaders di avere un automatico allineamento a sinistra della colonna header, in modo da non dover fare ogni volta l'override per il text-align:left. Grazie in anticipo, qualunque sia il responso. --Redjedi23 T 19:55, 18 mar 2023 (CET)

(specifico che questa è una parte che ho preso pari pari dal common.css su enwiki) --Redjedi23 T 18:53, 19 mar 2023 (CET)

@Sakretsu scusami in anticipo per il ping... Siccome sei l'unico con cui mi sono interfacciato (seppur in solo un'occasione) che si occupa di queste cose non sapevo a chi altro chiedere, altrimenti non ti avrei disturbato. Cosa ne pensi di questa possibile aggiunta da enwiki? Se vuoi un confronto diretto tra com'è qui e com'è lì, guarda Bozza:DC Universe (franchise)#Film e en:DC Universe (franchise)#Films. Un saluto e scusa ancora per il disturbo. --Redjedi23 T 21:04, 20 mar 2023 (CET)

Intanto sarebbe da discutere come e perché usare la classe plainrowheaders, che da noi non è descritta in Aiuto:Tabelle né altrove. A parer mio quelle nell'esempio dovrebbero essere semplicemente delle normali caselle bianche --Bultro (m) 23:24, 23 mar 2023 (CET)

Scusa, non sapevo nemmeno dell'esistenza di Aiuto:Tabelle e non sapevo come muovermi.

Ad ogni modo, andrebbe usata ogni qualvolta ci troviamo davanti una tabella in cui abbiamo la necessità di introdurre delle header column. Nel caso in esempio, si può parlare tranquillamente di header column, siccome il film in questione è il main argument della riga da cui tutte informazioni inserite poi dipenderanno. --Redjedi23 T 00:07, 24 mar 2023 (CET)

Siccome ho una memoria pessima, correggo un refuso. Conoscevo aiuto:tabelle e avevo aperto una discussione lì qualche giorno fa, ho controllato ora. --Redjedi23 T 00:16, 24 mar 2023 (CET)

Belle paroline inglesi, ma non vedo il vantaggio del fondo grigio. C'è una valanga di altre tabelle simili dove nessuno ha sentito il bisogno di evidenziare la prima colonna. Oltretutto così non è un header, non è né carne né pesce --Bultro (m) 01:24, 25 mar 2023 (CET)

Non ho capito il senso di ironizzare sulla cosa quasi a sminuire. L'ho chiamata "header column" perché sono abituato a chiamarla così, siccome in tutti i programmi che uso dove ci sono tabelle così viene indicata, ma se vuoi uso un più italiano "colonna d'intestazione", sinceramente poco cambia.

Ripeto, tutto le altre celle della riga sono in funzione della prima, se non è questo il caso di una colonna d'intestazione... --Redjedi23 T 01:30, 25 mar 2023 (CET)

Inoltre, il fatto che nessuno abbia mai posto la questione prima d'ora è un non-argomento, al quale si potrebbe obbiettare in tremila modi diversi, partendo dal più controverso in itwiki ovvero che in altre edizioni questo problema se lo sono evidentemente posto (e credo faccia bene ogni tanto uscire dalla propria bolla). Questo "argomento" poi potrebbe smontare ogni singola nuova proposta e personalmente lo reputo abbastanza ridicolo, scusami se lo dico e senza offesa alcuna nei tuoi confronti. --Redjedi23 T 01:34, 25 mar 2023 (CET)

Chiamala come vuoi, ma io non ritengo migliorativo evidenziarla in quel modo, né in chiarezza né in bellezza. Ad esempio in Provincia di Ancona#Comuni, tipica tabella nello stile di it.wiki (non copincollata da en.wiki), i comuni sono la colonna d'intestazione secondo il tuo criterio, e per me stanno benissimo a fondo bianco. Puoi sempre proporre un cambiamento stilistico, ma prima si trova consenso sul concetto, poi si vede come realizzarlo su CSS --Bultro (m) 11:31, 25 mar 2023 (CET)

Ammetto di aver copiato la tabella da enwiki (ma non l'ho mai nascosto in realtà) per ignoranza, nel senso che non sapevo che le singoli classi andassero prima discusse e credevo fossero più o meno tutte utilizzabili a priori, non so se mi spiego.

A dire il vero però, le colonne d'intestazione non sono inedite su itwiki. Se guardiamo le tabelle generate con ClimaAnnuale, ad esempio, vediamo come la colonna d'intestazione c'è eccome. In generale troviamo un po' in giro per l'enciclopedia diverse tabelle con le header column, dichiarate con !scope="col". Pertanto credo che si possa nel frattempo introdurre questa classe per dare un'alternativa su come queste colonne vengano visualizzate. In alcuni casi può avere senso usarle come in Napoli, per ragioni estetiche, però, credo che questa non sia la soluzione migliori in casi come en:DC Universe (franchise)#film, dove risulta assai più gradevole la soluzione di rimuovere il grassetto e allineare tutto a sinistra.

Comunque grazie, mi rivolgerò su Aiuto:Tabelle. --Redjedi23 T 13:01, 25 mar 2023 (CET)