MediaWiki Discussão:Common.css

Domínio MediaWiki (ver tudo)

Javascript e CSS

Javascript comum (disc)

CSS comum (disc)

Listas negras

Ligações externas (disc)

Títulos (disc) 1 2 3

Imagens (disc) 1

Prefixos de imagens (disc) 1

Listas brancas

Ligações externas (disc)

Títulos (disc)

Bloqueios automáticos (disc)

Captcha-addurl (disc)

Outros

Mudanças Recentes (disc)

Gadgets (disc) GD

Sitenotice (disc)

Sitenotice id (disc)

Anonnotice (disc)

Edittools (disc)

Edittools Javascript (disc)

Deletereason-dropdown (disc)

Filedelete-reason-dropdown (disc)

Ipbreason-dropdown (disc)

Meta-Wiki (global)

Bloq. ligações externas (disc)

Bloq. títulos/nomes usuários (disc)

Bloq. usuários (disc) - instruções

CentralNotice - NoticeTemplate

Interwiki map (disc)

phabricator MediaWiki Translatewiki (esta msg)

Informações sobre a página MediaWiki:Common.css (domínio MediaWiki)

---

A página MediaWiki:Common.css contém o código CSS utilizado por todos os usuários, anónimos e registados.

Páginas de aparência (skins) específicas:

• Cologneblue.css
• Modern.css
• Monobook.css
• Vector.css (padrão)

Outras páginas CSS:

• Geshi.css (destaque da sintaxe de código-fonte)

Para mais informações consultar mw:Manual:Interface/Stylesheets (em inglês).

• Arquivo desta página.

Classes para mboxes

Podiam por favor adicionar as regras para mboxes (como, .ambox, .ambox-*, .cmbox, .cmbox-*, .messagebox etc.) que estão na Wikipédia em inglês? Creio que seja importante. --CaiusSPQR (discussão) 22h02min de 4 de março de 2019 (UTC)

Vamos fazer isso com estilos em linha como foi discutido no café dos programadores, então essas classes da enwiki não serão necessárias. Mas precisamos das modificações abaixo para garantir uma aparência diferente na versão mobile:

.caixa {
    border: 1px solid #C7C7C7
}

A classe caixa já existe, então é só encontrar a classe e adicionar essa linha da borda. Como a borda é definida nos estilos em linha das predefinições, os estilos em linha vão sobrescrever esse estilo, e essa mudança só passará a ter efeito quando eu modificar os estilos em linha para não informar o border-style, com isso a borda só aparecerá na versão desktop. Esse é um complemento do que está no MediaWiki:Mobile.css para fazer a diferenciação das caixas na versão mobile. ^Danilo.mac_(discussão) 21h24min de 29 de março de 2019 (UTC)

Inclusão efetuada.[1] !Silent (discussão) 21h38min de 29 de março de 2019 (UTC)

Regra para small

Pode adicionar uma regra para o elemento <small> para que o tamanho da fonte seja de 85 %? Como em [2], que segue as regras de {{Small}}. —CaiusSPQR (discussão) 23h36min de 13 de março de 2019 (UTC)

@CaiusSPQR Feito.[3] !Silent (discussão) 23h43min de 31 de março de 2019 (UTC)

Remover classe "metadata"

Podem por favor remover a classe "metadata"? Ela serve para não ser mostrada quando é impressa, como definido em MediaWiki:Print.css. Também, podem adicionar à regra o seguinte seletor?

.ns--1 .metadata

—CaiusSPQR^(discussão) 02h19min de 30 de março de 2019 (UTC)

É para remover o quê exatamente? Isso tudo?

/* Dados pessoais */
table.metadata {
	border: 1px solid #aaa;
	display: none;
	speak: none;
}

.metadata-label {
	color: #aaa;
}

E adicionar o seletor .ns--1 .metadata em que regra exatamente? Nessa(s) acima? !Silent (discussão) 00h23min de 1 de abril de 2019 (UTC)

Exatamente isso. A class "metadata" foi inicialmente criada para a predefinição Persondata na enwiki, mas ela já não existe. Hoje, a class pode ser usada de forma semelhante à class "noprint", por isso é mantida em MediaWiki:Print.css. Já a class "metadata-label" não é utilizada em nenhuma página (de facto, creio que nunca chegou a ser implementada cá na ptwiki), então pode ser seguramente eliminada. Como referência, pode verificar a página en:MediaWiki:Print.css. —CaiusSPQR^(discussão) 00h37min de 1 de abril de 2019 (UTC)

@CaiusSPQR Certo. E quanto à .ns--1 .metadata, é para pôr no lugar de table .metadata utilizando as mesmas regras? Se sim, por que não pôr em en:MediaWiki:Print.css junto com o resto? !Silent (discussão) 01h32min de 1 de abril de 2019 (UTC)

A class "metadata" serve para não ser exibida somente quando é impressa, por isso deve ser posta em MediaWiki:Print.css. Idealmente, não deve haver nenhuma class "metadata" em MediaWiki:Common.css.

.ns--1 .metadata é para ser adicionado ao lado de .ns-0 .metadata, como pode verificar em en:MediaWiki:Print.css.

Minha proposta é também adicionar classes "n--1" em MediaWiki:Print.css. Seria assim:

.ns--1 .ambox,
.ns-0 .ambox,
.ns--1 .navbox,
.ns-0 .navbox,
.ns--1 .vertical-navbox,
.ns-0 .vertical-navbox,
.ns--1 .infobox.sisterproject,
.ns-0 .infobox.sisterproject,
.ns--1 .hatnote,
.ns-0 .hatnote,
.ns--1 .dablink,
.ns-0 .dablink,
.ns--1 .metadata,
.ns-0 .metadata,
.sistersitebox,
.editlink,
.navbar,
a.NavToggle, span.collapseButton, span.mw-collapsible-toggle,
th .sortkey, td .sortkey,
#mw-revision-nav {
	display: none !important;
}

—CaiusSPQR^(discussão) 01h53min de 1 de abril de 2019 (UTC)

@CaiusSPQR Feito.[4][5] !Silent (discussão) 15h23min de 1 de abril de 2019 (UTC)

Pequenos ajustes visuais

Gostava de pedir alguns ajustes para melhorar a visualização de conteúdo.

As regras seguintes não existem.

/* Aspas retas para <q> */
q {
	quotes: '"' '"' "'" "'";
}

/* Evitar colisão de blockquote com elementos flutuantes ao trocar margem com padding */
blockquote {
	overflow: hidden;
	margin: 1em 0;
	padding: 0 40px;
}

pre, .mw-code {
	overflow-x: hidden;
	overflow-wrap: break-word;
}

/* Mesmo espaçamento para parágrafos indentados e não-indentados em páginas de discussões */
.ns-talk .mw-body-content dd {
	margin-top: 0.4em;
	margin-bottom: 0.4em;
}

As seguintes regras já existem, então basta serem atualizadas.

Ajustes para regras já existentes

Regra atual	Pedido para atualizar regra
/* Consistent size for <small>, <sub> and <sup> */ small { font-size: 85%;  }	/* Tamanho consistente para <small>, <sub> e <sup> */ small { font-size: 85%; } .mw-body-content sub, .mw-body-content sup, span.reference /* para Parsoid */ { font-size: 80%; }
/* Reduce page jumps by hiding collapsed/dismissed content */ .client-js .mw-special-Watchlist #watchlist-message, .client-js .collapsible.collapsed > tbody > tr:not(:first-child) { display: none;  }	/* Reduzir saltos de página ao esconder conteúdo recolhido/dispensado */ .client-js .mw-special-Watchlist #watchlist-message, .client-js .NavFrame.collapsed .NavContent, .client-js .collapsible:not( .mw-made-collapsible).collapsed > tbody > tr:not(:first-child) { display: none; }
/* Realce a azul das referências ''clicadas'' para ajudar na navegação */ .citation:target, .reference:target { background-color: #DEF; /* Fallback */ background-color: rgba(0, 127, 255, 0.133);  }	/* Realce a azul das referências ''clicadas'' para ajudar na navegação */ body.action-info .mw-body-content :target, .citation:target { background-color: #def; /* Fallback */ background-color: rgba(0, 127, 255, 0.133); }
/* Formatação de citações */ span.citation, cite { font-style: normal; word-wrap: break-word; }	/* Formatação de citações. Quebrar URLs longas etc., em vez de uma caixa transbordante */ .citation { word-wrap: break-word; }
/* Para números e IDs de documentos ligados, em que o número * não precisa ser mostrado em uma tela ou computador de mão, * mas deve ser incluído na versão impressa */ @media screen, handheld { span.citation *.printonly { display: none; }  }	/* Para números e IDs de documentos ligados, em que o número não precisa ser mostrado em uma tela ou dispositivo de mão, mas deve ser incluído na versão impressa */ @media screen, handheld { .citation .printonly { display: none; }

--CaiusSPQR^(discussão) 19h01min de 10 de abril de 2019 (UTC)

@CaiusSPQR Feito.[6] !Silent (discussão) 21h37min de 10 de abril de 2019 (UTC)

@!Silent: Como meu pedido removeu o seletor "cite", peço também que adicione a seguinte regra no topo da página:

/* Reajustar estilização em itálico definido pelo agente de utilizador */

cite, dfn {
	font-style: inherit; 

}

Obrigado. --CaiusSPQR^(discussão) 13h57min de 11 de abril de 2019 (UTC)

@CaiusSPQR Feito. [7] !Silent (discussão) 14h05min de 11 de abril de 2019 (UTC)

Class "treeview"

Movi as regras com a class "treeview" para Predefinição:Lista em árvore/styles.css. Podem agora remover a class "treeview" de Common.css? --CaiusSPQR^(discussão) 14h24min de 11 de abril de 2019 (UTC)

@CaiusSPQR Feito.[8] !Silent (discussão) 14h32min de 11 de abril de 2019 (UTC)

Classes para Caixa lateral

A predefinição {{Caixa lateral}} necessita de algumas classes para funcionar de forma esperada. Utilizar estilos em linha não é viável pois afeta negativamente estilos customizados de utilizados em Especial:Minha página/common.css. Peço, então, que seja adicionadoo seguinte código.

/* Tamanhos de células para message boxes */

th.mbox-text, td.mbox-text {   /* A(s) célula(s) do corpo da mensagem */
	border: none;
	/* @noflip */
	padding: 0.25em 0.9em;     /* 0.9em esquerda/direita */
	width: 100%;               /* Fazer todas as mboxes da mesma largura independente do comprimento do texto */
}
td.mbox-image {                /* A célula de imagem esquerda */
	border: none;
	/* @noflip */
	padding: 2px 0 2px 0.9em;  /* 0.9em esquerda, 0px direita */
	text-align: center;
}
td.mbox-imageright {           /* A célula de imagem direita */
	border: none;
	/* @noflip */
	padding: 2px 0.9em 2px 0;  /* 0px esquerda, 0.9em direita */
	text-align: center;
}

/* Estas classes mbox-small devem ser postas depois de todas as outras classes ambox/tmbox/ombox etc. "html body.mediawiki" existe para que sobreponham "table.ambox + table.ambox". */
html body.mediawiki .mbox-small {   /* Para a opção "pequeno=sim". */
	/* @noflip */
	clear: right;
	/* @noflip */
	float: right;
	/* @noflip */
	margin: 4px 0 4px 1em;
	box-sizing: border-box;
	width: 238px;
	font-size: 88%;
	line-height: 1.25em;
}
html body.mediawiki .mbox-small-left {   /* Para a opção "pequeno=esquerda". */
	/* @noflip */
	margin: 4px 1em 4px 0;
	box-sizing: border-box;
	overflow: hidden;
	width: 238px;
	border-collapse: collapse;
	font-size: 88%;
	line-height: 1.25em; 

}

Obrigado. --CaiusSPQR^(discussão) 03h49min de 14 de abril de 2019 (UTC)

@CaiusSPQR Feito.[9] !Silent (discussão) 14h06min de 14 de abril de 2019 (UTC)

Essas alterações modificaram a aparência das caixas do Módulo:Mbox, esta página de testes mostram como as imagens ficaram deslocadas para a direita. Classes como mbox-text, mbox-image e ambox são usadas pela extansão MobileFrintend para fazer transformações na versão mobile, elas não devem ter estilos pois interfere em todas predefinições que a usam para fazer tais transformações, por favor desfaça esta alteração. E CaiusSPQR, não existe isso de "usar estilos em linha não é viável", nós já discutimos sobre isso, eu estou desenvolvendo módulo de infobox e de mboxes com estilos em linha para diminuir o número de classes aqui e assim deixar os estilos organizados somente no código das predefinições/módulos, e você está fazendo o trabalho oposto, fazendo com que estilos fiquem separados do código da predefinição e com isso dificultado sua edição, e neste caso em particular afetando estilos de outras predefinições. Se não souber usar estilos em linha na predefinição, é só pedir que eu ajudo. ^Danilo.mac_(discussão) 18h29min de 14 de abril de 2019 (UTC)

Não vi grandes problemas em Predefinição:Ambox/Exemplos para testes3. Se há, basta editar Módulo:Mbox. O MobileFrontend funciona apenas em dispositivos móveis, então adicionar classes em MediaWiki:Common.css não muda em nada. Além disso, MobileFrontend não definiu as classes "mbox-" de forma exclusiva, elas já existiam antes na enwiki. Estilos em linha sobrepõem o CSS definido por editores(as), então não são boas. --CaiusSPQR^(discussão) 18h55min de 14 de abril de 2019 (UTC)

As imagens antes tinham o mesmo alinhamento da ambox atual, depois da alteração ficaram deslocadas para direita por causa do padding adicionado. Claro que classes aqui mudam a versão desktop, tudo o que está no Common.css afeta somente a versão desktop, é o Mobile.css que afeta os estilos mobile. São essas classes que fazem as transformações, então não importa se na enwiki eles usam como estilo, se eles dificultam a edição de estilos separando-os do código da predefinição/módulo e misturam com classes de transformações, isso é problema deles, não somos obrigados a seguir o que as outras wikis fazem. CSS de usuários raramente são usados para mudar a aparência de predefinições, e se alguém realmente quiser fazer isso é possível sobrepor os estilos em linha usando o "!important", e da mesma forma os estilos definidos aqui no Common.css podem sobrepor os dos usuários usando regras de especificidade do CSS. E estou tentando organizar os estilos mantendo eles nas predefinições em vez de levar para uma segunda página, estilos de predefinições devem ser fáceis de editar e testar alterações, manter os estilos aqui no Common.css só traz dificuldades, é preciso pedir para um administrador de interface editar e é mais difícil testar novos estilos em predefinições de testes, além de ter editores que sabem editar estilos em linha mas não em classes. Se quiser me passa os estilos que quer nesse módulo da caixa lateral que eu coloco no código dele. ^Danilo.mac_(discussão) 19h33min de 14 de abril de 2019 (UTC)

Não disse que devemos usar as mesmas classes que eles. Disse que MobileFrontend usa as classes "mbox-" porque a enwiki já a utilizava antes. Isto signfica que não há problema utilizar uma classe que MobileFrontend usa. Todo editor de CSS sabe que deve evitar ao máximo utilizar "!important"; inclusive o software de CSS do MediaWiki aponta como aviso.

Estilos de predefinições muito usadas não devem ser tão fáceis de editar, pois podem causar problemas a toda a Wikipédia. Por isso existe o domíio MediaWiki. E os estilos não possuem problemas, então é melhor editar uma única predefinição com problema do que um estilo que afeta mais de uma predefinição e consequentemente grande parte da Wikipédia.. --CaiusSPQR^(discussão) 19h53min de 14 de abril de 2019 (UTC)

E nós não temos culpa que os desenvolvedores da MobileFrontend escolheram classes que a enwiki usa para estilo. O !important deve ser evitado para não sobrepor os estilos definidos em predefinições e definidos por CSS de usuários, mas o usuário faz o que ele quiser com o .css dele pois só ele vê o que ele configurou, a questão é que não existe a necessidade de usar classes de estilo para predefinições. Se uma predefinição é usada em muitas páginas então ó código dela é protegido, e os estilos ficam protegidos junto, e tem vários níveis de proteção que variam de acordo com a visibilidade da predefinição. Já se colocarmos os estilos aqui eles ficam mais protegidos do que a maior proteção que pode ser aplicada a uma predefinição que a edição somente de administradores, pois existem muito mais administradores do que administradores de interface. Os estilos na predefinição vão sempre ter o mesmo nível de proteção do código da predefinição, o que faz muito mais sentido. Além disso fica tudo no código da predefinição, o que facilita a edição quando ela for necessária e facilita testes de alterações de estilos. O Módulo:Mbox pode ser corrigido em seu código, mas toda vez que adicionarem algum estilo aqui nessas classes de transformação temos que ficar verificando se isso não alterou a aparência das predefinições que usam essas classes. O Common.css deve ser usado para estilos de interface, não para estilos de predefinição, algumas wikis estão tentando corrigir isso com a extenssão TemplateStyles, que não corrige o problema de ter os estilos em uma segunda página e cria o risco de as classes de uma predefinição ser conflitantes com as de outra que usa classes com o mesmo nome, por isso eu estou tentando corrigir esse problema desenvolvendo módulos sem classes de estilo. Ficar colocando estilos de predefinição aqui é um retrocesso nessa tentativa de organização. Nós devemos remover os estilos de predefinição que existem aqui e não ficarmos colocando mais. ^Danilo.mac_(discussão) 20h42min de 14 de abril de 2019 (UTC)

Há certamente a necessidade de classes de estilo para predefinições. Não há a necessidade de utilizar estilos em linha para tudo, visto que não há o mínimo de controlo e organização sobre eles. Classes são importantes, do contrário não existiria CSS, que serve unicamente para estilização.

Uma das funções das classes é ser utilizadas mais de uma vez. Classes "Mbox-" são utilizadas mais de uma vez [10] e não estão necessariamente atreladas a uma só predefinição (inclusive nem há uma única predefinição message box). Então o uso de "Mbox-" vai além de estilo de uma predefinição. E para qualquer caixa de mensagem (está no nome). --CaiusSPQR^(discussão) 20h51min de 14 de abril de 2019 (UTC)

Aqui na Wikipédia, diferentemente de outros sites, existem as predefinições, o que está no código delas é aplicado nas várias páginas em que ela está, então as predefinições funcionam como classes no sentido que está tudo concentrado em um único lugar, por isso os estilos em linha conseguem substituir as classes aqui. O fato de uma classe ser usada por várias predefinições é uma desvantagem, nem sempre queremos que duas predefinições diferentes tenham a mesma aparência, o que aconteceu aqui foi um exemplo disso, o Módulo:Mbox não tinha padding definido para imagem porque não usa padding nessa parte, e quando o padding foi adicionado na classe alterou a aparência. Existe uma exceção em que usar classe é a única solução, quando a aparência mobile é diferente da aparência desktop, por isso existe a classe caixa, para que a borda não apareça na versão mobile. ^Danilo.mac_(discussão) 21h22min de 14 de abril de 2019 (UTC)

Estilos em linha não substituem classes na Wikipédia, porque o código HTML vai possuir estilos em linha, não em classes. Classes existirem em mais de uma predefinição não é uma desvantagem. Como você próprio disse, nem sempre queremos que duas predefinições diferentes tenham a mesma aparência. Nem sempre. Às vezes queremos, às vezes não. Se não quiser, basta não utilizar a predefinição. As classes "mbox-" que estavam nesta página, possuíam o mínimo de estilização, que pode ser usado em mais de uma predefinição, em afetar a individualidade de uma predefinição, além de ser possível sobrepor uma classe com estilos em linha. É o que pode fazer com Módulo:Mbox. Já que gosta tanto de estilos em linha, não deve ser um problema. --CaiusSPQR^(discussão) 21h31min de 14 de abril de 2019 (UTC)

Eu disse em que sentido que os estilos em linha substituem as classes, leia de novo o que eu escrevi. Não é porque duas predefinições usam alguns estilos iguais que vamos criar uma classe para elas, isso só dificulta a edição quando alguém quiser mudar alguma coisa nesses estilos, e quando algo é mudado pode melhorar a aparência em uma predefinição e piorar em outra. E se algo é sobrescrito com estilos em linha isso só aumenta a desorganização, pois parte dos estilos ficam em linha e parte em classes. Por tudo o que eu já disse, os estilos em linha são a melhor solução para estilos de predefinições. A extensão TemplateStyles pode ser uma alternativa, apesar de ter os problemas que citei. O que deve ser evitado são os estilos aqui no Common.css, principalmente em classes usadas para transformações. O que aconteceu com o Módulo:Mbox foi apenas uma amostra dos efeitos de se usar classes para inserir estilos nas predefinições, o problema não está no módulo. ^Danilo.mac_(discussão) 22h03min de 14 de abril de 2019 (UTC)

┌─────────────────────────┘ Primeiro, foi exatamente o que disse: (…) por isso os estilos em linha conseguem substituir as classes aqui. Segundo, não disse que é para se criar uma classe para duas predefinições parecidas. A realidade é que já existem predefinições que utilizam essas classes. Terceiro, uma das razões de as classes estarem aqui é evitar de serem editadas. Normalmente as classes definem padding ou borda, que raramente necessitam de ajustes. Quarto, TemplateStyles são inviáveis nesse caso, porque mais de uma predefinição utiliza as mboxes. As classes em questão pode estar cá nesta página, pois são usadas em milhares de páginas da Wikipédia. Cinco, o código não mudaria em nada: atualmente usa uma classe vazia seguida por estilos em linha. Com as classes definidas, ainda vai usar uma classe seguida por estilos em linha. Seis, não houve qualquer mudança notável em Módulo:Mbox. Se acha que houve, basta adicionar estilos em linha. O que não pode é milhares de páginas terem predefinições quebradas porque foram removidas as classes porque "quebra" seu módulo em testes. —CaiusSPQR^(discussão) 22h27min de 14 de abril de 2019 (UTC)

Substituem classes no sentido em que os estilos de uma predefinição estão definidos todos em um único lugar, no código da predefinição. Até algumas horas atrás essas classes não tinham estilo nenhum, então são só predefinições criadas ou alteradas nessas últimas horas que podem ter sido afetadas, se esse for o problema é só desfazer a alteração que fez com que essas classes fossem usadas no lugar dos estilos em linha. Como eu já disse, se uma predefinição não deve ser alterada então ela é protegida e os estilos ficam protegidos também. O TemplateStyles é apenas uma alternativa para o caso de não ser possível usar estilos em linha, o modo preferível são os estilos em linha. O código não muda mas os estilos ficam divididos em dois lugares. O que aconteceu com o Módulo:Mbox não é o maior problema, o problema é usar classes para adicionar estilos em predefinições. ^Danilo.mac_(discussão) 23h06min de 14 de abril de 2019 (UTC)

Apenas você que diz que classes não devem ser usadas em predefinições. O resto da Wikipédia as usa, tanto cá na ptwiki quanto nas outras interwikis. E em nenhum lugar existe qualquer problema. Só com seu módulo.

Já expliquei que TemplateStyles neste caso é inviável.

Se não quer utilizar classes, tudo bem, não as use, mas não tente proibir outros de as usarem. Ainda mas com a desculpa de que quebrou seu módulo. —23h40min de 14 de abril de 2019 (UTC)

O problema é ter classes no Common.css, e não sou só eu que digo isso, o TemplateStyles foi criado justamente para evitar que estilos de predefinições sejam incluídos aqui no Common.css, só que, como nós dois aparentemente concordamos, o TemplateStyles tem problemas, então a solução são os estilos em linha. Eu iniciei o desenvolvimento do Módulo:Info para começar a resolver os problemas dos estilos e outros problemas como o uso do Wikidata pelas infoboxes, que é uma das predefinições mais usadas, e submeti o Wikipédia:Padrão visual a aprovação da comunidade para ter certeza que a comunidade apoiava as mudanças que eu estava começando a fazer, pois seria muito frustrante ter todo esse trabalho para depois alguém que discorda interromper o processo, a questão dos estilos em linha não está no texto do padrão, mas faz parte desse esforço de organização dos estilos. Começar a colocar mais classes de predefinições no Common.css vai prejudicar todo esse esforço. Usando uma metáfora, é como se eu estivesse organizando alguma coisa em ordem alfabética e você chegasse depois e começasse a organizar a mesma coisa por ordem de cor. ^Danilo.mac_(discussão) 02h01min de 15 de abril de 2019 (UTC)

"For" não substitui classes, pois ainda não utilizados estilos em linha, que são mais problemas do que classes. Além de que "for" não é utilizado por predefinições. Utilizadoras(es) não definem regras para predefinições por dois motivos: primeiro, eles devem definir regras para classes, não para predefinições em si. Segundo, como podem definir regras se são utilizados estilos em linha e não classes?

Além disso, sua proposta vai de encontro com as convenções do MediaWiki e contra o princípio "mobile first". (Por causa de seus estilos em linha, precisou de quebrar um princípio sem necessidade para implementar algo que não é necessário.) E não há qualquer necessidade de copiar classes para MediaWiki:Common.css. —CaiusSPQR^(discussão) 02h19min de 15 de abril de 2019 (UTC)

Eu não falei sobre isso acima, não desvie o assunto. ^Danilo.mac_(discussão) 04h00min de 15 de abril de 2019 (UTC)

Como houve contestação, reverti novamente para a versão anterior. !Silent (discussão) 20h18min de 14 de abril de 2019 (UTC)

Como pode considerar a contestação válida se o módulo com problema está em testes e possui somente 7 transclusões, em comparação a milhares de páginas que usam Módulo:Caixa lateral e são afetadas. --CaiusSPQR^(discussão) 20h21min de 14 de abril de 2019 (UTC)

É só fazer a predefinição não usar o módulo enquanto ele não estiver com os estilos adequados. ^Danilo.mac_(discussão) 20h42min de 14 de abril de 2019 (UTC)

É só você consertar seu módulo quebrado (que nem quebrado me parece). --CaiusSPQR^(discussão) 20h51min de 14 de abril de 2019 (UTC)

O Módulo:Mbox funciona bem desde que não adicionem estilos nas classes que ele usa para transformações, você pode até aplicá-lo nas moxes se quiser, ele só não é usado em milhares de páginas ainda porque você o contestou. O que está errado no Módulo:Caixa lateral é o uso de classes de estilo, eu corrijo isso se você concordar. ^Danilo.mac_(discussão) 21h22min de 14 de abril de 2019 (UTC)

Não, ele não funciona bem, como já falámos em WP:CP. E não é só o Módulo:Caixa lateral que utiliza essa classe. --CaiusSPQR^(discussão) 21h44min de 14 de abril de 2019 (UTC)

Se viu algo que não está funcionando bem diga na discussão do módulo. E até ontem essa classe não tinha estilo nenhum, então não deve ter tantos módulos/predefinições que precisam desses estilos. Se tiver me diga quais são que eu coloco os estilos em linha também. ^Danilo.mac_(discussão) 22h23min de 14 de abril de 2019 (UTC)

Hoje já há milhares de páginas que utilizam as classes, e como falei, ela é útil e organizativa. EM vez de mudar algumas dezenas de predefinições/módulos, é melhor mudar apenas o seu, que afeta apenas 7 páginas. --CaiusSPQR^(discussão) 22h37min de 14 de abril de 2019 (UTC)

Até algumas horas atrás essas classes não tinham estilos, essas milhares de páginas foi modificações que você fez nessas últimas horas. ^Danilo.mac_(discussão) 23h06min de 14 de abril de 2019 (UTC)

E? Ainda assim, é melhor (e neste caso, mais recomendado) utilizar classes que estilo em linha. —CaiusSPQR^(discussão) 23h37min de 14 de abril de 2019 (UTC)

┌──────────────────────┘ Há três possíveis soluções para resolver este impasse: utilizar TemplateStyles, estilo em linha e esta página (Common.css).

• Não é possível utilizar TemplateStyles, pois ele serve para (e deve) ser usado apenas em uma predefinição. A situação é que são múltiplos módulos e uma classe que pode ser potencialmente usada em múltiplas outras predefinições. Não há nada que impede ser usada por mais de uma vez; na verdade, é esse o ponto de uma classe.
• Estilos em textos possuem vários problemas:

• Não há separação de conteúdo e apresentação, o que resulta em código difícil de entender e manter para a maioria dos editores.
• Estilos têm de ser repitidos para cada elemento de HTML ao qual aplicam, o que resulta em muito copiar e colar e em código que é difícil de ler e manter.
• Atributos de estilo são limitados.
• Estilos em linha têm precedência sobre quaisquer outras folhas de estilo CSS, então customizações específicas para utilizadores(as), skins ou dispositivos tornam-se mais difíceis.
• Para customizações específicas, é necessário utilizar para todas as declarações "!important", o que compromete a manutenção do código e vai de encontro com as convenções de código do MediaWiki.

• A opção que resta é utilizar esta página. Claro que ela possui seus contras, mas de entre todas as opções, esta é a melhor. --CaiusSPQR^(discussão) 00h14min de 15 de abril de 2019 (UTC)

Muitos editores têm mais facilidade com estilos em linha do que com classes de estilos, manter os estilos no Common.css é que é difícil de entender e alterar para a maioria dos editores. Não é preciso repetir, para isso existe o for, no Módulo:Info por exemplo o estilo de cada campo está definido apenas uma vez, o for replica. Os usuários não ficam definindo CSS de usuário para modificar predefinições, e modificações para skin pode ser feita com classe como a classe caixa faz para não ter borda na versão mobile. Já se quisermos que um estilo definido em classe seja usado no mobile também temos que ficar copiando o que está aqui no Common.css para o Mobile.css, o que aumenta ainda mais o problema de organização dos estilos. ^Danilo.mac_(discussão) 02h01min de 15 de abril de 2019 (UTC)

"For" não substitui classes, pois ainda não utilizados estilos em linha, que são mais problemas do que classes. Além de que "for" não é utilizado por predefinições. Utilizadoras(es) não definem regras para predefinições por dois motivos: primeiro, eles devem definir regras para classes, não para predefinições em si. Segundo, como podem definir regras se são utilizados estilos em linha e não classes?

Além disso, sua proposta vai de encontro com as convenções do MediaWiki e contra o princípio "mobile first". (Por causa de seus estilos em linha, precisou de quebrar um princípio sem necessidade para implementar algo que não é necessário.) E não há qualquer necessidade de copiar classes para MediaWiki:Common.css. —CaiusSPQR^(discussão) 02h19min de 15 de abril de 2019 (UTC)

Você está dizendo coisas sem comprovação, estilos em linha são "mais problemas que classes", é algo que já apontei o contrário em toda essa discussão, e para mim os usuários não definem regras para predefinições porque eles não querem ver algo diferente dos outros usuários e porque a grande maioria não sabe editar classes, isso faz mais sentido do que o que você alega ser os motivos. Eu fiz o Módulo:Mbox tendo atenção ao mobile, usei as classes de transformação e removi a borda no mobile, nem tudo precisa ser diferente no mobile. ^Danilo.mac_(discussão) 04h00min de 15 de abril de 2019 (UTC)

Como mostrado que as classes "mbox-" são utilizadas por mais de uma predefinição/módulo, não só Módulo:Mbox e Módulo:Caixa lateral, e que são úteis e organizativas, peço por favor a @!Silent que implemente as classes novamente a MediaWiki:Common.css. --CaiusSPQR^(discussão) 21h00min de 14 de abril de 2019 (UTC)

@!Silent, CaiusSPQR e Danilo.mac: Saudações a todos. Algumas horas atrás, editores que utilizam bastante a predefinição {{escutar}} — inclusive eu — perceberam a mudança realizada. E uma pequena introdução, já tentei editar a polêmica da caixa escute, devido a falta e/ou erros de formatações no que diz respeito ao lado esquerdo do texto. De fato, não possuo o mesmo domínio apurado de vocês nessa área das formatações. Pelo que li na discussão acima, vocês devem entrar em um consenso para não prejudicar a estrutura das verbetes que utilizam a predefinição da mesma — inclusive de verbetes qualificados nas EADs. Se o método do CaiusSPQR realmente resolver o velho problema de formatação do lado esquerdo, então o apoio veementemente. Caso não, sugiro que volte ao método de como estava anteriormente. Fiem-se em resolver o problema, e não quem terá a última palavra. À espera de uma posição de vocês. Boas contribuições! Gabriel bier ^{fala aew} 00h55min de 15 de abril de 2019 (UTC)

@Gabriel bier A alteração já foi revertida desde cedo. !Silent (discussão) 01h04min de 15 de abril de 2019 (UTC)

Acho que ele se refere a desfazer a reversão. Se o método do CaiusSPQR realmente resolver o velho problema de formatação do lado esquerdo, então o apoio veementemente. —CaiusSPQR^(discussão) 01h09min de 15 de abril de 2019 (UTC)

Resolvido, é só não usar o módulo por enquanto. ^Danilo.mac_(discussão) 02h10min de 15 de abril de 2019 (UTC)

Não foi resolvido. O(a) editor(a) não estava a falar desse problema. —CaiusSPQR^(discussão) 02h18min de 15 de abril de 2019 (UTC)

As classes colocadas aqui no Common.css só durou algumas horas, logo não pode ter sido a retirada delas que quebrou algo que funciona bem há anos. Se você sabe qual é o problema corrija, se não sabe me explique o que está errado com a predefinição que eu corrijo. ^Danilo.mac_(discussão) 04h00min de 15 de abril de 2019 (UTC)

O que ele(a) quis dizer é que as classes resolveram um problema que já existia antes. —CaiusSPQR^(discussão) 04h16min de 15 de abril de 2019 (UTC)

Então diga o que é, se são as margens quando a caixa está na esquerda eu adicionei. Seja o que for, é muito improvável que seja algo que não possa ser corrigido por estilos em linha. ^Danilo.mac_(discussão) 05h09min de 15 de abril de 2019 (UTC)

O mesmo pode ser dito sobre o seu módulo, que é o único que foi quebrado (que na verdade nem o foi) pela classe. —CaiusSPQR^(discussão) 10h17min de 15 de abril de 2019 (UTC)

Eu já expliquei isso, o módulo foi só um indicativo do que pode acontecer ao colocar estilos através de classes em predefinições. O problema é colocar estilos em predefinições usando o Common.css, e não sou só eu que digo isso, a extensão TemplateStyles foi criada justamente para resolver esse problema, só que essa extensão tem seus problemas também, por isso e por tudo mais que já expliquei usar estilos em linha é a melhor solução, deixando o Common.css somente para os casos onde um estilo específico deve ser diferente no mobile, como é feito com a classe caixa. ^Danilo.mac_(discussão) 15h46min de 15 de abril de 2019 (UTC)

Atualizar regra para navbar

A regra atual para navbar não funciona, pois houve alterações na predefinição e ela não utiliza mais a tag <span>. Por isso, peço que façam a seguinte substituição:

Agora	Proposta de alteração
.navbar.mini li span { font-variant: small-caps;  }	.navbar.mini li abbr[title] { font-variant: small-caps; border-bottom: none; text-decoration: none; cursor: inherit;  }

Obrigado. --CaiusSPQR^(discussão) 21h06min de 4 de maio de 2019 (UTC)

@CaiusSPQR Feito.[11] !Silent (discussão) 21h40min de 4 de maio de 2019 (UTC)

Atualizar regras para infoboxes antigas

Algumas predefinições ainda usam a antiga class "infobox". Ela não é atualizada há tempos, e seu código pode ser melhorado enquanto algumas predefinições são atualizadas para o novo código. A seguir, há uma tabela com as regras que necessitam de ser atualizadas; também há as regras que necessitam de ser incluídas, pois algumas predefinições foram copiadas da enwiki com classes que nunca foram incluídas cá na ptwiki.

Regras para atualizar

Agora	Proposta de atualização
.infobox { border: 1px solid #aaa; background-color: #f9f9f9; margin-bottom: 0.5em; margin-left: 1em; padding: .2em; float: right; clear: right; }	.infobox { border: 1px solid #a2a9b1; border-spacing: 3px; background-color: #f8f9fa; color: black; /* @noflip */ margin: 0.5em 0 0.5em 1em; padding: 0.2em; /* @noflip */ float: right; /* @noflip */ clear: right; font-size: 88%; line-height: 1.5em; }
.infobox caption { margin-left: inherit; }	.infobox caption { font-size: 125%; font-weight: bold; padding: 0.2em; text-align: center; }
.infobox tr { vertical-align: top; }	.infobox td, .infobox th { vertical-align: top; /* @noflip */ text-align: left; }
.infobox.bordered td, .infobox.bordered th { border: 1px solid #aaa; }	.infobox.bordered td, .infobox.bordered th { border: 1px solid #a2a9b1; }
.infobox.sisterproject { width: 22em; }	.infobox.sisterproject { width: 20em; font-size: 90%; }

Regras para adicionar

.infobox.standard-talk {
	border: 1px solid #c0c090;
	background-color: #f8eaba;
}
.infobox.standard-talk.bordered td,
.infobox.standard-talk.bordered th {
	border: 1px solid #c0c090;
}

/* Estilos para infocaixa com bordas com linhas fundidas */
.infobox.bordered .mergedtoprow td,
.infobox.bordered .mergedtoprow th {
	border: 0;
	border-top: 1px solid #a2a9b1;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

.infobox.bordered .mergedrow td,
.infobox.bordered .mergedrow th {
	border: 0;
	/* @noflip */
	border-right: 1px solid #a2a9b1;
}

/* Estilos para infocaixas de geografia */
.infobox.geography {
	border-collapse: collapse;
	line-height: 1.2em;
	font-size: 90%;
}

.infobox.geography  td,
.infobox.geography  th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.4em 0.6em;
}
.infobox.geography .mergedtoprow td,
.infobox.geography .mergedtoprow th {
	border-top: 1px solid #a2a9b1;
	padding: 0.4em 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedrow td,
.infobox.geography .mergedrow th {
	border: 0;
	padding: 0 0.6em 0.2em 0.6em;
}

.infobox.geography .mergedbottomrow td,
.infobox.geography .mergedbottomrow th {
	border-top: 0;
	border-bottom: 1px solid #a2a9b1;
	padding: 0 0.6em 0.4em 0.6em;
}

.infobox.geography .maptable td,
.infobox.geography .maptable th {
	border: 0;
	padding: 0;
}

Obrigado. --CaiusSPQR^(discussão) 00h21min de 6 de maio de 2019 (UTC)

Segundo esta pesquisa sobre uso de classes, somente 21 predefinições/páginas usam a classe geography e 8 usam a sisterproject. Eu tenho atualizado algumas infoboxes antigas sobre localidades, como a {{Info/Cabo Verde/Povoação}}, eu posso dar prioridade para essas que usam a geography. As que usam a .infobox.sisterproject como esta página também podem ser corrigidas manualmente. As alterações que não envolvam essas duas classes eu não me oponho, pois de fato a atualização de todas as infoboxes ainda vai demorar. ^Danilo.mac_(discussão) 04h10min de 6 de maio de 2019 (UTC)

O problema é que ainda vai continuar a haver editoras(es) que importarão predefinições com essas classes para cá. Não são muitas regras, então não deve afetar o carregamento das páginas. É só uma questão de suporte a elas, da mesma forma que "NavFrame", que por mais que seja obsoleta, ainda permanece na ptwiki. —CaiusSPQR^(discussão) 04h16min de 6 de maio de 2019 (UTC)

Eu concordo em colocar essas classes até que as infoboxes sejam atualizadas. ^Danilo.mac_(discussão) 05h26min de 6 de maio de 2019 (UTC)

Feito. [12] !Silent (discussão) 22h39min de 6 de maio de 2019 (UTC)

Favor remover o .infobox td, .infobox th {text-align: left}, isso está mudando o alinhamento de textos e imagens que devem estar centralizados. Já existem dois tópicos recentes no Café dos programadores reclamando disso. ^Danilo.mac_(discussão) 05h31min de 12 de maio de 2019 (UTC)

Problema já resolvido. Já não há a necessidade de remover a regra. Isso ocorreu porque as predefinições não usam nem {{Info}} nem {{Infobox}}. Mais tarde irei verificar cada uma das predefinições para me certificar de que não há mais problema algum. —CaiusSPQR^(discussão) 05h57min de 12 de maio de 2019 (UTC)

Atualizar regras para navboxes

Conforme discussão em Predefinição Discussão:Navbox § Utilizar módulo, a predef {{Navbox}} passará a utilizar o módulo Módulo:Navbox. Isso fará com que a predef deixe de utilizar Predefinição:Navbox/core e irá requerer que sejam feitas algumas alterações para o CSS da predef. Não são muitas modificações, no entanto. Como pode ver pelas tabelas a seguir, as alterações que proponho são derivadas da enwiki e são mínimas e no geral mais organizativas, como fundir "table.navbox" e ".navbox", pois não há necessidade de duas regras diferentes para a mesma predef. Testei as novas regras para a predef, como pode verificar em Predefinição:Navbox/styles.css, Predefinição:Navbox/Testes e Predefinição:Navbox/Exemplos para testes, e não percebi nenhum problema com o CSS. Também testei as regras novas em {{Navbox/lua}} e até agora não houve nenhuma reclamação desde minha alteração na predef.

Regras para atualizar

Atual Proposta .navbox { /* Navbox container style */ border: 1px solid #aaa; width: 100%; margin: auto; clear: both; font-size: 88%; text-align: center; padding: 1px; } .navbox { /* Navbox container style */ box-sizing: border-box; border: 1px solid #a2a9b1; width: 100%; clear: both; font-size: 88%; text-align: center; padding: 1px; margin: 1em auto 0; /* Prevent preceding content from clinging to navboxes */ } .navbox, .navbox-subgroup { background: #fdfdfd; /* Background color */ } .navbox, .navbox-subgroup { background-color: #fdfdfd; /* Background color */ } .navbox th, .navbox-title { background: #ccccff; /* Level 1 color */ } .navbox th, .navbox-title { background-color: #ccccff; /* Level 1 color */ } .navbox-abovebelow, th.navbox-group, .navbox-subgroup .navbox-title { background: #ddddff; /* Level 2 color */ } .navbox-abovebelow, th.navbox-group, .navbox-subgroup .navbox-title { background-color: #ddddff; /* Level 2 color */ } .navbox-subgroup .navbox-group, .navbox-subgroup .navbox-abovebelow { background: #e6e6ff; /* Level 3 color */ } .navbox-subgroup .navbox-group, .navbox-subgroup .navbox-abovebelow { background-color: #e6e6ff; /* Level 3 color */ } .navbox-even { background: #f7f7f7; /* Even row striping */ } .navbox-even { background-color: #f7f7f7; /* Even row striping */ } .navbox-odd { background: transparent; /* Odd row striping */ } .navbox-odd { background-color: transparent; /* Odd row striping */ } .navbox-title .navbar { /* @noflip */ float: left; /* @noflip */ text-align: left; /* @noflip */ margin-right: 0.5em; width: 6em; } .navbox-title .navbar { /* @noflip */ float: left; /* @noflip */ text-align: left; /* @noflip */ margin-right: 0.5em; }

Seletores para substituir
Atual Proposta table.navbox table.navbox { margin-top: 0; /* No top margin for nested navboxes */ } .navbox .navbox { margin-top: 0; /* No top margin for nested navboxes */ } table.navbox + table.navbox { margin-top: -1px; /* Single pixel border between adjacent navboxes */ } .navbox + .navbox { margin-top: -1px; /* Single pixel border between adjacent navboxes */ }

Regras para remover
<syntaxhighlight lang="css">table.navbox { margin-top: 1em; /* Prevent preceding content from clinging to navboxes */ } .navbox .mw-collapsible-toggle { width: 6em; }

Regra para adicionar

/* cell spacing for navbox cells */ tr + tr > .navbox-abovebelow, tr + tr > .navbox-group, tr + tr > .navbox-image, tr + tr > .navbox-list { /* Borders above 2nd, 3rd, etc. rows */ border-top: 2px solid #fdfdfd; /* Must match background color */ }

Proponho remover algumas declarações e regras, pois o módulo já lida com essas situações, o que faz com que as regras sejam desnecessárias. Elas também já foram removidas há alguns anos na enwiki. Quanto à regra do seletor "table.navbox", ela pode ser removida sem problemas, pois proponho que ela seja fundida com ".navbox", visto que ela não é necessária e possui uma única declaração.

Também proponho substituir os seletores "table.navbox table.navbox" e "table.navbox + table.navbox" por ".navbox .navbox" e ".navbox + .navbox" por "table" ser desnecessário. Também peço que, por questão de organização e para evitar problemas com o CSS, peço que coloquem ".navbox .navbox" e ".navbox + .navbox" abaixo de ".navbox".

A regra para ser adicionada é para que haja espaçamento apropriado entre as células. Peço que seja colocada depois da regra para ".navbox-list" e antes da regra para ".navbox th, .navbox-title". Obrigado. --CaiusSPQR^(discussão) 21h14min de 5 de junho de 2019 (UTC)

@!Silent: Pode fazer as alterações pedidas? --CaiusSPQR^(discussão) 02h45min de 14 de junho de 2019 (UTC)

@CaiusSPQR Feito [13]. !Silent (discussão) 16h32min de 14 de junho de 2019 (UTC)
PS: por algum motivo o ping não me notificou.

@!Silent: Ah, entendo. Obrigado. No entanto, como CSS se importa com a ordem das regras (as regras inferiores podem sobrepor-se às superiores) e também por questão de organização (regras para navboxes juntas), gostaria de lhe pedir para que coloque as regras na seguinte ordem, de cima para baixo:

1. ".navbox"

2. ".navbox .navbox"

3. ".navbox + .navbox"

4. ".navbox-inner, .navbox-subgroup"

5. ".navbox-group, .navbox-title, .navbox-abovebelow"

6. "th.navbox-group"

7. ".navbox, .navbox-subgroup"

8. ".navbox-list"

9. "tr + tr > .navbox-abovebelow, tr + tr > .navbox-group, tr + tr > .navbox-image, tr + tr > .navbox-list"

10. ".navbox th, .navbox-title"

11. ".navbox-abovebelow, th.navbox-group, .navbox-subgroup .navbox-title"

12. ".navbox-subgroup .navbox-group, .navbox-subgroup .navbox-abovebelow"

13. ".navbox-even"

14. ".navbox-odd"

15. ".navbox .hlist td dl, .navbox .hlist td ol, .navbox .hlist td ul, .navbox td.hlist dl, .navbox td.hlist ol, .navbox td.hlist ul"

Obrigado. --CaiusSPQR^(discussão) 16h47min de 14 de junho de 2019 (UTC)

@CaiusSPQR Feito.[14] !Silent (discussão) 23h25min de 14 de junho de 2019 (UTC)

TeX e HTML

Seria possível adicionar as seguintes regras para TeX quando for usada com HTML por algumas predefs?

/* Classes genéricas para serifa baseada em Times, classe texhtml para matemática em linha */
.times-serif,
span.texhtml {
	font-family: "Nimbus Roman No9 L", "Times New Roman", Times, serif;
	font-size: 118%;
	line-height: 1;
}
span.texhtml {
	white-space: nowrap;
}
span.texhtml span.texhtml {
	font-size: 100%;
}
span.mwe-math-mathml-inline {
	font-size: 118%;
}

/* Forçar exibição tabular e de revestimento para dígitos e texhtml */
.digits,
.texhtml {
	-moz-font-feature-settings: "lnum", "tnum", "kern" 0;
	-webkit-font-feature-settings: "lnum", "tnum", "kern" 0;
	font-feature-settings: "lnum", "tnum", "kern" 0;
	font-variant-numeric: lining-nums tabular-nums;
	font-kerning: none;
}

Obrigado. —CaiusSPQR^(discussão) 03h00min de 3 de julho de 2019 (UTC)

@CaiusSPQR Feito.[15] !Silent (discussão) 00h34min de 5 de julho de 2019 (UTC)

Margem em infobox_v2

Podiam por favor adicionar uma margem-top à classe infobox_v2, ao alterar o texto .infobox_v2 { margin: 0 0 .5em 1em; ... } para .infobox_v2 { margin: 0.5em 0 0.5em 1em; ... }. Faço este pedido pois quando uma infobox utiliza o parâmetro título sem o parâmetro cabeçalho, a infobox fica desalinhada com parágrafos, que no topo de uma página, possuem uma margem de 0.5 em. Com uma margem no topo da infobox, a infobox e o texto ficam alinhados. --CaiusSPQR^(discussão) 21h49min de 1 de dezembro de 2019 (UTC)

@CaiusSPQR Feito.[16] !Silent (discussão) 22h54min de 1 de dezembro de 2019 (UTC)

Estilos para referências e colunas

@!Silent, Poderia por favor atualizar a página para incluir as seguintes regras? As duas últimas para resetar margem de topo de listas em colunas para que fiquem com margens uniformes em colunas. As duas primeiras são para que referências tenham o mesmo tamanho de 90% (atualmente é diferente em algumas predefinições como Predefinição:InícioRef, que tem um elemento div). Eu atualizei o common.css de minha própria conta e não percebi nenhum bug. Isto é baseado em como é feito na enwiki, então o conteúdo não é meu. Por isso por favor também não se esqueça de seguir a licença (que é somente CC BY-SA).

ol.references,
div.reflist {
	font-size: 90%;            /* font-size padrão */
	margin-bottom: 0.5em;
}
div.reflist ol.references {
	font-size: 100%;           /* Resetar font-size quando aninhado em div.reflist */
	margin-bottom: 0;          /* Evitar margem dupla quando aninhado em div.reflist */
	list-style-type: inherit;  /* Habilitar tipos de estilo de lista personalizadoss */
}

/* Resetar margem de topo para listas embutidas em colunas */
div.columns {
	margin-top: 0.3em;
}
div.columns dl,
div.columns ol,
div.columns ul {
	margin-top: 0;
}

Também é importante remover uma regra para "ol.references" que está atualmente na página. --CaiusSPQR^(discussão) 07h05min de 19 de agosto de 2020 (UTC)

@CaiusSPQR Feito.[17] !Silent (discussão) 11h22min de 19 de agosto de 2020 (UTC)

Etiquetas

Quero colocar o seguinte estilo CSS para etiquetas, assim como na enwiki:

/* Styling for Abuse Filter tags */
.mw-tag-markers {
	font-style: italic;
	font-size: 90%;
}

@!Silent, Albertoleoncio, Diego Queiroz e He7d3r: concordam com essa proposta? --Francisco (discussão) 14h16min de 11 de setembro de 2021 (UTC)

@Francisco Leandro Não me oponho. !Silent (discussão) 14h50min de 11 de setembro de 2021 (UTC)

Por mim tudo bem. Helder 19h56min de 11 de setembro de 2021 (UTC)

Done. :-) Diego Queiroz (discussão) 05h46min de 21 de setembro de 2021 (UTC)