Комментарии 240
Ладно.
НЛО прилетело и опубликовало эту надпись здесь
Согласен в том плане, что CSS по сравнению с другими web-технологиями (HTML5, node, и т.п.) еще вполне себе ок и логичнее поливать грязью их.
Об ущербности же CSS говорит хотябы сам факт существования вещей вроде less или sass.
В нем даже констант нету, зато каждый год добавляют всякую ерунду типа 3d-transform.
Об ущербности же CSS говорит хотябы сам факт существования вещей вроде less или sass.
В нем даже констант нету, зато каждый год добавляют всякую ерунду типа 3d-transform.
Бесполезное (кроме как для показать «какие мы крутые») 3d завезли, а центрирование без костылей — нет :(
Многие функции аля «какие мы крутые», добавить значительно проще, т.к. они не нарушают никаких зависимостей и в итоге достаточно просто интегрируются, но многие вещи которые кажутся на первый взгляд легкоизменяемыми, такими не являются.
А по поводу центрирования, разве при помощи display: flex эта проблема не решается в несколько строк?
А по поводу центрирования, разве при помощи display: flex эта проблема не решается в несколько строк?
А что за костыли нужны для центрирования?
От неочевидного margin: auto до чуть более очевидных, но и более костыльных сдвигов на -50% (или изменения высоты строки).
А просто vertical-align и horizontal-align — нет, вы что, это слишком просто.
А просто vertical-align и horizontal-align — нет, вы что, это слишком просто.
Во первых margin:auto — вполне себе очевиден, если хоть раз читали спеку на тему отступов.
Во вторых align-items:center и justify-content:center таки есть, но слишком форсируют центрирование, что как правило не нужно.
Как должно происходить выравнивание, когда установлено horizontal-align:center, а у блока есть margin-right:0?
Ну раз горизонтальное выравнивание установлено по центру, значит и отступы должны считаться от центра. Мысленно проводим вертикальную линию через центр и от нее считаем. Конкретно в случае margin-right:0 ничего не изменится, т.к. 0 он и в африке 0. Будет просто выравнивание по центру. А вот при margin-right:10px, будет сначала выравнивание по центру, а затем дополнительное смещение влево на 10px.
Это на вскидку. Возможно я чего-то не учел.
Это на вскидку. Возможно я чего-то не учел.
Центрировать по внешней границе, определённой box-sizing'ом, и после этого добавлять маржины.
НЛО прилетело и опубликовало эту надпись здесь
Можно дополнить еще этим, на русском:)
В данный момент на основе опыта полученного при взаимодействие с препроцессорами в спеки активно добавляются вещи которые во многом превосходят всякого рода «константы», например кастомные свойства.
Последние несколько лет CSS активно разрабатывается и улучшается, безусловно у CSS еще множество проблем, но называть его ущербным я бы не стал.
Последние несколько лет CSS активно разрабатывается и улучшается, безусловно у CSS еще множество проблем, но называть его ущербным я бы не стал.
В сях тоже есть препроцессор, но вы же не поливаете его?
НЛО прилетело и опубликовало эту надпись здесь
и логичнее поливать грязью их
Как насчёт того, чтобы не поливать кого-либо грязью?
НЛО прилетело и опубликовало эту надпись здесь
Чего действительно не хватает в CSS, это препроцессора, регулярных выражений и функционального подхода. И тогда JSON-библиотеку, адаптированную к CSS, каждый сам себе напишет.
НЛО прилетело и опубликовало эту надпись здесь
Можно и регулярок добавить, почему нет?
Главное — не брать в руки чужой CSS код с регулярками)
Главное — не брать в руки чужой CSS код с регулярками)
Твой же код станет тебе чужд через N месяцев.
Да, я этого и не отрицаю, а тут сразу минусы посыпались. Видимо, кого-то задел, как казалось, безобидной шуткой =(
Нет, это вы сами шутку не распознали.
“Если у вас есть проблема и вы решили использовать регулярные выражения, у вас уже две проблемы”
PS относитесь к минусам проще. В карму-то вам никто не плюнул, то есть с сайта вас не изгоняют. Просто намекнули что комментарий не к месту.
“Если у вас есть проблема и вы решили использовать регулярные выражения, у вас уже две проблемы”
Про это я знаю, спасибо. Вы считаете, что я именно эту шутку не распознал? По-вашему, мой комментарий как-то противоречит этой шутке?
PS К минусам, как и к карме, отношусь абсолютно нейтрально, обе эти сущности не доставляют мне ни радости ни огорчения. А про «намекнули»… Ну тут сложно сказать, что он не к месту, ибо сначала там стало 5 минусов, сейчас всего 3. Как-то и 3 и 5 человек, поставивших минус, это слишком уж мало, чтобы думать, что комментарий реально на ресурсе не к месту.
А какого плана регулярки вам нужны?
Если хочется, то уже сейчас можно делать так
//все ссылки, начинающиеся на http, сделать красными
a[href^="http://"] {
color: red;
}кроме матчинга с начала строки, так же есть аналогичные attr$=value для конца строки, и attr~=value для поиска слова целиком в строке.
Source: https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
А можно вопрос? Зачем в языке описания стилей вообще нужны регулярки? Ну просто не представляю себе этого.
Там скорее нужен селектор для парента. Там скорее нужно центрование в одну строку. Но никак не регулярки, которые там просто нафиг не нужны.
Почему вместо «horizontal-align: center», я должен писать «margin: 0 auto»? Это риторический вопрос, конечно. Да и это далеко не единственная и не главная проблема CSS. Просто первое, что вспомнилось. Это первое, что меня когда-то взбесило в нем. Так уж сложилось, что CSS достаточно кривая технология. Что имеем, то имеем.
Не понимаю причем тут это? Какой еще барьер? Почему вы так болезненно воспринимаете критику CSS? Вы что, разрабатывали этот стандарт? А если нет, то к вам нет никаких претензий. Люди критикуют CSS, а вовсе не тех, кто им пользуется.
А вот с этим проблема. В этом весь ужас фронтенда. На бэкенде, там да, там есть выбор. Если мне не нравится, скажем, PHP, то я могу выбрать ASP.Net, Python или Ruby. Да вообще много из чего можно выбрать. С фронтендом так не получится. Там приходится жрать что дают. Не нравится CSS или JavaScript? Или, может быть, HTML? Тебе все равно придется их использовать. Именно поэтому мыши продолжают жрать кактус. При этом, не упуская возможности поплакать об этом.
Это возводит жесткий барьер между «разработчиками» и «людьми, делающими всякую веб-всячину», они же «ненастоящие разработчики».
Не понимаю причем тут это? Какой еще барьер? Почему вы так болезненно воспринимаете критику CSS? Вы что, разрабатывали этот стандарт? А если нет, то к вам нет никаких претензий. Люди критикуют CSS, а вовсе не тех, кто им пользуется.
Другими словами: не нравится — не пользуйтесь.
А вот с этим проблема. В этом весь ужас фронтенда. На бэкенде, там да, там есть выбор. Если мне не нравится, скажем, PHP, то я могу выбрать ASP.Net, Python или Ruby. Да вообще много из чего можно выбрать. С фронтендом так не получится. Там приходится жрать что дают. Не нравится CSS или JavaScript? Или, может быть, HTML? Тебе все равно придется их использовать. Именно поэтому мыши продолжают жрать кактус. При этом, не упуская возможности поплакать об этом.
НЛО прилетело и опубликовало эту надпись здесь
С фронтендом так не получится. Там приходится жрать что дают. Не нравится CSS или JavaScript? Или, может быть, HTML? Тебе все равно придется их использовать.
Точно так же, как на веб-бекенде всё равно придётся использовать IP, TCP и HTTP. Это просто ограничение платформы, называющейся «веб». Не нравится — можно перестать писать под эту платформу и начать писать, например, под мобильные устройства, десктопы, или какую-нибудь встраиваемую фигню. Только быстро выяснится, что там ограничений не меньше, устаревших технологий даже больше, и — сюрприз — тоже приходится жрать, что дают.
Вы просто немного подменили понятия. HTML/CSS/JS в браузерах — не совсем языки, а скорее очень сложное, но конечное и неизменяемое API браузера. Соответственно, вы посредством какого-то языка (или даже без него) собираете набор вызовов вида «дорогой браузер, нарисуй мне тут, пожалуйста, заголовок», и передаёте это в браузер. Выбор языка при этом остаётся на ваше усмотрение, всё по-честному, а вот API браузера поменять не удастся.
НЛО прилетело и опубликовало эту надпись здесь
API браузера поменять не удастся
Можно конечно считать, что HTML/CSS/JS это как бы браузерное API, но разве это значит, что API не нужно улучшать и расширять? Конечно, web-программист этого сделать не может, а вот разработчики браузеров и стандартов — вполне. Этого от них и хотят, на это и направлена критика того же CSS. Только не поймите меня не правильно, я не призываю срочно что-то менять. И вовсе не уверен, что критика CSS на всяких конференциях принесет существенный профит. Я лишь высказал свою точку зрения, почему многие люди ругают CSS. Из-за ограниченности платформы они вынуждены им пользоваться, альтернатив нет, а динамика развития, ну субъективно, она хуже, чем у JS, например.
И если уж говорить об ограниченности платформ, то TCP/IP и HTTP это все же немного не то, о чем я говорил. Речь ведь не о принципиальном наличии каких-то ограничений, а о том, что на бэкенде их меньше, и что очень важно, они менее заметны в повседневной работе. Сколько процентов в коде составляет работа с протоколом HTTP? А язык это то, с чем ты работаешь все 100% времени. Еще раз повторюсь, можно конечно считать что CSS это часть браузерного API. Но в то же время это язык, на котором человек пишет код. Он очень глубоко погружается в этот API. Общение с технологией выходит довольно тесное, отсюда и высокая придирчивость. Не получается просто так смириться с недостатками. Так-то недостатки можно найти во всем. Тот же HTTP, тоже не идеален, и не всех устраивает. Не зря же Google экспериментировал с SPDY, на основе которого потом выкатили HTTP/2. Последний, впрочем, тоже довольно жестко критиковали. Так что, все закономерно, люди критикуют то, что им не нравится, особенно, когда отказаться от этого проблематично. Это настолько очевидно, что я даже ничего бы не стал писать тут в комментариях, но меня смутило то, что автор статьи как-то странно воспринимает критику CSS. Словно эта критика как-то оскорбляет верстальщиков. Но мне не понятно причем тут они, особенно учитывая тот факт, что у них и альтернативы-то нет. Возможно это обратная сторона того тесного общения с технологией, а которой я упомянул. Получается какое-то сочувствие к используемому инструменту.
Консорциум W3 состоит в основном из крупных компаний, в том числе и компаний выпускающих браузеры. Так что разработчики браузеров и стандартов это одни и те же люди. К слову, стандарты постоянно дополняются, появляется что-то новое. Но не забывайте про тот факт, что реализация той или иной фичи должна устраивать всех. Что является плюсом, т.к. появляется единый стандарт. И именно к этому шли столько лет. Я думаю все уже устали от того, что было ранее, от этой разрозненности.
Почему вместо «horizontal-align: center», я должен писать «margin: 0 auto»?
Потому что нет особого смысла вводить еще одно свойство, достаточно понять логику. auto в данном случае означает автоматический расчет отступов по краям.
потому что вы подменяете понятия.
вы хотите использовать веб фронтенд, при этом вам сразу говорят:" Вам придется использовать 3 кита отображения данной технологии, это html,css,js)" и вы де-факто с этим соглашаетесь. а потом почему-то начинаются жалобы на то, что вы с этим не согласны. выход то простой. не нравится использовать это соглашение? пишите на .net, дельфях, etc. только там полезут другие проблемы. понимаете, идеальных технологий и продуктов нет. везде приходится с чем-то мириться, даже в вашем бэкенде, и если вас раздражает писать css через препроцессоры и т.д. то откажитесь от этого, уйдите только в бэкенд.
вы хотите использовать веб фронтенд, при этом вам сразу говорят:" Вам придется использовать 3 кита отображения данной технологии, это html,css,js)" и вы де-факто с этим соглашаетесь. а потом почему-то начинаются жалобы на то, что вы с этим не согласны. выход то простой. не нравится использовать это соглашение? пишите на .net, дельфях, etc. только там полезут другие проблемы. понимаете, идеальных технологий и продуктов нет. везде приходится с чем-то мириться, даже в вашем бэкенде, и если вас раздражает писать css через препроцессоры и т.д. то откажитесь от этого, уйдите только в бэкенд.
вы хотите использовать веб фронтенд
Может я чего-то не понимаю, но я всегда думал, что разработчик делает web-приложение или web-сайт, не потому, что хочет использовать web-технологии, а потому, что в обществе сложилась традиция, потреблять определённый контент и услуги через браузер. Перед разработчиком стоит задача сделать приложение или информационный ресурс доступным для тех, кто использует браузер. И для этого ему приходится использовать «веб фронтенд».
потому что вы подменяете понятия.
Это как раз вы подменили понятия, назвав «веб фронтенд» целью, в то время, как он является лишь средством.
везде приходится с чем-то мириться
Пять лет назад я на подобный аргумент уже отвечал выше. Процитирую себя же:
Речь ведь не о принципиальном наличии каких-то ограничений, а о том, что на бэкенде их меньше, и что очень важно, они менее заметны в повседневной работе. Сколько процентов в коде составляет работа с протоколом HTTP? А язык это то, с чем ты работаешь все 100% времени.
и если вас раздражает писать css через препроцессоры и т.д. то откажитесь от этого, уйдите только в бэкенд
Если человеку что-то не нравится, то он имеет право об этом говорить. Критика, конечно, не всегда бывает конструктивной. Но предложение всем недовольным валить — ещё менее конструктивно. А то что CSS препроцессоры стали стандартом де-факто, только подтверждает обоснованность критики нативных CSS. Это же касается и ситуации с современными JS фреймвёрками. Куда ни глянь, фронтендеры везде ушли от использования нативных технологий, которые им были предложены. И это в ситуации, когда уйти от них, казалось бы, невозможно. Людям дали плохие инструменты, и они превозмогают, как могут.
С момента публикации этой статьи прошло почти 5 лет. Хотел сделать какие-нибудь выводы, огляделся вокруг, задумался. Кажется, единственное, что осталось от нативного фронтенда — это тег div.
Слабо вам взглянуть на те умопомрачительные штуки, что делает на CSS Ана Тюдор, и сказать мне в лицо, что это «ненастоящее программирование» и сделано на «тупом языке»?
Такие кубики на паскале в школе делали в 90-х. И что, теперь именно это — настоящее программирование? На брэйнфаке при желании тоже можно кубик написать, сервером и CSS-фронтендом. И даже заставить работать в Canary или Firefox Night Build.
А так обычно в гос. организациях каких-нибудь стоят хрюши с в лучшем случае IE9 и без этого кубика им конечно никуда… Ну и естественно про flex тоже можно не вспоминать. Иногда смотришь в caniuse и грустишь.
Короче очень уж спорная аргументация в статье, возражения из плоскости «не делаешь кубики на CSS — не говори что он неудобен» и «не нравится не ешь».
А на что именно вы смотрите в caniuse и грустите?
IE9 уже настолько непопулярный, что его там даже не показывают:
https://habrastorage.org/files/d7f/f20/1cb/d7ff201cb351433f8e53247488c8ad9c.png
Есть еще, правда, IE8, но там своя ретро-атмосфера, за которую нужно брать дополнительную оплату так-то.
Я же всё написал. Есть еще дремучие случаи, когда IE9 используется. Мало ли что caniuse скрывает — и то что он скрывает IE9 это кстати еще +1 повод погрустить.
Суть претензий, по полкам.
1. CSS — язык стилей. Многие естественные для тех же десктопных интерфейсов стили в нём проблематичны.
2. IE9 — боль. Я бы с удовольствием отказался бы от поддержки. Но никак. Пользователи WinXP — имеют IE9. Как минимум до установки Chrome.
3. Аргументы в статье омерзительны. Кубиками доказывать что CSS это круто — ну бред же. Видел слайдеры «кубические», даже в десятке работают… ну профита никакого — ни юзеру, ни заказчику.
4. Сам верстаю. И пишу. Fullstack. И node.js и sass и jade и даже php и прочее.
5. Веб-фронтенд — имхо конечно — следовало бы двигать в сторону системы лайаутов какие они были еще в java.awt релиза 2000-х. Но веб пошел другим путем. В этом возможно только моя личная печаль.
6. Я против фронтенд-разработчиков (верстальщиков как их тут называют слегка пренебрежительно по-моему) ничего не имею — я за них двумя руками за. И по-моему, CSS у них головная боль куда меньше, чем jQuery, которому многие из них памятник бы поставили.
7. Да, CSS развивается. Да, с учетом legacy.
НО. Почему черт побери я должен считать CascadeStyleSheets языком программирования, и почему, черт побери я не должен считать его неудобным (даже для стилей интерфейсов)? Бох с ними с браузерами. Если CSS так хорош, почему есть PostCSS, SASS/LESS/STYLUS, и ими пользуются и хвалят? Почему я должен считать вращающийся кубик чем-то крутым, когда похоронили wrml в своё время, в котором такой кубик в гораздо более понятном и коротком коде вращался? И почему я должен впечатлятся кубиком, который никому не нужен в каком-нибудь интернет-магазине, а нужно юзать какой-нибудь sticky.js для плавающих контейнеров? Вопрос риторический. Сами все понимаете.
Суть претензий, по полкам.
1. CSS — язык стилей. Многие естественные для тех же десктопных интерфейсов стили в нём проблематичны.
2. IE9 — боль. Я бы с удовольствием отказался бы от поддержки. Но никак. Пользователи WinXP — имеют IE9. Как минимум до установки Chrome.
3. Аргументы в статье омерзительны. Кубиками доказывать что CSS это круто — ну бред же. Видел слайдеры «кубические», даже в десятке работают… ну профита никакого — ни юзеру, ни заказчику.
4. Сам верстаю. И пишу. Fullstack. И node.js и sass и jade и даже php и прочее.
5. Веб-фронтенд — имхо конечно — следовало бы двигать в сторону системы лайаутов какие они были еще в java.awt релиза 2000-х. Но веб пошел другим путем. В этом возможно только моя личная печаль.
6. Я против фронтенд-разработчиков (верстальщиков как их тут называют слегка пренебрежительно по-моему) ничего не имею — я за них двумя руками за. И по-моему, CSS у них головная боль куда меньше, чем jQuery, которому многие из них памятник бы поставили.
7. Да, CSS развивается. Да, с учетом legacy.
НО. Почему черт побери я должен считать CascadeStyleSheets языком программирования, и почему, черт побери я не должен считать его неудобным (даже для стилей интерфейсов)? Бох с ними с браузерами. Если CSS так хорош, почему есть PostCSS, SASS/LESS/STYLUS, и ими пользуются и хвалят? Почему я должен считать вращающийся кубик чем-то крутым, когда похоронили wrml в своё время, в котором такой кубик в гораздо более понятном и коротком коде вращался? И почему я должен впечатлятся кубиком, который никому не нужен в каком-нибудь интернет-магазине, а нужно юзать какой-нибудь sticky.js для плавающих контейнеров? Вопрос риторический. Сами все понимаете.
А вы в курсе, что пользователи WinXP ограничены только IE8, и поддерживать IE9 не имеет смысла?
То что IE9 поддерживать нет смысла я давно в курсе. А вот что WinXP (я почему-то по запарке думал девятка в нём последняя) только до восьмерки поддерживает, в этом я ошибся. Спасибо за инфу. Теперь еще плюс один аргумент против IE9 у меня есть. Пункт 2 можно вычеркнуть.
И еще опечатка в п. 6. — CSS у фронтендеров большая (а не меньшая) головная боль, чем jQuery.
И еще опечатка в п. 6. — CSS у фронтендеров большая (а не меньшая) головная боль, чем jQuery.
WinXP ограничен Хромом 49 (и Хромиумом), что не очень плохо, и не ограничен Firefox-ом.
Вы сейчас просто весь мой мир сломали. Завтра же пойду пинать начальство отказываться от поддержки.
Если CSS так хорош, почему есть PostCSS, SASS/LESS/STYLUS, и ими пользуются и хвалят
Есть машиночитаемый код, а есть исходники.
CSS изначально был заточен для легкого разбора и интерпретации. Не вижу ничего плохого в использовании специальных иструментов для подготовки кода браузеру.
Какой смысл молниеносно парсить CSS, если будет тормозить соединение, выкачивающее тонны этого избыточного кода? Очевидно, что отвратительный дизайн обязан чьей-то не самой удачной идее в начале и длительной поддержке с помощью нагромождения костылей.
Веб-инструменты славились динамичностью, без необходимой компиляции. В мире программирования эта фаза нужна для оптимизации на семантическом уровне и только в вебе таким образом стараются абстрагироваться от стрёмного браузерного API (в широком смысле).
Веб-инструменты славились динамичностью, без необходимой компиляции. В мире программирования эта фаза нужна для оптимизации на семантическом уровне и только в вебе таким образом стараются абстрагироваться от стрёмного браузерного API (в широком смысле).
Избыточность решается алгоритмами сжатия.
Основная идея в том, что css — это таблица, то есть данные, которые не нужно исполнять. Для динамики в браузере есть javascript, а css статический, без шансов словить бесконечный цикл или какую-нибудь ошибку компиляции.
Если вам нужно что-то посложнее, миксины или переиспользование кода, надо брать препроцессор и тогда все эти ошибки исполнения вылезут при сборке, а не у пользователей в браузере.
> без шансов словить бесконечный цикл или какую-нибудь ошибку компиляции.
устаревшие сведения.
https://github.com/elitheeli/stupid-machines
http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-turing-complete/
устаревшие сведения.
https://github.com/elitheeli/stupid-machines
http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-turing-complete/
Открыл страницу в браузере, ни циклов, ни ошибок не увидел.
К чему вы привели эти ссылки?
https://jsfiddle.net/78yahLg8/
Вот вам ошибка. Пусть и глупая, но самая настоящая, мешающая прочитать текст. И отсутствие компиляции не помогло...
Еще как помогло!
У вас есть отдельная невалидная конструкция, но это никак не ломает остальные стили.
В то время как ошибка в Javascript или другом языке вызовет остановку и программа дальше исполняться не пойдет.
Имеется ввиду что в идеале вы не можете написать css который можно особо не проверять и он не положит браузер, а не то, что верстальщик не налажает.
Вы наверное, настоящий веб-разработчик, не имеете профильного образования и даже не представляете, чего теряете. Тьюринг-полнота это возможность построить и циклы вообще, и некорректные, в частности.
Здравствуйте! Спасибо за замечание о моем образовании.
В указанной статье показывается, как построить вычислительную машину в браузере силами HTML+CSS. В этой ситуации они являются лишь составными частями, но не самим языком.
С таким же успехом можно называть Тьюринг-полными микросхемы и шестеренки, из которых строятся компьютеры. Но, согласитесь, что это немного не то.
Есть большая разница. Микросхемы и шестерёнки в компьютер надо собирать руками, что требует значительного времени и ресурсов. А копирование компьютерных программ почти ничего не стоит, и значит реализацию цикла будет несложно воспроизводить. Дорога от возможности до реализации короче и воспроизводима.
Избыточность решается алгоритмами сжатия.
То есть вместо того, чтобы сделать умный интерпретатор и не испытывать боли, мы будем делать умные (на уровне языковой семантики) компрессоры/декомпрессоры?
Если CSS так хорош, почему есть PostCSS, SASS/LESS/STYLUS
Если C так хорош, почему есть C++, C#, Java, Objective-C.
Да потому что, это естественный процесс развития чего бы то не было. Есть языки, и есть люди которых они не устраивают, и они вкатывают свои реализации, под свои нужды.
Так, в принципе, все яп появились.
HTML — дерьмо.
CSS — дерьмо.
JavaScript — дерьмо.
Node.js — дерьмо.
jQuery — дерьмо.
PHP — дерьмо.
Смерть неизбежна.
CSS — дерьмо.
JavaScript — дерьмо.
Node.js — дерьмо.
jQuery — дерьмо.
PHP — дерьмо.
Смерть неизбежна.
CSS — просто супер-вещь!
Конечно немного нехватает наследования и прочих плюшек (для которых есть куча инструментов вроде less/sass) и не всегда предсказуемый синтаксис (например разместить блок без чётких размеров по центру экрана), но зато как легко можно изменить дизайн сайта подправив всего несколько строчек кода. Кто ругает CSS, тот просто не умеет им пользоваться…
Тут скорее нужно ругать разработчиков браузеров с их разной обработкой комманд и префиксами. Конечно может быть в будущем будет хорошая замена CSS, но я думаю это случится не раньше чем через 5-7 лет. Да и скорее просто CSS продолжит эволюционировать становясь всё удобнее. Например переход к 3 версии CSS был огромным шагом вперёд.
Конечно немного нехватает наследования и прочих плюшек (для которых есть куча инструментов вроде less/sass) и не всегда предсказуемый синтаксис (например разместить блок без чётких размеров по центру экрана), но зато как легко можно изменить дизайн сайта подправив всего несколько строчек кода. Кто ругает CSS, тот просто не умеет им пользоваться…
Тут скорее нужно ругать разработчиков браузеров с их разной обработкой комманд и префиксами. Конечно может быть в будущем будет хорошая замена CSS, но я думаю это случится не раньше чем через 5-7 лет. Да и скорее просто CSS продолжит эволюционировать становясь всё удобнее. Например переход к 3 версии CSS был огромным шагом вперёд.
> Конечно может быть в будущем будет хорошая замена CSS, но я думаю это случится не раньше чем через 5-7 лет.
Ага, только вот будет как обычно — было X стандартов, стало X + 1. И все их потребуется поддерживать.
Ага, только вот будет как обычно — было X стандартов, стало X + 1. И все их потребуется поддерживать.
Подскажите, пожалуйста, что я должен там увидеть.
https://habrastorage.org/files/17e/45e/a36/17e45ea3699f448a9ee785ea03698844.png
https://habrastorage.org/files/17e/45e/a36/17e45ea3699f448a9ee785ea03698844.png
Думаю, что-то типа этого (вертикальное центрирование)
Можно на CSS сделать так, чтобы секунды на экране не пересчелкивались, а плавно прокручивались?
Что-то типа барабана с цифрами.
В JS я могу один раз вызвать прокрутку (задать атрибут, для которого в CSS прописаны padding-top и transition).
Вопрос, как ее взбодрить потом?
Спасибо.
Что-то типа барабана с цифрами.
В JS я могу один раз вызвать прокрутку (задать атрибут, для которого в CSS прописаны padding-top и transition).
Вопрос, как ее взбодрить потом?
Спасибо.
Дисклеймер: я не фронтенд-разработчик. Я халтурщик на все руки full-stack фрилансер. Я куда больше разбираюсь в backend (ASP.NET), но приходится и верстать. Я многого не знаю, и опыт мой в CSS скуден.
Все это говорю со своей позиции дилетанта.
Каждый раз, когда я что-то делаю, у меня обязательно возникает "WAT" от очередной нелогичности CSS (да-да, я сам сделал криво). Из последнего: я выравнивал inline-block элемент по вертикали, применил классический подход с table-cell, и он растянулся на всю высоту родителя. Я долго смотрел на это и думал, как же исправить, и как я делал раньше, если все работало.
Да, есть приемы, да, нужно все знать и иметь опыт, это я не отрицаю. Но некая "недерменированность" CSS, когда поведение элемента зачастую странным и не очевидным образом зависит от совершенно других — разрдажает. Да, я понимаю, что причина этому — особенности реализации, и поток элементов расположить совсем как угодно не так уж и легко.
А вы ожидали, используя вещи не по назначению, что всё будет работать как вам надо? Что за "классический подход с table-cell"?
6 методов вертикального центрирования с помощью CSS ., метод №2. Присутствует практически в каждой статье про вертикальное выравнивание.
Не читайте статей пятилетней давности — ничего полезного вы оттуда уже не узнаете.
Первая попавшееся ссылка из гугла, таких много, вот свежее: habr
Да, идеально flexbox, но он даже в IE11 поддерживается с ограничениями (на основе caniuse)
Из последнего: я выравнивал inline-block элемент по вертикали, применил классический подход с table-cell, и он растянулся на всю высоту родителя. Я долго смотрел на это и думал, как же исправить, и как я делал раньше, если все работало.
Из последнего: я выравнивал пользовался грязным хаком, который я даже не понимаю, как работает и что-то пошло не так. Я долго смотрел на это и думал, как же исправить, и как я делал раньше, если все работало.
Я предупредил, что я профан в этом деле.
С помощью гугла я нашел несколько способов вертикального выравнивания, например, использовать line-height родителя, равный высоте или задание родителю display:table, потомку display:table-cell и vertical-align.
И да, все способы вертикального выравнивания, что я видел — грязные хаки. 80% "как сделать XXX в CSS" — грязные хаки. Собственно это и есть моя главная претензия к CSS — все делается грязными хаками.
А так, я буду очень рад узнать, как вертикально выравнивать блочные элементы без грязных хаков.
Собственно это и есть моя главная претензия к CSS — все делается грязными хаками.Это, к сожалению, так.
Частично из-за того, что стили, придуманные для гибкого веба, пытаются применять к макетам, нарисованным для неизменяемой полиграфии.
Частично из-за того, что не все потребности веб-дизайнеров были предусмотрены авторами спецификаций.
Кроссбраузерность флексбокса делает меня страдать.
Вы из тех бедолаг, которых заставляют поддерживать ие9 в 2016 году?
Поверьте, мы еще есть…
Вроде в соседней ветке вас убедили больше его не поддерживать, разве нет?
Я то давно в этом убежден. Увы, есть бизнес.
Работодатель — не рабовладелец, его можно сменить. ;-)
Увы, есть бизнес
Да, и он умеет считать деньги. И, как правило, счёт не в пользу устаревшей технологии:
Мой разговор с человеком из бизнеса (крупный интернет-магазин):
— (я) Судя по статистике, у вас около 5% пользователей на ie8, но поддержка этого браузера отсутствует, почему?
— У нас была поддержка, но мы её закрыли, т.к. на поддержку этого устаревшего браузера уходит больше денег, чем приносят пользователи, которые им пользуются.
Дальше он показал мне точные цифры, по которым было видно, что разница стоимость поддержки / прибыль была около порядка!
НЛО прилетело и опубликовало эту надпись здесь
Кроссбраузерность флексбокса лучше кроссбраузерности бордер-радиуса.
Для России и др. постсоветских стран CanIUse выдает заниженные проценты, т.к. не учитывает Я-браузер и других локальных «хромят». Если приплюсовать их суммарную долю, цифры сравняются с общемировыми.
Для России и др. постсоветских стран CanIUse выдает заниженные проценты, т.к. не учитывает Я-браузер и других локальных «хромят». Если приплюсовать их суммарную долю, цифры сравняются с общемировыми.
Вы Show all забыли нажать.
Да даже если бы у них была одинаковая кроссбраузерность — это всё равно бы не позволило использовать флексбокс в продакшене ещё года два, потому что флексбоксом делается раскладка страницы, и без него она просто развалится в хлам, а бордер-радиус — это просто симпатичная свистелка, от отсутствия которой внешний вид становится чуть хуже.
Show all не меняет картину качественно (особенно если в придачу нажать еще и Usage relative). Некоторые браузеры CanIUse, увы, не учитывает в принципе (см. внизу).
В простейшем случае без флексбоксов раскладка не «развалится в хлам», а изящно деградирует до минималистичной одноколоночной версии а-ля мобильная. Которая зато молниеносно грузится и мгновенно реагирует на действия юзера, что куда более критично для того ископаемого железа, на котором доживают свой век бесфлексовые IE и андроид-браузеры 4.3-.
В наш адаптивно-отзывчиво-мобайлфёстный век гламурные раскладочные навороты — именно что симпатичная свистелка, и ее вполне можно добавлять как постепенное улучшение!
В простейшем случае без флексбоксов раскладка не «развалится в хлам», а изящно деградирует до минималистичной одноколоночной версии а-ля мобильная. Которая зато молниеносно грузится и мгновенно реагирует на действия юзера, что куда более критично для того ископаемого железа, на котором доживают свой век бесфлексовые IE и андроид-браузеры 4.3-.
В наш адаптивно-отзывчиво-мобайлфёстный век гламурные раскладочные навороты — именно что симпатичная свистелка, и ее вполне можно добавлять как постепенное улучшение!
Буду сильно утрировать…
Если вам не хватает опыта, и вы не понимаете, как что устроено внутри языка, не значит что язык плохой. Это значит лишь, что вам не хватает опыта и вы не понимаете как что устроено внутри языка.
Так то я гуманитарий, но иногда балуюсь математикой. И каждый раз, когда я что-то делаю, у меня обязательно возникает «WAT». Вот из последнего, попытался найти квадратный корень из бесконечности поделенной на ноль, и вселенная перезагрузилась… Говно, эта ваша, математика.
Если вам не хватает опыта, и вы не понимаете, как что устроено внутри языка, не значит что язык плохой. Это значит лишь, что вам не хватает опыта и вы не понимаете как что устроено внутри языка.
В свое время, когда я в школе только начинал программировать, то пробовал и паскаль, и html, и css, но в случае с html+css постоянно чувствовал себя какой-то обезьяной, которая не понимает, что делает, потому что если ваша программа на паскале некорректна — она не скомпилируется. И там даже будет текст ошибки! А если она упадет в рантайме, то вы тоже получите сообщение об ошибке, и если из этих сообщений вам всё еще непонятно, что происходит, то можно добавить отладочный вывод в консоль, можно поставить брекпоинт и т.д. Вы понимаете, к чему я клоню?
Если ваш элемент на странице отрисовался не так, как вы планировали, то вы можете только догадываться, почему же это так. Потом вы, конечно начнете читать доку, анализировать её и заниматься прочими полезными вещами, но вы так и будете сами работать дебаггером.
Надо ли говорить, что после того, как я больше часа потратил на выравнивание содержимого ячейки таблицы, у меня даже мысли не было заниматься вебом. Я еще со школы помню то чувство, когда ты даже не знаешь, куда начинать копать.
Если ваш элемент на странице отрисовался не так, как вы планировали, то вы можете только догадываться, почему же это так. Потом вы, конечно начнете читать доку, анализировать её и заниматься прочими полезными вещами, но вы так и будете сами работать дебаггером.
Надо ли говорить, что после того, как я больше часа потратил на выравнивание содержимого ячейки таблицы, у меня даже мысли не было заниматься вебом. Я еще со школы помню то чувство, когда ты даже не знаешь, куда начинать копать.
ctrl+shift+I?
Во-первых, во времена моей школы я о таком не знал, и я даже не уверен, что это было.
Во-вторых — это не совсем ответ. Инспектор показывает вам результат, но вы не всегда можете понять, почему он такой. Вы добавляете какой-нибудь align-center (не помню, как оно точно называется), а у вас ничего не происходит, и вы не знаете почему.
Во-вторых — это не совсем ответ. Инспектор показывает вам результат, но вы не всегда можете понять, почему он такой. Вы добавляете какой-нибудь align-center (не помню, как оно точно называется), а у вас ничего не происходит, и вы не знаете почему.
Если вы не знаете что именно делает тот или иной элемент API, то чему вы удевляетесь? Если я за 2-3 минуты не понял почему оно не работает, я открываю спек. И не только css, с любой вещью так. Просто вам почему-то кажется что веб должен быть простым и веселым и потратить 4 часа на решения какой нибудь мелочи можно только в «настоящем» яп.
в том-то и дело, что на бекенде на решение мелочи я потрачу 10 минут. Если не пойму, то открою дебаггер и посмотрю, что происходит. А на фронте я должен кучу вещей именно знать, потому что там нюансы и костыли на каждом углу
Скажите, спасибо, что вы не рисуете те самые сайты. У дизайнеров ни спеков, ни доков, ни дебаггеров отродясь не было. Да и есть куча других сфер, где нужно просто знать. И коли вам не по душе такой расклад, ну не лезьте туда. Делов то.
А если у дизайнера выходит круглый квадрат, то решается это проблема заменой дизайнера.
А если у дизайнера выходит круглый квадрат, то решается это проблема заменой дизайнера.
Ну сравнение очень странное! Паскаль все-таки компилятор… А css я бы отнес к интерпретаторам. Надеюсь не надо объяснять разницу?
Доля ИЕ9+10 в России в совокупности составляет в среднем 0.5%. Перестаньте уже выдумывать, что в каких-то абстрактных непонятных случаях вас просят во что-бы то ни стало сделать вертикальное выравнивание для этих браузеров. И начните пользоваться flexbox-ом.
Признаю, я был не прав. Как я и сказал — я нуб. Ну благодаря комментариям здесь, узнал много нового. Спасибо!
Корпоративный, мать его, клиент. Основной, между прочим, источник дохода.
А добиться одинакового вида во всех современных браузерах, я считаю — норма.
одинакового вида во всех современных браузерах
1) выделенное слово — не ключевое?
2) в Safari на айфоне и Самсунг-браузере на «умном телевизоре» тоже вид должен быть одинаковым?
- Да, ключевое. В старых браузерах просто должно как-нибудь работать.
- Прошу прощения, не могу ответить. Я занимаюсь не сайтами, которые смотрят на любых устройствах, а приложениями для дистанционного обучения, рассчитанными если не на десктоп, то по крайней мере на планшет с крупным экраном. Опыта вёрстки под телефоны и телевизоры не имею. Вероятно, я сделаю отдельные версии для названных устройств, если получу команду поддерживать и их тоже.
ИМХО CSS отличная задумка, нормальная реализация,
Если бы они оставили CSS просто как дополнительный способ назначения параметров, было бы ок, но они покусились на полную отмену HTML.
Реализовали они это убого через псевдо классы (например first-of-type).
C чего-то разработчики CSS решили, что могут простым переназначением параметров убрать все тэги оставив абстрактные box и inline+ css настройки, и это почти получилось, пока они не уперлись в table, list и т.п.
И их реализация Table tr td через CSS просто отстой.
А поддерживать (рендер машине) надо.
Короче, жадность фраера сгубила.
В прочем этим страдают многие, например авторы Imap -отличный формат, но зачем его сделали ХУМАН_РИДИБЛ ???? Куча гемора и лишних данных, а нужных наоборот не вставить.
Если бы они оставили CSS просто как дополнительный способ назначения параметров, было бы ок, но они покусились на полную отмену HTML.
Реализовали они это убого через псевдо классы (например first-of-type).
C чего-то разработчики CSS решили, что могут простым переназначением параметров убрать все тэги оставив абстрактные box и inline+ css настройки, и это почти получилось, пока они не уперлись в table, list и т.п.
И их реализация Table tr td через CSS просто отстой.
А поддерживать (рендер машине) надо.
Короче, жадность фраера сгубила.
В прочем этим страдают многие, например авторы Imap -отличный формат, но зачем его сделали ХУМАН_РИДИБЛ ???? Куча гемора и лишних данных, а нужных наоборот не вставить.
они покусились на полную отмену HTML
Вы точно не путаете семантическую структуру (HTML) документа с его отображением (CSS) на экране?
Я к тому, что разработчики CSS в плотную подошли к полной отмене за ненадобностью всех тегов форматирования, оставив два основных: div для бокс элементов и span для inline, заменив установку дефаулт параметров через CSS стили.
Но обломились на комплексных типа tabel и list, у которых по мимо параметров есть поведение. А попытки CSS разработчиков преодолеть эту проблему привели к нагромождениям и уродcтву в довольно стройной (до этого) идеологии.
Причем тут синтаксис HTML и рендер ДОМ объектов не понял.
Но обломились на комплексных типа tabel и list, у которых по мимо параметров есть поведение. А попытки CSS разработчиков преодолеть эту проблему привели к нагромождениям и уродcтву в довольно стройной (до этого) идеологии.
Причем тут синтаксис HTML и рендер ДОМ объектов не понял.
Я к тому, что разработчики CSS в плотную подошли к полной отмене за ненадобностью всех тегов форматированияРазработчики CSS не подходили и не собирались подходить к такому.
Они просто дали авторам очень гибкий инструмент и некоторые из авторов начали забивать микроскопами гвозди, попутно жалуясь, что ручка не очень удобная.
>Разработчики CSS не подходили и не собирались подходить к такому.
Вряд ли вы анализировали CSS на столько, что бы утверждать подобное.
Впрочем это легко узнать: какие есть тэги форматирования которые нельзя сэмулировать используя DIV, SPAN и CSS?
Вряд ли вы анализировали CSS на столько, что бы утверждать подобное.
Впрочем это легко узнать: какие есть тэги форматирования которые нельзя сэмулировать используя DIV, SPAN и CSS?
Ячейки таблиц с colspan/rowspan, навскидку. Отчасти fieldset (пока еще). Самое элементарное — br с атрибутом clear (CSS-свойство clear работает только для блоков, а br формально текстовый). Ну и, раз уж речь о тегах форматирования — куда же без легендарного center? :)
Рукалицо.
HTML — это стандарт семантической разметки документа с помощью тегов.
Расскажите, пожалуйста, как вы собрались семантику эмулировать с помощью CSS, эмулятор вы наш. Очень интересно послушать.
Т.е. вы не знаете, как используя только div и span сделать любое форматирование? Яж об этом и говорил: ваши знания скорее всего из другой области, а значит и понимания не возможно.
Я вам про Фому, а вы мне про Ерёму.
Ознакомьтесь с матчастью по ссылке выше.
Для вас веб-страница — это только текст и форматирование его на экране?
Для моей задачи да, HTML страница это ДОМ объекты (боксы и текст) форматированные на экране. Плюс переходы и всякие мелочи.
Если речь идёт о страничке, которую никто, кроме вас не увидит — пользуйтесь тем, что удобно лично вам.
Не понял, что еще собой представляет HTML как не форматированные боксы и инлайны?
И я не создаю страницы я их отображаю.
Отсюда и отношение к CSS
Плюсы CSS он строгий и легко парсится, в отличии от HTML.
Минусы, заставляет редактировать уже созданные объекты или дожидаться полной загрузки блоков, с HTML такого нет — кусок загрузился, создал для него объекты, отобразил.
И я не создаю страницы я их отображаю.
Отсюда и отношение к CSS
Плюсы CSS он строгий и легко парсится, в отличии от HTML.
Минусы, заставляет редактировать уже созданные объекты или дожидаться полной загрузки блоков, с HTML такого нет — кусок загрузился, создал для него объекты, отобразил.
HTML представляет собой структуру данных, на основании которой можно построить визуальную структуру боксов (инлайновых, блочных, плавающих, табличных, флексовых, гридовых, черто-в-ступочных и т.д.). Причем строится она по правилам CSS.
А можно построить по этим же данным еще что-нибудь. Не обязательно визуальное.
А можно построить по этим же данным еще что-нибудь. Не обязательно визуальное.
Дерево объектов с параметрами причем объектов двух типов box & inline.
Float это параметр для box объекта
Table это совокупность box объектов. И т.д.
Visible = false это тоже параметр объекта.
Float это параметр для box объекта
Table это совокупность box объектов. И т.д.
Visible = false это тоже параметр объекта.
Визуальный объект всё-таки box. А уже box бывает разных типов — block, inline и еще куча более редких. Голый текст «два» между абзацами в конструкции
У элемента есть параметр, создавать ли box или нет. А если создавать — то какого типа.
<p>раз</p> два <p>три</p>
У элемента есть параметр, создавать ли box или нет. А если создавать — то какого типа.
А что не так с first-of-type и прочими псевдоклассами? Как связаны псевдоклассы и параметры html? Или вы пользуетесь nth-of-type вместо идентификаторов или хотя бы инлайн-стилей?
Они нарушают HTML принцип: считал, создал, отформатировал.
Появляется зависимость от еще не считанных и не обработанных тегов, т.е. последующие влияют на предыдущие.
Также некоторые псевдо классы используемые в теге заставляют создавать несколько объектов, причем иногда перед уже созданными.
Появляется зависимость от еще не считанных и не обработанных тегов, т.е. последующие влияют на предыдущие.
Также некоторые псевдо классы используемые в теге заставляют создавать несколько объектов, причем иногда перед уже созданными.
поясните примерами, что ли
Ну например last, заставляет дождаться окончания считывания блока тэгов с выходом на родителя что бы появилась возможность прогнать через стили и назначит параметры, а учитывая что параметры могут сильно влияют на форматирование, невозможно сделать нормальное отображение блока пока он полностью не загружен.
В чистом HTML (или без псевдоклассов) такого почти нет, т.е. сколько считал столько показал.
И еще больший тупизм — before
Т.е. мало того что я не могу нормально показать считанные данные, так еще иногда приходится вставлять ПЕРЕД уже созданными объектами новый объект.
и т.д.
В чистом HTML (или без псевдоклассов) такого почти нет, т.е. сколько считал столько показал.
И еще больший тупизм — before
Т.е. мало того что я не могу нормально показать считанные данные, так еще иногда приходится вставлять ПЕРЕД уже созданными объектами новый объект.
и т.д.
Не ПЕРЕД, а ВНУТРИ.
Шаблонно мыслите.
У объекта с параметром before в 99% будут внутренние объекты, для которых объект созданный по параметру content будет ПЕРЕД ними.
У объекта с параметром before в 99% будут внутренние объекты, для которых объект созданный по параметру content будет ПЕРЕД ними.
Они будут созданы уже после.
Т.е вы считаете, что еще до закрытия тэга можно узнать какие CSS стили ему подходят?
На чем основывается ваша уверенность. Есть опыт, построения DOM?
На чем основывается ваша уверенность. Есть опыт, построения DOM?
НЛО прилетело и опубликовало эту надпись здесь
«На основе DOM и CSSOM строится дерево отображения,»
«DOM тут не причём».
Не находите что-то странное в этих утверждениях?
Впрочем это не важно, повторяю
1 во время считывания и обработки тэгов, невозможно гарантированно прогнать Тэг по CSS стилям, пока не будет закрыт тэг родителя. (из-за last-child)
2 из-за п1 и after нужно или дожидаться полного считывания HTML прежде чем строить объекты, или превращать HTML viewer в HTML editor, что бы появилась возможность делать inser в уже готовые и отображенные объекты.
а это нарушает потоковый принцип ХТМЛ и т.д. выводы читай выше.
«DOM тут не причём».
Не находите что-то странное в этих утверждениях?
Впрочем это не важно, повторяю
1 во время считывания и обработки тэгов, невозможно гарантированно прогнать Тэг по CSS стилям, пока не будет закрыт тэг родителя. (из-за last-child)
2 из-за п1 и after нужно или дожидаться полного считывания HTML прежде чем строить объекты, или превращать HTML viewer в HTML editor, что бы появилась возможность делать inser в уже готовые и отображенные объекты.
а это нарушает потоковый принцип ХТМЛ и т.д. выводы читай выше.
НЛО прилетело и опубликовало эту надпись здесь
1 А зачем создавать объекты «позже»?
Юзерам важно отобразить как можно быстрее.
Считал, распарсил, создал объекты, отобразил.
2 пересчет стилей = удаление/изменение старых объектов.
А все из-за убогости пары никому не нужных параметров CSS, о чем я и говорил.
Юзерам важно отобразить как можно быстрее.
Считал, распарсил, создал объекты, отобразил.
2 пересчет стилей = удаление/изменение старых объектов.
А все из-за убогости пары никому не нужных параметров CSS, о чем я и говорил.
Вы так пишите, как будто css — единственное препятствие на пути отображения по мере загрузки!
А таблицы? Картинки? Что насчет картинки в плавающем блоке?
Если эти параметры не нужны ВАМ, не значит, что не нужны НИКОМУ.
Кто бы спорил, но только не я, а учитывая, что моя задача не делать CSS, а выводить, я такие извращенные HTML насмотрелся…
Так что полностью с вами согласен, все, все что только можно изгадить или извратить, все будет использовано.
ps
подскажите какая есть задача, где вы, вынужденны использовать эти параметры?
Так что полностью с вами согласен, все, все что только можно изгадить или извратить, все будет использовано.
ps
подскажите какая есть задача, где вы, вынужденны использовать эти параметры?
::before и ::after не требуют информации о контенте элемента. Они требуют лишь его наличия (ну и допустимости их для этого элемента — напр. для пустых и замещаемых элементами они по одним спекам запрещены, по другим — не определены). Так что браузеру ничто не мешает сразу при создании бокса для элемента создать и боксы для его ::before и ::after — а потом, по мере построения боксов для его дочерних элементов, добавлять их между ними.
Вот :empty, :last-child и :nth-last-*, действительно, должны либо дождаться закрытия элемента, либо перестраиваться «на лету» при добавлении каждого потомка. Поэтому они и медленные.
Вот :empty, :last-child и :nth-last-*, действительно, должны либо дождаться закрытия элемента, либо перестраиваться «на лету» при добавлении каждого потомка. Поэтому они и медленные.
La vie, voyez-vous, ça n’est jamais si bon ni si mauvais qu’on croit. — Guy de Maupassant
А css — это жизнь
А css — это жизнь
На самом деле, брак Анны Болейн был признан недействительным. Так что она никак не может быть Тюдор.
как минимум она сама себя так называет
Вот скажите, зачем вообще сделали HTML + CSS тьюринг-полным? Пока, создаётся такое впечатление, что действительно хотели наговнять
То что язык CSS кривоват — это медицинский факт.
Последние годы ситуация в этой области, конечно же, заметно улучшилась и нам стало казаться, что CSS стал мощный, гибкий и в умелых руках способен творить чудеса. Отчасти это так, но лишь на фоне того, что было 5-10 лет назад. Если посмотреть непредвзято, то можно заметить и несуразности, и костыли, и проблемы с поддержкой. Даже нынешний любимец публики — Flexbox — и тот вызывает вопросы.
А все те «умопомрачительные» демо, которые можно найти где-нибудь на codepen, обычно невероятно замудрены и костыльны. Это просто прикольные упражнения для мозгов. В реально работе 90% того кода неприменимо.
Последние годы ситуация в этой области, конечно же, заметно улучшилась и нам стало казаться, что CSS стал мощный, гибкий и в умелых руках способен творить чудеса. Отчасти это так, но лишь на фоне того, что было 5-10 лет назад. Если посмотреть непредвзято, то можно заметить и несуразности, и костыли, и проблемы с поддержкой. Даже нынешний любимец публики — Flexbox — и тот вызывает вопросы.
А все те «умопомрачительные» демо, которые можно найти где-нибудь на codepen, обычно невероятно замудрены и костыльны. Это просто прикольные упражнения для мозгов. В реально работе 90% того кода неприменимо.
Демо Анны выглядят интересно, но за внешней простотой скрываются:
— циклы, «спрятанные» в Haml и SCSS (на самом деле делается 6 раз по 256 дивов-тайтлов)
— малопонятные значения вида (что это значит и зачем оно я лично сразу понять не могу и как это можно поддерживать остается загадкой)
— циклы, «спрятанные» в Haml и SCSS (на самом деле делается 6 раз по 256 дивов-тайтлов)
— малопонятные значения вида (что это значит и зачем оно я лично сразу понять не могу и как это можно поддерживать остается загадкой)
$p: 50%/($n - 1)*
($j + abs((1 - $mod)*($n - 1) - $k));
@if $mod > 0 { $p: 100% - $p; }
Какой-то пост странный, сплошные эмоции, какой-то разговорный сленг — это всё больше уместно для личной днявочки по-моему.
вы совершенно не виноваты, что и стандарт и реализации вам достались (пока что) проблемные сильно. ругают и стебутся не над профи, пытающимися достичь свободы самовыражения на сss, а над всем тем, что мешает этому.
А как вообще получилось, что родилась связка html+css? Ведь ко времени зарождения Web'а уже существовала такая отличная штука, как TeX, где всё тоже human-readable и где контент отделён от форматирования. И были уже готовые движки для рендеринга этой штуки.
Ну ведь логично было бы не изобретать костыли на коленке, которые вполне закономерно получились кривыми, а использовать уже отлаженное и проверенное временем решение.
Ну ведь логично было бы не изобретать костыли на коленке, которые вполне закономерно получились кривыми, а использовать уже отлаженное и проверенное временем решение.
А как в ТеХ описываются стили?
У TeX порог входа повыше, да и он во многом заточен именно под вёрстку книг, а не одной большой страницы неопределенных габаритов.
Там была долгая история… Основной упор был на быстроту передачи смысловой части по хилым каналам и адаптацию отображения для конкретного пользователя/ситуации (да, HTML с самого начала был адаптивным:). Но многое решил и слепой случай, как обычно.
Хочу такую кружку)
Интерфейсы, которые я в 10-м классе делал в дельфи за час мышкой, сейчас целыми командами делают неделями. Покажите мне готовый грид-компонент, хотя бы близкий по скорости и фичам к аналогам хотя бы того что 20 лет назад было в delphi.
Верстка текста в вебе — как была говном, так и осталась. Где переносы уже, где выключка по ширине? А ведь текст в браузерах читают уже сильно больше чем в книгах и газетах. Оно даже долбаный текст не научилось рисовать.
Веб настолько плох, что у любого хабра и жежешки, уже есть мобильная аппа, удобнее браузера.
Веб должен умереть. И можете мне не петь про обратную совместимость: выкинуть веб в мире где люди ходят в фейсбук и почту через мобильные аппы — вообще не проблема.
Верстка текста в вебе — как была говном, так и осталась. Где переносы уже, где выключка по ширине? А ведь текст в браузерах читают уже сильно больше чем в книгах и газетах. Оно даже долбаный текст не научилось рисовать.
Веб настолько плох, что у любого хабра и жежешки, уже есть мобильная аппа, удобнее браузера.
Веб должен умереть. И можете мне не петь про обратную совместимость: выкинуть веб в мире где люди ходят в фейсбук и почту через мобильные аппы — вообще не проблема.
Простите, оффтоп, но выскажусь про мобильные приложение. Это исключительно мое личное мнение.
Когда какое-то приложение не предоставляет каких-то особых функций\оффлайна\производительности по сравнению с мобильной версией сайта — оно должно умереть.
Там нельзя:
- выделять текст
- делать поиск
- открывать вкладки
- добавить какую-то конкретную страницу в закладки
- переслать кому-то ссылку
На эту тему есть комикс XKCD
Заголовок спойлера
НЛО прилетело и опубликовало эту надпись здесь
Так возможность расшаривания должна быть предусмотрена разработчиком, если я все правильно понял. А в браузере всегда можно скопировать адрес.
Я никому не навязываю эту точку зрения, но на 100% согласен с этим
Покажите мне готовый грид-компонент, хотя бы близкий по скорости и фичам к аналогам хотя бы того что 20 лет назад было в delphi.
Покажите, для начала, что там было в Дельфи.
Где переносы уже, где выключка по ширине? А ведь текст в браузерах читают уже сильно больше чем в книгах и газетах.
Вы, видимо, проспали то время, когда в вебе было модно делать текст с выключкой по ширине и с переносами. Сейчас уже так не делают. Подумайте почему.
Переносы уже везде, только хромята ещё хромают, но и там буквально на днях пофиксили. Не везде (как говорят, сам пока глубоко не исследовал) словари этих переносов для русского языка (и др. языков кроме англ.). Но есть большое подозрение, что с правильным атрибутом lang и словари будут находиться чаще…
> Интерфейсы, которые я в 10-м классе делал в дельфи за час мышкой, сейчас целыми командами делают неделями.
Сейчас, кстати, и нативные десктопные приложения не брезгуют css для задания собственных стилей.
Сейчас, кстати, и нативные десктопные приложения не брезгуют css для задания собственных стилей.
Эти интерфейсы, в большинстве своём, были для фиксированного размера окна и элементов в нём. Некоторые заморачивались и через костыли делали растягивающиеся окна. Но в любом случае, размер элементов всегда остаётся одним и тем же. А вот с сайтами можно делать всё что угодно: увеличивать, уменьшать размеры элементов, просматривать на экранах с портретной и ланшафтной ориентацией экрана и даже адаптироваться под маленькие экраны!
Где переносы уже
Переносы отлично работают, если их расставить в тексте заранее с помощью ­. А если вы хотите авторасстановку переносов браузером для каждого известного науке языка, то у меня для вас плохие новости — эта задача ещё не решена.
Вам надо подключать огромное количество словарей и всё равно оно будет работать хуже, чем проверка грамматики.
Анимация классная.
Проблема не в CSS или других веб-стандартах, а в том, что при разработке спецификаций почти не учитывается обратная связь от практикующих веб-разработчиков и даже простая и полезная функциональность, для стандартизации и реализации которой требовались бы минимальные усилия, игнорируется годами.
Например, спустя 10 лет (!) у нас всё ещё нет возможности переопределить отдельный фоновый слой без необходимости повторять все остальные слои. Не говоря уж о генерации виртуальных контейнеров средствами CSS.
Например, спустя 10 лет (!) у нас всё ещё нет возможности переопределить отдельный фоновый слой без необходимости повторять все остальные слои. Не говоря уж о генерации виртуальных контейнеров средствами CSS.
у нас всё ещё нет возможности переопределить отдельный фоновый слой без необходимости повторять все остальные слои.Если мы о правилах слоя, но не о слое, то — есть, но никто этим не пользуется, т.к. не принято — надо обратиться к правилу document.styleSheets[i].rules[j] и поменять там selectorText или style. Изменится правило для любого слоя. Но, как видно, подход неудобен, потому что принято, что правила статичны. Нет именованных списков и есть хаотично создающиеся таблицы правил styleSheets, за количеством которых никто не следит по причине их условной «статичности» — как бы ни определил, результат будет тот же.
А если мы о слое, в который вложены другие — то же самое, неудобной манипуляцией с нодами можем сделать что угодно — подменить, удалить, дочерние ноды рассовать по другим местам, без необходимости переписывания. Но принято переписывать.
Вот с контейнерами (если вы о компонентах) — действительно, у CSS проблемы.
Я о множественных фонах в CSS и виртуальных контейнерах, генерируемых средствами CSS.
MTonly наверное имеет ввиду, что нельзя изменить только средний слой в правиле типа
Придется повторять правило полностью.
html{
background-image: url("semitransparent.png"), url("semitransparent2.png"), url("semitransparent3.png");
}
Придется повторять правило полностью.
Как часто вы используете множественные фоны? Я думаю это свойство не дорабатывают именно из-за того, что частота использования множественного фона стремится к нулю.
По генерации виртуальных контейнеров. CSS стилизует элементы. Именно в этом его предназначение. Оставьте динамический контент для других стезей.
По генерации виртуальных контейнеров. CSS стилизует элементы. Именно в этом его предназначение. Оставьте динамический контент для других стезей.
НЛО прилетело и опубликовало эту надпись здесь
думаю это свойство не дорабатывают именно из-за того, что частота использования множественного фона стремится к нулю.Когда требуется — тогда использую, и очень рад, что для этого нет необходимости засорять HTML-разметку дополнительными вложенными элементами. А не дорабатывают в общем случае потому, что заняты «более важными или трудоёмкими» (но не обязательно востребованными в веб-разработке) вещами. Конкретно для переопределения фонового слоя обсуждался вариант синтаксиса с указанием слоя с помощью индекса:
background[0], но для этого потребовалось бы менять базовый синтаксис CSS (core syntax), а этого там боятся как огня, даже если на самом деле в конкретном случае это совершенно безопасно с точки зрения обратной совместимости.CSS стилизует элементы. Именно в этом его предназначение.А виртуальные контейнеры, по-вашему, для чего нужны? Именно для применения стилей к визуальным группам элементов без необходимости засорять HTML-разметку лишёнными семантического смысла элементами
DIV/SPAN, нужными только для применения стилей.
Мои претензии к CSS:
1. Плохо читабелен, прочитав CSS код нельзя понять, как будет выглядеть конечная картинка. Когда CSS много, то по читабельности он может соревноваться с ассемблером, конкретно, что вот эта строчка делает понимаю, а что будет когда все вместе, нужно смотреть на результат в броузере с открытым инспектором.
2. Следствие пункта номер 1, тяжело поддерживать. Часто переделать все с нуля, в разы быстрее, чем что то подправить в существующем коде. Если у вас не получается победить грабли, любовно расставленные предыдущим верстальщиком, попробуйте этот метод.
1. Плохо читабелен, прочитав CSS код нельзя понять, как будет выглядеть конечная картинка. Когда CSS много, то по читабельности он может соревноваться с ассемблером, конкретно, что вот эта строчка делает понимаю, а что будет когда все вместе, нужно смотреть на результат в броузере с открытым инспектором.
2. Следствие пункта номер 1, тяжело поддерживать. Часто переделать все с нуля, в разы быстрее, чем что то подправить в существующем коде. Если у вас не получается победить грабли, любовно расставленные предыдущим верстальщиком, попробуйте этот метод.
Сложность CSS отчасти продиктована сложностью того, чем ей приходится управлять — текста. Который к тому же отображается в не самых предсказуемых условиях. Ты не знаешь ширину и разрешения экрана у пользователя, не можешь быть уверен в поддержке тех или иных опций браузера, да даже содержание текста. И всё это должно определённым образом двигаться, реагировать на действия пользователя.
Плохо читабелен, прочитав CSS код нельзя понять, как будет выглядеть конечная картинка.Можете привести пример такого CSS-кода?
Можно я, сыграю разок за противника? ;)
Какого цвета будет кнопка после первого нажатия? :)
Но лично я вот во многом как раз за такие вещи CSS и люблю:)
button {
transition: background 0s 99999s
}
button:active {
background: red;
transition: none;
}
<button onclick="this.style='background: green !important'">
Нажми меня
</button>
Какого цвета будет кнопка после первого нажатия? :)
Но лично я вот во многом как раз за такие вещи CSS и люблю:)
Какого цвета будет кнопка после первого нажатия? :)А что говорит практика? ;-)
Лучше расскажите, почему снова инкрементировали индекс в нике. Или всё это — разные люди? ;-)
Моя практика согласуется с моим пониманием стандарта — после первого нажатия красный, после второго и последующих зеленый :-)
Это была невеселая история… Но стараюсь смотреть в будущее, а не назад :-)
Это была невеселая история… Но стараюсь смотреть в будущее, а не назад :-)
UPD: практика в iOS 9.3 Safari преподнесла мне сюрприз — там кнопка остается красной и после последующих нажатий. Интересно, в чем дело — неужели в пресловутой 300-миллисекундной задержке?
Css отличная штука, хотя складывается впечатление что ошибок бывает много, приходится придумывать разные костыли, типа клирфикса, верт. позиционирования, надеюсь со временем всё это вообще уйдет в небытие ))
CSS, как и javascript — это просто инструмент. Те, кто этими технологиями не владеет, начинает обвинять технологию в чём-то, что у него не получается на ней сделать. А дело не в технологии.
Есть такая вещь. Стандарт и реализация. Стандарт — вполне хорош, а вот реализация...
Не хватит.
В вебе нет альтернатив CSS, ни в части селекторов (управление inline стилями через JS непроизводительно), ни в части графических возможностей (хотя некоторые от безысходности пытаются пилить интерфейсы на SVG или canvas).
И мы делаем «невероятно сложные, впечатляющие и красивые штуки в вебе» потому что мы хорошие разработчики, а не потому что это правильный инструмент.
Алсо откровенно сексистская подборка докладчиков не добавляет впечатления объективности от статьи.
В вебе нет альтернатив CSS, ни в части селекторов (управление inline стилями через JS непроизводительно), ни в части графических возможностей (хотя некоторые от безысходности пытаются пилить интерфейсы на SVG или canvas).
И мы делаем «невероятно сложные, впечатляющие и красивые штуки в вебе» потому что мы хорошие разработчики, а не потому что это правильный инструмент.
Алсо откровенно сексистская подборка докладчиков не добавляет впечатления объективности от статьи.
Нет, не хватит.
Есть за что поливать.
А по поводу примеров и «доказательств»… В вебе можно найти очень крутые рисунки, сделанные попиксельно в MS Paint. Являются ли они доказательством того, что Pain продвинутый, удобный и самодостаточный редактор?
Есть за что поливать.
А по поводу примеров и «доказательств»… В вебе можно найти очень крутые рисунки, сделанные попиксельно в MS Paint. Являются ли они доказательством того, что Pain продвинутый, удобный и самодостаточный редактор?
Просто мы слышим поколение нытиков-миллениумов. Все им не то и не так. Не прошли они через табличную верстку, однопиксельные распорки и адские хаки для кроссбраузерности.
CSS — отличный язык. Помню свое первое знакомство с ним в начале нулевых — когда
CSS — отличный язык. Помню свое первое знакомство с ним в начале нулевых — когда
a:hover выглядело необычайно круто (ведь для интерактива был не нужен JavaScript). А сейчас все его «недостатки» полностью нивелировали Sass, Less и PostCSS. Браузеры с тех времен реально шагнули вперед, технологии фронтенда — тоже. Что-то неудобно — пиши свой миксин Sass или плагин для PostCSS и используй. Ной не ныл и ты не ной.В качестве контраргумента к заявлениям о плохом синтаксисе приводить примеры с буханками из троллейбусов — это сильно.
Хотя я считаю разговоры о синтаксисе css не более чем вкусовщиной. И не надо мешать синтаксис с багами реализации.
Хотя я считаю разговоры о синтаксисе css не более чем вкусовщиной. И не надо мешать синтаксис с багами реализации.
--и сказать мне в лицо, что это «ненастоящее программирование» и сделано на «тупом языке»?
Это настоящее программирование на тупом языке.
Зачем все эти боль и страдания?
Это настоящее программирование на тупом языке.
Зачем все эти боль и страдания?
Так вроде это картинкой высмеивают не столько сам язык CSS сколько проблемы в больших проектах где команда не позаботилась о методологии, порядке, etc…
Ругающие CSS ни разу не рисовали стили в ASS (формат субтитров для видео). Особенно караоке эффекты.
А ведь функционал похож.
А ведь функционал похож.
Не принимайте все так близко к сердцу. Людям свойственно шутить в двух случаях: когда они не очень хорошо понимают предмет обсуждения и когда понимают его очень хорошо. На первых не стоит зацикливаться, а вторым дозволительно.
Благодарю за приложения к статье. Впечатляет показанное.
Благодарю за приложения к статье. Впечатляет показанное.
Согласен с автором. Всегда считаешь ущербной и кривой технологию которую не понимаешь и не умеешь пользоваться. Но ребята, будем честны, вы просто не умеете их готовить. И потому вам проще психануть, чем разобраться почему так а не иначе.
В чём суть претензий к разработчикам? Указывать на недостатки технологии что-то постыдное? Тогда css и развиваться не будет, а браузеры продолжат внедрять свистелки вроде управляемых параметров шрифтов вместо человеческих гридов, которых в 2016 году всё ещё нет.
Вместе с критикой должны идти варианты решения, а не просто ныть какой плохой CSS, PHP и т.д.
А шуточки про это уже поднадоели…
А шуточки про это уже поднадоели…
Работал бы еще этот css везде одинаков.о
Я в вебе встречал кучи страничек собранных фанатиками. Причем не на каких-то там школоло сайтах. И самый распространенный вопрос у меня при виде таких вот страничек — Зачеем(лицоладонь).Вот от них то и появляются такие темы. Я склонен считать что CSS это не графический редактор, и не adobe illustrator, это всего-лишь средство внесение однородности и единообразия в структуру всего сайта. Перестаньте считать CSS тем чем он не является и все будет ок.
Можно и про неправильные глаголы в английском говорить, что они неправильные и переливать из пустого в порожнее, потому как ими все равно будут пользоваться.
В действительности ноют о всем и вся, и обычно это идет в начале что бы начать разговор про «еще одну новую технологию которая все исправит». Как и во всех популярных технология есть свои плюсы и недостатки, и все зависит от человека который работает с технологией. Технология уже довольно стара, новым людям которые познакомились с ней пару лет назад какие т оприколы (напрмер как схлопывание или же работа float) кажется не логичными и они думают что это баг, но WEB изначально был просто текстовыми страницами, все интерфейсное богатство уже сделали по ходу. В таких популярных технология как CSS в действительности все зависит от прослойки мержу креслом и монитором, и увы проще искать проблему в технологии, а не в себе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Может, хватит уже поливать грязью CSS на конференциях разработчиков?