Может я не прав, но выдавать фатальные ошибки при отображении обычной страницы… это неправильно.
Ну отобразится страница криво и что?? Показывать пользователю ошибки парсинга это тупо как-то.
Такой строгий синтаксис существует для передачи и обработки данных… там подобные ошибки могут быть роковыми.
Поэтому всё должно быть на своих местах: страница в вебе — html, обмен данными сервер-клиент — xml(а лучше json:) )
Это тоже… найдётся же умник, который напишет *[class*=a] подразумевая … и всё… счастливой отладки....:)
Скорость тут не имеет значения, пока проект небольшой… когда он разрастётся… это станет ощутимо… и тогда начнутся реальные проблемы… всё переписывать. Поэтому системные вещи нужно очень осторожно разрабатывать.
Браузер не вуду, для него *[class*=neobtn-thick] и .neobtn-thick сов-но разные вещи. Если вы этого не понимаете очень жаль. Не один я пытаюсь донести эту мысль. Что можно сказать, читайте больше умных книг… например Реактивные веб-сайты
Настолько, что ваш крупный сайт со сложным dom-деревом зависнит наглухо в каком-нибудь ie7(про 6-ой можно и не упоминать)
Селектор *[class*=neobtn-thick] означает пройтись по всем элементам и найти среди них те, у которых есть атрибут class, в котором *внимание* содержится значение neobtn-thick. Сами думайте на сколько он медленный
И не переживайте так за скорость отрисовки. Экономия на удалении одной «звёздочки» в данном случае — экономия на спичках.
В статье речь идёт о системе составления классов, то есть все эти спички в итоге выльются вполне ощутимые тормоза. А если css не разделён по разделам? о-ооО-О:)
согласен, но комментарий был про то, что селекторы типа
*[class*=neobtn-thick] гораздо медленнее чем .neobtn {} и использовать их повсеместно мне кажется неправильно.
Всё можно сделать обычными классами.А для удобной разработки css можно использовать, например less(но на боевом использовать скомпилированный вариант конечно же)
> Одно уточнение — вы эти камеры прикрутили своими собственными руками.
Принёс в дом сам, но мне сказали, что там конфеты… про камеры никто ничего не сказал:)
Про Метрику могу сказать, что практически все её ставят на всех страницах, я не встречал людей, которые ставили бы выборочно( до известных инцидентов ).
Более того зачастую счётчики и реклама ставятся не программистами, а самим хозяином сайта через админку, а такие люди вообще не знают чего творят
Но основной моей мыслей было то, что открытая часть сайта это те страницы, на которые можно попасть с главной, пройдя n-ое кол-во уровней. Если страница никак не связана с главной, то она закрытая и не должна попадать в индекс. Такой логикой должен руководствоваться поисковик, а не класть в индекс всё подряд
Во-первых совершенно некорректно индексировать страницы, которые «не просматриваются по ссылкам с главной». Раньше такие страницы не попадали в индекс даже при наличаи ссылок с других сайтов(хотя тут я могу и ошибаться)
Яндекс.Метрика — это прежде всего инструмент для веб-мастера и предназначена для внутреннего использования. Если они хотят использовать обрабатываемую информацию в публичных целях, то должны обязательно предупредить об этом веб-мастера (должно быть пользовательское соглашение)
Читал мнения об открытых дверях в домах… у меня другое представление ситуации — Попробуйте что-либо спрятать дома, когда из каждой коробки конфет на самом деле спрятана камера
А кривых программеров всегда было много и яндексу с этим тоже нужно считаться
Согласен! Многие пользователи свои любимые пароли-то забывают, а когда сервис не принимает пароль начинаются приписки типа _1, 123 итд. и всё… крах:)
Так что пусть Hotmail готовится теперь к всплеску жалоб типа «Помогите! я забыл свой пароль!.. ААА!!»
Дебажу всегда в error_log с названием класса и номером строки, очень удобно
А после случая, когда админы напортачили и файл index.php отдался как текст, я стал писать в нём только одну строчку => require '../index.php' // который, естественно, не виден снаружи
Ну отобразится страница криво и что?? Показывать пользователю ошибки парсинга это тупо как-то.
Такой строгий синтаксис существует для передачи и обработки данных… там подобные ошибки могут быть роковыми.
Поэтому всё должно быть на своих местах: страница в вебе — html, обмен данными сервер-клиент — xml(а лучше json:) )
Скорость тут не имеет значения, пока проект небольшой… когда он разрастётся… это станет ощутимо… и тогда начнутся реальные проблемы… всё переписывать. Поэтому системные вещи нужно очень осторожно разрабатывать.
Селектор *[class*=neobtn-thick] означает пройтись по всем элементам и найти среди них те, у которых есть атрибут class, в котором *внимание* содержится значение neobtn-thick. Сами думайте на сколько он медленный
В статье речь идёт о системе составления классов, то есть все эти спички в итоге выльются вполне ощутимые тормоза. А если css не разделён по разделам? о-ооО-О:)
*[class*=neobtn-thick] гораздо медленнее чем .neobtn {} и использовать их повсеместно мне кажется неправильно.
Всё можно сделать обычными классами.А для удобной разработки css можно использовать, например less(но на боевом использовать скомпилированный вариант конечно же)
селекторы будут проще и поиск по ним гораздо быстрее
в варианте автора… мне кажется это жесть
Принёс в дом сам, но мне сказали, что там конфеты… про камеры никто ничего не сказал:)
Про Метрику могу сказать, что практически все её ставят на всех страницах, я не встречал людей, которые ставили бы выборочно( до известных инцидентов ).
Более того зачастую счётчики и реклама ставятся не программистами, а самим хозяином сайта через админку, а такие люди вообще не знают чего творят
Но основной моей мыслей было то, что открытая часть сайта это те страницы, на которые можно попасть с главной, пройдя n-ое кол-во уровней. Если страница никак не связана с главной, то она закрытая и не должна попадать в индекс. Такой логикой должен руководствоваться поисковик, а не класть в индекс всё подряд
Во-первых совершенно некорректно индексировать страницы, которые «не просматриваются по ссылкам с главной». Раньше такие страницы не попадали в индекс даже при наличаи ссылок с других сайтов(хотя тут я могу и ошибаться)
Яндекс.Метрика — это прежде всего инструмент для веб-мастера и предназначена для внутреннего использования. Если они хотят использовать обрабатываемую информацию в публичных целях, то должны обязательно предупредить об этом веб-мастера (должно быть пользовательское соглашение)
Читал мнения об открытых дверях в домах… у меня другое представление ситуации — Попробуйте что-либо спрятать дома, когда из каждой коробки конфет на самом деле спрятана камера
А кривых программеров всегда было много и яндексу с этим тоже нужно считаться
Так что пусть Hotmail готовится теперь к всплеску жалоб типа «Помогите! я забыл свой пароль!.. ААА!!»
А после случая, когда админы напортачили и файл index.php отдался как текст, я стал писать в нём только одну строчку => require '../index.php' // который, естественно, не виден снаружи
Взять другие аккорды и ритм и получится совсем другая мелодия.
Так что это магия музыки, а не чисел:)
Пусть допилят агрегат, чтобы он ещё и чинил!
А то больше некому:)
if 1 in arguments — проверка на существование
if arguments[1] — проверка на не пустое значение