Действительно ли это практично для создания веб-сайта с помощью строгого XHTML и полагаясь на CSS 100% для визуального стиля?

Подход, за которым Вы хотите следовать, является правильным. Всего две вещи:

1. при использовании блока проверки допустимости для CSS или HTML не притворяйтесь, что весь HTML или CSS проходят тест. Очевидно, идеальная цель состоит в том, что все проверяет, но в первой стадии я думаю, лучше не, проводят много времени в проблемах проверки. И помните, что никакой блок проверки допустимости не прекрасен, и хороший способ использовать его вначале состоит в том, чтобы вести Вас в правильном направлении и избежать больших ошибок (т.е. помещать тот же идентификатор дважды в одну страницу или помещать элементы блока во встроенных...). Затем когда приложение на хорошем этапе, можно сделать CSS и HTML прекрасными и допустимыми.
2. не разрабатывают интерфейс в конце. Я думаю, что интерфейс приложения может дать Вам хорошие направления в том, как разрабатывают Ваш бэкенд также. Так, в Вашем месте я разработал бы интерфейс сначала с HTML и CSS, и затем я начну добавлять функциональность к нему.

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

Это может быть очень практично, и Вы будете удивлены, как чистый Ваш HTML смотрит. Мне нравится использовать файл сброса CSS, чтобы помочь начать, мне лично нравится , YUI сбрасывают . Другой объект Дзэн для рассмотрения является использованием незаметный JavaScript. Это далее разделяет различные слои Вашего кода. Библиотеки JavaScript, как jquery, прототип и додзе могут помочь с этим.

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

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

, Конечно, Вы будете требовать обходных решений для поддержки IE, но это может быть сделано с несколькими методами. Во-первых, IE поддерживает условные комментарии, позволяя Вам включать специальные таблицы стилей CSS только для исправления ошибок IE, которые должны получить Вас большая часть пути, не влияя на Вашу совместимую стандартную версию страницы.

Для некоторых вещей, Вы можете потребность немного JavaScript также, но это не должно быть необходимо для наиболее распространенной функциональности.

Существуют причины, объясненные в http://www.webdevout.net/articles/beware-of-xhtml против использования XHTML сегодня. Подводя итоги, XHTML не поддерживается, если Вы не служите ему как таковой и если Вы нацелены на более старые браузеры (любая версия IE является старым рассмотрением, что большинство его опций реализовано, когда они были все еще незрелыми и не измененные существенно некоторое время), Вы не имеете никакого выбора, но служите ему в качестве HTML.

, Если Вы не требуете функций, которые быть XML обеспечивает (как SVG, MathML), палка с HTML. Вы не будете иметь никакого серьезного преимущества перед HTML, будете больше семантическими, иметь лучшую поддержку CSS (еще меньше). Но Вы получаете более широкую совместимость, и Ваше расположение будет более предсказуемым (например, ячейки таблицы могут наследоваться первой ячейке в строке в HTML, никакой такой вещи в XML, даже верный XHTML не имеет исключений где-нибудь).

Блоки проверки допустимости не будут помогать записи XHTML больше, чем HTML. Даже раздражайте при использовании строгого, оставляя Вас задающийся вопросом, что является всей суетой о / в теге br, если Вы лежите и говорите, что это - HTML. (Источник представления Firefox показывает ему яркий красный, если Вы служите XHTML в качестве HTML). Я уверен, что можно найти больше примеров.

в то время как это звучит хорошим в теории, Вы наклоняетесь, создают расположение для сайта 100% с CSS. Все еще необходимо использовать некоторую разметку так, чтобы у Вас было что-то для применения CSS к. Тем не менее можно приехать справедливо близко к идеалу с помощью этого метода. Я постоянно поражаюсь тем, как мало разметки истинный гуру CSS на самом деле требует.

ближе подход "дзэн", который Вы действительно ищете, является xslt., он работает Вашим приложением, генерирующим данные XML, и затем xslt преобразовывает это xml в html/css. это требует изучения xslt и добавляет другой слой сложности к процессу генерации страницы, но добавляет разделение, которое Вы ищете. В идеальном мире теория состоит в том, что программист только должен волноваться о генерации данных XML, и затем разработчик может генерировать зрительный ряд с помощью тех данных, однако это редко прокладывает себе путь, поскольку xslt является более техническим, чем большинство разработчиков может обработать. Большую часть времени программист заканчивает тем, что генерировал xslt, который несколько побеждает цель.

Несомненно, можно сделать это, но быть подготовлены, что это НЕ представит под IE. На недавнем веб-проекте большинство наших дефектов фронтенда фиксировало материал в IE, который уже хорошо работал в Firefox. Возможно, это изменится в IE8, но я сомневаюсь относительно этого. В некоторых случаях мы даже должны были записать некоторый JavaScript, который будет выполняться на IE только для работы вокруг вещей, которые не могли быть сделаны только с CSS.

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

В theoria да, на практике, различия в браузере могут вынудить Вас добавить немного JavaScript для контакта с различиями.

Теперь... Польза от чего-то отличается от практичности. Вы забываете об IE или даже о клиенте, который хочет сделать невозможное?

Я склонен сказать, что вы должны сделать какое-то исключение из строгого DTD, который вы используете, чтобы заставить его работать в разумном наборе браузеров и угодить вашему заинтересованному лицу для сайта/web-приложения.

Я помешан на стандартах, и никто не был бы счастливее меня, если бы можно было создать сайт, который не нарушает хотя бы одно правило DTD. Но спустя 4 года я просто не смог сделать это в практических целях.

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