Comments 131
1. Ленивую загрузку, например, без JS вы не сделаете.
2. Аналогично. Шаг в сторону и прийдется вешать JS.
3. Как вы его вызовете из другого места? Ленивая загрузка опять же?
4. Свайп от левого края на CSS не отработаешь.
5-6. Снова шаг в сторону и каюк каруселям.
Все эти крутые штуки типа морды лица Гомера создаются просто по приколу. В остальных случаях JS выпоняет свою задачу на отлично, если конечно уметь им пользоваться.
Если сайту нужно свайп-меню, галерейка и модальные окна, на 99% можно быть уверенным, что для других серьезных задач понадобится JS. Тогда зачем городить этот огрод в неполоденном месте? :)
В каждой такой статье задаюсь вопросом: а зачем лепить функционал в CSS?
Затем, чтобы такие параноики, как я, могли пользоваться функционалом сайта без включения скриптов.
Впрочем, меню, реализованные на JS, меня совершенно не беспокоят: если страница адекватна и внушает доверие, то я просто включаю скрипты. Непрятности доставляют только сайты, которые вообще не рендерят контент без включения скриптов (при этом поисковикам отдают нормальные версии страницы).
Это просто примеры реализации, причем не требующие никаких больших трудозатрат во внедрении на сайт.
По поводу свайпов и тач событий — да, на css это не обработаешь.
"Шаг в сторону" — можно сказать про многое. В том числе и про js: другой скрипт может тормозить загрузку ваших скриптов; jquery обновилась, и каруселька сломалась и тд. (это чисто примеры).
Приведенные в статье варианты реализации можно использовать для каких-то конкретных случаев (хотя меню и модальное окно я использую и на рабочих проектах).
Модальное окно можно вызвать из любого места на странице. В описании к примеру написано, как это сделать.
3. Точно также как и функционал с js. Или тот уже html разметки не требует?
4.5. Бессмысленные аргументы. Там где нужен js — там пусть будет js, никто с этим не спорит.
Вводя в оборот понятие «Огород», почему вы имеете под ним ввиду именно css а не js?
Так и функционал на CSS неделают. Тоже можно, но зачем?
CSS отвечает за отображение контента, в который относительно недавно добавили анимации. Но это по прежнему всего лишь внешний вид.
Автор же пытается переделать на CSS то, что должен делать и прекрасно делает JS.
С таким же успехом можно аякс-отправку заказов сделать на CSS: input:checked + img {display:block;}
А в ссылке картинки указать скрипт на заказ. И в картинке отдавать текст «Заказ принят».
Работать будет, т.к. изначательно картинки с display:none не загружаются.
И вроде все хорошо, но нафига? Примеры автора просто слишком примитивны, но в реальном применении такое не прокатит.
Считаю это костылем. Стили в css, функционал и логика в js. Имхо, абсолютно все, что представлено в этой статье, должно быть сделано на js.
css отличается тем, что он декларативен. Ты указываешь, что хочешь получить, достаточно сложное уравнение и браузер его вычисляет и показывает. Это гораздо лучше чем терпеть javascript. К тому же можно просто скачать страницу и сохранить на локальный диск, без подгрузки тысяч библиотек с внешних ресурсов.
CSS тоже полный по Тьюрингу.
Это по сути не язык программирования… Как он может быть полным по Тьюрингу?
Да на brainfuck тоже можно писать, только толку?
Да, бесчисленные демки Гомеров Симпсонов и прочих троллейбусов из хлеба «на чистом CSS» приучили нас считать горы несемантичных тегов их неотъемлемой частью, но по-моему это неправильно. А без разметки на голом CSS мало что можно сделать (хотя кое-что всё-таки можно:)
Беда в том, что если вы пишете что-то сложнее форума — это такой невозбранный объем адского гемороя, что вы либо получите неподдерживаемый гроб, либо не получите продукт вообще
Писать все без JS имеет смысл в двух случаях: нечем заняться и это что-то чрезвычайно нишевое и специфическое, требующее сверхъестественной стабильности и совместимости
В остальных случаях — инструмент под задачу
Ага, чтобы программисты видели кучу сложночитаемого и сложноподдержимоего кода. Слайдеры на CSS — не читаемый код.
Кстати, отличное задание для сосискателей :-)
Наверное было бы интересно, если бы вы сделали всё то же самое, но через :target. Единственная проблема это что при закрытии диалогового окна вы переходите по адресу # и перескакиваете в начало страницы. Тут приходится уже использоваться JavaScript:
document.getElementById('close-button').addEventListener('click', function (e) {
e.preventDefault(); history.go(-1); });
Ага. А что если я открыл ссылку с #dialog в новой вкладке браузера? Оно же не закроется. Или в другой уже открытой? Вместо решения задачи начинаются танцы с бубном, как же мне закрыть окно, сохранив текущую страницу и позицию скролла. Причем на том же JavaScript.
Таких вопросов много. Как сделать первую вкладку в табах по умолчанию открытой? И самый главный вопрос — как сделать 2 элемента с табами на одной странице?
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?
В этом случае просто ничего не делаем:
Тогда '#' остается.
Чтобы первая вкладка таба была по умолчанию открытой, у неё адрес должен быть просто #.
Пробую пример отсюда, не работает.
Два элемента с табами — это из той же области, что два фрейма на странице. Очень старая проблема: адрес один, а страницы две. К какой из них относится адрес? Эта проблема более глубокая, чем JavaScript vs HTML+CSS.
Это одна страница, фреймы здесь ни при чем. В бизнес-приложениях часто встречается вариант, когда в форме редактирования объекта поля разделены на вкладки, а внизу еще вкладки с информацией, связанной с объектом в целом — комменты, лог изменений и т.д. Или другой вариант, когда есть табы и модальное окно. Весело будет, если при открытии окна пол-странцы в фоне исчезнет.
Как средствами JavaScript открыть сразу нужную вкладку таба, если стоит такая задача? Это можно сделать только с помощью якорных ссылок
Можно через якорь, можно через GET-параметр, можно через local storage или cookies, если надо запоминать. Отличие в том, что это не будет влиять на отображение остальных элементов. А через split можно и несколько табов обрабатывать.
Якорь это глобальное состояние, и создает все связанные с ним проблемы. Поэтому его влияние лучше минимизировать.
Скажем, галерея картинок. Если ссылка на каждую картинку делается через якорь, то это очень удобно. Можно сохранить ссылку и открыть сразу нужную картинку. В этом случае глобальное состояние это плюс. И альтернатив я тут не вижу.
Да, насчет вкладки по умолчанию вы правы, тут всё несколько сложнее, но есть решение через комбинатор селекторов ~. Вот, пример. Я не призываю отказываться от JavaScript, если что, я библиотеку для теории категорий на нём пишу :) Но и про селектор :target знать не лишне и использовать его иногда, явно штука не бесполезная.
Всё это привело к тому, что для работы какого-нибудь интернет-банка (например, на букву Т), требуется выкачать 500 кБайт заgzipованных скриптов, хотя большую часть функционала можно реализовать вообще без скриптов.
А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк, заменяющий 5 часов поездок в банк на каждый чих.
Почему бы просто не сделать приложение, которое можно скачать. Например на джаве, как делали до этого.
И она таки лучше подходит для сложного GUI, чем html+css+js.
А если всем поставить джаву, то в следующий раз у всех уже будет джава.Ну сначала поставьте ее всем. Вы удивитесь насколько неохотно пользователь ставит то, что ему не нужно, чтобы заработало то, что и так уже в вебе работает.
И она таки лучше подходит для сложного GUI, чем html+css+js.Таки с чего вы взяли?
Не загадывая вдаль,
Так скажу: зачем мне java?
Я согласен на web-app.
Повторюсь: зачем еще следить за новой сущностью — jvm, если
В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.
В чем-то десктопные GUI действительно лучше, но в среднем (для клиент-банка) они примерно равны с вебом.Ну так в чем же? Я вовсе не холиварю и прекрасно понимаю различия (а не то, что одно лучше другого). Просто со стороны эти заявления нелепо выглядят без аргументации.
То что одно лучше другого я как раз не утверждал. Они по-своему специфичны, но в целом равны.
Возвращаясь к нашему вопросу, все вышеперечисленное к GUI имеет ровно никакого отношения, и, если сравнивать десктопную вертску (если такая имеется, как например в wpf или qt), то там ровно то же самое, только вот работа с темами корявая, ибо нет удобной декларативности css. Если верстка отсутствует (как саме знаете где), то тут я вообще не знаю, насколько уместны все эти разговоры про преимущества платформы (сами знаете какой).
И вы почему-то думаете, что этот браузер — мозилла или хромиум. К сожалению, после того как и тот и другой подло внесли в свою дистрибуцию бинарные программы (chromium — какую-то хрень для аудио, а firefox — DRM), у меня нет ни того, ни другого. Хрен с два ваша замечательная программа, написанные под четыре браузера (хром, файерфокс, эдж или сафари) будет работать у меня. А JVM — унифицирован.
А теперь посчитайте: у какого процента пользователей есть JVM, а у какого процента пользователей — обычный браузер.
Бинарники, запускаемые в JVM, вас значит не смущают?
Не, я говорю про байткод, который он выполняет. Он же тоже бинарный. Вдруг в одной из программ есть какая-нибудь хрень для аудио?
А весь остальной используемый софт я собираю сам.
А почему бы тогда браузеры в специальной виртуальной машине не запускать?
(Это из разряда «Мне пожалуйста свиной стейк. Только он веганский? Потому что я веган. Я не ем мясо. И вы не ешьте. Но мне нужен стейк. Из свиньи. Но чтоб веганский.»)
А баш и не надо в виртуалку засовывать. И виртуалок много не надо. Для обычных сайтов используете свой браузер, собранный из исходников. Для особых, наподобие клиент-банков, отдельная виртуалка с последней версией популярного браузера. Зашли в банк, сделали необходимые операции, вышли, сбросили виртуалку на последний снимок. Работать будет для любого веб-приложения. А бинарники да, придется каждый на свою виртуалку ставить.
UI главной Хабра за сколько времени сделаете?)
А делается оно для обычных пользователей, для которых это сложно.
А зачем делать еще одно нативное приложение для разных платформ, которое нужно юзерам устанавливать, ради которого нужно нанимать несколько новых программистов ради мобильных платформ, если можно просто сделать РЕАЛЬНО кроссплатформу через веб, до которой будет проще добраться (запустить сайт значительно проще)?
P.S.: Электрон — зло, конечно, имхо, там все в принципе можно и в браузере запустить (и запускают, веб-версия скайпа есть и используется мной, если мне вдруг нужно в 2017 скайп запустить)
Поэтому админ должен сидеть с прерывистого 3G. Ну или лучше не сидеть, и не админ, а отдел тестирования должен тестировать такой кейс, как заход с мобильного из зоны с плохим покрытием сети.
А можно уехать куда-то в тундру или тестировать с отключенным интернетом. Где грани разумного?
Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство (теория «диктатуры меньшинства»).
Возможно, действительно, можно было оставить неудобный и обрезанный кабинет для некоторых индивидов. Но скорее всего, банки плевать хотели на тот процент медленных клиентов из-за которых бы пришлось раздувать отдел ИТ.
Почему сейчас все интернет-магазины гоняются за долями секунд в выдачи контента? Ответ простой — высокая конкуренция. А т.к. товар, цены, условия очень похожи, то есть профит в ускорении сайта. Что самое интересное — далеко не у всех ИМ получается сделать быстрый и удобный сайт.
А что же с банками? Я ищу в первую очередь надежный банк, который не аухнет при первом скачке курса. Мне как-то все-равно, если клиент-банк будет грузиться минуту, вместо 1,52 секунды. Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится, больше интересна комиссия за перевод и процент по вкладу.
И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.
Нужно делать хорошо и удобно большинству, а не подстраиваться под меньшинство
Вот ведь парадокс, нужно делать хорошо и удобно большинству, но делают хорошо и удобно абсолютному меньшинству, а именно — фронтенд-разработчикам, которым проще ХХВП на каком-нибудь JS-фреймворке и владельцам бизнеса, которые наймут этих фронтендеров по копейке за пучок.
И да, лучше ждать 10 минут ответа от клиент-банка, сидя в кафе, чем 2 часа ругаться с бабуськами.
«Ругань с бабуськами» существует только в фантазиях людей, не бывавших в отделениях банков уже лет по десять.
«с бабуськами» — это образное собирательное выражение. Чтобы попасть в банк оффлайн надо как минимум надеть штаны. (Кстати, как раз вчера около часа бродил вокруг банка, т.к. «программисты всё сломали, ничего не работает»:)
Также не сильно беспокоит сколько будет запросов и сколько Мб загрузится
Вот в этом и проблема. Если это сайт с минимумом JS, то будет один клик — один запрос. Ответ не пришёл из-за проблем со связью — не беда, кликаем ещё раз и добиваемся результата.
Если же сайт нафарширован JS, то будет множество запросов. Если отказал хоть один из них — то пиши пропало, придётся загружать всё заново и начинать с нуля.
Для телефонов есть приложение, которое есть меньше траффика. Зачем запускать браузер, елси уже есть приложение?
Разве что древне-непопулярная платформа, тогда извините :)
Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.
@
Для всего остального, есть мобильное приложение.
Которое, по случаю чего, можно и отключать, когда оно не надо.
@
Нет, оно жрёт батарейку, требует много разрешений( будто бы оно банковское, в самом то деле!:) ) и… и вообще… хочу сайт… но… но не такой, который есть, а, как бы такой, но… но чтоб красивый и удобный, и… именно без JS и всё реализовывалось на CSS и под мобильный и… и чтоб мобильный его полностью поддерживал — ведь приведённый в статье( и подобных статьях, гуляющих по интернетам) ужас на CSS одинаково идеально и стабильно работает и отображается на всех устройствах и браузерах, даже старых, то ли дело, ненавистный JS и… да не просто под мобильный, а такой, для которого даже приложение тянуть — ощутимая нагрузка на батарею.
Ну разве не абсурд?)
Разрабатывается удобный веб-сайт для ПК и всего, для чего загрузить разово( к слову о кэшировании ) 500Кб — не проблема.
Конечно, не проблема. Проблема в том, что это уже не веб-сайт, а веб-приложение. Пользоваться веб-приложениями действительно удобно: страница грузится один раз, дальше скрипты делают мелкие запросы и выводят результат без перезагрузки страницы.
Главный жирный минус подобных веб-приложений — однооконность. Хотите открыть несколько писем gmail в разных окнах — пожалуйста, загрузите по экземляру в каждое окно, каждое из которых будет кушать больше 100 мегабайт. Хотите открыть второе окно Т-банка? А авторизоваться по-новой не хотите?
Собственно, можно сказать, что у Т больше нет мобильного сайта, есть только приложение: одно — программа для смартфона, второе — веб-приложение.
Это уж вопрос к соотв. специалистам — для чего конкретно каждое из разрешений требуется.
Вполне логично решит( что устарело ). Это и всевозможные обновления контента/услуг/функционала и безопасности, а не просто проггеры сидят, да думают, как бы ещё бедным пользователям насолить — «лишних» 30 мб их заставить качать, что ли).
А вообще, если не нравится автообновление, то, в случае с Play Market'ом, оно отключается в пару кликов. Посему, нет, оно не может просто так решить и начать качать, если на то нет согласия пользователя( хотя бы молчаливого, т.е дефолтного ).
Хотя, если даже акка в гуглплей нет… На андроиде… То, дальнейшие вопросы( в т.ч безопасности и источников приложений, которые «могут работать, когда им вздумается») отпадают)
Представьте себе, в некоторых местах 3G/4G настолько ужасен, что диалап кажется раем, при EDGE вообще молчу. И это не глушь в Сибири, а обычные города-миллионники. Добавим тяжесть скриптов, и получаем, что сайт Т для меня при использовании мобильника полностью закрыт.
Жалкие 500Кб скриптов в упакованном виде позволили разработчикам просто поиграться с модными хипстерскими технологиями. Новый банк Т от старого, где скриптов было сильно меньше, отличается по функциональности совершенно ничем.
А "ущербные" компании типа Яндекса и Гугля предлагают пользователям для работы с почтой облегчённый HTML интерфейс, и он очень удобен.
Современный вэб к сожалению вообще не юзабелен при плохой связи, причем тяжелые страницы это пол беды, если очень надо можно было бы и подождать, да вот только большая часть серверов сейчас дропает соединение секунд через 30. В итоге, когда нас телефоне включается EDGE это значит, что интернета фактически нет.
А жалкие 500Кб скриптов позволили сделать какой-то нормальный интернет-банк
Пользователи с вами не согласны, почитайте комментарии.
Не рубите так с плеча, про идеальный сайт. Я вообще думаю, что бизнес во многом сейчас решает быть или не быть js на сайте. Про интернет банкинг, могу сказать, что без js вообще нельзя — есть и логика защиты процеса работы с данными и шифрование и трюки-крюки простите за слег.
А если мне нужен клиентбанк на макбуке, или айпаде, или лептопе дочери (да да у нее линукс стоит). Мне на этот зоопарк как поставить клиент банки? А если у меня счета в нескольких банках, а я с семьей поехал отдохнуть и допустим с собой только айпад и деньги нужно перекинуть со счета на карту? Что делать то?
То, что банки сделали клиент банки в браузере, это не просто плюс, это просто огромный плюсище и респект им!
PS Юзаю клиент банки приват и райфайзен банков. Удобно и юзабельно.
PSS согласен только с одним. К разработке надо подходить с умом. Не надо из танка по воробьям.
Вывод: каждый будет пользоваться тем, что ему удобно.
Переход по ссылкам-якорям внутри страницы, ведь, абсурд делать на JavaScript через ручной скроллинг. Хотя, стоп, даже на этом сайте навигация по новым комментариям именно так и сделана.
Ну и по поводу того же скроллинга между якорями не надо забывать, что плавный скроллинг выглядит естественнее резкого, а нативный scroll-behavior появился не так давно и по-прежнему не работает в Safari (т.е. на славящейся своей плавностью платформе, для которой резкие перескоки особенно чужеродны). Так что технически, да, вроде бы абсурд — но комфорт пользователя превыше пуризма разработчика.
Когда мне (случай из практики) звонят и говорят «Эй, %админнэйм%, мне кажется, что у нас с каналом что-то не то. Или с сервером. Главная сайта медленно грузится, посмотри, а.», а я через ff вижу 4,5 Мб только одних скриптов, грузящихся до конца за 47 секунд, то я не злюсь (мне-то всего открыть браузер и в ответ позвонить), но мне по настоящему жалко пользователя, которому выпала участь открывать такую страницу.
Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.
Кстати, из 4,5 Мб один скрипт весил почти 800 Кб, а всего-то отвечал за меню-аккордеон. Т.е. всё ради одной функции. Остальное — бесполезный груз.
Зато не велосипед! И скопировать только одну функцию тоже нельзя — а вдруг библиотека обновится?
И написать код в 10 раз меньше тоже нельзя — это же дополнительные расходы на веб-программистов.
А это от того, что в вебе нет аналога npm — репозитория всех этих либ. Поэтому каждый сайт вынужден тащить с собой копию всего: начиная от сортировки пузырьком и заканчиваю менюшками.
А че прикольно, для простейших задач. Но правда в наше время простейшие наверное никому не нужны. Это для любителей не использовать сторонние библиотеки.
Интересный подход, заставил задуматься, но использовать на практике, думаю, не стоит.
работа в браузерах с выключенным JavaScript (если в наше время кто-то таким пользуется)
В скобках вообще ключевой момент, согласен.
В современных браузерах (по крайней мере в Chrome и Firefox) даже выключить нельзя никак js.
Насчёт злоупотреблений — да, можно согласиться (видал, когда ради одной единственной функции на 3 строчки подключают тяжеленную библиотеку, особенно когда это в моб. версии).
Но в данном случае вышло злоупотребление HTML и CSS. Как минимум нарушена семантика (используются элементы форм, а форм нету). Хотя сам подход, повторюсь, интересен (в академических смысле), я и не думал, что так можно.
Насчёт фото и background затея не очень — возможно проседание по СЕО. Я не сеошник и может меня поправят, по крайней мере это логично, в img можно (нужно) alt прописать, напр., да и не только поэтому, опять же семантика.
2. Интересно, что на сайте apple.com раскрытие меню в мобильной версии происходит тоже с помощью checkbox, label и css-стилей.
Инпуты без формы могут иметь смысл, для чисто клиентской логики (напр. выбора условия для асинхронной подгрузки добавочного чего-то тем же JS). Но грань между осмысленным употреблением и злоупотреблением очень тонка :)
Валидатор и не должен ругаться. Может вы аяксом значения инпутов отправляете.
Но другой пример. Многие любят в тег p пихать то, что абзацем не является, чисто для упрощения вёрстки (чтобы class не писать). Это нарушение семантики или нет?
В html она и так не слишком богатая… html5 правда пытается это исправить...
Да, конечно интересно. И я в целом за то, что часть логики (отвечающей по сути за отображение), которая раньше была возможна лишь в js, переносится в html и сss: placeholder, transition и прочее. Я лишь против нарушения той минимальной, но семантики, что есть в html.
Примерно это я и имел ввиду, да.
Если меню и табы можно реализовать на чистом css, я как бы за (это же визуальное оформление).
Но не нарушать семантику. Так что поддерживаю.
Хотя лично я в тех же табах люблю урл без якорей (используя HTML5 History API). Правда без js тут уже не обойтись.
Но как рабочий вариант и без нарушения семантики :target мне кажется интересным. Нужно будет как-нибудь попробовать на досуге.
Один из плюс таких реализаций — это работа в браузерах с выключенным JavaScript
Был клиент, который говорил: «Оно не работает, когда я отключаю поддержку JS». Видимо начитался в интернетах всяких статей «Как проверить качество работы верстальщика». Достаточно показать статистику из Яндекс.Метрики, где почти всегда 99% пользователей сидят с включенным JS и только 1% — неизвестно.
Я вот не понимаю споров о том, что все надо делать на JS, или не делать на JS. Делайте как хотите, браузеры Вам это позволяют. Здесь лишь пример того, как то же самое можно сделать по другому.
Стоит ли этот функционал лишних тегов и инпутов?
Все прекрасно, только по-моему вероятнее встретить пользователя без CSS3, нежели без JS'а. Поэтому в то время, как Babel позволяет транспилить и поддерживать хоть IE6 (прости господи), то для CSS'а я такого не знаю (CSS Next в CSS3 разве что). Когда речь идет о какой-нибудь анимации, то хрен бы с ней, пусть мгновенно без красивого перелистывания таб откроется, но когда основной функционал не работает (модальные окна не открываются, табы не переключаются и т.п.) то это финиш.
P.S. Лет… цать назад, за присутствие JS на сайте «бил по рукам». Аргументы мои звучали примерно так «иди изучай HTML и CSS». 99 процентов случаев его лепили там, где он на самом деле не был нужен. Был уверен, что JS так всю жизнь и останется «маленьким помощником Санты» и в общем то ни для чего серьезного применяться никогда не будет, а все что необходимо будет сидеть в сетевых десктопных приложениях.
Прошло некоторое время. Думаю — ну ладно, чувствуется и в вебе будет интерактив дай бог каждому, но вполне очевидно, что все это будет тоже в приложениях, только в браузерных, на флеше или апплетах.
«Скоро ничего не будет,
Не угадал.
Состояние приложения, если таковое имеется, должно контролироваться в JS, а отображение этого состояния, по возможности, в CSS. Они прекрасно дополняют друг-друга и позволяют многое упростить (и даже ОЧЕНЬ упростить) при совместном использовании. Не вижу смысла отказываться от чего-то одного в пользу чего-то другого.
Поздравляю, вы только что переписали You Might Not Need JavaScript, причём переписали хуже. Сразу после его публикации поднялась дискуссия о том, стоит ли что-то писать на чистом CSS только потому, что можно. Чаще всего таки натужные решения недоступнее, неудобнее и хрупче аналогичных на JavaScript.
Уберите элемент с #slide-4 в слайдере — и он будет изначально с пустым фоном.
Добавьте в аккордеон более 4х элементов, или просто с другими id — и она перестанет работать.
И надо лезть в css, что бы подстраиваться под id и кол-во элементов!
В моих же примерах лезть в css при изменении количества элементов на странице не надо! Добавьте Вы хоть 20 слайдов с любыми id — все будет работать! 1 раз настроил и все;)
Статей подобных я видел много, как и всяких видеоуроков на данную тему. Анимации на CSS должны быть уместны. Например, слайдер без переключений по свайпу чаще всего делать не стоит. А вот табы и аккордеон возьму на заметку. JS уменьшается, кому-то на мобильных мы экономим трафик
Да и на сайтах-визитках всяких если что-то случится с js-файлом… Например, полу-юзверь (не все же тру программисты) создатель сменил расположение, а пути не поменял. В таком случае сайт хоть немного можно будет покрутить и посмотреть. Например. А на повсеместное использование эти методы и не претендуют
А если без JavaScript?