以下是由 Karol K 撰写的客座文章。Karol 代表 ThemeIsle.com 写作,ThemeIsle.com 是一家 WordPress 主题销售商。他向我推荐了这篇文章,我对此很感兴趣。我是一个喜欢按自己的方式做事并将任何我使用的工具强加于它的前端开发人员。这样做是有道理的,但只有在一定程度上。在命名上的哲学差异上浪费数小时通常不值得。在 WordPress 中,你可以强迫它做任何事情,但默认设置通常很不错,而且遵循系统将使事情变得更容易。这就是 Karol 在这里用 CSS 和 WordPress 建议的内容。
在 WordPress 上构建一个网站是一种独特的体验。一方面,你获得了大量开箱即用的功能。另一方面,WordPress 通常期望你在显示内容时使用某些结构来利用这些功能。
WordPress 中的一些结构是自动使用的,无论你如何构建你的设计(例如,所有菜单都是 <ul>
,无论你是否喜欢),而其他结构则可以通过自定义 PHP、WordPress 操作挂钩和 其他技巧 来控制。虽然平台没有施加太多限制,但如果你希望你的内容正确显示,你仍然需要注意最基本的功能。
在本指南中,我们将快速了解构建 WordPress 网站时需要处理的绝对最少 CSS 集。
我的意思是。我们都有自己喜欢的 HTML 和 CSS 结构以及一般编码方式。我不想告诉你什么是对的,什么是不对的。相反,我想列出 WordPress 将会吐出的类,**无论**你在自己身上做什么。简而言之,在你的网站脚手架方面,随意使用你喜欢的任何结构。但是,也要注意默认的 WordPress 类,以确保你的 CSS 尽可能地针对 WordPress 优化。
高级 WordPress 开发人员可能会注意到 WordPress 是高度可定制的,并且可以更改这些默认类,但我们在这里不会深入讨论。
如果我们看一下第一个例子,谈论 WordPress 中非常原生的元素,就更容易解释我的意思。
当我们看一下示例时,你就会更容易理解我的意思,所以让我们看一下广受欢迎的小部件。
样式小部件
很难想象一个完全不使用任何小部件的 WordPress 网站。自从引入以来,小部件在各种各样的网站上都很受欢迎。它们的目的通常是在帖子和页面旁边显示辅助内容,通常是在侧边栏中。
WordPress 自带了一些小部件,许多插件也添加了自己的小部件。在撰写本文时,默认集包括:存档、日历、类别、自定义菜单、元数据、页面、最新评论、最新帖子、RSS、搜索、标签云、文本。
每个小部件都附带其自己的 CSS 类范围,这些类在使用特定小部件时都会包含在内。
WordPress 为所有小部件元素(无论小部件类型如何)分配的类是
.widget {} /* top level class for every widget */
.widget-title {} /* usually on the inner header element */
然后,根据小部件类型,可以使用任何这些类
/* Archives */
.widget_archive {} /* used next to .widget (on the same tag) */
/* Calendar */
.widget_calendar {} /* used next to .widget (on the same tag) */
#calendar_wrap {} /* on <div> wrapping the calendar */
#wp-calendar {} /* on <table> building the calendar */
/* Categories */
.widget_categories {} /* used next to .widget (on the same tag) */
.cat-item {} /* on each item in the <ul> list */
/* Custom Menu */
.widget_nav_menu {} /* used next to .widget (on the same tag) */
.menu-item {}
/* Meta */
.widget_meta {} /* used next to .widget (on the same tag) */
/* Pages */
.widget_pages {} /* used next to .widget (on the same tag) */
.page_item {}
/* Recent Comments */
.widget_recent_comments {} /* used next to .widget (on the same tag) */
.recentcomments {} /* on each item in the <ul> list */
/* Recent Posts */
.widget_recent_entries {} /* used next to .widget (on the same tag) */
/* RSS */
.widget_rss {} /* used next to .widget (on the same tag) */
.rsswidget {} /* on each RSS link */
/* Search */
.widget_search {} /* used next to .widget (on the same tag) */
.search-form {} /* used with the actual <form> element */
/* Tag Cloud */
.widget_tag_cloud {} /* used next to .widget (on the same tag) */
.tagcloud {} /* on the <div> wrapping the cloud */
/* Text */
.widget_text {} /* used next to .widget (on the same tag) */
.textwidget {} /* on the actual text content of the widget */
这里最好的起点是首先对 .widget 类本身进行样式化,并确保主小部件块始终正确显示。然后根据需要对各个类进行样式化。这就是我们一直以来的做法。
与这些默认值一起使用可以更快地构建设计,与想出自己的方式来包装某些元素相比。作为副产品,你还将确保网站管理员在尝试使用任何这些原生小部件时不会看到任何奇怪的东西。
若要查看实际的 HTML 文档结构,我建议你使用默认主题设置一个测试 WordPress 网站,将所有小部件放在侧边栏中,并检查 HTML 源代码。
<body>
样式化 WordPress 在向 <body>
标签添加各种类方面非常慷慨。它们都有不同的用途,并在网站的不同子页面上显示。这使你能够轻松地为不同的页面和不同类型的页面引入自定义样式。例如:类别档案、帖子和作者页面,仅举几例。
让我们从头开始
.home {} /* if it's the homepage */
.page {} /* if it's any page */
.postid-XX {} /* if it's a post - XX is the post's ID */
.rtl {} /* when dealing with right-to-left content */
.blog {} /* if it's the custom blog listing */
.archive {} /* if it's any sort of archive page */
.category {} /* if it's a categories listing page */
.tag {} /* if it's a tags listing page */
.search .search-results {} /* if it's a search results page */
.author {} /* if it's an authors page */
.author-XX {} /* if it's an individual author's archive - XX is the author's nickname */
.date {} /* if it's a date-based archives page */
.error404 {} /* if it's a 404 page */
以上并非完整的类列表,但它足以让你开始并涵盖所有基础知识。
样式化帖子和页面
虽然帖子和页面根据网站的不同而有不同的用途,但 WordPress 本身对它们的处理方式非常相似。帖子和页面都保存在数据库中的同一张表中,并且在网站上显示时也共享相同的通用结构。
因此,根据你处理的是帖子还是页面,WordPress 将为主要内容标签(在 HTML5 中通常是 <article>
)分配以下类。
.post-XX {} /* the ID of the element being displayed; used for both the posts and the pages */
.post {} /* if it's a post */
.page {} /* if it's a page */
.attachment {} /* if it's an attachment; on most sites this is not used */
.sticky {} /* if it's a sticky post */
.format-YY {} /* assigned to custom content types - YY is the name of the content type, e.g. "audio" */
这里重要的部分是像 .post-XX
和 .format-YY
这样的类。它们使你能够为数据库中的任何帖子或页面引入自定义样式,还可以区分网站管理员使用的各种内容类型。CSS 可以做很多事情。有时当你需要看起来不同的页面时,你会倾向于创建全新的模板,但这可能会变得难以控制,所以请记住,在你能够的情况下,依靠 CSS 和这些自定义类。
样式化菜单
WordPress 处理所有菜单的方式非常简单。每个菜单都显示在一个标准的无序列表 (<ul>
) 内。你唯一可以做的事情(不进行一些高级过滤)就是单独对这些列表及其元素进行样式化。
对于包装列表本身的元素,它们完全取决于你和注册菜单区域的方式。因此,这里没有 WordPress 使用的任何默认类。
简而言之,使用什么外部结构取决于你。然后,WordPress 将进入并以列表形式在该结构内显示菜单。
样式化内容
WordPress 为用户提供了一个 WYSIWYG (TinyMCE) 编辑器,让他们可以使用该编辑器创建内容。因此,为了确保所有内容都经过漂亮地样式化,你只需要处理 TinyMCE 输出的每个类。
建议的方法是首先创建一个测试帖子,并在其中放置所有可能的内容类型。然后查看帖子的 HTML 源代码,并将这些类包含在你的 CSS 中。
这里有一个快速备忘单,可以帮助你开始
/* the main classes used for alignment */
.alignnone {}
.alignleft {}
.alignright {}
.aligncenter {}
img.alignnone {}
img.alignleft {}
img.alignright {}
img.aligncenter {}
.wp-caption {} /* img caption */
.gallery {}
.gallery-caption {}
/* styles for img sizes */
img.size-full {}
img.size-large {}
img.size-medium {}
img.size-thumbnail {}
/* not classes, but surely something you should take care of */
blockquote {}
code {}
pre {}
hr {}
del {}
到目前为止,列表中最重要的是图像样式。网站上线后,管理员会定期使用它们,因此你需要确保你的 CSS 能够处理 图像的最奇怪组合。
例如,如果有人将两张图片并排放置,一张是 .alignleft
,另一张是 .aligncenter
会发生什么?如果附近还有第三张图片怎么办?等等。
始终从重置开始
从重置所有默认标签开始你的 CSS 工作是一个好习惯,无论你正在处理什么项目,WordPress 也不例外。
例如,WordPress 的当前默认主题——Twenty Fourteen——使用 Eric Meyer 的重置样式表 的修改版本。
在使用自己的样式表时,也可以从 Meyer 的重置开始。但是,如果你想要捷径,只需下载 WordPress 当前的默认主题,获取其样式表,并将重置部分复制粘贴到你的样式表中。当前默认主题的重置有 400 多行,因此自己构建类似的东西肯定会花费很长时间。
好了!这里有一份 CSS 类列表,可以帮助你开始为 WordPress 主题构建样式表。你对 WordPress 如何使用 CSS 有什么看法?你认为它是否过于臃肿,可以更简洁一些?或者是不是不够?
在这方面,另一个重要的方面是:所有用于评论的类名。
管理员界面的内容编辑器也有样式 ;-)
很棒的集合,为什么没有 gists?
注意:不要使用通用的 CSS 重置,使用 normalize.css。它组织得更好,它不会“以防万一”重置所有内容,并且它不会用应用于所有内容的混乱、冗长的选择器来使开发人员工具混乱。
感谢这个小提示…
感谢分享。这是一个很棒的包。
很棒的文章,很难在 WP.org 上找到这样的信息。
创建新主题时,最好的做法是基于一个入门主题。
非常有用的东西!
在使用 TinyMCE 输出时,另一个需要注意的是
p:empty { display: none; }
,因为 WordPress 喜欢在周围散布空段落。很棒的资源!谢谢!
注意,在“body”部分,我认为
.search search-results
应该是.search .search-results
吗?(请注意第二个声明前的点。)你说得对。是我的错。
已修复。我会关闭这个线程,因为现在已经不那么重要了,但感谢你敏锐的观察。
太棒了,感谢分享。这真是一次有趣的阅读。我认为我已经真正理解了这里的一切——出于某种原因,WordPress 的 CSS 本地类让我困惑了一段时间。这很有帮助。
早在 2010 年,Jeff Starr 就尝试收集所有(当时可用的)WordPress 类和 id——即前端
http://digwp.com/2010/05/default-wordpress-css-styles-hooks/
这种类似 BEM 的方法可能在没有使用其他类的情况下导致更好的性能,但 WordPress 内部类除外。我只是想知道这种方法的持续性以及是否真的可以或应该依赖它。在大多数情况下,事情不会造成麻烦,但如果新的主要 WordPress 版本由于某种原因删除了特定类/id 会怎么样?
这可能会导致主题渲染出现重大故障。我猜调试将是一场噩梦,因为你需要找到不存在的东西(不再存在),即没有使用的 CSS 声明。
我明白,使用上述元素和属性,出现故障的可能性非常小,但对于更“深入”目的的声明呢?比如
.hentry
类,即使 digwp 也不知道它的用途 :-) ?你能不能写一篇关于如何实际搭建一个好的专业 WordPress 网站的文章?我读过你的书。但我的意思是,一篇关于如何以如今的正确方式做这件事的文章。比如,现在的网站上有这些彩色全宽块,你是在模板中设置这些,然后让客户使用自定义字段进行修改,还是创建短代码,并在 WP 的主要编辑文本区域中完成所有操作?我想从专业的角度学习它。
谈到全宽块,大多数情况下,这都是在主题本身内完成的(我的意思是,这是你在编码主题时需要手动实现的东西)。你需要使主题变为全宽,然后通过自定义字段或短代码启用任何额外的功能。在使用短代码时,我发现 Shortcodes Ultimate 插件非常有效。例如,我在这里使用它来启用全宽视差块:newinternetorder.com
简而言之,我认为最简单的解决方案通常是最好的。因此,只需构建一个基本的全宽结构,然后使用短代码来实现你需要的任何自定义外观。