Первая $(".header > a") будет быстрее потому, что будет использоваться нативный метод для выборки, где он есть. Но вторая $(".header").find("a") строго говоря не эквивалентна первой: find находит все дочерние элементы, а селектор > — только непосредственно вложенные (в данном случае, поскольку <a> не могут быть вложенными друг в друга, результаты будут одинаковые).
На мобильном (андроид), к сожалению, выделение текста внутри ссылки выливается только в неудобство и раздражение: когда хочешь открыть в новой вкладке (а это бывает намного чаще, чем желание выделить текст), длинное нажатие, если попадешь не туда, начинает выделение, а не открывает меню, в котором есть выбор: открыть или выделить.
Уважаемые разработчики! Если будет время и возможность, сделайте по длинному нажатию на ссылках только меню (в нем открыть в новой и выделить) — иначе очень бесит… особенно при чтении хабра ;)
Возможно, в новой (бета) это уже поправили, не помню — сейчас пользоваться ею невозможно, виснет и тормозит на Galaxy S2.
Вы, кажется, спутали многопоточность и многопроцессность. Память в ОС выделяется процессам, а процессорное время — потокам. Опера имеет однопроцессную и, насколько я знаю, многопоточную архитектуру. Хромиум же использует по умолчанию многопроцессную, хотя я видел где-то ключи командной строки, переключающие группировку сущностей по процессам (рендерер, еще какие-то, не помню).
period у Вас равен 600. Чтобы обновление секунд было более точным, нужно обновлять не реже, чем раз в полсекунды (а лучше чаще), иначе будет смещение, которое так проявляется.
Есть скрипт для подключения к внешней точке доступа, который кладется на AR.Drone и запускается автоматически при загрузке системы, пытается подключиться к указанной в настройках точке и, если не получается, переводит устройство обратно в режим самосозданной точки доступа.
Вот, это более похоже на мой сценарий, только отличие в том, что hover-стилей через CSS не задается, и происходит не удаление элемента, а сброс внутреннего флага, запрещающего дальнейшие действия на время перехода. Нужно попробовать фишку из доклада, который порекомендовали Odnoklassniki_ru — вчера посмотрел. Там говорят, что нужно при прерывании перехода устанавливать текущее значение CSS-свойства и удалять свойство transition из style (я не удаляю, только устанавливаю transition-duration в 0s). Событие не отрабатывает, но этот момент мы знаем без события, поскольку мы его кодируем.
Да, transitionend. У меня в коде событие правильное, поскольку несколько раз оно срабатывает, а потом перестает. Причем вкладка при этом не переключается. Пример, оторванный от контекста, типа jsfiddle, пока нет времени сделать, прошу прощения за телепатию. Но если кто сталкивался с таким поведением в принципе, независимо от конкретного случая, опыт будет полезным. Спасибо за ссылки, посмотрю в ближайшее время.
Расскажите, работаете ли вы с CSS transitions из JavaScript? Если да, то не сталкивались ли с тем, что события ontransitionend в Firefox срабатывают только несколько раз, а потом перестают? Другие браузеры отрабатывают каждое завершение. Все значения свойств для перехода задаются через element.style с префиксами. Переход только по opacity. Может, кто-то еще сталкивался, или есть ссылки, где почитать, как исправить или обойти.
Мне кажется, здесь размыто понятие «веб-интерфейс» между интерфейсом одностраничных веб-приложения (RIA), где HTML-документ как основа приложения уже не подходит, и интерфейсом веб-сайта, форума, блога, где HTML-документ наиболее подходит в качестве основы.
Для первых «gracefull degradation» в части случаев невозможна в принципе из-за необходимости всего стека доступных технологий для предоставления функций веб-приложения, а в другой части может иметь вид разве что отдельно разработанного с нуля упрощенного интерфейса (пример — почтовые веб-клиенты, где можно привести работу с почтой как работу с HTML-документами).
Для вторых эта концепция действительно имеет место быть в полном объеме: посетителю предоставляется контент, а не функциональность.
Многие пытаются объединить эти две несовместимых области (например, проект jQuery UI), и это запутывает.
Скажите, планируется ли в ближайшее время такая юзабилити-переработка Яндекс.Картинок?
После сравнительно недавно выпущенного обновления, когда убрали ленту картинок внизу, добавили прокрутку страницы и «проигрыватель» картинок, пользоваться стало совсем неудобно.
Какими критериями руководствовались разработчики этого интерфейса, внося столь существенные изменения?
Например, IE9 отвратительно реализует Flash External Interface (даже хуже, чем IE8): по-видимому, из-за перехода к асинхронному взаимодействию, при удалении Flash-объекта из DOM возникают асинхронные ошибки, связанные с завершением вызовов в сторону Flash или обратно (ошибка с SetReturnValue во внутреннем JavaScript-коде IE9). К сожалению, в некоторых сферах альтернативы для Flash по-прежнему нет и не предвидится в ближайшем будущем.
Дополнительную головную боль доставляют ошибки вида «Интерфейс не поддерживается», «Access denied.», "'undefined' — есть null или не
является объектом", «Object doesn't support property or method 'SetMaximized'» и тому подобные, без внятного стека или дополнительной информации для понимания причины (например, ошибка происходит на строке 1 по адресу страницы, на которой происходит).
Скорее всего, бОльшая часть таких ошибок вызвана какими-то внедрениями дополнений в стандартные функции браузера, поэтому то же самое происходит и в Chrome, и в Firefox, и в Opera. Но кроме IE9 винить некого в том, что браузер не сообщает сведения, которые помогли бы отфильтровать такие ошибки (как делает Chrome и пытается делать Firefox, указывая URL вида extension или chrome:// ).
Как-то вы сами сложно о простом написали. Как это «они наследуются от null», ведь null — это специальное значение переменных, как и undefined? То, что null является значением свойства prototype последнего объекта в цепочке прототипов, не значит, что все объекты от него наследуются, а значит, что этот последний объект ни от кого не наследуется.
Google Docs отправляет изменения на сервер почти сразу после того, как их внесли, причем чуть ли не посимвольно. Плюс сохраняет историю изменений. Поэтому, во-первых, потерять один символ не очень страшно, а во-вторых, нужно очень постараться, чтобы мгновенно после внесения изменений закрыть вкладку или окно браузера, будь то крестик или комбинация клавиш.
$(".header > a")будет быстрее потому, что будет использоваться нативный метод для выборки, где он есть. Но вторая$(".header").find("a")строго говоря не эквивалентна первой:findнаходит все дочерние элементы, а селектор>— только непосредственно вложенные (в данном случае, поскольку<a>не могут быть вложенными друг в друга, результаты будут одинаковые).Уважаемые разработчики! Если будет время и возможность, сделайте по длинному нажатию на ссылках только меню (в нем открыть в новой и выделить) — иначе очень бесит… особенно при чтении хабра ;)
Возможно, в новой (бета) это уже поправили, не помню — сейчас пользоваться ею невозможно, виснет и тормозит на Galaxy S2.
periodу Вас равен 600. Чтобы обновление секунд было более точным, нужно обновлять не реже, чем раз в полсекунды (а лучше чаще), иначе будет смещение, которое так проявляется.Смотрите, что получается: jsfiddle.net/sompylasar/uhMqL/
Возможно, на танке можно организовать нечно подобное.
Вот он (точнее, open-source программа для его установки и настройки): sites.google.com/site/androflight/arautoconnect
Для первых «gracefull degradation» в части случаев невозможна в принципе из-за необходимости всего стека доступных технологий для предоставления функций веб-приложения, а в другой части может иметь вид разве что отдельно разработанного с нуля упрощенного интерфейса (пример — почтовые веб-клиенты, где можно привести работу с почтой как работу с HTML-документами).
Для вторых эта концепция действительно имеет место быть в полном объеме: посетителю предоставляется контент, а не функциональность.
Многие пытаются объединить эти две несовместимых области (например, проект jQuery UI), и это запутывает.
Немного оффтоп, но все-таки.
Скажите, планируется ли в ближайшее время такая юзабилити-переработка Яндекс.Картинок?
После сравнительно недавно выпущенного обновления, когда убрали ленту картинок внизу, добавили прокрутку страницы и «проигрыватель» картинок, пользоваться стало совсем неудобно.
Какими критериями руководствовались разработчики этого интерфейса, внося столь существенные изменения?
Заранее спасибо за ответ.
Дополнительную головную боль доставляют ошибки вида «Интерфейс не поддерживается», «Access denied.», "'undefined' — есть null или не
является объектом", «Object doesn't support property or method 'SetMaximized'» и тому подобные, без внятного стека или дополнительной информации для понимания причины (например, ошибка происходит на строке 1 по адресу страницы, на которой происходит).
Скорее всего, бОльшая часть таких ошибок вызвана какими-то внедрениями дополнений в стандартные функции браузера, поэтому то же самое происходит и в Chrome, и в Firefox, и в Opera. Но кроме IE9 винить некого в том, что браузер не сообщает сведения, которые помогли бы отфильтровать такие ошибки (как делает Chrome и пытается делать Firefox, указывая URL вида extension или chrome:// ).
stackoverflow.com/questions/7688902/what-is-functions-proto
stackoverflow.com/a/5982610/1346510
И всё-таки специальная таблица есть:
code.google.com/searchframe#W9JxUuHYyMg/trunk/include/v8.h&l=863