rash

nuna, а можете показать примеры работ? Можно в личку. Ну хоть что-то ведь вы уже делали в процессе работы, какие-нибудь попытки, тестовые страницы и т. д.

А чем так опасны сторонники адекватно спроектированных языков?

Извините, что придираюсь, но HTML (а здесь, как видим, не XHTML) вполне себе может начинаться не с html. html, head, body — необязательные теги. Поэтому первым на законных основаниях может идти title, meta, style и т. д. Так что формально все верно, но по крайней мере в самом начале так делать не надо. Да и потом стоит так писать только если есть для этого хоть какие-то причины.

Ну можно правила отключать по одному Может дело в шрифте? По этому фрагменту кода непонятно.

Использовал бы объекты как деревья Если такую структуру можно описать на JSON, то сложностей быть не должно.

Ну я имел в виду с JS на C, например. Думаю, будет поначалу «ломать». Но, вообще, степень «ломки» будет зависеть от культуры программирования, да.

Ага, со строгой на нестрогую типизацию и наоборот Безболезненно

Я стараюсь не использовать необязательные элементы и атрибуты по максимуму. В некоторых случаях это может касаться и кавычек. Давайте вы не будете придумывать, что я считаю? Откуда взялся этот вывод совершенно непонятно, как минимум DTD не позволит написать от балды на уровне синтаксиса. На уровне семантики в XHTML тоже нет никаких дополнительных ограничений. А давайте вы сначала прочитаете то, на что отвечаете? Процитирую самого себя, раз уж вы прочитать не удосужились: …«заведомо известно, какие значения требуют кавычек, а какие — нет». …и не понимаете, зачем. Будьте добры воздержаться от подобных высказываний.

Знаете, чем куки не подходят для хранения относительно большого объема информации, нужного только локально исполняемому скрипту? Тем, что они при каждом запросе передаются на сервер. То есть 10 кб. информации в куки — 10 кб. ненужных отправляемых на сервер данных при каждом запросе на этот домен. А хранить такие (и даже несколько большие) объемы информации бывает нужно. Вспоминается случай, когда пользователю нужно просмотреть много наименований, а затем сравнить несколько понравившихся (это «несколько» может исчисляться десятками). Фактически нужно просто сохранить набор ссылок, однако делать это следует на стороне клиента (затем меню с этими закладками формируется на странице скриптом), поскольку авторизации на сайте и профилей пользователей нет, нет никакой регистрации, хранить эти данные между сессиями попросту больше негде. Раз встречался такой случай, думаю, найдутся и другие. Так что технология найдет своего потребителя.

Кеширование не для джедаев?

Почему вы считаете XML-синтаксис «правильным», а sgml-синтаксис — «неправильным»? Почему «правильно» закрывать одиночные теги слешем? Набор одиночных тегов в HTML заранее известен парсеру, и он сам в состоянии без подсказок определить, где тег парный, а где — одиночный. Почему нельзя поручить парсеру самому понять, где, например, заканчивается <p> или <td>? В синтаксически корректном документе это совершенно очевидно из контекста. Зачем, в конце концов, все атрибуты в кавычки заключать, если заведомо известно, какие значения требуют кавычек, а какие — нет? А насчет DTD и схем — а как это противоречит сказанному? Для HTML-синтаксиса DTD не применяется? Впрочем, если для вас HTML5 — это только хеды, футеры, и асайды, а XHTML — это слеши в конце одиночных тегов, DTD и схемы, то на этом уровне обсуждать вопрос просто неинтересно. И то и другое включает в себя гораздо больше нюансов. Как удобных, так и неудобных, как полезных, так и сомнительных. На основе этого как раз и делается выбор. Тут еще могут влиять используемые технологии, конечно, но часто ли выходной документ создается XML-сериализатором, который кроме XML больше ничего не умеет?

В смысле — не так много я видел? Я сужу не по вашему сайту или вашим проектам (я вообще их не видел), а по тому, что такие оптимизации вы считаете излишними. Значит нагрузки еще не требуют таких оптимизаций, только и всего.

Если на вашем сайте 3 калеки в базарный день — то проку нет. За всех не говорите

Да я-то решил, просто хочу понять тех, кто видит в XHTML какие-то веские преимущества. А они от ответа уходят

Вы забываете, что в генерации (X)HTML обязательно на каком-либо этапе участвует человек. Одна ошибка человека — и страница не отображается. В общем, на свалку XHTML в перспективе отправить очень хочется. Строгость в этом случае — недостаток, а не преимущество. А в чем преимущества-то?

Эээ… Ничего, что это системный элемент, и в разных браузерах, в разных ОС он может отображаться совершенно по-разному? В какое состояние сбрасывать стили, что считать стилями по умолчанию? Если рассчитывать только на браузеры, и только на современные версии, можно попробовать селектор :not Сам не использовал на практике, но должно быть что-то вроде input:not([type=file]) Ну или как вариант — перечислить в селекторе все типы инпутов, кроме file.

Я, конечно, не художник, чтобы красиво, но: .head { width: 902px; height: 131px; margin: auto; /* auto ставит нулевой вертикальный отступ, так что указывать это явно нет необходимости */ border: solid #979c98; border-width: 0 1px; background: #d9e2da } и да, стили навешиваем на класс.

Воскресная схватка двух Якодзун… А по теме: самый занудный, конечно, я

В вебките textarea — инлайн-блок. vertical-align: bottom или display: block решают проблему.

Стандарт — это стадия развития спецификации (ну формально это не стандарт, а рекомендация, но смысл тот же). Пока спецификация не вошла в стадию рекомендации — стандарта еще нет, а спецификация уже есть.

Это как-то опровергает утверждение, что стандарта еще нет?

Экранируйте специальные символы слешем. Можно делать автоматически.

Да я решил свою проблему уже Может даже от настроек конкретного сервера зависит. Мне, вроде, помог редирект на ./

в смысле если редирект выполняется на урл вида /seciton/article/ без протокола и домена.

Подсказали, в чем дело. Оказывается, что если урл начинается со слеша, то редирект обрабатывается прозрачно на сервере, браузер никакого редиректа не видит. У меня была как раз эта ситуация.