SelenIT

Если искомая тэдэшка — единственная в таблице с классом entrybox (и ее потомках), у кого colspan="2", то можно к этому атрибуту и прицепиться: .entrybox td[colspan="2"] { ... } Должно работать от IE7 и выше.

Еще так можно.

Они не исчезают, а просто тупо прячутся за левую границу окна (блок как бы расширяется в 11 раз и 10/11 его ширины туда уходит), а первая строчка возвращается в видимую область отступом. Проценты тут, конечно, неоптимальны, это я от бессонницы нахимичил, лучше было бы что-то типа 30000px (поближе к оперному лимиту общей ширины в 32k px, но с небольшим запасом). И то сильная завязка на то, что пунктов мало и невидимая часть второй строки не заполнится. Впрочем, решения на этом пути найти так и не удалось, [censored] высота строки никак не поддается дрессировке, а с отрицательным маргином для li теряется связь с высотой контейнера Первый вариант, на мой взгляд — близкое к максимальному приближение к решению по букве и духу спеки (самый "лобовой" способ отделить первую строку от других плюс разрешенные для :first-line приемы). И пример IE9 (да и FF8 в статике) показывает, что "в принципе" это может работать. Но для др. браузеров, видимо, это слишком сложно...

Насколько я в курсе, это оборачивание стилей и скриптов в комменты (для скрытия от браузеров древнее IE3/NС3, не знавших CSS) уже лет 10–12 как неактуально. И даже вредно, т.к. HTML-комменты — никак не то, что приличные браузеры ждут от контента, помеченного как "text/css". При XHTML-парсинге браузеры такие стили вообще игнорируют как любой "закомментаренный" мусор...

Моей извращенной фантазии пока хватило лишь на такое, но, увы, ожидаемым образом оно работает только в IE9 (в IE8 — не скрывает, в Опере — скрывает текст, но оставляет блоки, в Хроме — показывает пустую рамку вообще без текста, а в FF вообще глючит по-невообразимому). Просто "пропадание" блоков еще можно сымитировать как-то так, но вот как быть с высотой контейнера...

Это http://jsperf.com/access-to-nodes-via-queryselectorall-vs-getelementsbyta/4?

Там и для кнопок, и для ссылок, и для файл-инпутов хватает. С contenteditable-то еще ладно, я вообще с трудом представляю, как должны вести себя инпуты при редактировании "по живому". Да и должно исправиться в 12-й версии, с приходом полноценного HTML5-парсера. Но вот хром, как говорится, "нас радует"

inlne-block для дивов + text-align:justify для контейнера, типа такого?

Хм, а и вправду ведь. Судя по всему, баг. Забавно, что помечен как пофикшенный. Там еще были проблемы с кроссплатформенностью (виндовцы привыкли к фокусу, маковцы — к его отсутствию), возможно, корень зла где-то там...

Ну почему, в самом XPath-е как раз есть очень удобные оси ancestor и preceding/following-sibling именно для "хождения в гости к соседям". В CSS (и, соответственно, квериселекторах) с этим, таки да, куда хуже (плюс да тильда — и всё, кажись). Но даже этих куцых возможностей хватает, например, чтобы одним махом собрать подписи к чекнутым чекбоксам (что-то типа ".myfieldset input[type=checkbox]:checked + label"), скажем, для формирования странички подтверждения после выбора чего-то из очень большой кучи во всплывающем диалоге. Не спорю, что нынешние квериселекторы не тянут на универсальную замену DOM-методам, но во многих случаях они — очень удобное подспорье/дополнение к ним. А если добавить относительную адресацию или ограничитель контекста (в том же многострадальном jQ есть) — и задачи а-ля "найти первый инпут в ближайшем общем контейнере, имеющем класс 'active', с кликнутой ссылкой" начинают легче поддаваться (без необходимости руками писать многоэтажные циклы с проверками, пользуясь правилом "меньше кода — меньше ошибок"). Вот зависимость от текущей структуры разметки — это да, ограничение. Но, по-моему, поменять один-два селектора в случае изменения структуры всё же проще, чем выворачивать вложенный цикл наизнанку или переносить половину проверок с уровня на уровень. И можно ли полностью избавиться от этой зависимости, кроме как раздав id-ы всем без исключения "участникам шоу"? Однако, в моей Опере 11.51 (Win 7 Pro x86) главная странность этого теста подтверждается: document.querySelectorAll("#a1")[0] почти равен по скорости document.getElementById("a1"), отстает всего на 7%, а вот document.querySelector("#a1") в разы медленнее. При этом в простом тесте querySelectorAll у меня в ней оказывается в среднем втрое-вчетверо быстрее, чем getElementsByTagName (правда, последний стабильно дает разброс аж под 40%). По итоговым цифрам расклад противоположен таковому в FF8.0b. Интересно, почему?

document.write вообще не обязан работать после полной загрузки документа (как минимум, без предварительного document.open). То, что в FF document.open при этом вызывается автоматически — лишь добрая воля FF, полагаться на которую не стоит (стандарт DOM этого не запрещает, но и не требует, да и вообще эта архаика вот-вот "may be deprecated"). Забудьте уже этот древний хлам, пользуйтесь нормальными innerHTML и DOM-методами, чай, не 90-е на дворе

Беглый поиск подсказывает такой быстрый фикс: -webkit-tap-highlight-color: rgba(0, 0, 0, 0); /* первые 3 числа могут быть любыми < 256 */ Но почему вообще див подсвечивается по тапу? Там ссылка, onfocus или что? У меня почему-то подсвечиваются только изначально активные элементы типа ссылок...

А что, есть еще причины, кроме тормознутости текущих реализаций? Конечно, интересно узнать! Да (только это не совсем массив, это коллекция). А он возвращает коллекцию, которая с виду очень похожа, но на последующие изменения документа не реагирует (если из документа дивы удалятся, в этой коллекции они останутся). Что-то похожее на присваивание по значению (в отличие от результата getElementsByTagName, похожего на присваивание по ссылке). Это я так перевел слово "snapshot", которое Закас использует для неизменяемой ("неживой") коллекции, которую возвращает querySelectorAll(). Кстати, да. За счет чего в Опере настолько разительно отличная от др. браузеров картина результатов бенчмарка? Вряд ли же DOM-методы в ней настолько тормознее?

Меня интересовало, как он в документацию попал (с) Но логично объясняет резоны. Еще раз большое спасибо за полезную и познавательную информацию!

s0rr0w, спасибо за тему и поучительную ссылку! Читал статью Николаса Закаса с объяснениями, откуда такая разница, много думал... Не совсем понимаю, почему результат выборки по селектору "обязан быть" статическим. И вообще, откуда и для чего взялся этот "статический NodeList"? Какие у него преимущества (кроме защиты от угрозы поймать бесконечный цикл при модификации DOM, как в примере у того же Николаса), что они оправдывают такой проигрыш в скорости? Может, на каком-нибудь новом повороте логики скрипта можно отыграть это упущенное время взад, используя этот "мгновенный снимок" структуры в качестве этакого кеша?

Хм... во всех статьях про Selectors API, что мне попадались, как раз скорость приводят как главный плюс... (например) Впрочем, имхо, это уже оффтопик (хотя и безумно интересный). Может, есть смысл завести новую тему а-ля "Плюсы и минусы мышления в стиле XPath" где-нибудь во Флейме?

Я лишь хотел сказать, что на нюансы этих способов — те из них, что явно не регламентированы спекой — в любом случае нельзя полагаться. ЕМНИП, с порядком вызовов eventListener-ов та же фигня (есть некая "традиция", но никто не гарантирует, что новейший движок ради быстродействия или еще чего-то ее не поломает)... Задачи разные бывают

Формально да, но в JS есть устоявшаяся терминология, по которой массив (Array) и хэш (Object) — разные объекты, и второй вроде бы и не претендует на часть свойств/методов/особенностей первого (такие как length и сохранение порядка элементов). Это ж не PHP, где все массивы по сути одинаковы и ассоциативны... Или я чего-то упустил? Похоже, это только для дефолтного значения ("text"). Стоит изменить, скажем, на "checkbox" — сразу же отзывается, голубчик. Где-то "дооптимизировались", имхо. А насчет способов проверки на ум приходит разве что парсинг outerHTML не, и это не помогает — боюсь что никак... P.S. Нет, кое-какой толк от outerHTML есть: совсем левые значения типа "polnykabzdez" через attribute.specified тоже не простукиваются, но в outerHTML прекрасно попадают. Всё страньше и чудесатее! Кстати, про specified я только сейчас узнал, как-то пользоваться не доводилось . Насколько же удобнее новые инструменты типа querySelector-ов!

Емнип, способ с гигантскими паддингами всегда глючил с внутристраничными якорями, это было едва ли не главным ограничением этого подхода...

В нынешнем CSS, к сожалению, пока нельзя. Вот-вот, по-видимому, станет можно, но пока приходится изворачиваться с помощью наслоений классов или генерации CSS серверными языками (либо тулзами типа LESS/SASS). На правах курьеза существуют вот такие решения, но применять ли такое кунфу в боевых условиях, каждый мастер решает для себя сам...

Есть media queries (см. напр. здесь). Старые IE (8-) в пролете, но туда им и дорога...

Вдогонку: есть подозрения, что громоздкий обработчик document.attachEvent('onreadystatechange', function() {...можно заменить на однострочный document.attachEvent('onfocusin', changeTarget);не только без потерь, но даже с выгодой (появляется реакция на смену hash вручную). Вот только history не поддается, но чего ж хотеть от полувымерших динозавров?..

В упор не вижу тут массива . А в хеше, вроде, ключи имеют полное право храниться в таком порядке, как интерпретатору удобнее (прошу ткнуть мордой в спеку, если неправ)...

Так не получится, noscript реагирует на физическую возможность выполнения скрипта, а не на его наличие/отсутствие. В IE9 (по-моему, в IE8 тоже) скрипт можно выключить из Developer tools-ов (или просто не включать "заблокированное активное содержимое" при открытии файла локально), в более старых он выключается в "Свойствах обозревателя" (в неожиданном месте, на вкладке "секьюрити").

Удалять-то скрипт зачем? Пусть <noscript> лежит себе рядом...