Обсуждение MediaWiki:Common.css

Излишняя область действия убирания паддингов у медалей

Шаблон:Перенесено с Из-за этого правила паддинги пропадают не только в таблицах медалей, но и во всех вложенных в карточки таблицах, включая те, у которых эти свойства переопределены в скине — например, в карточках, вложенных в карточки. Надо бы, например, проставить класс infoboxmedals в ячейках, куда такие таблицы вставляют, и ограничить правило им. Просто оставлю это здесь на будущее. Викизавр (обс.) 10:25, 8 ноября 2018 (UTC)

FlaggedRevs

Убрал давно мозолящую мне глаза лесенку между Шаблон:Code и Шаблон:Code, однако из-за того, что плашки находятся в Шаблон:Code, в векторе и монобуке у них появляется еще один левый отступ. Проблему можно решить отрицательным отступом, но может быть есть какие-то более удачные предложения? grain of sand (обс.) 23:44, 3 ноября 2021 (UTC)

• Хе-хе, у меня есть такое более удачное предложение: фундаментально редизайнить этот позор Википедии, находящийся на самом видном месте у всех читателей, раз и навсегда. @Stjn. — Джек (обс.) 00:01, 4 ноября 2021 (UTC)
  • Это было бы совсем замечательно. grain of sand (обс.) 00:25, 4 ноября 2021 (UTC)

Убрать лигатуры из <pre>, <code>

Современные браузеры обрабатывают некоторые сочетания латинских букв как лигатуры. Лигатуры отображаются как символ полуторной ширины. Это совершенно не к месту в программном коде, где все символы должны иметь одинаковую ширину.

Пример: The fictional file is finally filtered.

Решение проблемы: добавить CSS-правило, убирающее лигатуры там, где они не нужны. <source lang="css"> code, tt, pre, textarea {

   font-variant-ligatures: none;

} </source> —Sauron (о⬩в) 08:13, 8 марта 2024 (UTC)

• @DrSauron: я не вижу, чтобы лигатуры в этом коде появлялись. Пожалуйста, напишите на Фабрикатор с указанием своего браузера / операционной системы и приведением скриншотов, чтобы, возможно, подобные изменения были внесены в CSS всех сайтов (можете подписать меня к этому таску через упоминание @stjn). stjn 22:54, 8 марта 2024 (UTC)

Стратегия работы с общим CSS

Занимаясь в последние дни работой над общим CSS, подумал, что было бы хорошо где-то описать (и получить отзывы) о стратегии работы с общим CSS, которая мне кажется оптимальной в качестве баланса между повсеместным использованием TemplateStyles и помещением всего подряд в MediaWiki:Common.css. Контекст:

1. сейчас разработчики обсуждают отказ от MediaWiki:Mobile.css в пользу MediaWiki:Minerva.css, см. phab:T248416
2. MediaWiki:Mobile.css грузится асинхронно, MediaWiki:Minerva.css грузится синхронно
3. переход на MediaWiki:Common.css при этом разработчикам видится нецелесообразным, так как у большинства проектов там находится много CSS, который не нужен для большинства просмотров сайта.

Я посмотрел на часть шаблонов, которые обслуживались Common.css, и пришёл к следующему плану:

1. в Common.css должен остаться только CSS, который невозможно реализовать через TemplateStyles или который критичен для оформления сайта;
2. в общих случаях, за исключением чрезмерно малого размера кода (а-ля Шаблон:Lang-ref), критичность CSS должна оцениваться по формуле «используется в более 50% страниц основного пространства в мобильной версии»;
3. всё остальное может быть перенесено в защищённые до администраторов (или незащищённые) стили шаблонов: см. подстраницы Модуль:Message box, Модуль:Coordinates/styles.css, Модуль:Navbar/styles.css (не защищён) и т. п.;
4. (менее важно из-за малого размера) из файлов отдельных скинов так же нужно перенести в TemplateStyles всё, что возможно.

Ввиду отказа от Mobile.css и того факта, что Mobile.css грузится асинхронно, я переименовал Mobile.css в новый гаджет по умолчанию, в котором можно будет совместить критичные стили для обеих версий сайта: MediaWiki:Gadget-common-site.css. Сейчас он работает только на скине Минерва, но после ревизии стилей в гаджете и выноса наиболее полезных стилей из Common.css по правильным местам я планирую включить его для всех скинов (= для обеих версий). Включение Common.css для обеих версий пока кажется нереалистичным из-за его объёма.

По критерию выше предложение, например, добавить plainrowheaders можно в целом отклонить, потому что использований plainrowheaders вряд ли когда-нибудь будет более 50% страниц в ОП. Если что, это пока не «правило», а просто наброски технического соглашения и мотивация предпринимаемых технических решений.

Пишите, если у вас есть какие-то комментарии. stjn 00:24, 26 марта 2024 (UTC)

• Оффтоп: Модуль:Navbar/styles.css (не защищён) стоит описать более конкретно в документации (this). Плашка [[{{#if:|{{{2}}}#{{{lang}}}|{{{2}}}#Шаблон:Lang-onTS}}|{{#if:|{{{{{sc}}}|{{{2}}}}}|{{{2}}}}}]] {{#ifeq:onTS|{{#switch:onts|nan=zh-min-nan|yue=zh-yue|cmn=zh|onts}}||^{[[:{{#switch:onTS|nan=zh-min-nan|yue=zh-yue|cmn=zh|onTS}}:{{{2}}}|(onTS)]]}}}{{#switch:|f|m|mf|n|c|nm= {{{{{3}}}}}|p|pl= Шаблон:Мн}}{{#switch:|s|p= {{{{{4}}}}}|}}{{#if:| ({{{tr}}})}} предполагает, что стили включаются всегда, а здесь они включаются (судя по текущему количеству включений - 1433) очень редко, вероятно, только для [[{{#if:|{{{2}}}#{{{lang}}}|{{{2}}}#Шаблон:Lang-Tnavbar}}|{{#if:|{{{{{sc}}}|{{{2}}}}}|{{{2}}}}}]] {{#ifeq:Tnavbar|{{#switch:tnavbar|nan=zh-min-nan|yue=zh-yue|cmn=zh|tnavbar}}||^{[[:{{#switch:Tnavbar|nan=zh-min-nan|yue=zh-yue|cmn=zh|Tnavbar}}:{{{2}}}|(Tnavbar)]]}}}{{#switch:|f|m|mf|n|c|nm= {{{{{3}}}}}|p|pl= Шаблон:Мн}}{{#switch:|s|p= {{{{{4}}}}}|}}{{#if:| ({{{tr}}})}} или прямого вызова его же из модуля. ~~‍~~ Jaguar K · 06:35, 26 марта 2024 (UTC)
• Я долго об этом думал. Насколько сильно изменится время загрузки и вес страниц если мы перенесем из коммона в тс, например, навбоксы и амбоксы? Iniquity (обс.) 10:05, 26 марта 2024 (UTC)
  • Ну, амбоксы (и, до этого, остальные мбоксы) я уже перенёс в TS, так как они используются где-то в четверти статей. В целом единственная рекомендация, о которой мне известно, была от Ladsgroup и касалась скорее перформанса баз данных сайта: phab:T343131#9140322 («шаблоны, которые используются в большинстве статей, лучше держать в common.css; шаблоны, которые используются в 30%, лучше держать в TS»). Возможно, какой-нибудь Krinkle или кто-то ещё писали на подобные темы тоже, но это надо где-то найти. stjn 10:45, 26 марта 2024 (UTC)
    • Окей, спасибо. Iniquity (обс.) 16:04, 26 марта 2024 (UTC)

class=Unicode

А почему класс «Unicode» содержит только два шрифта? Необходимо добавить шрифты, содержащиеся в шаблоне Шаблон:Lang-ref. Tril��a (обсуждение | вклад) 17:36, 15 марта 2013 (UTC)

К сожалению, из Вашей реплики пока что непонятно, понимаете ли Вы, что здесь указано только исправление класса для Windows браузеров (а судя по коду, который сейчас в enwiki, оно видимо нужно только для Windows XP). А указанный выше шаблон в enwiki давно удалён. — AlexSm 18:06, 15 марта 2013 (UTC)

Но ни Arial Unicode MS, ни Lucida Sans Unicode не поддерживают символы SMP. Т.е. если я напишу «{{unicode|𐀀}}», то никакого толку не будет. Даже при шрифте, поддерживающем этот символ, пользователь всё равно увидит непонятно что. Tril��a (обсуждение | вклад) 11:01, 17 марта 2013 (UTC)

P.S. Можно к примеру сделать так: <source lang="javascript"> mw.util.addCSS('.IPA, .Unicode { font-family: "Шаблон:Unicode fonts"; }') </source> Tril��a (обсуждение | вклад) 15:03, 20 марта 2013 (UTC)