Но если тема заходит об обычном сайте со стандартным функционалом, не редки случаи, когда JavaScript начинают “злоупотрелять”. И все, в принципе, нормально… Но порой задаешься вопросом: «А если без JavaScript?».
Поэтому хочу поделиться с Вами вариантами реализации того или иного функционала, используя только html и css. Возможно, какие-то Вы уже видели, или даже используете в своих проектах, но здесь я решил собрать все полезные (и не очень) наработки, которые могут заменить js.
Все примеры адаптивные и легко расширяемые. Логика работы построена на checkbox и radiobutton, с которыми связаны label по id. Id можно генерировать на стороне сервера.
Но сразу хочу заметить, что данный код служит лишь примером реализации, и я не добавлял к свойствам вендорных префиксов.
Пойдем от простых решений к более интересным.
1. Табы / вкладки
label — вкладка;
p — контейнер для текста (можно заменить на div, к примеру).
Чтобы добавить новую вкладку, надо добавить в html теги input+label+p.
2. Аккордеон
Работает по такому же принципу, как и 1 пример.
3. Модальное окно
Модальное окно открыто, когда input:checked.
Теперь в любом месте в документе можно разместить кнопку label[for=zayavka], нажатие на которую будет открывать модальное окно. «zayavka» — это id модального окна, а точнее id input'а, который его «открывает». Т.е. что бы добавить еще 1 модальное окно, надо скопировать input+div.modal и заменить id input'а и for у label, которые с ним связаны.
4. Навигация / меню
Это вариант реализации мобильного меню с подпунктами. Можно, естественно, адаптировать через медиа-запросы до десктопной версии.
5. Слайдер с превью изображений
Размер слайдера и количество изображений в нем можно сделать любое. Чтобы добавить новое изображение, нужно скопировать конструкцию input+(.item>img)+label>img (опять же, это можно генерировать автоматически на стороне сервера). Первый img — это основное изображение, второй img — превью. При желании, flex можно заменить на inline-block или float.
6. Карусель с «ленивой» загрузкой изображений
Размер карусели и количество изображений в ней можно сделать любое. Также можно доработать css и сделать отображение нескольких изображений в ряд. «Ленивая» загрузка здесь достигается путем того, что изображения прописываются в background-image для div, а в css есть строка, которая перебивает это свойство для div, которые не отображены на экране. В итоге, изображения загрузятся только тогда, когда пользователь начнет листать карусель.
Div с background-image можно заменить на обычный <img>, но тогда ленивая загрузка работать не будет. Чтобы добавить новое изображение, надо добавить в html теги input+div>label+.item. Причем, for у label должен вести на input перед предыдущим изображением (пример см. в коде выше).
Итог
Все примеры не привязаны к id элементов и их количеству! Т.е. не надо лезть в css при добавлении слайда в карусель, или новой вкладки таба. Id элементов можно задавать любые — все будет работать!
Так же хочу добавить, что, например, «прилипание» меню к верхней части экрана при скроллинге можно сделать, установив свойство position: sticky для меню. Но это свойство поддерживается не всеми браузерами.
Надеюсь, данная статья оказалась полезна для Вас! Таким образом можно реализовать еще много различных элементов на сайте без JavaScript. Один из плюс таких реализаций — это работа в браузерах с выключенным JavaScript (если в наше время кто-то таким пользуется).
Спасибо за внимание!
Комментарии (131)
kana-desu
28.01.2017 02:56+7Считаю это костылем. Стили в css, функционал и логика в js. Имхо, абсолютно все, что представлено в этой статье, должно быть сделано на js.
Saffron
28.01.2017 04:01-3javascript — опасен. Он тьюринг-полный, он может завешивать браузер полностью, он может сливать информацию пользователя третьим лицам. Браузеры так и не научились запихивать javascript в надёжную песочницу, поэтому пользователям остаётся только блокировать его целиком.
css отличается тем, что он декларативен. Ты указываешь, что хочешь получить, достаточно сложное уравнение и браузер его вычисляет и показывает. Это гораздо лучше чем терпеть javascript. К тому же можно просто скачать страницу и сохранить на локальный диск, без подгрузки тысяч библиотек с внешних ресурсов.
Shchvova
28.01.2017 04:13-9CSS тоже полный по Тьюрингу.
Ivan_Kotov
28.01.2017 19:41Это по сути не язык программирования… Как он может быть полным по Тьюрингу?
Realetive
31.01.2017 22:38Не совсем верно — CSS в сочетании с HTML позволяет «строить» клеточные автоматы (Правило 110), являя собой пример тьюринговой машины, т. е. быть тьюринг-полным. Но не уверен, что об этом знали минусуюшие…
SelenIT3
01.02.2017 12:13+1Намека на сочетание с чем-либо в заминусованном комментарии не было. Причем, если я верно понимаю, для полной полноты, кроме чекбоксов для хранения состояния, нужен еще внешний цикл в лице человека, кликающего по этим чекбоксам. Не читерство ли это?
Да, бесчисленные демки Гомеров Симпсонов и прочих троллейбусов из хлеба «на чистом CSS» приучили нас считать горы несемантичных тегов их неотъемлемой частью, но по-моему это неправильно. А без разметки на голом CSS мало что можно сделать (хотя кое-что всё-таки можно:)
Maccimo
28.01.2017 10:57-4Всё, что может быть сделано без JavaScript, должно быть сделано без JavaScript.
APaMazur
28.01.2017 12:29+3Очень многие очень серьезные штуки, включая брузерные инженерные системы (количество которых стремительно растет, ибо удобно всегда иметь актуальную версию клиента на любой машине с браузером, ничего не устанавливая) можно сделать без JS или почти без JS
Беда в том, что если вы пишете что-то сложнее форума — это такой невозбранный объем адского гемороя, что вы либо получите неподдерживаемый гроб, либо не получите продукт вообще
Писать все без JS имеет смысл в двух случаях: нечем заняться и это что-то чрезвычайно нишевое и специфическое, требующее сверхъестественной стабильности и совместимости
В остальных случаях — инструмент под задачу
kana-desu
28.01.2017 13:56+3Ага, чтобы программисты видели кучу сложночитаемого и сложноподдержимоего кода. Слайдеры на CSS — не читаемый код.
kiloper
28.01.2017 12:18+3Ну и используйте js, здесь лишь описан пример как можно, меня это поразило, как опыт очень ценно, мало ли где и что надо будет.
GraneDirval
28.01.2017 19:41+2Если человек умеет делать вещи, которые все шлёпают на JS, то это лишь "+" ему в карму как фронтендера. Это отличный показатель навыков и уровня.
Кстати, отличное задание для сосискателей :-)
Ares_ekb
28.01.2017 07:25+7Для модальных окон есть более естественная реализация через селектор :target — пример. Кстати, через :target можно сделать и все остальные примеры кроме меню. Причём, при выборе вкладки или при открытии модального окна соответствующим образом изменяется адрес страницы: добавляется #dialog, #tab1, #tab2. И, соответственно, при обновлении страницы откроется та же самая вкладка или то же самое диалоговое окно. В этом преимущество по сравнению с checkbox. Плюс CSS-стили выглядят гораздо проще.
Наверное было бы интересно, если бы вы сделали всё то же самое, но через :target. Единственная проблема это что при закрытии диалогового окна вы переходите по адресу # и перескакиваете в начало страницы. Тут приходится уже использоваться JavaScript:
document.getElementById('close-button').addEventListener('click', function (e) { e.preventDefault(); history.go(-1); });michael_vostrikov
29.01.2017 08:27Ага. А что если я открыл ссылку с #dialog в новой вкладке браузера? Оно же не закроется. Или в другой уже открытой? Вместо решения задачи начинаются танцы с бубном, как же мне закрыть окно, сохранив текущую страницу и позицию скролла. Причем на том же JavaScript.
Таких вопросов много. Как сделать первую вкладку в табах по умолчанию открытой? И самый главный вопрос — как сделать 2 элемента с табами на одной странице?Ares_ekb
29.01.2017 09:03+1Да, новую вкладку браузера не учел, нужна проверка. В этом случае просто ничего не делаем:
document.getElementById('close-button').addEventListener('click', function (e) { if (history.length > 1) { e.preventDefault(); history.back(); } });
Чтобы первая вкладка таба была по умолчанию открытой, у неё адрес должен быть просто #.
Два элемента с табами — это из той же области, что два фрейма на странице. Очень старая проблема: адрес один, а страницы две. К какой из них относится адрес? Эта проблема более глубокая, чем JavaScript vs HTML+CSS.
Тут идеального решения нет. Если в табах реально отображается основное содержимое страницы, то совершенно естественно ссылаться на каждый таб через свой якорь. Если в HTML+CSS уже есть этот механизм, то почему бы им не пользоваться? Вы же для таблиц используете тег table, а не отрисовываете их на JavaScript? Если табов может быть несколько или если требуется асинхронная подгрузка их содержимого, то, да, нужен JavaScript.
К тому же, у меня встречный вопрос :) Как средствами JavaScript открыть сразу нужную вкладку таба, если стоит такая задача? Это можно сделать только с помощью якорных ссылок, которые из коробки поддерживаются HTML+CSS. Какой смысл тут городить JavaScript?michael_vostrikov
29.01.2017 11:15В этом случае просто ничего не делаем:
Тогда '#' остается.
Чтобы первая вкладка таба была по умолчанию открытой, у неё адрес должен быть просто #.
Пробую пример отсюда, не работает.
Два элемента с табами — это из той же области, что два фрейма на странице. Очень старая проблема: адрес один, а страницы две. К какой из них относится адрес? Эта проблема более глубокая, чем JavaScript vs HTML+CSS.
Это одна страница, фреймы здесь ни при чем. В бизнес-приложениях часто встречается вариант, когда в форме редактирования объекта поля разделены на вкладки, а внизу еще вкладки с информацией, связанной с объектом в целом — комменты, лог изменений и т.д. Или другой вариант, когда есть табы и модальное окно. Весело будет, если при открытии окна пол-странцы в фоне исчезнет.
Как средствами JavaScript открыть сразу нужную вкладку таба, если стоит такая задача? Это можно сделать только с помощью якорных ссылок
Можно через якорь, можно через GET-параметр, можно через local storage или cookies, если надо запоминать. Отличие в том, что это не будет влиять на отображение остальных элементов. А через split можно и несколько табов обрабатывать.
Якорь это глобальное состояние, и создает все связанные с ним проблемы. Поэтому его влияние лучше минимизировать.
Ares_ekb
29.01.2017 11:54В некоторых ситуациях якорь — это проблема, а в некоторых, как-раз наоборот, якорь — единственное адекватное решение. Например, если в табах отображается основное содержимое страницы. Ваш пример с формами редактирования — это другое дело, там якоря действительно не нужны.
Скажем, галерея картинок. Если ссылка на каждую картинку делается через якорь, то это очень удобно. Можно сохранить ссылку и открыть сразу нужную картинку. В этом случае глобальное состояние это плюс. И альтернатив я тут не вижу.
Да, насчет вкладки по умолчанию вы правы, тут всё несколько сложнее, но есть решение через комбинатор селекторов ~. Вот, пример. Я не призываю отказываться от JavaScript, если что, я библиотеку для теории категорий на нём пишу :) Но и про селектор :target знать не лишне и использовать его иногда, явно штука не бесполезная.
PaulZi
28.01.2017 11:01Идеальный сайт может по максимуму работать с отключённым JavaScript. К сожалению, таких сайтов всё меньше и меньше, а фреймворков JS всё больше и больше.
Всё это привело к тому, что для работы какого-нибудь интернет-банка (например, на букву Т), требуется выкачать 500 кБайт заgzipованных скриптов, хотя большую часть функционала можно реализовать вообще без скриптов.pudovMaxim
28.01.2017 12:44+2Идеальный программист должен быть с бородой и в свитере, а также сидеть на диалапе в 32 кб/с. Стойте, а какой сейчас год? Оу, 2017.
А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк, заменяющий 5 часов поездок в банк на каждый чих.Saffron
28.01.2017 13:30-6А зачем делать интернет банк в вебе? Зачем майкрософт сделало новый скайп плагином для браузера (электрон)?
Почему бы просто не сделать приложение, которое можно скачать. Например на джаве, как делали до этого.pudovMaxim
28.01.2017 13:54+4К электрону я тоже отношусь не очень. Но вот предлагать ставить всем джаву, когда у всех уже есть браузер в котором можно сделать тоже самое, то это, мягко говоря, глупо.
Lsh
29.01.2017 12:40-2А если всем поставить джаву, то в следующий раз у всех уже будет джава.
И она таки лучше подходит для сложного GUI, чем html+css+js.
raveclassic
29.01.2017 14:31+1А если всем поставить джаву, то в следующий раз у всех уже будет джава.
Ну сначала поставьте ее всем. Вы удивитесь насколько неохотно пользователь ставит то, что ему не нужно, чтобы заработало то, что и так уже в вебе работает.
И она таки лучше подходит для сложного GUI, чем html+css+js.
Таки с чего вы взяли?
pudovMaxim
29.01.2017 14:40+1— Нет, ребята, я не гордый.
Не загадывая вдаль,
Так скажу: зачем мне java?
Я согласен на web-app.
Повторюсь: зачем еще следить за новой сущностью — jvm, еслиу меняу всех уже есть установленный браузер?
В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.raveclassic
29.01.2017 14:44В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.
Ну так в чем же? Я вовсе не холиварю и прекрасно понимаю различия (а не то, что одно лучше другого). Просто со стороны эти заявления нелепо выглядят без аргументации.pudovMaxim
29.01.2017 15:29Я подразумевал скорее «десктопный GUI может быть в чем-то лучше web-app».
То что одно лучше другого я как раз не утверждал. Они по-своему специфичны, но в целом равны.raveclassic
29.01.2017 21:16Так в чем же, в чем может быть «в чем-то лучше»? Ну здравый интерес же, расскажите.
pudovMaxim
29.01.2017 21:50Не знаю. Это было предположение. Может быть лучше, а может быть и нет, подтвердить не могу — мало опыта для этого. Возможно есть какие-то проблемы, которые десктопными приложениями будут решаться эффективнее, чем в вебе, но 90% повседневных задач современный веб может решить без проблем.
raveclassic
29.01.2017 22:05Ну так вот, десктоп лучше только в том плане, что там есть инструменты, которые стабилизировались десятилетиями, когда вебу (такому, какому мы его сейчас видим) всего несколько лет, и, несомненно, вся эта каша вызывает обоснованное недовольство со стороны десктоп-разработчиков. С другой же стороны, технология веб-платформы практически полностью покрывает требования и запросы любого типичного приложения. Само собой, если вам нужна оптимальная бд под задачу или, например, udp или еще не дай бог какая экзотика уже не в рамках того же «любого типичного приложения», то ничего вы не получите. Это обоснованное ограничение платформы, которая выполняется в удаленном пользовательском браузере. Вспомните апплеты и флэш, которые умели все, где они теперь?
Возвращаясь к нашему вопросу, все вышеперечисленное к GUI имеет ровно никакого отношения, и, если сравнивать десктопную вертску (если такая имеется, как например в wpf или qt), то там ровно то же самое, только вот работа с темами корявая, ибо нет удобной декларативности css. Если верстка отсутствует (как саме знаете где), то тут я вообще не знаю, насколько уместны все эти разговоры про преимущества платформы (сами знаете какой).
Saffron
29.01.2017 17:21-1> jvm, если у меня у всех уже есть установленный браузер?
И вы почему-то думаете, что этот браузер — мозилла или хромиум. К сожалению, после того как и тот и другой подло внесли в свою дистрибуцию бинарные программы (chromium — какую-то хрень для аудио, а firefox — DRM), у меня нет ни того, ни другого. Хрен с два ваша замечательная программа, написанные под четыре браузера (хром, файерфокс, эдж или сафари) будет работать у меня. А JVM — унифицирован.DistortNeo
29.01.2017 18:14А теперь посчитайте: у какого процента пользователей есть JVM, а у какого процента пользователей — обычный браузер.
michael_vostrikov
29.01.2017 19:19Бинарники, запускаемые в JVM, вас значит не смущают?
raveclassic
29.01.2017 21:21Ого, бинарники это уже новые «аргументы» после нашего последнего разговора
Saffron
30.01.2017 02:39openjdk я собираю лично
michael_vostrikov
30.01.2017 10:45Не, я говорю про байткод, который он выполняет. Он же тоже бинарный. Вдруг в одной из программ есть какая-нибудь хрень для аудио?
Saffron
30.01.2017 15:38Для банка у меня готова специальная виртуальная машина. Чтобы он не выбрался, и чтобы ему не мешали. Очевидно.
А весь остальной используемый софт я собираю сам.raveclassic
30.01.2017 15:52+1Хм, а вы случайно ось себе из исходников не собираете? А то закрадываются подозрительные сомнения…
michael_vostrikov
30.01.2017 16:23А почему бы тогда браузеры в специальной виртуальной машине не запускать?
pudovMaxim
30.01.2017 18:52Тогда не получилось бы поконопатить мозги пользователям хабра.
(Это из разряда «Мне пожалуйста свиной стейк. Только он веганский? Потому что я веган. Я не ем мясо. И вы не ешьте. Но мне нужен стейк. Из свиньи. Но чтоб веганский.»)
Saffron
30.01.2017 21:09копировать неудобно и работать неудобно. Одно дело, когда у тебя есть исключительный случай и большая потребность — ради банковских операций я готов приложить все усилия, чтобы получить безопасность. Тратить такие же усилия на чтение баша — абсурд. Рассовывать каждый сайт по своей виртуалке — так может и память закончится досрочно
michael_vostrikov
31.01.2017 06:30А баш и не надо в виртуалку засовывать. И виртуалок много не надо. Для обычных сайтов используете свой браузер, собранный из исходников. Для особых, наподобие клиент-банков, отдельная виртуалка с последней версией популярного браузера. Зашли в банк, сделали необходимые операции, вышли, сбросили виртуалку на последний снимок. Работать будет для любого веб-приложения. А бинарники да, придется каждый на свою виртуалку ставить.
asoukhoruchko
31.01.2017 09:03У всех гиков.
А делается оно для обычных пользователей, для которых это сложно.
kana-desu
28.01.2017 14:00+2А зачем делать еще одно нативное приложение для разных платформ, которое нужно юзерам устанавливать, ради которого нужно нанимать несколько новых программистов ради мобильных платформ, если можно просто сделать РЕАЛЬНО кроссплатформу через веб, до которой будет проще добраться (запустить сайт значительно проще)?
P.S.: Электрон — зло, конечно, имхо, там все в принципе можно и в браузере запустить (и запускают, веб-версия скайпа есть и используется мной, если мне вдруг нужно в 2017 скайп запустить)
Saffron
28.01.2017 19:52+1Java — это тоже кроссплатформенно. А у веба есть свои заморочки — кросс браузерность. И написание типичного GUI на вебе не проще чем на классических GUI фреймворках.
sumanai
28.01.2017 15:47+2сидеть на диалапе в 32 кб/с. Стойте, а какой сейчас год? Оу, 2017.
Поэтому админ должен сидеть с прерывистого 3G. Ну или лучше не сидеть, и не админ, а отдел тестирования должен тестировать такой кейс, как заход с мобильного из зоны с плохим покрытием сети.
А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк, заменяющий 5 часов поездок в банк на каждый чих.
Замечу, что эти 500кб далеко не обязательны, и тот же интернет банк можно было сделать вообще без скриптов/с минимумом скриптов.
По моему мнению, сайт должен работать с отключёнными скриптами, отдавая нормальную страницу с тегами form и прочее.pudovMaxim
28.01.2017 16:04-4Поэтому админ должен сидеть с прерывистого 3G. Ну или лучше не сидеть, и не админ, а отдел тестирования должен тестировать такой кейс, как заход с мобильного из зоны с плохим покрытием сети.
А можно уехать куда-то в тундру или тестировать с отключенным интернетом. Где грани разумного?sumanai
28.01.2017 16:40+2Вот вы перешли грань, а я ещё нет, так как пользователи с плохим интернетом заходят на сайты, а жители тундры — нет.
pudovMaxim
28.01.2017 20:35Для жителей с плохим интернетом уже сделали хорошо — сжали скрипты с 5Мб до 500Кб. И это стало оптимальным решением по затратам на разработку и прибыли от этих клиентов. И у жителя «нетундры» есть преимущество — можно найти более подходящий канал связи.
Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство (теория «диктатуры меньшинства»).
Возможно, действительно, можно было оставить неудобный и обрезанный кабинет для некоторых индивидов. Но скорее всего, банки плевать хотели на тот процент медленных клиентов из-за которых бы пришлось раздувать отдел ИТ.
Почему сейчас все интернет-магазины гоняются за долями секунд в выдачи контента? Ответ простой — высокая конкуренция. А т.к. товар, цены, условия очень похожи, то есть профит в ускорении сайта. Что самое интересное — далеко не у всех ИМ получается сделать быстрый и удобный сайт.
А что же с банками? Я ищу в первую очередь надежный банк, который не аухнет при первом скачке курса. Мне как-то все-равно, если клиент-банк будет грузиться минуту, вместо 1,52 секунды. Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится, больше интересна комиссия за перевод и процент по вкладу.
И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.Maccimo
28.01.2017 21:00Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство
Вот ведь парадокс, нужно делать хорошо и удобно большинству, но делают хорошо и удобно абсолютному меньшинству, а именно — фронтенд-разработчикам, которым проще ХХВП на каком-нибудь JS-фреймворке и владельцам бизнеса, которые наймут этих фронтендеров по копейке за пучок.
И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.
«Ругань с бабуськами» существует только в фантазиях людей, не бывавших в отделениях банков уже лет по десять.
pudovMaxim
28.01.2017 21:10Может и правда у банка Тинькова не очень удачные обновления. В сбере тоже клиент-банк не шустрый, но вроде не смертельно тормозной.
«с бабуськами» — это образное собирательное выражение. Чтобы попасть в банк оффлайн надо как минимум надеть штаны. (Кстати, как раз вчера около часа бродил вокруг банка, т.к. «программисты всё сломали, ничего не работает»:)
DistortNeo
28.01.2017 21:21+1Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится
Вот в этом и проблема. Если это сайт с минимумом JS, то будет один клик — один запрос. Ответ не пришёл из-за проблем со связью — не беда, кликаем ещё раз и добиваемся результата.
Если же сайт нафарширован JS, то будет множество запросов. Если отказал хоть один из них — то пиши пропало, придётся загружать всё заново и начинать с нуля.
raveclassic
28.01.2017 21:46Если отказал хоть один из них — то пиши пропало, придётся загружать всё заново и начинать с нуля.
Вот вообще необязательно. На современном фронт-стэке прекраснно пишутся оффлайн-приложения с обычной фоновой синхронизацией либо самих данных, либо оплогов при появлении сети.
vgoloviznin
28.01.2017 19:42+1Для телефонов есть приложение, которое есть меньше траффика. Зачем запускать браузер, елси уже есть приложение?
Разве что древне-непопулярная платформа, тогда извините :)
sumanai
28.01.2017 20:24Не все хотят ставить приложение, которое будет кушать батарейку и требует себе столько разрешений, сколько я и не знаю.
msatersam11
29.01.2017 00:29Это уже где-то на грани абсурда:
Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.
@
Для всего остального, есть мобильное приложение.
Которое, по случаю чего, можно и отключать, когда оно не надо.
@
Нет, оно жрёт батарейку, требует много разрешений( будто бы оно банковское, в самом то деле!:) ) и… и вообще… хочу сайт… но… но не такой, который есть, а, как бы такой, но… но чтоб красивый и удобный, и… именно без JS и всё реализовывалось на CSS и под мобильный и… и чтоб мобильный его полностью поддерживал — ведь приведённый в статье( и подобных статьях, гуляющих по интернетам) ужас на CSS одинаково идеально и стабильно работает и отображается на всех устройствах и браузерах, даже старых, то ли дело, ненавистный JS и… да не просто под мобильный, а такой, для которого даже приложение тянуть — ощутимая нагрузка на батарею.
Ну разве не абсурд?)
DistortNeo
29.01.2017 02:16Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.
Конечно, не проблема. Проблема в том, что это уже не веб-сайт, а веб-приложение. Пользоваться веб-приложениями действительно удобно: страница грузится один раз, дальше скрипты делают мелкие запросы и выводят результат без перезагрузки страницы.
Главный жирный минус подобных веб-приложений — однооконность. Хотите открыть несколько писем gmail в разных окнах — пожалуйста, загрузите по экземляру в каждое окно, каждое из которых будет кушать больше 100 мегабайт. Хотите открыть второе окно Т-банка? А авторизоваться по-новой не хотите?
Собственно, можно сказать, что у Т больше нет мобильного сайта, есть только приложение: одно — программа для смартфона, второе — веб-приложение.
sumanai
29.01.2017 04:12Которое, по случаю чего, можно и отключать, когда оно не надо.
Больно много действий для захода в онлайн банк. Он и так требует нескольких шагов, но они хотя бы мотивируются большей безопасностью.
требует много разрешений( будто бы оно банковское, в самом то деле!:) )
Да, скажите, зачем банковскому приложению что-то, кроме доступа в интернет да к СМС? Доступ к списку контактов, чтобы я мог типа быстро отправить контакту, при этом паля свою адресную книгу и позволяя связать свой номер телефона и карточку любому постороннему, на радость мошенникам?
А зачем тогда остальной ворох разрешений:
Разрешения для сбербанк онлайнВерсия 7.6.0: разрешения
История использования устройства и приложений
Получение данных о запущенных приложениях
Просмотр закладок и истории поиска
Настройки мобильных данных
Изменение/перехват сетевых настроек и трафика
Идентификационные данные
Поиск аккаунтов на устройстве
Контакты
Поиск аккаунтов на устройстве
Просмотр контактов
Местоположение
Примерное местоположение (на основе сети)
Точное местоположение (на основе сети и сигналов GPS)
Доступ к дополнительным командам управления источниками геоданных
SMS
Просмотр SMS и MMS
Прием SMS
Изменение SMS и MMS
Телефон
Осуществление телефонных вызовов
Просмотр журнала вызовов
Получение данных о статусе телефона
Изменение журнала вызовов
Фото/мультимедиа/файлы
Просмотр данных на USB-накопителе
Изменение/удаление данных на USB-накопителе
Память
Просмотр данных на USB-накопителе
Изменение/удаление данных на USB-накопителе
Камера
Фото- и видеосъемка
Данные о Wi-Fi-подключении
Просмотр подключений Wi-Fi
Идентификатор устройства и данные о вызовах
Получение данных о статусе телефона
Другое
Получение данных из Интернета
Просмотр сетевых подключений
Установление связи с устройствами Bluetooth
Изменение сетевых настроек
Подключение/отключение сети Wi-Fi
Неограниченный доступ к Интернету
Закрытие других приложений
Управление NFC-модулем
Запуск при включении устройства
Показ элементов интерфейса поверх других окон
Управление функцией вибросигнала
Предотвращение переключения устройства в спящий режим
Изменение настроек системы
Изменение закладок и истории поискаmsatersam11
29.01.2017 11:54Сказано красиво, только вот… приложение, в случае полноценного отключения/остановки, НЕ может работать, когда ему вздумается — оно начинает работать именно тогда, когда его запускают.
Это уж вопрос к соотв. специалистам — для чего конкретно каждое из разрешений требуется.
Вполне логично решит( что устарело ). Это и всевозможные обновления контента/услуг/функционала и безопасности, а не просто проггеры сидят, да думают, как бы ещё бедным пользователям насолить — «лишних» 30 мб их заставить качать, что ли).
А вообще, если не нравится автообновление, то, в случае с Play Market'ом, оно отключается в пару кликов. Посему, нет, оно не может просто так решить и начать качать, если на то нет согласия пользователя( хотя бы молчаливого, т.е дефолтного ).
Хотя, если даже акка в гуглплей нет… На андроиде… То, дальнейшие вопросы( в т.ч безопасности и источников приложений, которые «могут работать, когда им вздумается») отпадают)sumanai
29.01.2017 19:47Сказано красиво, только вот… приложение, в случае полноценного отключения/остановки, НЕ может работать, когда ему вздумается — оно начинает работать именно тогда, когда его запускают.
Не спорю. Но удобство ниже плинтуса.
Это уж вопрос к соотв. специалистам — для чего конкретно каждое из разрешений требуется.
Для сбора данных и про запас, как всегда. Реальной потребности в этом ворохе нет.
А вообще, если не нравится автообновление, то, в случае с Play Market'ом, оно отключается в пару кликов.
И приложение вывесит грустную табличку «Обновите, иначе работать не буду». И опять качать 30мб вместо 1,5 для сайта.
То, дальнейшие вопросы( в т.ч безопасности и источников приложений, которые «могут работать, когда им вздумается») отпадают)
Ну да конечно в маркете ни одного вируса, а на сайтах производителей ПО сплошные трояны.
DistortNeo
28.01.2017 16:35+4Представьте себе, в некоторых местах 3G/4G настолько ужасен, что диалап кажется раем, при EDGE вообще молчу. И это не глушь в Сибири, а обычные города-миллионники. Добавим тяжесть скриптов, и получаем, что сайт Т для меня при использовании мобильника полностью закрыт.
Жалкие 500Кб скриптов в упакованном виде позволили разработчикам просто поиграться с модными хипстерскими технологиями. Новый банк Т от старого, где скриптов было сильно меньше, отличается по функциональности совершенно ничем.
А "ущербные" компании типа Яндекса и Гугля предлагают пользователям для работы с почтой облегчённый HTML интерфейс, и он очень удобен.
M_AJ
29.01.2017 08:24Современный вэб к сожалению вообще не юзабелен при плохой связи, причем тяжелые страницы это пол беды, если очень надо можно было бы и подождать, да вот только большая часть серверов сейчас дропает соединение секунд через 30. В итоге, когда нас телефоне включается EDGE это значит, что интернета фактически нет.
TheCreator
28.01.2017 19:42Неправда ваша, никакой корреляции между предоставляемыми услугами и качеством разработки фронтенда нет, новая версия ТКС-банка действительно ужасает своей монструозностью, разучились делать эффективно и красиво.
Maccimo
28.01.2017 20:40А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк
Пользователи с вами не согласны, почитайте комментарии.
reforms
28.01.2017 19:43Не рубите так с плеча, про идеальный сайт. Я вообще думаю, что бизнес во многом сейчас решает быть или не быть js на сайте. Про интернет банкинг, могу сказать, что без js вообще нельзя — есть и логика защиты процеса работы с данными и шифрование и трюки-крюки простите за слег.
Aries_ua
29.01.2017 10:26А зачем мне ставить на ноуты джава машину, что бы запустить клиент банк? А потом еще следить за версиями, потому что в один прекрасный момент клиент банк перестает запускаться. А как быть с клиент банком, который написан под Windows? Все, мой любимы мак на свалку?
А если мне нужен клиентбанк на макбуке, или айпаде, или лептопе дочери (да да у нее линукс стоит). Мне на этот зоопарк как поставить клиент банки? А если у меня счета в нескольких банках, а я с семьей поехал отдохнуть и допустим с собой только айпад и деньги нужно перекинуть со счета на карту? Что делать то?
То, что банки сделали клиент банки в браузере, это не просто плюс, это просто огромный плюсище и респект им!
PS Юзаю клиент банки приват и райфайзен банков. Удобно и юзабельно.
PSS согласен только с одним. К разработке надо подходить с умом. Не надо из танка по воробьям.
blutovi
28.01.2017 14:15+1Мне, почему-то сразу, вспомнилась история о том, как программисты разных уровней реализовали пример hello word. Программист начального уровня написал одну строчку, а гуру — шесть экранных страниц текста.
Вывод: каждый будет пользоваться тем, что ему удобно.
Oxidant
28.01.2017 15:34+1Прям вспомнился язык Hex, который компилируется в 18 ( или сколько там) языков, простое хеллоу ворлд оно превратило в 18 классов.
Тем не менее по статье, интересный подход, вряд ли буду использовать, но симпотично.
SelenIT3
28.01.2017 19:00+1CSS сам по себе практически не умеет в состояния. Но мастерски умеет придавать визуальное великолепие состояниям того, у чего они есть:). Соответственно, для ховеров/фокусов форм, например, CSS идеален, и делать это через JS-обработчики — изврат. А для переключения произвольных панелей, наоборот, изврат — пихать в разметку левые инпуты чисто для привязки стилей. Всё имхо:)
Ares_ekb
29.01.2017 06:25+1Для панелей, табов, диалоговых окон и т.п. есть селектор :target. Просто люди привыкли делать это на JavaScript и им даже в голову не приходит, что это совершенно просто и естественно делается средствами HTML и CSS.
Переход по ссылкам-якорям внутри страницы, ведь, абсурд делать на JavaScript через ручной скроллинг. Хотя, стоп, даже на этом сайте навигация по новым комментариям именно так и сделана.SelenIT3
29.01.2017 09:19+2Мне кажется, вы путаете посылку с выводом. Из того, что поведение перехода по ссылке-якорю иногда можно (и даже нужно) визуально представить как переключение таба или открытие диалога, не следует, что любое переключение табов/открытие диалогов нужно (и можно) реализовывать через ссылки-якоря. Простейший контрпример из соседней ветки комментариев — две панели табов на странице. Так что надо знать оба способа и не видеть во всем гвозди просто потому, что освоили один молоток).
Ну и по поводу того же скроллинга между якорями не надо забывать, что плавный скроллинг выглядит естественнее резкого, а нативный scroll-behavior появился не так давно и по-прежнему не работает в Safari (т.е. на славящейся своей плавностью платформе, для которой резкие перескоки особенно чужеродны). Так что технически, да, вроде бы абсурд — но комфорт пользователя превыше пуризма разработчика.
LifeKILLED
28.01.2017 19:32Меню и анимашки на CSS3 работают плавнее, чем реализованные через JavaScript. В этом главное достоинство CSS3. В остальном часто легче использовать JavaScript, т.к. в CSS3 на данным момент слишком уж много получается запутанного текста.
DarthWazer
28.01.2017 19:44А зачем обходиться без JavaScript? Он с каждым годом все лучше и лучше.
khanid
29.01.2017 00:11+1Проблема не в самом JS как таковом, а в том, как его теперь используют в силу своего широкого распространения. По делу и без. Прямо как было с php. Имхо, пост об этом.
Когда мне (случай из практики) звонят и говорят «Эй, %админнэйм%, мне кажется, что у нас с каналом что-то не то. Или с сервером. Главная сайта медленно грузится, посмотри, а.», а я через ff вижу 4,5 Мб только одних скриптов, грузящихся до конца за 47 секунд, то я не злюсь (мне-то всего открыть браузер и в ответ позвонить), но мне по настоящему жалко пользователя, которому выпала участь открывать такую страницу.
Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.DistortNeo
29.01.2017 02:18+1Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.
Зато не велосипед! И скопировать только одну функцию тоже нельзя — а вдруг библиотека обновится?
И написать код в 10 раз меньше тоже нельзя — это же дополнительные расходы на веб-программистов.Ares_ekb
29.01.2017 06:29А чем большинство JavaScript-фреймвоков не велосипеды, которые загнутся через год-два? Нормальные фреймвоки обычно разбиты на модули.
ankh1989
29.01.2017 03:11А это от того, что в вебе нет аналога npm — репозитория всех этих либ. Поэтому каждый сайт вынужден тащить с собой копию всего: начиная от сортировки пузырьком и заканчиваю менюшками.
Hacksli
28.01.2017 19:44А че прикольно, для простейших задач. Но правда в наше время простейшие наверное никому не нужны. Это для любителей не использовать сторонние библиотеки.
sergiobelya
28.01.2017 19:44Интересный подход, заставил задуматься, но использовать на практике, думаю, не стоит.
работа в браузерах с выключенным JavaScript (если в наше время кто-то таким пользуется)
В скобках вообще ключевой момент, согласен.
В современных браузерах (по крайней мере в Chrome и Firefox) даже выключить нельзя никак js.
Насчёт злоупотреблений — да, можно согласиться (видал, когда ради одной единственной функции на 3 строчки подключают тяжеленную библиотеку, особенно когда это в моб. версии).
Но в данном случае вышло злоупотребление HTML и CSS. Как минимум нарушена семантика (используются элементы форм, а форм нету). Хотя сам подход, повторюсь, интересен (в академических смысле), я и не думал, что так можно.
Насчёт фото и background затея не очень — возможно проседание по СЕО. Я не сеошник и может меня поправят, по крайней мере это логично, в img можно (нужно) alt прописать, напр., да и не только поэтому, опять же семантика.
lipton_ice_tea
28.01.2017 19:541. validator.w3.org на чекбоксы без форм не ругается.
2. Интересно, что на сайте apple.com раскрытие меню в мобильной версии происходит тоже с помощью checkbox, label и css-стилей.SelenIT3
28.01.2017 20:08+2validator.w3.org — не показатель. Это не больше чем проверка орфографии в ворде. Если во фразе ни одно слово не подчёркнуто красным, это ещё не значит, что в ней есть смысл.
Инпуты без формы могут иметь смысл, для чисто клиентской логики (напр. выбора условия для асинхронной подгрузки добавочного чего-то тем же JS). Но грань между осмысленным употреблением и злоупотреблением очень тонка :)
sergiobelya
28.01.2017 20:55Валидатор и не должен ругаться. Может вы аяксом значения инпутов отправляете.
Но другой пример. Многие любят в тег p пихать то, что абзацем не является, чисто для упрощения вёрстки (чтобы class не писать). Это нарушение семантики или нет?
В html она и так не слишком богатая… html5 правда пытается это исправить...
Да, конечно интересно. И я в целом за то, что часть логики (отвечающей по сути за отображение), которая раньше была возможна лишь в js, переносится в html и сss: placeholder, transition и прочее. Я лишь против нарушения той минимальной, но семантики, что есть в html.
lipton_ice_tea
31.01.2017 09:11По поводу чекбоксов без форм: как вариант, можно создать форму, и привязать к ней все чекбоксы через атрибут form (html5).
sumanai
28.01.2017 20:26+1В современных браузерах (по крайней мере в Chrome и Firefox) даже выключить нельзя никак js.
Куча способов, хоть через дополнение, хоть через about:config, хоть через инструменты разработчика. Это я про Firefox.sergiobelya
28.01.2017 21:00+1Спасибо. Буду знать. Файрвоксом почти не пользуюсь, просто как-то искал ради интереса галочку в настройках — не нашёл.
Насчёт моего "нельзя никак" Вы правы, погорячился ))
Ares_ekb
29.01.2017 06:31Это элементарно делается через селектор :target без всякого нарушения семантики элементов.
sergiobelya
29.01.2017 15:32Примерно это я и имел ввиду, да.
Если меню и табы можно реализовать на чистом css, я как бы за (это же визуальное оформление).
Но не нарушать семантику. Так что поддерживаю.
Хотя лично я в тех же табах люблю урл без якорей (используя HTML5 History API). Правда без js тут уже не обойтись.
Но как рабочий вариант и без нарушения семантики :target мне кажется интересным. Нужно будет как-нибудь попробовать на досуге.
mSnus
28.01.2017 19:44Великолепная демонстрация, спасибо. Имеющимися инструментами надо уметь пользоваться!
poznawatel
28.01.2017 19:44-2У меня Огнелис с отключенными скриптами — ни один из примеров не работает.
tehSLy
28.01.2017 19:49Ну как фан задача, или там скиллы потренить сойдет. Использовать в релизном проекте я бы не стал
kholmukhamedovme
28.01.2017 19:49+1Один из плюс таких реализаций — это работа в браузерах с выключенным JavaScript
Был клиент, который говорил: «Оно не работает, когда я отключаю поддержку JS». Видимо начитался в интернетах всяких статей «Как проверить качество работы верстальщика». Достаточно показать статистику из Яндекс.Метрики, где почти всегда 99% пользователей сидят с включенным JS и только 1% — неизвестно.
zolt85
28.01.2017 19:49-1Круто, чо.
Я вот не понимаю споров о том, что все надо делать на JS, или не делать на JS. Делайте как хотите, браузеры Вам это позволяют. Здесь лишь пример того, как то же самое можно сделать по другому.
artygrand
28.01.2017 19:50Это конечно прикольно, но не семантично
Стоит ли этот функционал лишних тегов и инпутов?
PsyHaSTe
28.01.2017 20:55Все прекрасно, только по-моему вероятнее встретить пользователя без CSS3, нежели без JS'а. Поэтому в то время, как Babel позволяет транспилить и поддерживать хоть IE6 (прости господи), то для CSS'а я такого не знаю (CSS Next в CSS3 разве что). Когда речь идет о какой-нибудь анимации, то хрен бы с ней, пусть мгновенно без красивого перелистывания таб откроется, но когда основной функционал не работает (модальные окна не открываются, табы не переключаются и т.п.) то это финиш.
v-derckach
31.01.2017 22:36+1Да? Ну, вы, наверное, правы, у расширения NoScript всего каких-то 2.2 миллиона пользователей, а сколько у YesScript и прочих — вообще не считаем. Это, конечно же, гораздо меньше, чем количество пользователей IE6.
PsyHaSTe
01.02.2017 01:43в мире больше трех миллиардов пользователей интернета, доля неподдерживающих браузеров согласно caniuse составляет 5%, и 5% от 3 млрд все же поболее будет, чем 2 миллиона. Так что да, гораздо меньше.
Alex_T666
29.01.2017 15:09Интересно, но только в плане изучения CSS, а не как полноценная замена реализаций на JS. Впрочем, как сниппеты пригодится, спасибо!
P.S. Лет… цать назад, за присутствие JS на сайте «бил по рукам». Аргументы мои звучали примерно так «иди изучай HTML и CSS». 99 процентов случаев его лепили там, где он на самом деле не был нужен. Был уверен, что JS так всю жизнь и останется «маленьким помощником Санты» и в общем то ни для чего серьезного применяться никогда не будет, а все что необходимо будет сидеть в сетевых десктопных приложениях.
Прошло некоторое время. Думаю — ну ладно, чувствуется и в вебе будет интерактив дай бог каждому, но вполне очевидно, что все это будет тоже в приложениях, только в браузерных, на флеше или апплетах.
«Скоро ничего не будет,ни театра, ни кино, ни HTML, ни CSS сплошной флешь.» А JS? Не смешите меня!
Не угадал.
i360u
30.01.2017 06:06Состояние приложения, если таковое имеется, должно контролироваться в JS, а отображение этого состояния, по возможности, в CSS. Они прекрасно дополняют друг-друга и позволяют многое упростить (и даже ОЧЕНЬ упростить) при совместном использовании. Не вижу смысла отказываться от чего-то одного в пользу чего-то другого.
Loki3000
30.01.2017 11:52Ну вот, боролись-боролись за семантику и на тебе. Не, идея отличная но, как-то неправильно это… Какой-то возврат к каменным топорам.
pepelsbey
31.01.2017 21:05+1Поздравляю, вы только что переписали You Might Not Need JavaScript, причём переписали хуже. Сразу после его публикации поднялась дискуссия о том, стоит ли что-то писать на чистом CSS только потому, что можно. Чаще всего таки натужные решения недоступнее, неудобнее и хрупче аналогичных на JavaScript.
lipton_ice_tea
31.01.2017 23:34Примеры с этого сайта (слайдер, аккордеон) жестко привязаны к css и наименованию id…
Уберите элемент с #slide-4 в слайдере — и он будет изначально с пустым фоном.
Добавьте в аккордеон более 4х элементов, или просто с другими id — и она перестанет работать.
И надо лезть в css, что бы подстраиваться под id и кол-во элементов!
В моих же примерах лезть в css при изменении количества элементов на странице не надо! Добавьте Вы хоть 20 слайдов с любыми id — все будет работать! 1 раз настроил и все;)
Krasnodar_etc
31.01.2017 22:31Я смотрю, холивар нешуточный
Статей подобных я видел много, как и всяких видеоуроков на данную тему. Анимации на CSS должны быть уместны. Например, слайдер без переключений по свайпу чаще всего делать не стоит. А вот табы и аккордеон возьму на заметку. JS уменьшается, кому-то на мобильных мы экономим трафик
Да и на сайтах-визитках всяких если что-то случится с js-файлом… Например, полу-юзверь (не все же тру программисты) создатель сменил расположение, а пути не поменял. В таком случае сайт хоть немного можно будет покрутить и посмотреть. Например. А на повсеместное использование эти методы и не претендуют
green_tree
01.02.2017 09:05я ожидал прочитать «а давайте делать сайты так, чтобы основной функционал работал и без js»…
Akuma
В каждой такой статье задаюсь вопросом: а зачем лепить функционал в CSS?
1. Ленивую загрузку, например, без JS вы не сделаете.
2. Аналогично. Шаг в сторону и прийдется вешать JS.
3. Как вы его вызовете из другого места? Ленивая загрузка опять же?
4. Свайп от левого края на CSS не отработаешь.
5-6. Снова шаг в сторону и каюк каруселям.
Все эти крутые штуки типа морды лица Гомера создаются просто по приколу. В остальных случаях JS выпоняет свою задачу на отлично, если конечно уметь им пользоваться.
Если сайту нужно свайп-меню, галерейка и модальные окна, на 99% можно быть уверенным, что для других серьезных задач понадобится JS. Тогда зачем городить этот огрод в неполоденном месте? :)
DistortNeo
Впрочем, меню, реализованные на JS, меня совершенно не беспокоят: если страница адекватна и внушает доверие, то я просто включаю скрипты. Непрятности доставляют только сайты, которые вообще не рендерят контент без включения скриптов (при этом поисковикам отдают нормальные версии страницы).
Prototik
Не факт, сейчас многие поисковики выполняют JS, чтобы получить актуальную версию страницы.
AFakeman
Поисковики вроде теперь умеют в js, разве нет?
altai2013
Сценариев много, навскидку: описание товаров на Ebay и других онлайн-аукционах. Ebay уже объявил, что в этом году будет блокировать JS, разрешая только HTML и CSS для страниц описания товаров.
Akuma
Я как раз про это и говорю — CSS должно отвечать за визуализацию, а JS за функционал. У Ебея как раз все впорядке с таким подходом.
altai2013
Разного рода меню, табы, слайдеры и карусели очень активно используются в описаниях товаров на Ebay. Теперь их придется реализовывать без JS.
DarthVictor
Как минимум реализация табов на CSS проще чем на JS. Она не зависит от используемого JS-фреймворка/библиотеки одинаково хорошо работает как с серверным рендером так и с клиентским. Она не требует обертки директивой или компонентом под Angular или React, в отличие от jQuery плагинов. Эта реализация работает во всех браузерах уже лет 5 как, пережила jQuery, Prototype, Backbone и первый Angular. И у меня нет причин полагать, что не переживёт React и второй Angular.
Bellicus
Мир клином на jQuery, Prototype, Backbone и прочих не сошелся, реализуйте табы на нативном js (помните еще о таком?). И будет и во всех браузерах работать, и к фреймворкам не привязано, и счастье в семье.
lipton_ice_tea
Это просто примеры реализации, причем не требующие никаких больших трудозатрат во внедрении на сайт.
По поводу свайпов и тач событий — да, на css это не обработаешь.
"Шаг в сторону" — можно сказать про многое. В том числе и про js: другой скрипт может тормозить загрузку ваших скриптов; jquery обновилась, и каруселька сломалась и тд. (это чисто примеры).
Приведенные в статье варианты реализации можно использовать для каких-то конкретных случаев (хотя меню и модальное окно я использую и на рабочих проектах).
Модальное окно можно вызвать из любого места на странице. В описании к примеру написано, как это сделать.
craft37
1. 2. Когда нужно будет — повесить js на элемент будет не сложно.
3. Точно также как и функционал с js. Или тот уже html разметки не требует?
4.5. Бессмысленные аргументы. Там где нужен js — там пусть будет js, никто с этим не спорит.
Вводя в оборот понятие «Огород», почему вы имеете под ним ввиду именно css а не js?
Akuma
Потому что прополку граблями не делают. Можно конечно, но зачем?
Так и функционал на CSS неделают. Тоже можно, но зачем?
CSS отвечает за отображение контента, в который относительно недавно добавили анимации. Но это по прежнему всего лишь внешний вид.
Автор же пытается переделать на CSS то, что должен делать и прекрасно делает JS.
С таким же успехом можно аякс-отправку заказов сделать на CSS: input:checked + img {display:block;}
А в ссылке картинки указать скрипт на заказ. И в картинке отдавать текст «Заказ принят».
Работать будет, т.к. изначательно картинки с display:none не загружаются.
И вроде все хорошо, но нафига? Примеры автора просто слишком примитивны, но в реальном применении такое не прокатит.
crwin
Немного не верно. Следует уточнить, что они загружаются, если представлены в виде img, но не загружаются если установлены через background.
Akuma
Хм, ну я не экспериментировал на современных браузерах, но точно помню, что пару лет назад именно img {display:none} не загружалось. Как минимум в Opera
Aingis
Фоновые тоже загружаются. Не загружаются фоновые изображения у дочерних элементов. (Впрочем, тут есть свобода браузерной интерпретации.)
MKMatriX
Например для даркнета, где пользователям предлагают отключать js.
Akuma
Я думаю мы говорим об обычном интернете :)