Эта страница архивируется ботом

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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску


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

Перенесено со страницы Обсуждение MediaWiki:Mobile.css.

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

Исправление двойных иконок при ошибках фильтра правок в Визуальном редакторе[править код]

Салют, прошу добавить следующий код, который исправляет вот такое поведение иконок:

/* Костыль исправляющий дублирование иконки в сообщениях об ошибках (Editnotice) 
при сохранении правки в визуальном редакторе */
.ve-ui-mwSaveDialog .oo-ui-flaggedElement-error.oo-ui-iconElement table.fmbox {
  margin-top: 0;
}
.ve-ui-mwSaveDialog .oo-ui-flaggedElement-error.oo-ui-iconElement .mbox-image {
  display: none;
}

В TS его не занести, так как основной селектор находится за областью действия .parser-output. С уважением, Iniquity 08:34, 10 января 2021 (UTC)[ответить]

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

Желательно заменить hlist li:after • c символа на какую-либо подходящую картинку. В вики картинкой заменяется ul list-style-image: url(/w/skins/Vector/resources/common/images/bullet-icon.svg?d4515) а в англовики вместо маркера интерпункт - так они не читаются скрин-ридерами. Но тут маркер заданный текстовым символом постоянно зачитывается "элемент маркер элемент маркер …". Картинка в content может прочитаться, её можно в фон[1]. (aria-hidden к нему не применить) Половинчатое решение (не везде работает, но хотя бы такое) - добавить пустой альтернативный текст в content [2][3]. --Sunpriat 12:54, 11 августа 2022 (UTC)[ответить]

  • Пока просто добавил интерпункт вместо буллита. Давайте посмотрим, возмутит ли это кого-либо как решение. stjn 09:23, 9 июня 2023 (UTC)[ответить]

Добавить описание класса таблиц plainrowheaders[править код]

На англовики в en:MediaWiki:Common.css задан класс таблиц plainrowheaders, который делает колонку заголовков в таблице не жирной и выравненной по левому краю. У нас этот класс не задан, но присутствует в почти 10к статей. С дискографиями — это извечная проблема, которая превращает это en:David Guetta discography#2000s в это Дискография Давида Гетта#2000-е. Я полагаю что добавление этого куска кода должно решить эту проблему? Solidest (обс.) 20:54, 17 сентября 2023 (UTC)[ответить]

  • Т.к. теперь изменения не видны, вот их суть: https://i.imgur.com/hEPQbXR.png (Дискография Давида Гетта#2000-е) и https://i.imgur.com/vcVGJTU.png(до [4]) https://i.imgur.com/rxoTCoE.png (Thank U, Next#Чарты). Также разницу можно увидеть, если открыть редактирование раздела. ~~‍~~ Jaguar K · 22:47, 8 марта 2024 (UTC)[ответить]
  • так а чем плох русский вариант в сравнении с английским? MBH 23:10, 17 сентября 2023 (UTC)[ответить]
    • Тем, что он не работает как должен? "plainrowheaders" на рувики — это сейчас просто нерабочий текст, насколько я понимаю. Но и эстетически имхо текущий вариант дискографий выглядит плохо — в таблице не нужно столько заголовков, т.к. у нас жирный текст по правилам должен повторять заголовок статьи, да и выделять все эти "при участии" ни к чему. Но при этом есть смысл как-то отделять первый столбец. И это универсальный вариант отключать подобное оформление. Solidest (обс.) 23:15, 17 сентября 2023 (UTC)[ответить]
      • Кстати это также исправит несовпадающее оформление шаблонов альбомных чартов в случаях простановки кастомных чартов, см Thank U, Next#Чарты. Solidest (обс.) 23:44, 17 сентября 2023 (UTC)[ответить]
      • @Solidest нет, я имел в виду - чем плохо русское оформление в сравнении с английским. Да, у нас у таблиц заголовки жирные и центрированные, и по-моему так быть и должно. MBH 19:53, 8 марта 2024 (UTC)[ответить]
        • Я уже написал к этому контраргумент выше — и несоответствие ВП:Ж, и ненужность автовыделения «feat.» исполнителей. Да и кажется общепринятым и стандартным является размещение по левому краю целых колонок. А выделять центрированием правильно только горизонтальные заголовки колонок в шапке таблицы. Скорее всего это даже где-то есть в ГОСТах, но нужно поискать. В этом случае для выделения должно быть достаточно серого фона. Solidest (обс.) 20:16, 8 марта 2024 (UTC)[ответить]
          • Вот кажется и сам ГОСТ нашел: [5], см. пункт 6.6.6:
            Заголовки граф выравнивают по центру,а заголовки строк - по левому краю.
            Или тут [6] тоже самое рекомендуется для оформления т. н. боковика таблицы (см. изображение — «Пример 2»). Solidest (обс.) 20:21, 8 марта 2024 (UTC)[ответить]
          • А выделять центрированием правильно только горизонтальные заголовки колонок в шапке таблицы - а здесь речь не о них? MBH 20:22, 8 марта 2024 (UTC)[ответить]
            • Нет. См. иллюстрацию 6.6.4 из ГОСТа или Пример 2 из второй ссылки — здесь речь идёт о боковике, где должно быть центрирование по левому краю, а центрируются только заголовки граф в головке таблицы. Solidest (обс.) 20:25, 8 марта 2024 (UTC)[ответить]
  • (+) За, этот класс полезно перенести, имхо. Коллега Stjn, не посмотришь? Викизавр (обс.) 12:58, 18 сентября 2023 (UTC)[ответить]
  • Пожалуй, тоже за, ибо выглядит плохо. (Хотя тему, конечно, стоило разместить на более видном месте). ~~‍~~ Jaguar K · 15:43, 8 марта 2024 (UTC)[ответить]
  • На мой взгляд, в случае с этим классом, возможно, лучше сделать шаблон, который будет предоставлять возможность его использования в статьях, по типу {{стиль столбцов}}. Потому что в целом, насколько я понимаю, тенденция избавляться от общего CSS в случае с оформлением, которое может быть реализовано через TemplateStyles. stjn 20:30, 8 марта 2024 (UTC)[ответить]
  • (−) Против. Зачем это нужно? Ладно, где в таблице задан параметр «plainrowheaders», но есть статьи, где он не задан, например, в I Am Mina#Чарты вылезает жирность текста. К тому же если брать те же переведённые статьи с копированием таблиц чартов (Thank U, Next#Чарты), то ниже мы видим таблицу сертификатов, где этого серого фона в ячейках нет, тогда надо менять и там все.— Sanslogique (обс.) 09:30, 9 марта 2024 (UTC)[ответить]
    • Разделяйте против чего вы именно. Здесь предложение было в том, чтобы класс начал работать как и должен. То есть в тех случаях, когда класс указан и первый столбец уже выделен как заголовок с серым фоном, то тогда отключалось бы центрирование и жирный текст. То есть изменения должны выглядеть так https://i.imgur.com/vcVGJTU.png. Такая разница — это проблема того, что в шаблоне не прописаны некоторые чарты. То есть после изменений оставалось бы только обновить шаблоны {{albumchart}} и {{singlechart}}, чтобы этих серых пятен не было. А то, чем вы недовольны — это отдельные правки участников в {{albumchart}} и {{singlechart}}, которые к изначальному предложению отношения не имеют, и которые вероятно стоило обсуждать отдельно.
      То, что в этом шаблоне чартов когда-то появилось центрирование — это скорее всего именно подстраивание под то, что заголовочные столбцы везде центрировались автоматом и это нельзя было массово отключить, а теперь можно. И так как располагать по левому краю рекомендуют ГОСТы, то думаю что проблем с отключением центрирования быть не должно. А жирного текста там действительно не должно быть. И серый фон во всей таблице наверное всё же стоит обсуждать отдельно, как и фон у сертификатов. Solidest (обс.) 13:13, 9 марта 2024 (UTC)[ответить]
      • Я сейчас против этой жирности на серости (как и несколько лет назад), которая может привести к хаосу (Mina Fossati#Еженедельные чарты). Высказываюсь только по этому моменту. А цвета действительно стоит обсудить (и, возможно, наличие флагов и сам формат), включая шаблон дискографии артистов, цвет которого не сочетается с серыми таблицами... .— Sanslogique (обс.) 14:21, 9 марта 2024 (UTC)[ответить]
      • отдельные правки участников в {{albumchart}} и {{singlechart}}, которые к изначальному предложению отношения не имеют - имеют, конечно. Из-за отсутствия там !scope="row" (который, казалось бы, обязан быть в шаблоне, который создан для совместимости с англовики, раз он есть в англовики) смысл добавления стилей без добавления !scope="row" нулевой. ~~‍~~ Jaguar K · 20:59, 9 марта 2024 (UTC)[ответить]
        • Ну в серый цвет я не предлагал шаблоны чартов раскрашивать, поэтому и говорю что к изначальному предложению отношения это не имеет. Изначально я предполагал что отсутствующие в шаблонах чарты так и будут оставаться серыми, а остальные как были белыми, так и останутся. И сортировки по левому краю было бы достаточно. В общем я тоже за то, чтобы добавление серого фона обсуждать отдельно и пока вернуть везде белый (но не знаю возможно ли его убрать оставив scope row и ориентацию по левому краю). Solidest (обс.) 22:07, 9 марта 2024 (UTC)[ответить]
          • Проблема в том, что много где были разноцветные ряды (или этим лишь один шаблон страдал?).
            "Белый" фон (везде, где добавлены стили) делается так: [8] (правда, в мобильных используется настоящий белый и есть разница: [9])
            Я тоже считаю, что серый там не нужен, т.к. как минимум контрастность низкая. ~~‍~~ Jaguar K · 22:16, 9 марта 2024 (UTC)[ответить]
            • Кажется, можно вот так. ~~‍~~ Jaguar K · 22:22, 9 марта 2024 (UTC)[ответить]
              • Ну это решает проблему с чартами, но в общем кажется имеется смысл оставить серые, в дискографиях с ним точно будет лучше чем без него.
                Разноцветные ряды в чартах я не встречал. Но кажется встречаются такие дискографии (хоть и там наверное и не используется plainrowheaders), вроде ещё бывают такие таблицы наград. Solidest (обс.) 22:38, 9 марта 2024 (UTC)[ответить]
                • Думаю, это стоит рассмотреть отдельно. Как я понимаю (в связи с отсутствием !scope="row"), до сих пор у нас почти везде был белый фон, серый был лишь в ячейках, который заданы не шаблонами, а вручную с кодом
                  ! scope="row"| Argentina ([[Argentina Hot 100]])<ref>...,
                  то есть консенсус на белый цвет. То, что в англовики серый, нас волновать не должно, т.к. в данном запросе исправляется выравнивание и жирный шрифт, а не цвет. То есть, как накосячили при обновлении, так и вернули цвет к консенсусному. ~~‍~~ Jaguar K · 22:48, 9 марта 2024 (UTC)[ответить]
                  • У нас как раз был консенсус на выделение в дискографии столбцов с заголовками песен и названий альбомов, и так оно везде и было. Но раньше было чрезмерное выделение с центрированием и жирным текстом. Однако консенсуса на раскрашивание дискографий в белый цвет не было, как и не было консенсуса на отключение выделения столбцов с названиями полностью. Solidest (обс.) 22:54, 9 марта 2024 (UTC)[ответить]
      • Ну все же не большая. WCAG 2 AA не нарушает и ладно. Solidest (обс.) 23:49, 9 марта 2024 (UTC)[ответить]
    • >например, в I Am Mina#Чарты
      Исправлено, как и Mina Fossati.
      >К тому же если брать те же переведённые статьи с копированием таблиц чартов (Thank U, Next#Чарты), то ниже мы видим таблицу сертификатов, где этого серого фона в ячейках нет, тогда надо менять и там все.
      Это не технический вопрос, а вопрос единообразия. Его стоит обсудить отдельно (я бы везде отказался от серого фона). ~~‍~~ Jaguar K · 21:10, 9 марта 2024 (UTC)[ответить]
  • Раз этот стиль широко используется в статьях, да и для полной совместимости с английской Википедией, думаю, что стоит его перенести. Vladimir Solovjev обс 13:26, 9 марта 2024 (UTC)[ответить]

Убрать лигатуры из <pre>, <code>[править код]

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

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

Решение проблемы: добавить CSS-правило, убирающее лигатуры там, где они не нужны.

code, tt, pre, textarea {
    font-variant-ligatures: none;
}

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. в общих случаях, за исключением чрезмерно малого размера кода (а-ля {{ref-info}}), критичность 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). Плашка {{onTS}} предполагает, что стили включаются всегда, а здесь они включаются (судя по текущему количеству включений - 1433) очень редко, вероятно, только для {{Tnavbar}} или прямого вызова его же из модуля. ~~‍~~ 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)[ответить]