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

Ответ 1

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

Правильный подход, приведенный выше, заключается в том, чтобы позволить различным командам справляться с различными задачами. Для этого требуется (возможно) первоначальный графический дизайн, который может быть довольно грубым, и документированный и согласованный на совместной основе набор соглашений об именах для таких вещей, как "#viewport", ".user" и т.д.

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

Это последнее только мое $.02, но где один человек является одновременно ролями, опять же я думаю, что сначала вы возглавляете разметку/бэкэнд, а затем итеративно переходите к этапу проектирования, затем разметки, а затем проектируете по мере необходимости.

Ответ 2

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

• Если вы используете валидатор для css или html, не делайте вид, что все ваши html или css проходят тест. Очевидно, что идеальной целью является то, что все проверяется, но на первом этапе я думаю, что лучше не тратить много времени на вопросы валидации. И помните, что ни один валидатор не идеален, и хороший способ использовать его вначале - направлять вас в правильном направлении и избегать больших ошибок (например, дважды вводить один и тот же идентификатор на одну страницу или помещать элементы блока внутри встроенных...). Затем, когда приложение находится на хорошей стадии, вы можете сделать ваш css и html совершенным и действительным.
• Не создавайте интерфейс в конце. Я думаю, что интерфейс приложения может дать вам хорошие указания в том, как развивать ваш back-end тоже. Итак, на вашем месте, я бы сначала разработал интерфейс с html и css, а затем я начал бы добавлять к нему функциональность.

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

Есть причины, объясняемые в 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). Я уверен, что вы можете найти больше примеров.

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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