Leaderboard

И методология оценки эффективности тоже не помешала бы... Я думаю многим известно, что браузеры читают css справа налево поэтому при оценке эффективности селектора мы должны смотреть не только на количество элементов в селекторе но и на ключевой селектор то есть на последний. Например: .ingredient-details li { } В данном случае ключевой селектор это li. Эффективность этого li зависит от того сколько на странице ещё таких же li, чем их больше - тем больше браузер выберет(сматчит) элементов, тем медленнее отрисовка страницы. Браузеры сначала матчат все элементы на странице которые относятся к ключевому селектору а потом идут вверх по дереву пока не находят соответствия. Т.е здесь браузер сматчит все li на странице а потом пойдет вверх по дереву и сматчит все li относящиеся к классу .ingredient-details Скорость отработки этого селектора можно оптимизировать, уменьшив в нем общее количество элементов и количество элементов которые матчит браузер в соответствии с ключевым селектором, поехали Оптимизируем селектор Мы не знаем сколько классов .ingredient-details__item будет на странице но их должно быть явно меньше чем li, так что превращаем из .ingredient-details li { } в .ingredient-details .ingredient-details__item { } Здесь мы проставили на каждый li класс .ingredient-details__item Теперь этот селектор отработает быстрее т.к. ключевой селектор .ingredient-details__item матчит меньше элементов. Но здесь из-за 2 элементов в селекторе браузер лишний раз проходит по дереву, то есть мы как-бы говорим ему: "лисичка, хромик, деточка-опера, осел выбери-ка нам все .ingredient-details__item, ага, а теперь ещё все .ingredient-details__item которые относятся к .ingredient-details". Устанут детки яблоки перебирать, запыхаются. Этот селектор тоже можно оптимизировать, убрав .ingredient-details он нам не нужен, наш класс .ingredient-details__item и так напрямую относится к .ingredient-details и вне него существовать не может, превращаем из .ingredient-details .ingredient-details__item { } в .ingredient-details__item { } Теперь ключевым селектором является класс, браузер сразу выберет конкретные элементы относящиеся к этому классу, тем самым не будет матчить лишние элементы и лишний раз проходить по дереву. Правила Два главных правила скорости селекторов а значит скорости отрисовки страницы: 1. Скорость селектора напрямую зависит от количества сматченых ключевым селектором элементов. Например: Если у вас на странице будет 9999 span и 9999 .class, скорость у них будет одинаковая. Если у вас на странице будет 5000 span и 9999 .class, селектор по классу будет медленнее. Если у вас на странице будет 9999 span и 5000 .class, селектор по типу будет медленнее. (обычно так и бывает, но вряд ли в таких количествах^^) 2. Скорость селектора зависит от количества элементов в селекторе Например: .ingredient-details span { } отработает медленнее чем просто span .ingredient-details .ingredient-details__item { } отработает медленнее чем просто .ingredient-details__item { } Таблица эффективности селекторов * Украдено с CSS-tricks #main-navigation { } /* ID (Самый быстрые) */ body.home #page-wrap { } /* ID */ .main-navigation { } /* Class */ ul li a.current { } /* Class * ul { } /* Тег (Селектор типа) */ ul li a { } /* Тег (Селектор типа) */ * { } /* Универсальный (Самый медленный) */ #content [title='home'] /* Универсальные (Медленнее медленного) */ Цитата David Hyatt: * Украдено с CSS-tricks Контекстный селектор(селектор потомка) это самый дорогостоящий селектор в CSS. Он ужасно дорогой особенно если он идет вместе с селектором типа или универсальным селектором. Другими словами вот это катастрофа быстродействия: html body ul li a { } Зачем все это? Мы экономим миллисекунды, ну допустим прирост производительности за счет быстрых селекторов будет 200мс. Так и кому полезны эти 200мс? Может просто забить? Ан нет, как вы все знаете, jquery напрямую взаимодействует со страницей то есть когда например мы делаем .animate({"margin-top": "50px"}, "fast"); браузеру придется примерно 50 раз перерисовать страницу чтобы отработала анимация. (но и тут есть свои хитрости конечно) То есть прирост производительности в 200 мс увеличит скорость отработки и плавности анимации, может быть это будет не заметно на небольших страницах с небольшим количеством js, но на страницах больше 30кб с большим количеством анимации это будет ощутимо, даже очень. А в старых браузерах и подавно. Где-то у харисова была заметка что скорость отрисовки страницы, которая была сверстана независимыми блоками(нет медленных селекторов), в ie6-7 увеличилась в 3-5 раз, в ie8 в 2-3 раза, в остальных браузерах меньше но тоже ощутимо. Хочувсезнать: Страница отрисовывается(рендрится) при загрузке, или при работе javascript. Не только селекторами земля полнится На скорость отрисовки страницы влияет множество факторов например глубина DOM. Подробнее в книжке Мациевского "Реактивные веб-сайты". Как конретно померять скорость отрисовки? Вот например так: http://jsfiddle.net/E49EL/1/ http://banzalik.ru/labs/perf-test-classes/perf-test-classes1.html?reflow-meter Правда на разных компьютерах rewlow time будет разным, зависит от самой системы. Дополнительные материалы Та самая, знаменитая статья на 30 000 div'ов http://clubs.ya.ru/bem/replies.xml?parent_id=375&item_no=338&with_parent=1#reply-yacf-375 Firefox отрисовывает страницу CSS-triks про эффективный css http://css-tricks.com/6386-efficiently-rendering-css/ Мозила про эффективный css https://developer.mozilla.org/en/Writing_Efficient_CSS ещё http://www.shauninman.com/archive/2008/05/05/css_qualified_selectors#comment_3942 Видео на английском про эффективность селекторов

Исправьте на нормальный (12-14) и все будет работать. По поводу ИЕ не понял. зы: верстка формы дурацкая. Там много абсолютного позиционирования, который нужен только для псевдокнопки и все, но оно там повсюду. Это делается гораздо проще.

может быть тут? http://fasttut.com/design/psd-shabloni-sajtov-besplatno/ первый еще видела тут http://baterflay.biz/templates.php?id=4&page=2

Odrin, Лови, брат: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /> <title></title> <style type="text/css"> canvas { border: 1px solid; } </style> <script type="text/javascript"> function rand( min, max ) { return Math.floor(Math.random() * (max - min + 1)) + min; } function renderToCanvas(w, h, renderFunction) { var buffer = document.createElement('canvas'); buffer.width = w; buffer.height = h; renderFunction(buffer.getContext('2d')); return buffer; } function snow(qty) { var arr = []; for (var i = 0; i < qty; i++) { arr.push({ x: rand(-20, 520), y: rand(-20, 520), vx: rand(-1, 1) / 10, vy: rand(5, 10) / 10 }); } return arr; } window.onload = function() { var delta = 0; var frames = 0; var lastTime = (new Date()).getTime(); var updateTime = 0; var updateFrames = 0; var canv = document.getElementById('test'); var ctx = canv.getContext('2d'); var round = renderToCanvas(20, 20, function(ctx) { ctx.beginPath(); ctx.arc(10, 10, 10, 0, Math.PI * 2, false); ctx.fill(); }); var s = snow(5000); // кол-во шариков window.setInterval(function() { // FPS var now = (new Date()).getTime(); delta = now - lastTime; lastTime = now; frames++; updateTime+=delta; updateFrames++; if (updateTime > 1000) { document.getElementById('debug').innerHTML = 'FPS: ' + (1000 * updateFrames / updateTime); updateTime = 0; updateFrames = 0; } // Main ctx.clearRect(0, 0, canv.width, canv.height); for (var i = 0; i < s.length; i++) { s[i].x += s[i].vx; s[i].y += s[i].vy; if (s[i].x > 520) { s[i].x = -10; } if (s[i].y > 520) { s[i].y = -20; } ctx.drawImage(round, s[i].x, s[i].y); } }, 10); } </script> </head> <body> <canvas id="test" width="500" height="500"></canvas> <h2>С буфером</h2> <div id="debug"></div> </body> </html>

Когда читаю, то часто выделяю текст, чтобы не потерять место где сейчас читаю или то место где мне нужно прочесть несколько раз для лучшего восприятия. И как же меня раздражают подобные штучки: Нужно их как-то по другому делать. Или это сообщение показывать на фикседе, где-то где оно не будет текст закрывать, или еще какое-то решение придумать. Думаю, не я один такой, вот мы вам и скажем спасибо не только за полезные статьи, но и за удобство пользования вашим блогом.

Сама идея классная, например выделил и либо вставил в поле для цитирования, либо отправил репорт об ошибке, улучшает юзабельность. Но вот только чтобы текст не закрывало.

Как минимум, имхо, оно должно быстро пропадать при клике "мимо" (в любое другое место страницы). И, может, лучше ей всплывать не тут же над текстом, а справа от колонки, "на полях"? Ну и с "фикседом", да, имхо было бы удобно.

Читал я про Ваш доктайп! artlebedev.ru - доктайп есть? Сайт полностью не валидный, но сделанный с душой лучше чем пустая валидная страница!

во чередной раз сам тупанул , не обновил страницу ) в топку тему