Tema de Viquiprojecte Discussió:Adaptacions per al Mode Fosc

@Vriullop Mira com queda el nou format que he fet servir com a headerstyle a infobox person. Ex.:https://ca.wikipedia.org/w/index.php?oldid=33543625

És menys intrusiu en mode clar i ajuda a enquadrar en mode fosc.

Si observes com surt "obres notables", ja tinc la resposta al dubte que tenies quan vas instal·lar la class a la Collapsible conditional list, quan preguntaves si enlloc de infobox_headerstyle volia posar infobox-style. Doncs sí, per tenir menys línies, és millor la infobox.style. Però ho he canviat (línia 436) i no fa cas. Que he fet malament ?

Perfecte, es veu clar, o fosc segons com es miri :-)

El camp d'obres notables el veig bé. Jo crec que anaves bé, potser algun problema de refrescar pàgina o bé alguna col·lisió entre class. L'opció era format header o format label. Li he deixat només infobox-label. L'únic que hi trobo, en mode clar, és el fons més llarg que els altres labels. Potser és millor eliminar la definició with:40% i que surti al 100%.

Ahir al wikt em vaig trobar amb problemes semblants aparentment inexplicables. Vaig arribar a la conclusió que fins que no ho traslladem tot, els estils del mòdul i del mediawiki:common.css a un infobox/styles.css, ens podem trobar col·lisions empipadores.

Per cert, m'he trobat que el mode fosc és diferent en Vector i en Minerva. El que més interessa és en versió mòbil. L'encapçalament d'obres notables no sortia bé. Sembla que no interpreta bé un infobox-label que és dins d'un infobox-data, així que hi he afegit una definició per mode fosc per a aquest cas perquè l'hereti com un infobox-label.

Per altra banda, tenim un problema vell. Els headers buits surten buits en mòbil amb el seu border.

No entenc lo dels headers buits. No han d'haver. Estava mirant l'article del puigdemont actual i surten línies buides a la llista de càrrecs, però això és amb la versió vigent.

Les proves s'han de fer amb infobox person que és on estic fent tots els canvis del mode fosc, perquè és una versió més avançada i, a més, la vigent no treballa amb styles, o sigui que pot passar qualsevol cosa.

Ho veig a Puigdemont en versió mòbil tant amb la actual infotaula actual com amb la nova. Potser no són headers, no he comprovat on surten.

ja ho revisaré.

@Vriullop

Continuo amb els headers. Amb la infobox person hem fet el que hem volgut, perquè està en proves i ningú se sent agredit perquè no ho veu, però si eliminem els colors en la versió clar, no s'entendrà perquè cal eliminar-los si fins ara els tenim.

He canviat seguint el teu exemple i li he posat 2 classes: primer la dels border top i bottom pel mode fosc i després el que estem fent servir actualment pel mode clar. Així, res canvia visualment si consulten en clar, com sempre

Pots veure-ho als exemples que hi ha a {{infobox person}}. Això sí, el tema d'adaptar icones i backgrounds que s'han de veure tant en clar com en fosc (exemple {{Infotaula competició esportiva/ús}} ), han de ser de colors iguals per les dues situacions.

Què et sembla ?

Així que em responguis em posaré a crear styles per totes les infotaules (només tenen les grans) i a adaptar-les totes.

Em sembla bé.

He unificat les dues class, no calia separar-les, feien el mateix: en clar surt tal com està definit, en Vector fosc només canvia el background, en Minerva fosc no en fa cas perquè té una definició pròpia de infobox-header.

Caldria diferenciar les class genèriques de les class particulars d'una infobox. Són genèriques les afegides pel mòdul: infobox-header, infobox-label, infobox-full-data, infobox-data. També ho són les que s'haurien de definir igual en totes les infotaules. Són particulars les que només s'usen en un tipus d'infotaula. Per clarificar, les particulars haurien de tenir un nom que identifiqui la plantilla on s'usen, per exemple ib-person-pharaon-titlestyle. Al final, les genèriques s'hauran de traslladar al templatestyles del mòdul. Abans he d'actualitzar-lo perquè ho accepti.

Entesos amb la fusió, gràcies.

A veure si em puc situar sobre el model a seguir:

• Què és Minerva ?. L'app?
• Les genèriques del mòdul les tinc clar. Sempre havia entès que els paràmetres específics que se li aportaven via styles o amb un div/span s'afegien o anul·laven els del mòdul si ja existia.
• El problema (fins ara) era que t'havies de saber quins valors o classes aplicava el mòdul. Entenc que amb els styles.css serà més fàcil saber que fan per defecte.
• Les particulars d'una infotaula les estic fent quasi-clòniques per evitar dubtar i haver de mirar contínuament els seus valors quan es fa servir. De fet, normalment només canvia el background.
• Quan alguna infotaula requereix una altra combinació de valors, per exemple perquè cal forçar una negreta o un alineament diferent per un ús atípic d'un datann per allotjar altra mena de contingut, llavors li hi poso noms particulars. L'única cosa que no feia era indicar el nom de la infotaula usuaria
• Tinc dubtes de quin efecte té que a les classes les anomenem infobox_abcabc en tot aquest joc de generals/particulars.
• Per cert, parlant de particularitats. M'he trobat a infotaula organització alguns div style exclusivament per canviar l'alineament. Entenc que per un ús com aquest no cal amoïnar-se, perquè no tenen efecte amb el tema, oi?.

He afegit una llista d'infotaules a revisar amb canvis fets i pendents al viquiprojecte. Si vols afegir coses a fer, tindrem un ToDo estructurat.

Seguim,

• Minerva és l'aparença, l'equivalent a Vector per a mòbil, aka Mobile, però tècnicament per fer un enllaç és https://ca.wikipedia.org/wiki/Tei%C3%A0?useskin=minerva, en fosc https://ca.wikipedia.org/wiki/Tei%C3%A0?useskin=minerva&minervanightmode=1
• Sí, trobo que és massa obscur quines són les class que utilitza el mòdul i què es pot canviar amb paràmetres. Espero que al final sigui més clar i es pugui documentar millor.
• Els noms com infobox_abcabc no tenen cap efecte. Es passen via paràmetres, headerclass = infobox_headerclass, per tant és qualsevol nom. El mòdul usa dues class, infobox-header més la proporcionada args.headerclass. El que deia és usar noms que les identifiquin millor: "ib-person-header" si és específic d'aquella infotaula, o "infobox-header-abcabc" o bé "infobox-abcabc-header" en cas d'una variant genèrica. Si després hi ha cap problema i cal analitzar el resultat en codi font, llavors es llegeix millor.
• Per a casos senzills on no afecta el mode fosc, cap problema en mantenir-ho. Fins i tot si és més general, per a aquests casos està previst el paquet de paràmetres xxxstyle en lloc de xxxclass, són estils addicionals als que puguin tenir les class.

Disculpa que reiteri sobre el punt 3 (noms específics): Entenc el que dius, però tal com ho estic enfocant les styles.css fets per les infotaules, tot el seu contingut és específic per aquella infotaula.

Les col·lecció de classes que es maneguen són:

1. les "comunes" (body, above, title, header, subheader, label, below) bàsicament igual (excepte el BG) entre diferents uinfotaules
2. específiques: si alguna de les comunes té una variació: A) amb algun valor extra com negreta o alineament, o B) és un style que es farà servir amb un div/span i no està vinculat al mòdul. En aquest segon cas ja tenen nom específic per aquest styles.css i no té perquè existir un homònim a d'altres styles.css.

Llavors, quan dius d'identificar-les amb alguna referència a la infotaula no sé si et refereixes a aquest al grup 2 que són totalment específiques, o també a les del primer grup que no són multiuso perquè pertanyen a una infotaula.

Dit d'una altra forma, quan més amunt esmentes: "Són particulars les que només s'usen en un tipus d'infotaula.", comportaria que tan les del grup 1, com del 2 haurien de tenir prefix/suffix d'infotaula. És això ?.

No tinc inconvenient, però em produïa confusió pel fet que no estic generant cap classe que sigui 100% igual a més d'un style.css

Estic pensant en dues coses:

• El mòdul també ha de tenir el seu styles.css i hem de saber què hi traslladarem allà. D'entrada és més fàcil treballar cada infotaula i, de totes maneres, encara no està habilitat el templatestyles al mòdul. Al final, si una class té la mateixa definició en la majoria d'infotaules, serà millor traslladar-la, no tenir-la repetida en diferents llocs, potser amb diferents noms, i poder modificar-la més fàcilment. Caldrà identificar-les.
• Si miro el codi font d'una pàgina, puc reconèixer les class "vector-xxx", "mw-xxx", aquestes ja sé d'on surten. Una class "infobox-xxx" he de suposar que és del mòdul infobox, o potser d'una infotaula si té un nom més específic. Una class "tsingle", d'on deu sortir? He d'anar a la caixa de cerca per veure qui la defineix i com.

Vull dir que hem de seguir alguna convenció de noms i ara és el moment. A mw:Manual:Coding conventions/CSS recomanen tot minúscules, separacions amb guionet i amb un prefix. No m'encaparro en cap convenció, tu mateix, situa't fora de les infotaules i pensa com reconstruir i rastrejar tota l'estructura.

Si em preguntes, les del grup 1 i 2A són candidates a migració al mòdul quedant en local una variant pel background, la negreta o l'alineament. Les del grup 2B són les específiques, no haurien de tenir cap nom tipus "tsingle" que no expressi res, ni tampoc un "infobox-" que sembli una cosa genèrica.

@Vriullop Com deia abans, no tinc problema en que fixem una nomenclatura. Potser el meu baix domini d'aquest món em fa actuar de forma poc eficient i duplico coses que no calien.

Per què he fet una styles.css quasi igual per cada infotaula ?. perquè abans els valors CSS estaven escampats entre el defecte del mòdul, les definicions d'amplada, tipus de lletra i alineaments al començament de la crida al mòdul des de cada pàgina i els colors centralitzats en la {{colors infotaules}}. Era difícil mantenir una mínima harmonització i una bogeria fer un canvi en infotaules migrades a d'altres WP segons els desitjos dels receptors. Solució: extreure qualsevol variable del codi i situar-lo en un altre element (styles.css, modul:itemgroup, ..) que ho puguin gestionar ells sense haver de tocar el codi.

I quan vulguin canviar alguna cosa de les que el mòdul té per defecte, entenc que el lloc correcte és la seva styles.css (la de la infotaula específica de la WP concreta). Tenir una style.css per totes les infotaules pot ser una mesura eficient, però no crec que sigui una idea pràctica si volem aconseguir que siguin autònoms per fer els [pocs] canvis que vulguin. D'altra banda, penso que tenir a cada style.css d'infotaules la col·lecció de totes les classes que poden canviar per alterar/complementar el std. del mòdul, facilita la comprensió per a comunitats que tenen pocs o nuls coneixements tècnics.

I, encara que algunes siguin iguals, ningú diu que més endavant no vulguin configurar cada tipus de línia de forma diferent.

També hem de pensar com anomenar les classes de plantilles que, no són cridades només per altres plantilles, sinó utilitzades per editors. Per exemple, com la collapsible list que, no té sentit que tingui styles.css pròpia, i que el seu paràmetre "titleclass", ja ho diu tot. Però si algú el vol informar, d'on treurà la class que li és menester?. Farem una "styles.css repositori" ?. Si més no serviria per facilitar la manca de coneixements de CSS cada cop més generalitzat.

Sobre els noms, prefereixo que el prefix sigui la procedència i darrere, la seva funcionalitat.

Jo vaig fent infotaules com fins ara i després ja reanomenaré el que calgui.

És el procés normal, primer traslladar de cada plantilla al seu styles, després ja veurem què és configurable i què convé mantenir uniforme.

Sobre {{Collapsible conditional list}} té pocs estils propis, només algun alineament de text com a valor per defecte de paràmetres. No val la pena crear el seu styles. Hi ha dos tipus de paràmetres complementaris, com titleclass i titlestyle. El titleclass ja ve definit en la plantilla d'origen. El titlestyle és el que pot utilitzar un usuari.

En les infotaules ve a ser el mateix: la class infobox-header és pròpia del mòdul i de Minerva, el paràmetre headerclass és definit en la plantilla d'origen, el paràmetre headerstyle és definit per l'usuari en qualsevol altre ús o en plantilles més simples sense class en styles.css.

Perfecte. Per ara, tot el que faig és molt homogeni, per tant, quan tinguem clar com "optimitzar/esporgar", no serà un munt de casuístiques.

Crec que la munió de plantilles que, com la collapsible conditional list, permeten formatar sense ser un expert en CSS / HTML, haurien de comportar-se de forma similar: tenen uns valors per defecte i tot és canviable aportat-li una classe (que podria estar en un hipotètic catàleg de classes comunes) o un style= que requeriria uns coneixements bàsics de CSS.

Per cert, aprofitant que estic de neteja, que és millor fer servir dins altres plantilles (per claredat, consum, versatilitat,..): plantilles tipus {{Align}}, {{Small}}, o el seu codi ?

Merci

Aquestes són plantilles de drecera per a usuaris. Dins d'altres plantilles és millor el seu codi, més clar, més versàtil i t'estalvies dependències. Si ja tens un styles.css potser en una class.