Nova formatação de postagem

Atualização 3

Levei mais tempo do que eu queria, mas tenho algumas atualizações para você em nosso s-prosecomponente. Você pode ver a solicitação pull com minhas reflexões no repo do nosso sistema de design. Ele faz o seguinte:

1. Espalha s-prosecabeçalhos de parágrafos para melhor agrupamento.
2. Aperta s-proseum pouco os parágrafos e garante que o espaçamento sob os cabeçalhos seja mais consistente.
3. Substitui todas as s-prosemargens internas do componente por uma variável CSS var(--s-prose-spacing)para que nossos usuários possam mexer nela com mais facilidade em seus navegadores e scripts de usuário.
4. Mata as margens finais em s-prose

Você pode ver alguns exemplos de conteúdo em nossa documentação de pilhas.

Atualização 2

Eu dividi a diferença entre a 1.3altura da linha original e a altura da 1.6linha proposta . Estamos agora em 1.5, com refinamentos adicionais no espaçamento entre os elementos. Eu também reduzi a altura da linha dentro dos blocos de código para perto do valor original.

Atualização 1

Agora está ao vivo.

Estamos fazendo uma pequena refatoração em nossa formatação de postagem. Atualmente, aplicamos uma única classe com layout e estilo chamados .post-text. Nosso primeiro objetivo é separar o layout de nossos estilos de texto. Simples o suficiente!

No entanto, nosso estilo de postagem atual tem alguns pontos ausentes e áreas para melhorias. Usando nosso sistema de design como uma caixa de areia, reforçamos nosso estilo e criamos um novo componente chamado .s-prose. Ele foi projetado para oferecer estilo para tudo o que a especificação CommonMark permite. Isso deve nos permitir adicionar estilo com o sabor de Stack Overflow em qualquer lugar em que precisamos consumir Markdown - perguntas e respostas, é claro, mas também coisas como perfis de usuário.

Nosso .s-prosecomponente adiciona:

1. Formatação adequada para listas de definição

2. Mais suporte da plataforma e melhor espaçamento lá

3. blockquoteRefinamentos adicionais .

4. Refinamentos para revelar spoilers. Agora revelamos isso com um clique / toque para uma experiência mais consistente em todos os dispositivos - menos revelações acidentais também, já que não é mais uma :hoverinteração. Clicar novamente não esconde o spoiler. Agora também adicionamos um emblema no canto superior direito. Você pode ver como eles funcionam na documentação do nosso sistema de design . É mais ou menos assim:

   Este é um spoiler
   Tem duas linhas

5. Refinamentos gerais de espaçamento, incluindo listas aninhadas, imagens dentro de listas

6. Variações de dimensionamento para diferentes contextos. Oferecemos xs, sme mdvariações do. s-prosecomponente.

Como com tudo, nosso componente de prosa é um trabalho em andamento. Achamos que temos um ótimo começo para um componente reutilizável. Planejamos colocar ao vivo a nova rede de componentes na quinta-feira, 27 de agosto de 2020. Vamos editar este post se isso mudar.

Se você ver algo estranho, diga-nos. Algumas coisas são intencionais, mas podem parecer regressões - as imagens têm uma linha de base ligeiramente diferente - mas outras podem ter escapado pelas rachaduras.

status-bydesign

A quantidade de espaços em branco entre as linhas de texto ( line-height) mudou. Não sei se foi intencional, mas gostei mais do antigo. Houve um bom motivo para alterá-lo ou podemos tê-lo de volta? Eu, pelo menos, gostei mais do antigo, porque o novo faz as letras 'dançarem' um pouco mais para mim, só não parece tão bom.

Velho:

Novo:

Relacionado:

• Reverta a alteração da altura da linha!
• Pedido de possibilidade de ajustar o espaçamento entre linhas para pessoas com visão deficiente
• Usercript para obter a altura da linha antiga de volta
• Houve uma atualização com uma alteração do espaçamento entre linhas?

OK, aqui estão duas sugestões.

Primeiro, volte ao espaçamento de linha original. Acho este difícil de ler.

Em segundo lugar, envie uma mensagem a todos sobre isso e não conte com a barra lateral Meta para anunciá-lo. Na verdade, pensei que meu navegador tinha errado ou mudei uma opção em algum lugar. Eu tentei navegadores diferentes, reiniciei minha máquina, etc. e então decidi pesquisar Stack Overflow. Tudo porque eu não poderia imaginar que algo assim ocorreria sem um grande anúncio. Isso impedirá que outras pessoas percam seu tempo resolvendo problemas.

bug status-complete

Links em spoilers só podem ser clicados com o botão do meio

Exemplo:

Este link não é clicável com o botão esquerdo, mas apenas com o botão do meio - ele abre em uma nova guia e não há como clicar diretamente.

No celular, para abrir o link, você deve tocar e segurar até que o menu do link apareça, onde você pode escolher a opção “Abrir link em nova aba”.

Além disso, passar o mouse sobre o link sempre revela o URL do link na barra de status, mas isso é um problema menor.

Acho que a melhor solução seria não propagar cliques no spoiler se algum elemento interativo estiver sendo clicado, mas apenas se o spoiler já tiver sido revelado . Se o spoiler ainda não foi revelado, um clique com o botão esquerdo em qualquer lugar dentro do spoiler deve primeiro revelar o spoiler. ¹ Não quero sair clicando em um link invisível.

Também testei oneboxes do GitHub (link de 10k) que apresentam o mesmo problema. Isso, aliás, também consertaria trechos de pilha em spoilers .

Claro, os dois últimos são casos extremos e links regulares são os casos mais comuns, mas isso mataria três coelhos com uma cajadada só.

^{1 O} usuário 41686d6564 apontou que o clique do meio e o clique com o botão direito não devem revelar o spoiler. Embora este comentário tenha surgido de uma formulação ambígua, eu mesmo não tenho certeza de como lidar com cliques do meio ou com o botão direito em spoilers ocultos. Ignorá-los (ou seja, não revelar o spoiler, mas ainda permitir recursos padrão do navegador, por exemplo, menu de contexto) é provavelmente uma boa opção.

bug status-complete

Tentar arrastar e selecionar o texto do spoiler resulta em ele ser ocultado novamente

Parece um comportamento não intencional.

erro

O fundo do ( <pre>s) bloco ( s) de código está mais claro agora, tornando mais difícil distinguir do fundo branco à primeira vista (em todos os lugares, exceto no modo escuro do Stack Overflow).

Anteriormente, com background-color: var(--black-050);ou #EFF0F1em branco:

Agora, com background-color: var(--highlight-bg);ou #F6F6F6em branco:

Com a versão anterior, ficou absolutamente claro onde estão as bordas do bloco de código. Agora, tenho olhos melhores que a maioria, mas mesmo para mim no monitor, as bordas parecem desconfortavelmente indistintas.

Another example code block

(Usar a cor de fundo de inline <code>seria bom demais, IMO)

Notei que a própria cor do texto nas blockquotes agora está muito clara. É difícil ler para mim e tenho uma visão decente.

O estilo atual é .s-prose blockquote {color:var(--black-600)}. Excluí-lo completamente escurece o texto do bloco de notas e o torna legível novamente.

Este texto é muito claro. Por favor, escureça.

bug status-bydesign Os botões de rolagem são invisíveis nas janelas de código roláveis

Não tenho certeza se isso afeta a barra de rolagem vertical também, mas as janelas de código com rolagem horizontal não mostram mais os botões de rolagem reais . Eles ainda estão lá e clicáveis, apenas ... sem acento circunflexo ou qualquer coisa para indicar que é um botão de rolagem direcional.

(essas janelas de rolagem são roladas para a esquerda o máximo possível):

e modo leve:

erro

O plano de fundo do código embutido é diferente do plano de fundo dos blocos de código.

Isso faz com que pareçam "coisas diferentes" quando, na verdade, são apenas código e devem ser formatados da mesma maneira.

Exemplos ao vivo (no modo TÃO escuro a diferença é muito mais significativa):

Código inline: this is inline code

Um bloco de código:

this is a code block

status concluído

Existe um local / página / site público onde isso já está habilitado, onde eu possa testá-lo (para minha própria curiosidade ou potencialmente para relatar um problema), antes de ir ao ar em qualquer lugar?

Você escreveu: "Se você vir algo estranho, diga-nos." - onde posso olhar?

Eu gostaria de saber como é:

• Item da lista

  Lista para

• Item da lista

  Lista para

  • Subitem
  • Subitem

  Lista para

Você mencionou "Refinamentos gerais para espaçamento incluindo listas aninhadas", então estou curioso para saber se você corrigiu isso - isto é, que IMO deveria haver um espaço em branco vertical entre o último subitem e o próximo parágrafo da lista.

Atualmente, há algo estranho no primeiro parágrafo da lista também: margem de 15px após o primeiro item da lista antes do parágrafo da lista e apenas 7,5px de margem após o parágrafo da lista antes do segundo item da lista.

Os exemplos em seu https://stackoverflow.design/product/components/prose/ sugere que você corrigiu o segundo deles - a margem agora é de 7,5 px em todos os lugares - mas não vejo um teste / exemplo do primeiro cenário acima.

bug status-complete

Ao fazer uma pergunta com um spoiler, posso clicar no novo emblema 'Revelar spoiler' quantas vezes quiser, mas ele não revela nada.

Funciona quando você está escrevendo uma resposta:

revisão do status do bug

Links com formatação de código embutido parecem estranhos.

Captura de tela usando Firefox 68.11.0esr (64 bits) no Debian:

Ao pairar, o azul ligeiramente mais claro não é perceptível em comparação com um link normal.

Pelo menos o sublinhado do link azul está abaixo do sublinhado regular.

Captura de tela usando Firefox 73.0.1 (64 bits) no Windows 10:

Exemplo real: __index__

bug status-complete

Itálico não é renderizado na web móvel. Sem problemas aparentes com Markdown em negrito. Android 5.1.1, Chrome 84.0. Captura de tela desta resposta do sandbox de formatação :

*This should be rendered as italics (asterisks).*  
_That, as well (underscores)._  
**This is bold text.**  
__Also bold text.__

Estava funcionando bem esta manhã, antes de a mudança entrar no ar.

bug status-complete

No celular (especificamente na visualização acessada clicando no botão “site completo”, no iPhone), pelo menos no RPG.SE e no Puzzling.SE, o corpo do texto nas perguntas e respostas encolheu. Em comparação, comentários, títulos e cabeçalhos não parecem ter encolhido.

Eu uso óculos para miopia e uso SE diariamente. No meu telefone, agora devo segurá-lo a 15 centímetros de meus olhos para poder ver bem. Eu costumava ser capaz de ver melhor a cerca de trinta centímetros de distância. Isso é algo que acho inútil se eu aumentar o zoom da página, todo o resto cresce também, o que não é necessário.

Você pode aumentar o texto no celular?

Quero chamar a atenção dos leitores, principalmente do @AaronShekey, para o fato de que o W3C não recomenda definir a altura da linha para 1,5 ou mais .

As recomendações relevantes parecem ser os critérios das WCAG 1.4.12 (Espaçamento de texto) e 1.4.8 (Apresentação visual).

O critério 1.4.12 em relação ao espaçamento do texto diz:

No conteúdo implementado usando linguagens de marcação que suportam as seguintes propriedades de estilo de texto, nenhuma perda de conteúdo ou funcionalidade ocorre ao definir todos os itens a seguir e não alterar nenhuma outra propriedade de estilo:

• Altura da linha (espaçamento entre linhas) de pelo menos 1,5 vezes o tamanho da fonte;
• (etc.)

Portanto, este não é um requisito ou uma recomendação para a configuração da altura da linha - é um requisito que, se as linhas forem definidas para serem mais espaçadas, o site / página da web não se torne inutilizável ou disfuncional e nenhum conteúdo se torne invisível / inacessível.

O documento W3C intitulado "Noções sobre o Critério de Sucesso 1.4.12: Espaçamento do Texto" reitera isto (grifo meu):

A intenção deste Critério de Sucesso (SC) é garantir que as pessoas possam substituir o espaçamento do texto especificado pelo autor para melhorar sua experiência de leitura.

A recomendação é oferecer suporte à substituição de configurações para atender às necessidades de alguns leitores - não alterar as configurações padrão.

Critério das WCAG 1.4.8 em relação às leituras de apresentação visual (ênfase minha):

Para a apresentação visual de blocos de texto, um mecanismo está disponível para atingir o seguinte: (Nível AAA)

... recorte ...

O espaçamento de linha (entrelinha) é de pelo menos um espaço e meio dentro dos parágrafos, e o espaçamento de parágrafo é pelo menos 1,5 vezes maior do que o espaçamento de linha.

Portanto, não o padrão, mas a possibilidade de realização por meio de algum mecanismo.

@MaxD vinculado a um documento de "técnicas" referente ao critério 1.4.8 que menciona a importância de fornecer espaçamento de linha entre 1,5 e 2, mas:

• Esse documento não é o WCAG oficial.
• "Fornecer" não significa "ter esse como o padrão". O WCAG real esclarece que a intenção é fornecer o mecanismo para fazer essa configuração. Por exemplo, uma configuração por usuário no nível do site para esse efeito.
• O critério 1.4.8 diz respeito à conformidade de nível AAA. Esse nível não se destina (de acordo com o próprio documento WCAG) para uso geral, mas para sites mais especializados em acessibilidade.

_{Divulgação devida: Eu postei isso como uma resposta a essa discussão relacionada também.}

Vamos esconder spoilers

pedido de recurso

Isso parece ter surgido com uma solução alternativa para bloquear a ocultação novamente para que os links possam ser clicados e o texto arrastado, consulte este comentário sobre o assunto .

Isso foi corrigido. Não há mais cliques fantasmas de links subjacentes. Os spoilers são revelados com qualquer clique esquerdo em qualquer lugar do spoiler. Clicar novamente não oculta novamente o spoiler (mas permite que seu conteúdo manipule seus próprios cliques) - Ben Kelly ♦

Visto que isso foi introduzido para ajudar a minimizar a revelação acidental de texto, devemos permitir que os usuários também ocultem o texto novamente. Cliques acidentais ainda vão acontecer e, mesmo que não sejam, devemos dar aos usuários a chance de ocultar novamente o conteúdo que eles não querem ver.

Agora revelamos isso com um clique / toque para uma experiência mais consistente em todos os dispositivos - menos revelações acidentais também, já que não é mais uma interação: hover. Clicar novamente não esconde o spoiler.

Parece que essa funcionalidade foi removida como uma solução alternativa para corrigir o problema, em vez de qualquer outra coisa. Deve ser possível clicar em links / selecionar texto e ocultar novamente um spoiler. A maioria dos lugares oferece as duas opções e, se bem me lembro, a antiga formatação do spoiler também fornecia essa opção. Isso parece um passo na direção errada.

Vamos fazer o que fazemos de melhor como programadores;)

⭐Revert Stack Exchange Formatting⭐

• Extensão do Google Chrome (personalizável)
• Script Greasemonkey / Tampermonkey | (apenas altura da linha)
• Tema elegante (+ Stylus) - | [Modo escuro]

ATUALIZE OS SCRIPTS! : atualizado para corrigir novas alterações nos blocos de código (24 de setembro de 2020)

Móvel:

• Solução limitada: Javascript ativado por clique por página (iOS, Android)
• Kiwi Browser (Android) - instale a extensão do Chrome acima (não testada)

Contribuir:

Repositório GitHub - ajude-me a revertê-lo fielmente!

status concluído

O artigo da Central de Ajuda sobre a edição do Markdown precisa de atenção :

Spoilers

Para ocultar um determinado trecho de texto e torná-lo visível apenas quando um usuário move o mouse sobre ele , use a sintaxe blockquote com um ponto de exclamação adicional:

At the end of episode five, it turns out that
>! he's actually his father.

A parte que coloquei em negrito deve ser atualizada para refletir a nova situação.

pedido de recurso

Refinamentos adicionais de blockquote.

Este refinamento soa como tirar a ênfase da citação!

Em vez de tirar a ênfase do blockquote, sugiro diferenciar o blockquote do texto normal usando um fundo adequado. Gostaria de informar sobre o consenso dos usuários para a formatação blockquote citando:

(118 votos positivos) Por favor, reverta o fundo da citação de branco para amarelo

A atual formatação de blockquote precisa de uma correção o mais rápido possível. Espero que isso seja considerado.

Considerando os comentários contra isso, eu realmente acho o novo espaçamento mais fácil de ler.

Sou disléxico - e uma das 'adaptações' que faço (e não é positiva) é bloquear a leitura. Já que estou pegando menos coisas de uma vez e diminuindo a velocidade, é menos cansativo para mim.

Eu realmente não percebi que essa era uma opção ou se ajudaria, mas parece que sim, e de forma bastante dramática.

Como alguém que é descrito como "uma fração menor do seu público geral", obrigado por consertar algo que eu nunca percebi que estava quebrado e parece ser uma grande mudança na qualidade de vida para mim.

Eu vejo os argumentos para ter menos espaço entre as linhas de código (Monica tem alguns aqui , embora, no caso dela, eu entenda que ela mencionou no Twitter em vez de aqui, e espero que ela me perdoe por reproduzi-los aqui).

Espaçamento de linha fixo maior (sem levar em consideração a fonte), quase com espaço duplo, por isso é mais difícil rastrear ao ler um parágrafo e mais difícil ver as quebras de parágrafo. Para blocos de código, agora cabe menos na tela; o código não é lido apenas sequencialmente como a prosa. Não é possível reduzir o tamanho b / c inalterado.

Estou pessoalmente não ver um problema dizer aos meus parágrafos separados, e eu uso um monte deles em quebrar as minhas paredes de texto, mas outros talvez. Receio ter que deixar para eles postarem uma resposta explicando como isso não funciona.

bug status-complete

A nova exibição de spoiler não está funcionando corretamente em wikis de tag, por exemplo, aquele sobre spoilers . O emblema 'Revelar spoiler' é mostrado:

mas o conteúdo já é visível ao passar o mouse sobre ele (que é o comportamento antigo).

Não consigo ver por que uma refatoração do código de estilo do post é aplicada junto com mudanças significativas nessa formatação. Na minha experiência, é do conhecimento comum que você refatore sua infraestrutura primeiro sem alterar o comportamento do usuário (tanto quanto possível, é claro) e, em seguida, faça alterações de comportamento enquanto descansa de maneira estável na nova infraestrutura.

Também estou desapontado ao ver que o infeliz espaçamento de linhas foi ativado, visto que:

• Tem havido um feedback negativo maciço dos usuários.
• Não houve muito / nenhum feedback positivo.
• O argumento para aumentar o espaçamento entre linhas, mesmo quando tomado pelo valor de face, diz respeito a uma pequena minoria de pessoas em geral (algumas pessoas com certas deficiências), e provavelmente a uma minoria ainda menor da base de usuários do site; para o qual faria mais sentido introduzir uma opção.
• Não houve nenhuma reclamação de usuários sobre o espaçamento entre linhas ser muito pequeno, nem quaisquer estudos de grupos de usuários que tenham chegado a esta conclusão; pelo menos, não que saibamos.
• Não houve nenhuma avaliação se a suposta dificuldade para alguns usuários rastrear linhas em um espaçamento de 1,3 realmente se manifestou.
• Não houve avaliação do efeito oposto: a dificuldade de rastrear linhas quando estão muito espaçadas . Além disso, de observar claramente a distinção entre parágrafos.
• Nenhuma consideração foi feita sobre a arte textual com espaçamento uniforme antes de a mudança entrar em vigor na rede.
• (editado: veja minha resposta separada sobre o que o W3C faz e o que realmente não recomenda.)

A resposta de "dividir a diferença" e continuar em frente, embora seja melhor do que ignorar a reclamação, não é o curso de ação apropriado. Assim que for reconhecido que há um problema - a alteração pretendida deve ser adiada e analisada com mais atenção, em vez de "resolvida" apressadamente.

revisão de status

Outro usuário afirma que o texto encolheu , enquanto eu acho a mudança dentro dos limites aceitáveis ​​no Firefox Android; mas no Chrome Android o texto é muito grande em comparação com o que era anteriormente:

Como você pode ver com o Chrome, a diferença entre o tamanho das fontes do post e (por exemplo) as fontes da lista "Vinculadas" da coluna certa é significativa. A visualização no Chrome costumava ser semelhante à visualização no Firefox (que agora também é diferente, mas não terrível).

Com o novo tamanho de fonte maior da postagem do Chrome, muito pouco texto cabe em cada linha, basicamente 50% da quantidade de informação sendo apresentada na mesma área da tela.

Eu entendo que posso ajustar o tamanho das fontes no meu navegador, mas não quero que algumas fiquem muito pequenas ou tenham que se reajustar para visitar outros sites - estava tudo bem antes das alterações.

[Nota: Votei positivamente no anúncio quando o vi no Firefox, obrigado pela melhoria, mas agora, vendo-o no Chrome (e todas as outras reclamações), considero-o indigno do meu apoio anterior.]

Eu encontrei uma maneira de mostrar qual CSS está sendo usado para vários elementos, o Android Kiwi Browser (77.0.3865.92) é baseado no Chrome e permite extensões - aqui está o que a extensão "CSS Peeper" diz sobre as páginas da web: O tamanho da fonte do comentário parece grande , H2 é font-size 34,3 e H3 é de 33,3 (quase o mesmo), pergunta hyperlinks parecer normal em 13 px, enquanto regulares texto é 29,8 px e atribuído a P .

Samsung S9 + com Firefox Android 80.0.1-beta.2 (Build # 2015758611) e Chrome 85.0.4183.81

Ao adicionar suporte para mais tamanhos de título, h1parece muito grande agora e quebra algumas postagens mais antigas:

_{Postar: https://stackoverflow.com/a/38025376/3705191}

O h1tamanho antigo (ou #em MD) era mais próximo do h2tamanho da fonte atual , e o autor do post capturado acima provavelmente o pretendia como um cabeçalho h2 devido ao seu tamanho. O aumento no tamanho altera o significado pretendido e, portanto, a formatação pretendida do autor. O que antes parecia um subtítulo coerente, agora parece um título de artigo separado.

Eu gostaria que as respostas antigas fossem preservadas tanto quanto possível com a formatação original pretendida.

bug status-complete

Não há como revelar o spoiler em um perfil de usuário.

Além disso, quando passo o mouse sobre o conteúdo do Markdown do spoiler durante a edição do perfil, a opção "Revelar Spoiler" desaparece.

Isto é o que eu tenho ao editar o perfil:

E é quando eu passo o mouse sobre o conteúdo do Markdown:

A revelação de spoilers requer Javascript de terceiros

... quais novos usuários e os paranóicos (deveriam) ter bloqueado por padrão; o resultado é uma experiência ruim.

erro

Listas de uma linha (sem <p>) têm um grande espaçamento:

• Olá
• Mundo
• Teste

Markdown:

- Hello
- World
- Test

Isso é exatamente igual a listas com parágrafos:

• Olá

• Mundo

• Teste

Markdown:

- Hello

- Hello

- World

Listas sem linhas em branco entre os itens não devem ser renderizadas como um parágrafo (e não são, sem <p>tag) e provavelmente também não devem se parecer com um parágrafo. Este tem sido um recurso desde o Markdown original e também está no CommonMark .

Um lugar onde isso parece muito descolado é no meu perfil .

Isso é definido pelo CSS abaixo, e a remoção faz com que pareça correto:

.s-prose ol li, .s-prose ul li {
    margin-bottom: .7em;
}

Dado que a documentação do sistema de design menciona explicitamente pequenos textos , há uma chance de finalmente obter a <small>tag como HTML permitido nas postagens do Markdown? O caso<small> foi feito muitas vezes e, mais saliente, as pessoas abusam liberalmente de <sup>/ <sub>_{/ ^ambos} como uma solução alternativa, então todos os argumentos contra a introdução da tag já se aplicam ao status quo (exceto pior).

Links em torno do código não aparecem no site para celular

Veja a captura de tela de uma resposta minha (conforme aparece no Firefox e no Chrome no Android):

Observe que me refiro à "documentação que vinculei", mas não parece que tenha vinculado nada.

Na realidade, inseri um link em torno do nome da função da seguinte maneira

... use [`PyArray_ZEROS`](http://example.com) ...

... use PyArray_ZEROS...

Parece um código normal, sem nenhuma indicação de que seja clicável. (No desktop tem um sublinhado azul, então é um pouco mais óbvio)

"... com refinamentos adicionais ao espaçamento entre os elementos"

Você já deve saber, eu li algum designer que recomendou uma margem entre os parágrafos igual à altura da linha - para que haja exatamente uma linha vazia entre os parágrafos - a "grade" de linhas na página é perfeitamente regular, e a margem entre os parágrafos é perfeitamente óbvia, possivelmente nem muito grande nem muito pequena.

IMO ter meia altura de linha entre (e dentro) dos itens da lista, como você tem agora, também é uma idéia muito boa (para fazer uma lista mais compacta e coesa).

Eu vejo que você atualmente tem ...

• Tamanho da fonte 15px
• 1,5 altura de linha

... e então a altura da linha é 22,5 px.

E você atualmente tem:

• Margem interparágrafo de 21px
• Margem de 10,5 px nas listas

Observe que 21px está muito próximo de 22,5px - é por isso que parece certo, IMO - não exatamente.

IMO, uma margem de 21px seria perfeitamente adequada para uma altura de linha de 1,4 (15px * 1,4 = 21px).

Portanto, se você deseja ou deve ter uma altura de linha de 1,5 , sugiro que experimente uma margem entre parágrafos de 22,5 px em vez de 21 px - veja como fica, se funciona na prática e também na teoria - e 11,25 px nos itens da lista.

Também só para sua informação, um refinamento adicional que gostei em outro lugar:

• Zero margens internas (ou seja, apenas as alturas das linhas) separando os itens da lista, se for apenas uma lista "simples" (ou seja, quando todos os itens da lista não contêm nada além de texto, nenhuma sub-lista ou parágrafo) - isso torna essas listas mais compactas e coeso.

  Não sei se você pode implementar isso, dado o HTML que você tem que trabalhar.

  Acho que me lembro do Discourse fazendo isso - a margem entre os itens das listas torna-se espaçosa se você editar o markdown para tornar qualquer item complexo.

• Uma lista simples, sem margens verticais internas, poderia servir com meia linha de margem entre ela mesma e o parágrafo anterior que a apresenta (portanto, adere ou flui do parágrafo anterior).

  Eu acho que para implementar isso, seu CSS pode precisar definir a margem superior para tudo em vez de a margem inferior.

pedido de recurso

Em primeiro lugar, a diferença entre 1.3e 1.6para as novas mudanças de altura de linha é 1.45, na verdade , não 1.5. Em segundo lugar, gostaria de ter as alturas de linha adicionadas como opções nas preferências, o que seria uma melhoria real de acessibilidade.