Open CiaobyDany opened 6 years ago
Quando hai aperto quest'issue avevo da poco visualizzato questa anteprima, e mi stavo proprio chiedendo cosa farci quindi bravo che mi hai ninjato.
Poi le mie opinioni:
normal -> light -> normal
oltre a light -> normal -> light
PS: modificare il modulo css per avere la doppia sfumatura con la sintassi del type
dovrebbe essere facile, quindi da quel punto di vista qualsiasi soluzione è approvata.
@flavio-a Non dimenticate che certi colori light sono troppo chiari, secondo me è meglio normale - light - normale
Se ci sono due tipi si lascia as is. Il problema è lo sbilanciamento della pagina, soprattutto da mobile in cui attualmente "pende" verso destra, se fai un gradiente pesato al centro perdi questo effetto.
@lucas992 in realtà volevo anche usare questa issue come feedback per i colori problematici/da cambiare, ma non sapevo quanto fossi in-topic. Generalmente i colori light sono "giusti", l'unico problema evidente ce l'abbiamo con il colore attacco direi, quindi non darei la priorità su normale-light-normale. Qualcuno ha fatto una prova su una pagina per confrontare le opzioni?
@CiaobyDany Anche un colore del GCC ha questo problema, e in generale ricontrollerei tutti quelli "vicini" al giallo
@lucas992 Quelli del gcc sono stati importati da Bulba e mai modificati, potrei risolverlo (forse). Il giallo è un immenso problema però, sì, potesse essere abolito saremmo tutti più felici.
Comunque a prescindere dal colore chiaro problematico o meno, i box di due tipi vanno da un colore normale a un colore normale, quindi trovo più coerente che anche quelli monotipo abbiano normale ai bordi.
@lucas992 Questa è una buona argomentazione in effetti....
Anche questa discussione si è un po' persa :D allora vogliamo passare da light
-> normale
a normale
-> light
-> normale
?
Ricordo vagamente di una discussione con Denelio che servirebbero delle prove. Perché lo gradiente triplo, a mio avviso, non si vede sulle cose non sufficientemente larghe.
In alcuni casi è vero che non si nota troppo la presenza del gradiente. Ma è un problema ciò?
Ne approfitto anche per far notare che per certi colori la versione light
è perfettamente identica alla normale
. È voluta questa cosa? (https://wiki.pokemoncentral.it/Utente:Lucas992/Elenco_colori guardate per esempio i gruppi Uova)
@lucas992 dovrebbe succedere solo per i gruppi uova, alcuni colori _text, FFF e 000. Gli ultimi due per ovvi motivi, i colori _text perché credo che dovrebbe funzionare lo stesso su tutte e tre le shades del colore e i primi perché Dany non aveva (giustamente) voglia di inventarli visto che non c'erano su Bulba e non vengono usati tipo da nessuna parte. Non so di nessun altro caso di uguaglianza
Come ha osservato Crusca decidiamo se vogliamo o meno i cerchietti intorno ai MiniSprite. Secondo me sono un po' abbondanti (specie in elenchi molto più colorati di questo tipo il movelist (esempio) quindi se devo decidere tra sempre e mai dico mai. Se invece vogliamo metterli solo negli elenchi molto bianchi (tipo quello nell'immagine) mi va bene.
Come detto, per me va bene toglierlo da questo elenco. Comunque in quell'esempio che hai fatto i tipi sono già indicati, quindi è proprio inutile il radialgrad
lì.
a parte il caso specifico di questi due elenchi, il vero problema è che non abbiamo delle linee guida per stabilire quando usarlo oppure non usarlo. Visto che tutte le indicazioni all'inizio le aveva date @CiaobyDany, lo invoco per illuminarci sulla situazione. Anche con calma, penso che nessuno abbia furia.
@Cruifer È un periodo in cui sono un po' tanto preso. Quindi fatemi capire subito che priorità ha la cosa, o probabilmente ci guardo tra un mese.
@CiaobyDany Direi molto bassa; come ho detto, nessuno ha fretta spero
Up
Riuppo la questione. Innanzitutto per il normale>light>normale sui monotype su cui continuo ad essere favorevole. (per quanto riguarda i boxtipo sinceramente inizierei a considerare di cambiarli con le immagini dei tipi di SpSc che mi paiono sufficientemente grandi da non risultare pixelate e che non credo pesino troppo più di un box in gradiente, ma forse è meglio una issue a parte su questo) In secondo luogo per la questione radialgrad intorno ai Pokémon non saprei. Fare assoluti da applicare in casi che poi finiscono per essere drasticamente differenti non mi sembra particolarmente saggio. Nello screenshot che ha messo Flavio ci stanno bene. Nei movelist, che sono drasticamente differenti, va bene non metterli soprattutto considerando che ci sono specificati i tipi accanto. Ma, ad esempio, in template tipo il catch che non è particolarmente bianco secondo me sono ugualmente necessari perché chi guarda la pagina potrebbe voler decidere quali Pokémon catturare anche in base al tipo, e non è detto che tutti sappiano a memoria i tipi di ogni Pokémon.
Se volete il normale -> light -> normale io posso modificare il modulo css, però andrebbe ad impattare tutte le pagine in cui si usa la sintassi con il type
. Che di base è un vantaggio perché con una sola modifica si aggiornano tantissime pagine, però meglio sapere cosa stiamo facendo.
Le immagini dei tipi probabilmente pesano meno di un box in gradiente una volta caricate, e tanto sono solo 18 immagini che vengono pure cachate dai browser, quindi approvo. La domanda è: abbiamo quelle di SpSc o dobbiamo usarne di più vecchie?
Per i radialgrad intorno ai MS se dobbiamo decidere caso per caso non c'è molto da discutere, li metto nel VexEntry (quello dell'immagine) e poi ogni caso si discute a sé (anche su Telegram).
Sinceramente direi di aspettare periodi più calmi (che non so quando saranno) perché sì, è un cambiamento importante quindi va pesato bene. Le immagini dei tipi le abbiamo circa di SpSc, non ho ancora avuto tempo di sistemarle (erano in uno zip di abcboy ma erano solo le maschere con i colori da applicare a parte non so bene perché, forse ha a che vedere con il fatto che durante il Dygamax cambiano colore). Faccio presente che abbiamo sia i simboli che i loghi con nome esteso.
Also: ricordo a tutti, soprattutto @orionumeri che qui non è presente, ma a cui incollerò la issue sotto il naso, che avevamo optato per single color sui personaggi ove possibile per evitare gradienti da pugno in un occhio.
Girovagavo per la wiki in cerca di distrazioni, e ho notato che in questa pagina il gradiente non si nota per nulla, quindi i colori per zona_neve
sono troppo simili. Vale la pena di vedere se ci sono altri casi simili?
@Cruifer Possibilmente sì, grazie, così ci lavoro insieme agli altri.
Descrizione
Da quando abbiamo introdotto i gradienti lo stile di PCW è notevolmente migliorato e circa tutto il mondo è d'accordo nel dire che siamo molto più belli di Bulba (ad eccezione di qualche pirla che trova seriamente gradevole il layout di Serebii, ma che direi non sia da prendere in considerazione). Tuttavia il cambiamento è stato un enorme trial & error che non ha mai avuto delle linee guida precise da seguire, da cui la necessità di creare un punto di riferimento. Sappiamo tutti che in linea di massima i gradienti si fanno light to normal con box bianchi al loro interno, ma non sempre questo è applicabile e ci sono in particolare alcuni casi degni di nota da considerare.
Pagine affette
Pressoché tre quarti di wiki
Risoluzione del problema
I problemi sono diversi, qui metto i tre più lampanti.
Partiamo dai box di vario genere dei personaggi: nel 90% dei casi continuiamo ad incollare da Bulba i colori con risultati a volte impressionanti (NB: non è in senso positivo). Perché se un personaggio è vestito di arancione ma ha un cappello verde chiaro, fare gli infobox arancioni con bordo verde ha un certo effetto visivo, fare un gradiente da arancione a verde ne ha un altro (circa simile ad un pugno in un occhio). Cosa fare in questi casi? La soluzione è più banale di quanto si possa credere: mettiamo un colore solo. Si prende il colore più rappresentativo del personaggio (arancione, ad esempio) e si fa tutto così.
Seconda questione: @mexicat tempo fa aveva proposto di cambiare i gradienti per far diventare lo standard monocolor light to normal to light per riequilibrare le pagine. Attualmente è possibile implementarlo facilmente nel modulo css se viene usata la sintassi con type. Direi di iniziare a farlo così da poter poi identificare facilmente chi ha mantenuto la vecchia sintassi e aggiornare anche quelli. Se la transizione sarà lunga non credo sia un grosso problema: abbiamo impiegato anni per passare quasi definitivamente dai solid color ai gradienti, la disuniformità che si creerà sarà molto più trascurabile.
Terza questione: cosa fare con box dentro a contenitori a gradiente. Cercherei di non mettere gradienti a contatto con altri gradienti se possibile, soprattutto se sono di contenuto. I template degli allenatori hanno dimostrato che può essere molto carino mettere gradienti radiali dentro box bianchi dentro a gradienti. Quel layout lo vorrei vedere applicato nei catch (con calma, abbiamo altre priorità), ma non mi dispiacerebbe vedere delle prove anche negli evobox. Una valida alternativa può essere il layout usato nei template degli allenatori con tanti box bianchi che hanno dei finti bordi in gradiente (finti bordi perché de facto sono div parent in gradiente).
Screenshot
Originale su Bulba Importazione "as is" da noi Dopo la cura
Se qualcuno avesse altri dubbi sul perché non vanno bene i gradienti dentro ad altri gradienti.
P.S. ho assegnato Flavio e Maze solo perché devono sistemare nel modulo css i gradienti, non sto lasciando a loro la decisione anche se un loro parere sarebbe molto ben accetto.