Если говорить о POST/GET и href — то об этом уже писалось выше, и мной в том числе, что оставлять прямой url у ссылки и action у формы сами собой разумеющиеся вещи (для меня по крайней мере). Но в общем-то я понял к чему вы.
Опять таки, мы пришли к тому, с чего начинали. Все зависит от проекта.
С тестирование не совсем понял. Если мне нужно тестировать фронтенд, то какой мне толк от того, что у меня все работает без js (и оттестировано), если моя аудитория на 90% состоит из клиентов с js.
Я чего-то не так понял?
сложно представить себе типичного пользователя без js.
представьте функциональное авто-тестирование своим краулером (с behat например)
Мы сейчас об одних и тех же «типичных пользователях» говорим?
Ну с картинками — вопрос простой. Нет обработчика — переход по ссылке.
А вот, например, авторизация через соц. сети?
Вы не подумайте что я рву майку за обязательное наличие js. Я просто веду к тому, что тут вопрос довольно «интимный» и зависит как от заказчика так и от исполнителя и даже от аудитории сайта, как мне кажется. Просто в каждом случае нужно подходить индивидуально. Что, конечно же ни как не идет в разрез с общими правилами «хорошего тона» по типу нет js — переходим по ссылке и т.д. Это же очевидно, как по мне.
Да тут особо спорить не о чем. Это же все индивидуально от проекта к проекту, как мне кажется. Например — отправка формы в фоне: конечно у формы есть action и если js у пользователя не включен, то форма просто отправится «естественным образом». Но тут забота о пользователе проявляется постольку-поскольку. Как вы уже сказали: базовый функционал и так есть. Или к примеру карусель изображений ( типа jcarousel, JQuery Cycle и т.д.) изображения и так выводятся и если не включен js, то они будут показаны и можно даже облагородить их вывод.
А вот другой пример: fancybox. Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.
Прошу прощения если примеры вдруг показались вам наивными. Первое, что пришло в голову.
Возможно, сейчас я получу лучи добра и жесткий слив, но сейчас сложно представить себе типичного пользователя без js. Стоит ли тратить время на заботу о пользователе без js — вопрос сложный и зависит от многих факторов.
Плохо ли это? Да, пожалуй плохо. Забочусь ли я о таких пользователях постоянно (т.е. от проекта к проекту)? Ответ — нет.
Интересный подход с подстановкой картинок-заглушек. Сам когда-то сталкивался с подобной проблемой и писал велосипед, но о заглушках не подумал.
Поддерживаю MechanisM и жду код на github )
У меня Sublime Text 2 (Linux Mint) грузит процессор до 100% через 10-20 минут работы. Когда поставил — радости небыло предела, на столько понравился. А теперь вот гуглю эту проблему.
БЭМ — это всего навсего подход, методология. И довольно удачная. Она не делает что-то монстроообразное, от чего ее можно было б не рекомендовать в зависимости от размера сайта и количества страниц отданных на верстку. Уж по крайней мере, определенные элементы этой методики стоило б использовать. Это мое мнение.
Да, понял о чем вы. С точки зрения верстки вариант с необорачиванием в label всяко лучше. А по поводу уникальности id, но это ведь не единственный случай, где необходим id у элемента? И до этого как-то справлялись.
А по поводу глюков, то совпадение id — одно из первых что может прийти в голову в случае неверной работы.
Но, опять таки, ситуации бывают разные, так что… что тут спорить.
Я понял основную идею и в общем-то с ней согласен.
Как по мне и простой имя_поля_. _счетчик_ должно подойти. Имя поле само по себе уникально, а счетчик спасет в случае с radiobutton, где имя поля может быть одинаковым. Да, конечно, есть еще варианты _имя_поля_[] Но и тут что-то можно придумать. В общем, на мой взгляд, мы высасываем проблему из пальца.
Не могу сейчас сходу ответить, к сожалению. Я с XSLT не работал плотно. Но, если можно вывести имя (изменяющееся) input-a или передать любую переменную, то в чем проблема?
Опять таки, мы пришли к тому, с чего начинали. Все зависит от проекта.
Я чего-то не так понял?
Мы сейчас об одних и тех же «типичных пользователях» говорим?
Если я не ошибаюсь, то мы говорим о дополнительных затратах:
И это как раз случай дополнительных трудозатрат. Не так ли?
Паршиво :)
А вот, например, авторизация через соц. сети?
Вы не подумайте что я рву майку за обязательное наличие js. Я просто веду к тому, что тут вопрос довольно «интимный» и зависит как от заказчика так и от исполнителя и даже от аудитории сайта, как мне кажется. Просто в каждом случае нужно подходить индивидуально. Что, конечно же ни как не идет в разрез с общими правилами «хорошего тона» по типу нет js — переходим по ссылке и т.д. Это же очевидно, как по мне.
А вот другой пример: fancybox. Нужно по клику куда-либо показать окошко с информацией. И нет js. Как быть? Очевидного решения я не вижу, такого что б совсем без затрат времени.
Прошу прощения если примеры вдруг показались вам наивными. Первое, что пришло в голову.
Плохо ли это? Да, пожалуй плохо. Забочусь ли я о таких пользователях постоянно (т.е. от проекта к проекту)? Ответ — нет.
Поддерживаю MechanisM и жду код на github )
Подключение из CDN меня не устраивает скорее по «религиозным» соображениям. А переубедить себя пока не могу.
Ну вот хотя бы здесь…
А вы говорите о размере сайта. Ну да ладно, а то мы одно и тоже по несколько кругов обсуждаем )
А по поводу глюков, то совпадение id — одно из первых что может прийти в голову в случае неверной работы.
Но, опять таки, ситуации бывают разные, так что… что тут спорить.
Я понял основную идею и в общем-то с ней согласен.
Вот тут как раз и префиксы были б довольно полезными:
и уже не запутаетесь