rash

Наличие файла drupal.js наводит на мысли, что это именно он. http://drupal.org/

В пикселях нельзя только в том случае, когда текст должен масштабироваться в IE6. Если это не обязательно - можно в пикселях. А я предпочитаю словами - small, large и т. д.

Совершенно согласен. Поэтому и сказал, что не считаю свой вариант удачным. Из предложенных, кстати, мне понравился своей простотой вариант со словом на фоновом изображении.

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

Можно поверх инпута наложить блок с текстом, который убирать при щелчке по нему или получении инпутом фокуса. Пробовал сначала выводить в поле text, а потом менять его тип на password, но это не срабатывало.

У вас задана min-height, при этом height остается равна значению auto. А 100% отсчитывается именно от значения height.

Всем спасибо, постараюсь дальше сам :-)

Спасибо. Мое изучение матчасти дошло еще не до всех этих функций, так что будем искать и лепить :-) Главное, известно, где искать и из чего лепить :-) Дело не только в отображении. Я привел только верхушку айсберга, на самом деле надо будет еще менять внутреннюю структуру элемента, но для начала нужно сохранить его содержимое.

У себя проблемы не наблюдаю.

Есть такая задача: найти все определенные теги на странице и заменить их на другие. К примеру, найти все теги pre и заменить их на blockquote с тем же содержимым. Проблема заключается в том, что известные мне способы требуют обращения к контейнеру этого элемента, а затем удаления дочернего узла и создания нового с копией контента. Возможно ли это как-то сделать не зная ничего о структуре документа (к ней привязываться нельзя). То есть заранее неизвестно, какие будут элементы-родители и сестринские элементы у нужного, и для меня это серьезно усложняет задачу. Хотелось бы узнать, есть ли альтернативные варианты. Учить матчасть можно не посылать, сейчас как раз этим и занимаюсь. Можно подсказать материалы, где рассматривается что-то подобное. Спасибо.

Подпись к флажку (- Не запоминать IP?) Не нужен знак вопроса и дефис, можно с маленькой буквы.

А один из постулатов не экстремального программирования говорит, что комментарии и документация должны появляться одновременно с кодом или до появления кода. Каждому - свое. Комментарий может в нескольких строках выразить то, для понимания чего понадобиться прочитать пару десятков строк кода. Просто удобнее и быстрее. Хотя сам код, конечно, должен поддаваться пониманию и без комментариев.

Понравилось Да и картинок валидатора не должно быть. На самом лучшем сайте это и так понятно. А не самый лучший это не спасет.

Да.

_height: 350px; С подчеркиванием это поймет только IE, а в нем свойство height работает неправильно, и ведет себя так, как должно себя вести свойство min-height. То есть такая запись ничего не поломает и не разрушит.

Не вижу ничего плохого в том, чтобы работать быстрее. Зачем от этого отвыкать? Мелкие правки вы сможете сделать без привычного инструментария все равно, пусть и немного медленнее. А если нужно создавать что-то побольше, то скорее всего у вас под рукой будет все, что надо. Вообще эта боязнь привыкнуть к хорошему инструменту несколько удивляет. Если вы из принципа хотите, к примеру, работать только в Блокноте, то вы просто замедлите и затрудните свою ежедневную работу. Все равно, что забивать гвозди камнем, потому что вдруг когда-нибудь под рукой не будет молотка...

Ну в общих чертах да.

Хорошо. По спецификации при любой ошибке парсинг XML/XHTML должен прекращаться с сообщением об ошибке. Таким образом верный скрипт может пропустить, к примеру, какую-нибудь ошибку (например, неэкранированный амперсанд в URL) от пользователя в тексте комментария. И эта страница перестанет отображаться. Таким образом из-за необходимости проверки корректности отдаваемого кода существенно возрастает сложность серверных скриптов. Конечно, возможно добиться полностью корректного кода на выходе серверных скриптов, но это - существенное усложнение и удорожание создания и поддержки. В HTML 5 ошибки остаются ошибками, однако определяется, как клиент должен попытаться их исправить. Таким образом посетитель не будет брошен на произвол судьбы, если получит страницу с ошибкой. Нишей для XHTML я считаю, к примеру, отчеты программ, использование в служебных файлах и т.д. То есть те случаи, когда программа сама создает файл, не давая возможности человеку его сознательно или случайно испортить. Также это может иметь смысл для мобильных устройств, но тут несколько сомнительно - при более быстром и легком парсинге текста в стиле XML дополнительные расходы вычислительных ресурсов накладываются необходимостью проверять корректность данных. Прошу прощения, если опять слишком сложно.

Ниша HTML там, где он сейчас - веб, веб-приложения и т. д. XHTML/XML не слишком для этого подходят, так как в попытке упростить парсинг для браузера спецификация изрядно усложняет генерацию кода для серверных скриптов, которые работают автоматически без вмешательства человека. Поэтому на мой взгляд HTML свою нишу как занимал так и будет занимать, а вот XHTML возможно переместится в какую-нибудь более узкоспециализированную область, где не так интенсивно и часто приходится автоматически генерировать новую разметку, особенно полагаясь на данные, вводимые пользователем.

Пару новых элементов и так добавят. А еще наконец-то определят, что клиент должен делать в случае некорректного документа. Это уже тянет если не на разработку, то на весьма существенную доработку.

Это средства скрыть или показать фрагмент кода только для отдельных версий IE. <!--[if IE]> Код, который увидит только Internet Explorer <![endif]--> Более подробно по-английски - здесь: http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx

В спецификации нет средств для оформления полос прокрутки, эти средства - проприетарные возможности Internet Explorer'a. Можете либо вынести в отдельный файл для IE в условном комментарии, либо оставить как есть - другие браузеры просто проигнорируют оформление полос прокрутки.

И будут занимать память, как минимум. Решение можно активно использовать контролируя обработчики отдельно.

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

Красивое решение :-)