Обновить
46
0
Marat Tanalin@MTonly

Пользователь

Отправить сообщение
Да, идеальная форма клавиши Enter. Сейчас таких практически не делают: сплошь куцая вертикальная Enter и клавиша \ слева от неё, в 50% случаев случайно нажимаемая перед нажатием собственно Enter.
Добавили бы поддержку HiDPI (сейчас при системном масштабе 200% кнопки на панели инструментов и заголовки панелей очень мелкие) и исправили бы разбор кода C++ (сейчас регулярно оказываются подсвеченными фрагменты имён функций, при переходе по Ctrl+Click переход осуществляется совсем не на объявление функции, а «мимо», и проч. — когда такое начинается, приходится перезапускать IDE).

В 8.1 RC в этом плане, увы, всё по-прежнему.
Ну да, можно выводить растровое изображение пропорционально бОльших размеров, вписывая его в пропорционально меньшую область (и надеясь на точное попадание каждого логического пиксела в пиксел физический — для нештриховой графики сейчас так и приходится делать), но зачем, если можно просто использовать векторную графику, именно для штриховых изображений подходящую идеально и адаптирующуюся под любую плотность точек автоматически и с гарантированным качеством? (Вопрос риторический.)
А ещё SVG автоматически адаптирует своё качество в зависимости от плотности точек дисплея (например, на 4K-мониторе с системным масштабом 200%). Векторная графика есть векторная графика.
В соседних статьях (1, 2) есть JPEG-изображения, хранящиеся на hsto.org. Так что нет, это явно не самодеятельность хабрахранилища.
Скриншот обновления указан ниже на рисунке.
Хуже JPEG может быть только PNG, полученный пересохранением из JPEG. ;-)
Примечательная особенность Nexus 6P — OLED-экран.
На всякий случай: мб — это миллибит.
Родная реализация обычно, мягко говоря, быстрее чисто скриптовых. В PHP реализация DOM есть, просто низкого качества.
PHP бы DOM нормальный (в частности, с бережным отношением к пробельным символам при разборе HTML-кода с помощью loadHTML() и корректным сохранением с помощью saveXML() кода элементов типа script, требующих закрывающего тега) вместо кривого суррогата под названием DOMDocument.
У редакторов спецификаций порой своя, особенная логика. %)
С точностью до наоборот: амперсанд в названии свойства присутствовать не может, поэтому его наличие в начале селектора вложенного правила и устраняло бы неоднозначность. Например, CSS-парсеру здесь:

.example {
    color {}
}

чтобы понять, что color — это не имя свойства, а селектор вложенного правила, необходимо было бы просмотреть код до открывающей фигурной скобки.

А здесь:

.example {
    & color {}
}

по амперсанду сразу понятно, что это не имя свойства, а селектор.
Из моего второго комментария:
опасаются неоднозначностей, которые усложняли (и, соответственно, замедляли) бы механизм разбора CSS-кода, вынуждая его «заглядывать вперёд» (look ahead), чтобы отличить вложенное правило от обычного объявления.
стандарты пишут люди, не написавшие и 100 тысяч строк кода в области, которую они стандартизируют
К сожалению, такое явление действительно имеет место. Порой не учитываются не только потребности веб-разработчиков, но и непосредственная обратная связь от них.
Одно другому не мешает. Польза амперсанда как универсальной возможности сослаться на родительский селектор (например, для обозначенных вами целей) несомненна, он неоптимален именно для обеспечения простой вложенности правил. Иначе говоря, лучше так:

.example {
    color: red;
    {
        .a {}
        .b {}
        .c {}
    }
}

чем так:

.example {
    color: red;
    & .a {}
    & .b {}
    & .c {}
}
подводных камней в синтаксисе с амперсандами нету.
Подводных камней нет, просто неудобно и не оч. DRY каждое вложенное правило предварять амперсандом: проще добавить один вложенный блок ({…}), внутрь которого поместить произвольное количество правил без ведущего амперсанда.
Формально символ доллара не использован, т. к. принцип работы CSS-переменных сильно отличается от того, как работают переменные в препроцессорах. Символ доллара зарезервирован для возможного использования в синтаксисе глобальных констант.

CSS-переменные даже называются сейчас не переменными, а пользовательскими нестандартными свойствами (Custom Properties). Для нестандартных свойств, в свою очередь, всегда использовался префикс в виде дефиса, который для пользовательских свойств просто удвоен.
Насколько я понимаю, опасаются неоднозначностей, которые усложняли (и, соответственно, замедляли) бы механизм разбора CSS-кода, вынуждая его «заглядывать вперёд» (look ahead), чтобы отличить вложенное правило от обычного объявления:
Preprocessors are okay with needing arbitrary lookahead to parse CSS. Browsers aren’t — they want fast, parallizable parsing, and that means fixed, small amounts of lookahead.
В этом плане вложенные блоки мне импонируют больше (скорее всего, в собственном препроцессоре я бы сделал так же), чем необходимость предварять каждое вложенное правило амперсандом, как это было в изначальных предложении и соответствующем черновике.

Кроме того, стараются максимально обезопасить себя от проблем обратной совместимости в будущем: препроцессор при необходимости можно исправить, а синтаксис CSS — практически нет.
я в драфте вложенности не видел
Было предложение от Вкладки Таба Аткинса в списке рассылки www-style и даже черновик (сейчас ссылка недействительна) спецификации CSS Hierarchies, которая, судя по всему, особого энтузиазма у CSSWG не вызвала и сейчас доступна как не имеющий никакой формальной силы черновик CSS Nesting Module Level 3 в личном гитхабе Таба.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность