使用严格的 XHTML 并 100% 依赖 CSS 进行视觉样式构建网站是否可行？
我倾向于经常采用学术方法，并在开发中遵循严格的原则，而现实是，如果我稍微不那么谨慎的话，我本可以更快地完成项目。 我正在寻找适当的实用性。
我想采用“禅宗”方法来设计一个网站（用我的话说）“严格使用 HTML 进行内容结构，让 CSS 魔法完成其余的工作”。 这在现实中有多实用？ 我遇到的问题之一是我想先开发（使其功能化）网站，然后再回来设计它。 我知道我希望网站在结构上如何流畅，但我什至还没有开始使用 CSS 布局、图形或任何其他设计内容。 这里正确的方法是什么？
I tend to take the academic approach all too often and adhere to strict principles in my development when the reality is that I could have finished the project sooner had I been a little less cautious. I'm looking to find the right amount of practicality.
I want to take the "Zen" approach to designing a site which (in my words) says "Use HTML strictly for content structure, and let the CSS magic do the rest". How practical is this in reality? One of the issues I run into is that I want to develop (make functional) the site first, then come back in and design it later. I know structure-wise how I want the site to flow, but I haven't even begun playing with the CSS layout, graphics, or any of the other designy stuff. What is the right approach here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
它绝对实用，并提供无限的好处。 事实上，这正是 CSS 以及内容与布局分离的设计目的。
如上所述，正确的方法是让不同的团队处理手头的不同任务。 这需要（也许）一个可能相当粗糙的初始图形设计，以及一套记录在案且协作商定的命名约定，例如“#viewport”、“.user”等。
标记团队通常由后端驱动，并且将通常会稍微领导设计团队，但他们应该而且必须保持足够的灵活性，以便在需要时更改标记，或者将其置于设计人员的控制之下。
最后一个只是我的 0.02 美元，但是如果一个人同时担任两个角色，我再次认为您首先要引导自己进行标记/后端，然后根据需要迭代地进入设计阶段，然后是标记，然后是设计。
It's absolutely practical, and provides infinite benefit. In fact it's exactly what CSS and the separation of content and layout is designed for.
The right approach given the above, is to let different teams get on with the different tasks at hand. That requires (perhaps) an initial graphic design which can be quite rough, and a documented and collaboratively agreed set of naming conventions for things like "#viewport", ".user" etc..
The markup team will usually be backend driven and will usually lead the design team slightly, but they should and must remain flexible enough to change markup where required, or put that in the control of the designers.
This last is just my $.02, but where one person is both roles, again I think you lead yourself with the markup/backend first and then iteratively go to a design stage, then markup, then design, as required.
您想要遵循的方法就是正确的方法。 只有两件事：
（抱歉我的英语不好，欢迎纠正拼写。）
The approach you want to follow is the right one. Just two things:
(Sorry for my english, spelling corrections are welcome.)
它非常实用，您会惊讶地发现您的 HTML 看起来如此干净。 我喜欢使用 CSS 重置文件来帮助入门，我个人喜欢 YUI 重置。 另一个需要考虑的 Zen 项目是使用不引人注目的 JavaScript。 这进一步分离了代码的不同层。 JavaScript 库，例如 jquery、prototype 和 dojo 可以帮助解决这个问题。
It can be very practical and you will be suprised how clean your HTML looks. I like using a CSS reset file to help get started, I personally like the YUI reset. Another Zen item to consider is the use of unobtrusive JavaScript. This further separates the different layers of your code. JavaScript libraries, like jquery, prototype and dojo can help with this.
这是可以做到的，而且我认为你的网站（以及你的网页设计技能，尤其是）会因此而变得更好。 但它也有一定的学习曲线。 它需要比许多人更透彻地了解 XHTML/CSS 规范。
确保您的 HTML 可以被验证只是一个开始。
哦，并确保所有浏览器在渲染页面时都以严格模式运行。
当然，您将需要 IE 支持的解决方法，但这可以通过多种方法来完成。
首先，IE 支持条件注释，允许您包含特殊的 CSS 样式表来修复 IE 错误，这应该可以帮助您完成大部分工作，而不会影响页面的兼容标准版本。
对于某些事情，您可能还需要一些 JavaScript，但对于大多数常见功能来说这不是必需的。
It can be done, and I think your site (and your web design skills, not least) will be much better for it. But it also has a certain learning curve. It requires a more thorough understanding of the XHTML/CSS specs than many people have.
Making sure your HTML can be validated is just the beginning.
Oh, and make sure all browsers run in strict mode when rendering the page.
Of course, you will require workarounds for IE support, but that can be done with several methods.
First, IE supports conditional comments, allowing you to include special CSS stylesheets just to fix IE bugs, which should get you most of the way, without affecting your compliant standard-version of the page.
For some things, you may need a bit of javascript as well, but it shouldn't be necessary for most common functionality.
http://www.webdevout.net/articles/beware-of 中解释了原因-xhtml 反对今天使用 XHTML。 总而言之，XHTML 不受支持，除非您将其作为这样的服务，并且如果您的目标是较旧的浏览器（任何 IE 版本都是旧的，考虑到它的大部分功能是在它们还不成熟且暂时没有进行实质性更改时实现的），您别无选择，但将其作为 HTML 提供。
除非您不需要 XML 提供的功能（如 SVG、MathML），否则请坚持使用 HTML。 与 HTML 相比，您不会有任何明显的优势，不会有更多的语义，也不会有更好的 CSS 支持（甚至更少）。 但是您可以获得更广泛的兼容性，并且您的布局将更加可预测（例如，表格单元格可以从 HTML 中的行中的第一个单元格继承，在 XML 中没有这样的事情，甚至不确定 XHTML 在某处是否有任何例外）。
验证器不会比 HTML 更有助于编写 XHTML。 如果您使用严格的标签，甚至会很烦人，如果您撒谎并说它是 HTML，那么您会想知道 br 标签中的 / 有什么大惊小怪的。 （如果您将 XHTML 作为 HTML 提供，则 Firefox 查看源代码会显示为亮红色）。 我相信您可以找到更多示例。
There are reasons explained in http://www.webdevout.net/articles/beware-of-xhtml against using XHTML today. To summarize, XHTML is not supported unless you serve it as such and if you target older browsers (any IE version is old considering most of its features are implemented when they were still immature and not changed substantially for a while) you have no choice but serve it as HTML.
Unless you don't require features that being XML provides (like SVG, MathML), stick with HTML. You won't have any serious advantage over HTML, be any more semantic, have better CSS support (even less). But you get wider compatibility and your layout will be more predictable (for example table cells can inherit from first cell in the row in HTML, no such thing in XML, not even sure XHTML has any exceptions somewhere).
Validators won't help writing XHTML any more than HTML. Even annoy, if you use a strict one, leaving you wondering what is all the fuss about / in the br tag if you lie and say it is HTML. (Firefox view source shows it bright red if you serve XHTML as HTML). I am sure you can find more examples.
当然，您可以这样做，但要做好准备，它不会在 IE 下呈现。 在最近的一个 Web 项目中，我们的大部分前端缺陷都是修复 IE 中已经在 Firefox 中正常运行的内容。 也许这会在 IE8 中改变，但我对此表示怀疑。 在某些情况下，我们甚至不得不编写一些在 IE 上执行的 JavaScript，以解决仅使用 CSS 无法完成的事情。
Sure, you can do that, but be prepared that it WILL NOT render under IE. On a recent web project, the majority of our front-end defects were fixing stuff in IE that already worked fine in Firefox. Maybe this will change in IE8, but I doubt it. In some cases we even had to write some javascript that would be executed on IE only to work around things that couldn't be done with just CSS.
虽然理论上听起来不错，但您无法 100% 使用 CSS 创建网站布局。 您仍然需要使用一些标记，以便可以应用 css。 也就是说，使用这种方法您可以相当接近理想。 我经常惊讶于一个真正的 CSS 专家实际上需要的标记是多么少。
您真正寻找的更接近“禅宗”的方法是 xslt。 它的工作原理是您的应用程序生成 xml 数据，然后 xslt 将该 xml 转换为 html/css。 这需要学习 xslt，并为生成页面的过程增加了另一层复杂性，但增加了您正在寻找的分离。 在理想的世界中，理论是程序员只需担心生成 xml 数据，然后设计人员可以使用该数据生成视觉效果，但是这种方式很少起作用，因为 xslt 的技术性超出了大多数设计人员的处理能力。 大多数时候，程序员最终都会生成 xslt，这在某种程度上违背了目的。
while it sounds good in theory you cant create the layout for a site 100% with css. You still need to use some markup so that you have something to apply the css to. That said, you can come fairly close to ideal using this method. I'm constantly amazed at how little markup a true css guru actually requires.
closer the "zen" approach that you are really looking for is xslt. it works by your app generating xml data and then the xslt transforms that xml into html/css. this requires learning xslt and adds another layer of complication to the process of generating a page, but adds the separation you are looking for. In an ideal world the theory is that a programmer only has to worry about generating xml data and then a designer can generate the visuals using that data, however it rarely works that way as xslt is more technical than most designers can handle. Most of the time the programmer ends up generating the xslt which somewhat defeats the purpose.
对我有用的一种方法是首先构建 HTML，然后在同一文件的标签中添加一些最小的 CSS（足以创建正确的布局等）。 然后，一旦您对结构感到满意，您就可以将 CSS 提取到单独的文件中和/或完全重新设计 CSS。 这对我来说达到了正确的平衡 - 它仍然是一个轻量级的过程，但它避免了查找和替换内联 CSS 的潜在麻烦。
One approach that works for me is to structure the HTML first, then add some minimal CSS in a tag in the same file (just enough to create the right layout etc). Then once you're happy with the structure, you can pull the CSS out into separate files and / or completely rework the CSS. This strikes the right balance for me - it's still a lightweight process, but it avoids the potential headache of finding and replacing inline CSS.
理论上是的，实际上，浏览器差异可能会迫使您添加一些 JavaScript 来处理差异。
In theoria yes, in practice, browser differences may force you to add a bit of javascript to deal with the differences.
现在……某件事的好处与做这件事的实用性是不同的。 你们是否忘记了 IE，甚至忘记了那些想要完成不可能的事情的痛苦客户端？
我很想说，您必须对您所使用的严格 DTD 做出一些例外，以使其在一组合理的浏览器中工作，并取悦您的网站/网络应用程序的利益相关者。
我是一个标准狂，如果能够建立一个不违反甚至 1 个 DTD 规则的网站，没有人会比我更高兴。 但四年过去了，我还是没能实现实际目的。
当然，如果我是提出我要开发的网站要求的人，那可能是可能的，但我必须改变业务规则来适应这一点。 相信我，这是唯一可能的方法。
Now... Benefits of something is different from practicality of doing it. Are you guys forgetting IE or even the pain-in-the-whatever client who wants the impossible done?
I am tempted to say you have to make some exception to the strict DTD that you are using to make it work in a reasonable set of browsers and please your stakeholder for the website/web-app.
I am a standards freak and no one would be more happy than me if it was possible to build a website that doesn't violate even 1 DTD rule. But after 4 years, I just haven't been able to do it for practical purposes.
Sure if I am the one coming up with the requirements for the website I am going to develop, it might be possible, but I have to bend the business rules to accommodate that. Believe me, that's the only way it is possible.