Ну странный браузер (хром) и маловероятность функций (clone и contains) не отменяют факт. Мне просто интересно, почему они эти функции не сделали быстрее, ведь элементарно же было сделать хотя-бы не_медленнее. По факту эти функции действительно редкость.
Тем не менее остается ряд вопросов.
Во-первых, как выводить форму с зависимыми полями на чистом HTML, — это вытекает в неоднозначность решения. В некоторых случаях, когда это приведет к n-страничной форме, это вызовет батхерт на серверной стороне.
Во-вторых, формировать на сервере отвалидированную форму с ошибками напротив полей не всегда настолько простая задача, как возврат JSON'а типа field_name : invalid_status. Помножьте это на n страниц формы.
В-третьих, хитроумной валидации в некоторых случаях можно избежать. Пример: на сервере используется стандартное решение, а на клиенте вдруг захотелось принимать в поле «представьтесь» не просто какое-то одно слово, а три, типа фамилию, имя и отчество. Такая инвалидность не критична для данных, но валидацией на клиенте это решается элементарно. Т. е. оператору раз в месяц исправить неполное поле от клиента без JS обойдется дешевле, чем оплачивать специалисту время на написание своего валидатора для какого-то стандартного решения.
Не всегда это значит PE. Как можно лучше — значит доставляет больше профита пользователю/владельцу. Если за поддержку ~1% пользователей на IE6, Opera Mini или с отключенным JS приходится увеличивать объем работ на 10-20% и оплачивать часы специалистам при ограниченном бюджете, то лучше — вероятно, отказаться от PE.
GD гораздо естественнее выглядит с точки зрения процесса разработки: мы первым усилием покрываем основных пользователей, а только затем уже заботимся о маргиналиях.
1. +1 задача на серверного программиста [и множество бессмысленных URL]
И все-таки предлагаете на сервере определять наличие JS на клиенте и выводить либо пагинированные картинки, либо полную версию?
2. Примеры:
— Разный формат записи адреса в зависимости от выбранной страны;
— Разный вид реквизитов в зависимости от выбранного вида собственности (юр/физ лицо)
— Обычная специализация по дереву категорий (Общество > Развлечения > Праздники > Новый год)
— Выбор файла в дереве
Это все решаемо так или иначе, но трудозатраты очевидны, — а целесообразны ли?
А как вы реализуете отложенную загрузку картинок без JS?
Будете выводить картинки сотнями на каждый запрос? Или будете на сервере проверять юзер-агента каким-то образом?
Как вы реализуете форму, в которой одни поля зависят от значений в других?
Будете выводить совершенно все поля и хитроумно валидировать на сервере?
Вы видите, насколько возрастают трудозатраты на серверный код? Вы сравнивали трудозатраты на прямую CSS3 верстку с JS в сравнении с Progressive Enhancement? Они адекватно соотносятся с числом пользователей без JS и на старых броузерах?
Если вы делаете сайты из любви к веб-технологиям — PE безусловно хорош. Но если вы оцените его эффективность с точки зрения UX и экономически — этот подход родственен перфекционизму. Часто это значит, что вы просто не знаете пользователя, для которого делаете сайт.
Оу, понятно. Видимо стоило тогда глаз поместить рядом с заголовком или как -то отдельно оформить в виде filded code. Сейчас в блоке метаинформации совсем не понятно, что если кликнуть на глаз — откроется код.
Этот код может быть свернут, но он не дожен быть на другой странице. Мне заголовки ничто не говорят, это — субъективная точка зрения автора на его код, в то время как код скажет все.
Это надо для того, чтобы не плодить бессмысленные мета-сущности типа названий и описаний, а использовать распространенные практики документирования кода, типа javadoc. В сто раз удобнее писать док к коду прямо в коде, а не где-то на другой планете.
Отлично. Рад за ваш проект, надеюсь он получит поддержку и развитие. Сам планировал писать в точности такой же.
Хотелось бы, чтобы у вас появилось какое-то API и более удобный интерфейс.
Критика по пунктам.
— Сейчас категории видны в только подвале, хотя это один из важных элементов поиска сниппетов, который стоило бы оформить тегами в боковой колонке.
— Необходимы ключевые слова на сниппет и динамический поиск, к примеру, искать отключение выделения user-select можно как по запросу «select», так и по запросу «выделение», но сделать это быстро и удобно через ваш поиск совершенно невозможно.
— Третье, самое важное — размещайте код сниппета прямо в блоке с заголовком. Очень неудобно переходить на страницу сниппета ради какого-то мелочного куска кода. Заголовок сниппета вообще почти никогда ни о чем не говорит, а вот код можно почти всегда сразу узнать. В идеале, конечно, вообще отказаться от заголовков и оперировать прокомментированными кусками кода, как это сделано к примеру в Backbone annotated source. Заголовок и описание сниппета в отрыве от кода — самая бессмысленная и досадная вещь.
Метод _delay в виджетах особенно радует — всегда сам дописывал этот костыль. Чего еще не хватает виджетам — это системы нотации событий, как это есть у Backbone.View. Все приходится ручками привязывать.
Читал в предвкушении что вот-вот появится Mnesia. Не появилась,- опечалило. Это nosql старушка старше чуть ли не всех других, а вы её даже не упомянули :)
Так подумать — эта игра определила значительную часть моих вкусов и пристрастий в играх. Всегда искал еще игр, похожих на него. Но, к сожалению (к счастью) он такой один.
В CSS нет тегов, там свойства :)
Перепечатать закладки в хроме теперь предмет для статьи?
Но если полноценная замена, говорите, то можно попробовать. Во всяком случае, плюшки радуют.
Во-первых, как выводить форму с зависимыми полями на чистом HTML, — это вытекает в неоднозначность решения. В некоторых случаях, когда это приведет к n-страничной форме, это вызовет батхерт на серверной стороне.
Во-вторых, формировать на сервере отвалидированную форму с ошибками напротив полей не всегда настолько простая задача, как возврат JSON'а типа
field_name : invalid_status. Помножьте это на n страниц формы.В-третьих, хитроумной валидации в некоторых случаях можно избежать. Пример: на сервере используется стандартное решение, а на клиенте вдруг захотелось принимать в поле «представьтесь» не просто какое-то одно слово, а три, типа фамилию, имя и отчество. Такая инвалидность не критична для данных, но валидацией на клиенте это решается элементарно. Т. е. оператору раз в месяц исправить неполное поле от клиента без JS обойдется дешевле, чем оплачивать специалисту время на написание своего валидатора для какого-то стандартного решения.
GD гораздо естественнее выглядит с точки зрения процесса разработки: мы первым усилием покрываем основных пользователей, а только затем уже заботимся о маргиналиях.
И все-таки предлагаете на сервере определять наличие JS на клиенте и выводить либо пагинированные картинки, либо полную версию?
2. Примеры:
— Разный формат записи адреса в зависимости от выбранной страны;
— Разный вид реквизитов в зависимости от выбранного вида собственности (юр/физ лицо)
— Обычная специализация по дереву категорий (Общество > Развлечения > Праздники > Новый год)
— Выбор файла в дереве
Это все решаемо так или иначе, но трудозатраты очевидны, — а целесообразны ли?
Будете выводить картинки сотнями на каждый запрос? Или будете на сервере проверять юзер-агента каким-то образом?
Как вы реализуете форму, в которой одни поля зависят от значений в других?
Будете выводить совершенно все поля и хитроумно валидировать на сервере?
Вы видите, насколько возрастают трудозатраты на серверный код? Вы сравнивали трудозатраты на прямую CSS3 верстку с JS в сравнении с Progressive Enhancement? Они адекватно соотносятся с числом пользователей без JS и на старых броузерах?
Если вы делаете сайты из любви к веб-технологиям — PE безусловно хорош. Но если вы оцените его эффективность с точки зрения UX и экономически — этот подход родственен перфекционизму. Часто это значит, что вы просто не знаете пользователя, для которого делаете сайт.
Хотелось бы, чтобы у вас появилось какое-то API и более удобный интерфейс.
Критика по пунктам.
— Сейчас категории видны в только подвале, хотя это один из важных элементов поиска сниппетов, который стоило бы оформить тегами в боковой колонке.
— Необходимы ключевые слова на сниппет и динамический поиск, к примеру, искать отключение выделения user-select можно как по запросу «select», так и по запросу «выделение», но сделать это быстро и удобно через ваш поиск совершенно невозможно.
— Третье, самое важное — размещайте код сниппета прямо в блоке с заголовком. Очень неудобно переходить на страницу сниппета ради какого-то мелочного куска кода. Заголовок сниппета вообще почти никогда ни о чем не говорит, а вот код можно почти всегда сразу узнать. В идеале, конечно, вообще отказаться от заголовков и оперировать прокомментированными кусками кода, как это сделано к примеру в Backbone annotated source. Заголовок и описание сниппета в отрыве от кода — самая бессмысленная и досадная вещь.