Насчет скорости селектора, все браузеры разбирают селектор справа налево. В случае div.news сначала будут найдены все элементы с классом .news, а из них выберут элементы div, отсюда и потери. Хоть это и мелочи, но если так делают без надобности — выглядит глупо
«Для его переопределения достаточно воспользоваться точно таким же селектором: div.news_layout > ul > li > h3.»
Именно. Чтобы переопределить такой длинный селектор, придется воспользоваться селектором не меньшей длины. Из-за этого падает читаемость и такие стили трудней поддерживать.
Экономия в количестве символов в разметке это слишком слабая оптимизация. Повторяющиеся классы хорошо поддаются сжатию, экономия получается копеечной.
Такого рода оптимизациями можно заняться если у вас Google PageSpeed покажет 100 и заняться больше нечем.
отвратительный селектор, так лучше никогда без надобности не писать
Верстка всегда может немножко поменяться, и чем меньше таких селекторов, тем проще это будет сделать.
Учитывайте так же что лишние уточнения негативно складываются на производительности, и div.news хуже чем просто .news
Плюс ко всему, если вам понадобится в каком-то случае переопределить одно из свойств, вам придется использовать еще более специфичный селектор, как .error div.news_layout > ul > li > h3
Семантика это конечно хорошо, но не надо на ней так зацикливаться, <h3 class="news-title"> с точки зрения семантики, ничем не хуже чем <h3>, и при этом избавляет от нескольких граблей на пути
Подключение стилей «anythingslider.css» после jquery и плагинов будет сопровождаться ощутимо заметным скачком этого самого слайдера при загрузки страницы
Все подряд называть итемы тоже не дело, такая вложенность может выйти боком в самых неожиданных местах.
А для списка новостей лучше уж использовать список, и в css будет чище .news > li
Эти схематичные рисунки так и остались для меня загадкой, почему выбраны такие цвета, как понять где сработал :active, а где нет, и чем отличается поведение браузеров на втором и четвертом — неясно.
Но проблема в опере и ие действительно есть, и посмотреть можно на простом примере jsfiddle.net/gpCbA/33/
В винде при выборе десятилетий диапазоны сделаны не просто так, год вида 198x слишком непривычен, особенно если это первое что видишь после открытия календаря.
Там же первым слайдом показывается сегодняшняя дата и есть небольшая анимация, благодаря которой показывается как мы попали на выбор десятилетий.
Но. Если ваш календарь показывать с сегодняшней даты, тогда он начнет проигрывать уишному.
Сделайте более грамотные тесты, со случайными числами из одного месяца, года, десятилетия и столетия, настройте УИшный календарь (неделя должна начинаться с понедельника, названия на русском), выводите календари в случайном порядке, тогда можно будет сравнивать показатели.
После первых двух абзацев решил себя проверить, написал функцию сравнения:
function compareStrings(str1, str2) {
var rx = /([^\d]+|\d+)/ig;
var str1split = str1.match( rx );
var str2split = str2.match( rx );
for(var i=0, l=Math.min(str1split.length, str2split.length); i < l; i++) {
var s1 = str1split[i],
s2 = str2split[i];
if (s1 === s2) continue;
if (isNaN(+s1) || isNaN(+s2))
return s1 > s2 ? 1 : -1;
else
return +s1 - s2;
}
return 0;
}
console.log( [ 'file2', 'file10', 'file1' ].sort(compareStrings) );
На оптимальность так же не претендует. Подход простой, разбиваем строку на массив — строки одтельно числа отдельно ( 't123est' ~> ['t', '123', 'est'] ), и затем сравниваем каждый элемент получившихся массивов как строки и числа соотв.
Оттого что scope спрятан, недостатки eval никуда не исчезают. Вы не обходитесь без него, просто заменяете на неявный вызов.
С eval, кстати, можно было сделать так:
var data = 'test';
(function(global){
var data = 'value';
global.eval('alert(data);'); //test
})(this);
Про window["foo" + i] писал скорее к автору. Когда был новичком, сам писал eval("foo"+i) от незнания как это делать правильно, хотя подобных статей начитался :)
Отличная статья, спасибо за перевод.
Теперь мне стало ясно зачем нужен этот ИЕшный якорь(мета-тег) с указанием на версию браузера. А в будущем он может пригодиться и другим, чтобы не плодить почти-стандатрные методы.
div.newsсначала будут найдены все элементы с классом .news, а из них выберут элементыdiv, отсюда и потери. Хоть это и мелочи, но если так делают без надобности — выглядит глупо«Для его переопределения достаточно воспользоваться точно таким же селектором:
div.news_layout > ul > li > h3.»Именно. Чтобы переопределить такой длинный селектор, придется воспользоваться селектором не меньшей длины. Из-за этого падает читаемость и такие стили трудней поддерживать.
Экономия в количестве символов в разметке это слишком слабая оптимизация. Повторяющиеся классы хорошо поддаются сжатию, экономия получается копеечной.
Такого рода оптимизациями можно заняться если у вас Google PageSpeed покажет 100 и заняться больше нечем.
И штуки там очень хорошие подобраны, с комментариями ентами и ссылками, можно просто дергать оттуда в старые проекты.
отвратительный селектор, так лучше никогда без надобности не писать
Верстка всегда может немножко поменяться, и чем меньше таких селекторов, тем проще это будет сделать.
Учитывайте так же что лишние уточнения негативно складываются на производительности, и
div.newsхуже чем просто.newsПлюс ко всему, если вам понадобится в каком-то случае переопределить одно из свойств, вам придется использовать еще более специфичный селектор, как
.error div.news_layout > ul > li > h3Семантика это конечно хорошо, но не надо на ней так зацикливаться,
<h3 class="news-title">с точки зрения семантики, ничем не хуже чем<h3>, и при этом избавляет от нескольких граблей на путиПодключение стилей «anythingslider.css» после jquery и плагинов будет сопровождаться ощутимо заметным скачком этого самого слайдера при загрузки страницы
Все-таки стили нужно загружать до body
А для списка новостей лучше уж использовать список, и в css будет чище
.news > liНо проблема в опере и ие действительно есть, и посмотреть можно на простом примере jsfiddle.net/gpCbA/33/
Вообще база очень мала, насколько могу судить 500-1000 фильмов.
facepalm
Там же первым слайдом показывается сегодняшняя дата и есть небольшая анимация, благодаря которой показывается как мы попали на выбор десятилетий.
Но. Если ваш календарь показывать с сегодняшней даты, тогда он начнет проигрывать уишному.
Сделайте более грамотные тесты, со случайными числами из одного месяца, года, десятилетия и столетия, настройте УИшный календарь (неделя должна начинаться с понедельника, названия на русском), выводите календари в случайном порядке, тогда можно будет сравнивать показатели.
получилось
return 0;С первого раза без багов никогда не получается.
Дабы как-то оптимизировать можно прогнать регексп по массиву всего один раз перед сортировкой:
На оптимальность так же не претендует. Подход простой, разбиваем строку на массив — строки одтельно числа отдельно ( 't123est' ~> ['t', '123', 'est'] ), и затем сравниваем каждый элемент получившихся массивов как строки и числа соотв.
тем более с Modernizr
С eval, кстати, можно было сделать так:
Про
window["foo" + i]писал скорее к автору. Когда был новичком, сам писалeval("foo"+i)от незнания как это делать правильно, хотя подобных статей начитался :)javascript.crockford.com/code.html ну и www.jslint.com/lint.html
Лучше бы написали как без него обходиться. До
window["foo" + i]не каждый новичек допретТеперь мне стало ясно зачем нужен этот ИЕшный якорь(мета-тег) с указанием на версию браузера. А в будущем он может пригодиться и другим, чтобы не плодить почти-стандатрные методы.