Да с нормальной картинкой можно и на луну улететь, тут же вопрос именно в «чистом CSS». Хотя, например, с инлайновым SVG в бордер-имадже было бы отлично, но — FF…
Не, не получится. Для градиента внутри border-image нельзя задать background-size, т.е. то, от чего можно было бы отталкиваться для определения border-image. Кроме того, кажется, в ФФ это вообще не сработает. В вебкитах/опере можно, в итоге, лишь примерно подогнать это дело под известную ширину блока, но вот если размеры блока будут неизвестны — всё будет разъезжаться.
Но если же вы уже делали такое — было бы интересно посмотреть на пример. У меня сходу ничего толкового не вышло :)
Жаль, что live templates не были вынесены в Open Source. Мне долгое время казалось, что где-то в ярушке был пост про них, но не смог найти. Я хотел на него сослаться когда буду делать нормальный сайт для Хаяку, т.к. далеко в основе лежат live templates с Zen CSS наравне. Никаких внешний артефактов точно не сохранилось? Куда ссылку ставить? :)
«Присвоить» — нельзя. «Не упомянуть» — можно (но не нужно).
Я за то, чтобы авторство оригинальной идеи стояло наравне с остальными контрибьюторами. Если человек пишет ишью с фичреквестом — надо хотя бы в ченджлоге сказать спасибо такому человеку. Хотя сам он ни строчки кода не написал. Но я бы и на страницу описания фичи в документации писал благодарность этому человеку — он помог проекту стать лучше.
А если чья-то идея легла в основу твоего проекта, это тем более важно. Да, иногда про это можно забыть, это может потеряться и часто не узнаешь откуда та или иная идея пошла. Но сейчас не такой случай, конечно.
Реализация без идеи тоже ничего не стоит. Так как её не будет.
Идея CSS-selector-like HTML-сниппетов — то, из-за чего вообще Zen Coding обрёл популярность. Вадим не просто предложил идею, а довольно подробно её описал. И, прямо в описании, предложил кому-нибудь стать соавтором.
Вне зависимости от того, как проект дальше развивался и какие были отношения между автором идеи и тем, кто её реализовал, независимо от того какой сложный в итоге получился код и сколько всего было наверчено поверх, обсуждаемая идея — основополагающая штука, которая была в Зен Кодинге, и без неё Эммет не стал бы столь же популярным.
Вообще, опенсорс и большинство свободных лицензий строится именно на сохранении авторства.
Это то, что лежит в основе — взаимоуважение и послание людям: «сообщество уважает вас и ваши идеи, не бойтесь их выражать, их подхватят другие и разовьют». Сохранение авторства — та штука, которая может мотивировать людей придумывать новое, не класть идеи в стол.
Это свойство просто «выключает» cellspacing, если прописать таблице инлановый стиль border-collapse:separate, то мы его не вырежем и после этого cellspacing будет нормально работать.
3. Хмм, вот сейчас сам себе отослал письма с таблицей, ни border-collapse:separate ни cellspacing не вырезались. Как раз во встречающихся у простых пользователей письмах чаще нужно коллапсирование, чем его отсутствие.
4. Мы подумаем об этом, конечно, но ничего обещать не могу.
1. У меня не получилось это воспроизвести — быстро переслал себе через визивиг копипастом такую таблицу и получил то, что нужно — только пунктирную границу слева. Не могли бы вы мне переслать на kizu@yandex-team.ru конкретный пример, который у нас не работает? Посмотрим, разберёмся.
2. Ну, тут довольно спорный момент. Если не менять дефолтный лайн-хейт, то текст будет гораздо менее удобно читать. 1.2em — далеко не самая оптимальная высота строки для чтения. Тут уж или всем улучшать, или, в редких случаях, кому-то что-то по мелочи ломать. Так уж можно и ожидать, что пользователи везде будут ожидать дефолтного серифного 16px шрифта. Но в любом случае буду рад посмотреть на примеры писем, которые ломаются из-за большого лайн-хейта.
3. Разработчики писем, почему-то, чаще верстают так, что отсутствие коллапсирования всё ломает. После его добавления я не помню жалоб на то, что он у нас есть — так что, пожалуйста, пришлите конкретные примеры писем (+ скриншоты из десктопного аутлука с проблемой), чтобы можно было посмотреть что да как.
4. Нам самим хочется добавить возможность использовать хедерные стили, но там кроется очень много подводных граблей, на обхождение которых всё никак не может найти время :( Надо очень жёстко санитайзить такие стили, убирая или экранируя опасные стили, что не совсем банально и может сказаться на производительности. Альтернатива — использовать айфрейм для сендбоксинга — также имеет очень много проблем. В общем, мы думаем над этим, но пока времени нет на то, чтобы добраться до решения этой задачи — она довольно большая. Делать полумеру вроде поддержки только стилей для ховера также опасно — для этого всё равно надо парсить стили, санитайзить содержимое соответствующих блоков деклараций и т.д.
И да, ещё раз — можно мне пересылать на почту kizu@yandex-team.ru конкретные письма, которые ломаются в нашем веб-интерфейсе. Будем разбираться :)
Можно, но у нас такой необходимости нет т.к. используется, по сути, только одна старая версия ие — седьмая (шестой мы не поддерживаем, восьмой переводим в режим седьмого).
А так — да, для нормальных браузеров задаём ie=0, для разных ие — его версию, так будут даже работать проверки вроде if ie > 6 и т.д.
Особые заморочки. Там неверное архитектурное решение, из-за чего парсер размазан тонким слоем по всему коду, в итоге проблем именно из-за парсера встречается довольно много.
Неа. Люди просят, но авторы как-то подзабросили это дело. Для всяких респонсив штук Sass сейчас гораздо лучше подходит.
Теоретически, можно использовать одновременно и Stylus и rework (Головайчук сейчас, по сути, переписывает Стайлус с ноля, разбив всё на блоки и забросив сам Стайлус), сделав что-то на основе того, как там сделан плагин для тех же кейфреймов, но нам пока это не нужно (если нужно будет — что-нибудь придумаем).
Как я в статье и написал — для многих задач Sass подходит лучше, но не для наших :)
А вот это, кстати, очень спорный момент. Я понимаю необходимость подобных конструкций в препроцессоре, но не уверен, что это нужно в самом CSS.
Во-первых, использование возможностей препроцессора на клиенте будет заведомо медленнее чистого CSS. И заведомо более бажное — уже сейчас переменно-подобные сущности вроде `vw` и `vh` не всегда пересчитываются (например, при изменении размеров окна не вызывающего рефлоу), и совсем недавно в вебките комбинаторы `+` и `~` работали статическим образом для всех элементов, кроме первого совпавшего.
В идеальном мире, конечно, эти возможности не помешали бы на клиенте — особенно переменные (но они таки у нас будут), но, по факту, для серьёзных веб-приложений использование этих возможностей повлечёт новые баги и тормоза интерфейса. Сложне транзишны с анимациями уже могут очень затормозить страницу.
Во-вторых, если брать обычных разработчиков, которым производительность не так важна — условные конструкции, циклы и миксины потенциально могут вызвать бесконечный цикл или рекурсию. И часто что именно делать в таком случае на клиенте — не понятно. Тут уж либо мы получим отличную возможность выстрелить себе в ногу не прицеливаясь, или получим очень бедные возможности — с множеством ограничений вроде жёсткого ограничения глубины рекурсии, сложности отладки и т.д.
В CSS есть множество других вещей, которые нужно бы сделать до того, как нужно будет приступать к возможностям препроцессоров.
Но если же вы уже делали такое — было бы интересно посмотреть на пример. У меня сходу ничего толкового не вышло :)
Жаль, что live templates не были вынесены в Open Source. Мне долгое время казалось, что где-то в ярушке был пост про них, но не смог найти. Я хотел на него сослаться когда буду делать нормальный сайт для Хаяку, т.к. далеко в основе лежат live templates с Zen CSS наравне. Никаких внешний артефактов точно не сохранилось? Куда ссылку ставить? :)
Я за то, чтобы авторство оригинальной идеи стояло наравне с остальными контрибьюторами. Если человек пишет ишью с фичреквестом — надо хотя бы в ченджлоге сказать спасибо такому человеку. Хотя сам он ни строчки кода не написал. Но я бы и на страницу описания фичи в документации писал благодарность этому человеку — он помог проекту стать лучше.
А если чья-то идея легла в основу твоего проекта, это тем более важно. Да, иногда про это можно забыть, это может потеряться и часто не узнаешь откуда та или иная идея пошла. Но сейчас не такой случай, конечно.
Идея CSS-selector-like HTML-сниппетов — то, из-за чего вообще Zen Coding обрёл популярность. Вадим не просто предложил идею, а довольно подробно её описал. И, прямо в описании, предложил кому-нибудь стать соавтором.
Вне зависимости от того, как проект дальше развивался и какие были отношения между автором идеи и тем, кто её реализовал, независимо от того какой сложный в итоге получился код и сколько всего было наверчено поверх, обсуждаемая идея — основополагающая штука, которая была в Зен Кодинге, и без неё Эммет не стал бы столь же популярным.
Вообще, опенсорс и большинство свободных лицензий строится именно на сохранении авторства.
Это то, что лежит в основе — взаимоуважение и послание людям: «сообщество уважает вас и ваши идеи, не бойтесь их выражать, их подхватят другие и разовьют». Сохранение авторства — та штука, которая может мотивировать людей придумывать новое, не класть идеи в стол.
4. Мы подумаем об этом, конечно, но ничего обещать не могу.
1. У меня не получилось это воспроизвести — быстро переслал себе через визивиг копипастом такую таблицу и получил то, что нужно — только пунктирную границу слева. Не могли бы вы мне переслать на kizu@yandex-team.ru конкретный пример, который у нас не работает? Посмотрим, разберёмся.
2. Ну, тут довольно спорный момент. Если не менять дефолтный лайн-хейт, то текст будет гораздо менее удобно читать. 1.2em — далеко не самая оптимальная высота строки для чтения. Тут уж или всем улучшать, или, в редких случаях, кому-то что-то по мелочи ломать. Так уж можно и ожидать, что пользователи везде будут ожидать дефолтного серифного 16px шрифта. Но в любом случае буду рад посмотреть на примеры писем, которые ломаются из-за большого лайн-хейта.
3. Разработчики писем, почему-то, чаще верстают так, что отсутствие коллапсирования всё ломает. После его добавления я не помню жалоб на то, что он у нас есть — так что, пожалуйста, пришлите конкретные примеры писем (+ скриншоты из десктопного аутлука с проблемой), чтобы можно было посмотреть что да как.
4. Нам самим хочется добавить возможность использовать хедерные стили, но там кроется очень много подводных граблей, на обхождение которых всё никак не может найти время :( Надо очень жёстко санитайзить такие стили, убирая или экранируя опасные стили, что не совсем банально и может сказаться на производительности. Альтернатива — использовать айфрейм для сендбоксинга — также имеет очень много проблем. В общем, мы думаем над этим, но пока времени нет на то, чтобы добраться до решения этой задачи — она довольно большая. Делать полумеру вроде поддержки только стилей для ховера также опасно — для этого всё равно надо парсить стили, санитайзить содержимое соответствующих блоков деклараций и т.д.
И да, ещё раз — можно мне пересылать на почту kizu@yandex-team.ru конкретные письма, которые ломаются в нашем веб-интерфейсе. Будем разбираться :)
А так — да, для нормальных браузеров задаём
ie=0, для разных ие — его версию, так будут даже работать проверки вродеif ie > 6и т.д.Теоретически, можно использовать одновременно и Stylus и rework (Головайчук сейчас, по сути, переписывает Стайлус с ноля, разбив всё на блоки и забросив сам Стайлус), сделав что-то на основе того, как там сделан плагин для тех же кейфреймов, но нам пока это не нужно (если нужно будет — что-нибудь придумаем).
Как я в статье и написал — для многих задач Sass подходит лучше, но не для наших :)
Во-первых, использование возможностей препроцессора на клиенте будет заведомо медленнее чистого CSS. И заведомо более бажное — уже сейчас переменно-подобные сущности вроде `vw` и `vh` не всегда пересчитываются (например, при изменении размеров окна не вызывающего рефлоу), и совсем недавно в вебките комбинаторы `+` и `~` работали статическим образом для всех элементов, кроме первого совпавшего.
В идеальном мире, конечно, эти возможности не помешали бы на клиенте — особенно переменные (но они таки у нас будут), но, по факту, для серьёзных веб-приложений использование этих возможностей повлечёт новые баги и тормоза интерфейса. Сложне транзишны с анимациями уже могут очень затормозить страницу.
Во-вторых, если брать обычных разработчиков, которым производительность не так важна — условные конструкции, циклы и миксины потенциально могут вызвать бесконечный цикл или рекурсию. И часто что именно делать в таком случае на клиенте — не понятно. Тут уж либо мы получим отличную возможность выстрелить себе в ногу не прицеливаясь, или получим очень бедные возможности — с множеством ограничений вроде жёсткого ограничения глубины рекурсии, сложности отладки и т.д.
В CSS есть множество других вещей, которые нужно бы сделать до того, как нужно будет приступать к возможностям препроцессоров.
Первый, да, неточно написал — он компилится, но получается вот такое (если добавить какое-нибудь правило внутрь):