ホームページ > ウェブフロントエンド > htmlチュートリアル > Web セマンティック標準の解釈_html/css_WEB-ITnose

Web セマンティック標準の解釈_html/css_WEB-ITnose

WBOY
リリース: 2016-06-21 08:55:12
オリジナル
1052 人が閲覧しました

原文: https://github.com/kuitos/kuitos.github.io/issues/33

2015 年末に BEM 手法に関する記事を書きました (実践的な内容は同じではありません) これはオリジナルの BEM の記事ではありません) 記事の最後に、Web セマンティクスについて話したいと言いました。 2016年最初の記事は穴を埋めるために使われます!

セマンティクスとは

セマンティック Web は、アプリケーション、企業、コミュニティの境界を越えてデータを共有および再利用できるようにする共通のフレームワークを提供します。 --Wikipedia

セマンティック Web には、端末間でデータを共有/再利用する機能があります。

HTML システムの場合、Web セマンティクスとは、ページが適切な構造を持ち、ページ要素に意味があり、人間と機械の両方が容易に理解できるように、意味的に適切なタグを使用することを指します。

意味論的には理解されているようですが、実際の状況はそれほど楽観的ではありません。

さまざまないわゆる CSS デザイン パターンについて話しましょう

  • OOCSS (オブジェクト指向 CSS)

    ...CSS の「オブジェクト」 」は繰り返しの視覚的なパターンであり、HTML、CSS、場合によっては JavaScript の独立したスニペットに抽象化でき、そのオブジェクトはサイト全体で再利用できます。 — Nicole Sullivan

    <div class="item">  <ul class="item-list">    <li class="item-list--item">      <h3 class="item-heading">...      <button class="button button-primary">primary</button><button class="button button-info">info</button>
    ログイン後にコピー
    目標。 :

    • HTML 構造への依存を減らす

    • CSS クラスの繰り返し使用を増やす

  • SMACSS(Scalable and Modular Architecture for CSS)

    ...CSS を使用する場合のサイト開発への一貫したアプローチを文書化する試み — SMACSS

    <div class=“container”>      <div class=“container-header”>        <div class=“container-header__title”>              <h1 class=“container-header__title--home”>
    ログイン後にコピー
    CSS アーキテクチャ スタイル

  • BEM(Block,Element,Modular)

    BEM アプローチにより、Web サイトの開発に参加する全員が確実に同じコードベースで動作し、同じ用語を使用します — BEM 手法

    <ul class="menu">      <li class="menu__item">...</li>      <li class="menu__item_state_current">...</li>      <li class="menu__item">...</li></ul>    
    ログイン後にコピー
    SMACSS と同様

  • METACSS (Atomic CSS)

    <div class="fl mr10 red">    <span class="blue fl"></span>    </div> 
    ログイン後にコピー
  • WTFSS

なぜこれほど無限の (そして奇妙な) CSS デザイン パターンがあるのでしょう

カスケード スタイルシート (CSS) は、HTML または XML (SVG や XHTML などの XML 言語を含む) で記述されたドキュメントのプレゼンテーションを記述するために使用されるスタイルシート言語です。CSS は、要素を画面上、紙上、音声などでどのようにレンダリングするかを記述します。 -MDN

  1. CSS 自体には論理的な表現能力と抽象化能力がないという欠点があります

  2. クソ。 。 。したがって、私たちは病気になるコストをより効果的に削減する必要があります。 。

しかし、これらは客観的な理由の一部にすぎません。主な理由は、Web セマンティクスの理解が不十分であり、ワークフローが間違っていることです。

パフォーマンス中心 (UI 指向) VS 情報中心 (セマンティクス指向)

パフォーマンス中心のワークフロー: 要件プロトタイプ --> UI 設計ドラフト --> HTML/CSS を使用した

要件のプロトタイプ --> 要件を分析して HTML で記述 --> スタイルを分析して CSS で実装

この 2 つの最大の違いは、UI 指向のワークフローでは、HTML/CSS は UI を実装する単なる手段であるのに対し、純粋な Web 開発 (セマンティック指向のワークフロー) では、情報中心、つまり最初に考慮する必要があることです。情報の本質 (セマンティクス) を理解して適切なタグでマークし、最後にスタイルと動作 (UI) を検討します。

これほど多くの CSS デザイン パターン (何と呼ばれているのかは知りませんが) が次々に登場しているのは、それらのほとんどがパフォーマンス中心の「ベスト プラクティス」であるためであり、2 つの方法論自体はには適していません。

純粋な Web 開発はなぜセマンティック指向 (情報中心) なのでしょうか?

  1. Web の誕生の目的は、インターネット上でリソースと情報を配信することです。 。 HTML は元々、インターネット上の主要なコンテンツ キャリアとして設計され、それ自体が情報を記述するために使用されていました。 Web の初期には、HTML はインターネット上で送信/共有される文書の情報を表現するための汎用記述言語として使用されました。 Web World Wide Web

    World Wide Web (WWW) は、ドキュメントやその他の Web リソースが URL によって識別され、ハイパーテキスト リンクによって相互リンクされ、インターネット経由でアクセスできるオープン ソースの情報空間です。

    コンピュータの普遍的に理解される言語としての HTML

    世界的に配布する情報を公開するには、世界的に理解される言語、つまりすべてのコンピュータが使用できる一種の出版母語が必要です。

  2. Web 分野の一連のインフラストラクチャとテクノロジー (HTTP、REST、HTML などを含む) は、セマンティック中心の方法で設計されています。 UI 中心の方法論を採用すると、必然的にインピーダンスの不整合が生じます。

  3. w3c官方也在致力于推广Web语义化

    • 各种表现型标签/属性在HTML5中被废弃/不推荐使用(center、big、width等)

    • HTML5中新增的各种语义化标签(header、nav等),而这些标签在表现上跟div无二。

CSS语义化?

通常意义上我们说的CSS语义指的是class的语义。class作为HTML与CSS之间的主要钩子,却是被我们误解最深的一个东西。

There are no additional restrictions on the tokens authors can use in the class attribute, but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content. --w3c

class属性本意是用来描述元素内容的,而不是描述元素展现的。其典型‘反模式’代表就是METACSS。看看这两段代码,哪一个更容易理解?

<!-- 以表现为中心 --><div class="fl mr10">    <span>userName:Kuitos</span><div><!-- 以信息为中心 --><div class="user-info">    <span>userName:Kuitos</span><div>
ログイン後にコピー

class作为HTML描述属性集的一部分,本身是用来细化内容语义的,所谓的CSS语义化本质上就是HTML语义化。

符合标准的最佳实践

在CSS领域发展的初期,严格意义上的“最佳实践”都是不存在的,这主要受制于CSS的支持度,大部分浏览器的CSS的支持不够好,所以也导致我们很难在表现及语义之间做平衡。所以我们在翻看HTML标签的时候会看到诸如

这类纯样式的历史性标签(这些标签已经不被HTML5 spec推荐使用)。

但是为什么到了CSS已经如此强大(且浏览器支持度也都挺好)的年代,依然会出现那么多实质还是以表现为中心提出的所谓“最佳实践”?其实,这归结起来,源于我们对于CSS复用的这种刚性需求。

以OOCSS为例,我们写一组按钮可能会这么写:

<button class="button-primary"></button><button class="button-error"></button>
ログイン後にコピー
.button-primary {    width: 80px;    height: 40px;    background-color: green;    ...}.button-error {    width: 80px;    height: 40px;    background-color: red;    ...}
ログイン後にコピー

我不能每写一个button都重复一遍宽高啊,要复用,所以我们可能会把公共部分提取出来

<button class="button button-primary"></button><button class="button button-error"></button>
ログイン後にコピー
.button {    width: 80px;    height: 40px;}
ログイン後にコピー

如果你秉承这个思路,当哪天产品要求第一个按钮要左排第二个要右排的时候,我估摸着你会很自然的这么去写:

<button class="button button-primary float-left"></button><button class="button button-error float-right"></button>
ログイン後にコピー
.float-left {    float: left;}.float-right {    float: right;}
ログイン後にコピー

更甚者,哪天产品要求第二个按钮跟右边隔10像素,你会不会这么写?

<button class="button button-error float-right mr10"></button>
ログイン後にコピー

css我就不写了mr10什么意思我猜你已经知道了。。

且不说 这种写法中button本身就是一种冗余信息(我当没看见也罢), mr10则基本上无法忍受了,仔细想想这跟直接写inline-style有什么差别?相反我写inline-style更符合标准,至少我是挂载在专门用于描述表现的style属性上面,而不是用来描述内容的class上面。

基于这样的一连串演进,最后大概会诞生出两个症状:

  1. 样式类 即一系列诸如 mr10 fl之类的class

  2. 多class症 即几乎每个元素上都要挂载至少一个class。

原因在于,如果我们需要达到复用的效果,最后必定会魔障出一条理念:样式需具备独立性与上下文无关,同时粒度需要够小(样式类/通用原子类)。

其中也有一个主要原因是我们对CSS的误解

css = 层叠样式表,其关键词在层叠

“复用”需求最后一定会导致我们样式退化到平级的单class规则定义,因为这样才能足够无状态。但实际上CSS最独特的地方在于层叠,你避开这种机制从而来满足复用需求,最后不单单丧失了CSS的能力,反而会催生出一系列不符合语义化标准的反模式。

但是我也说过,复用是刚需,而CSS又不具备抽象能力,所以我们只能眼睁睁的看着一坨坨屎流行么?

好在我们有预处理器

最佳实践 Sass/Less

Sass/Less我这里就不一一赘述了,时至今日相比大家都很熟悉。为什么说最佳实践是Sass/Less呢?简单来说,就是这类预处理器在提供一定的抽象能力的同时,也不会破坏css自身的特性。拿上面的例子来看,如果我们使用Sass/Less的写法:

%button {    width:80px;    height:40px;}.button-primary {    @extend %button;    background-color: white;}.button-success {    @extend %button;    background-color: green;}.button-error {    @extend %button;    background-color: red;}
ログイン後にコピー

如果我们在项目级别需要统一的配色,可以做进一步的抽象

$primary-bgc: white;$success-bgc: green;$error-bgc: red;.button-primary {    @extend %button;    background-color: $primary-bgc;}.button-success {    @extend %button;    background-color: $success-bgc;}.button-error {    @extend %button;    background-color: $error-bgc;}
ログイン後にコピー

同样的手段还有mixin。我们可以将我们需要复用的“样式类”抽象成placeholder/mixin(对于“通用原子类”这样的需求我推荐用placeholder),然后使用语义化的 class/属性 作为钩子,来组装这些“原子类”(但实际上这些“原子类”对CSS而言是不可见的)。比如我们用a标签来模拟一个提交按钮,我们应该这样写:

<a href="#" role="submit-button">提交</a>
ログイン後にコピー
a[role="submit-button"] {    @include .button-success;}
ログイン後にコピー

所以css的最佳实践应该是: Sass + OOCSS/BEM/METACSS

这里有一个关键点在于,我们在使用这些css抽象方法论来写sass的时候,切记不要把中间变量暴露给css。什么意思呢,button那个例子我这样来写

.button{    width: 80px;    height: 40px;}.button-primary {    @extend .button;}
ログイン後にコピー

此时button对于css而言是可见的。对于button这类抽象产物,我们应该用placeholder和mixin代替,确保其对css的不可见从而保证web的“纯度”。(这也是我不推荐Less的原因,Less最大的失误在于没有placeholder的设计)

到这里估计思考过的同学会有疑问:很多场景可能并没那么容易语义化,比如我要第一个元素左浮动,第二个元素右浮动,第三个又左浮动,第四个右浮动。。。

这里需要提到另一个经常被误解的点:selector。selector作为HTML与CSS的结合点,实质上也是需要语义化的。tag跟id是天生带语义的,主要问题还是出在class上。我们总是尝试在class上挂载一些表现型的“名称”。这里面有一小部分确实是由于CSS本身的不完美(比如layout这种场景细则就比较难语义)导致的,但是过多的则归咎于我们语义化动力不足及对selector的认知不够。语义化动力不足完全是主观因素这里不赘述,对selector认知不够则是最普遍存在的情况。推荐阅读: 为后代选择器及id选择器辩护 结合智能选择器的语义化的CSS

综上所述,如果要秉持纯粹的Web开发,最佳实践是:

合适的语义化标签 + 语义化selector + Sass

为什么一定要按标准来?

其实我不太想回答这种问题。。。我更想反问:为什么不按标准来?!!

一定要说的话:

  1. 推行标准的目的是为技术交流构建一个统一的上下文语境平台,提高沟通效率,避免鸡同鸭讲。

  2. 同时标准跟规范的制定是经过一群 资深开发者/科学家 经过仔细研究及社区讨论的,一套完整的一致的基础架构系统是推进生态发展的必要条件。

  3. 就Web语义化这件事情而言,如果你的HTML是基于标准来编写的,意味着你的页面具备更多的可能性。比如搜索引擎友好,多终端适配(不是响应式。。是指兼容各种阅读设备、读屏软件等。参见 microformats),更智能的风格查错能力。

  4. 在前端开发体系里,能体系专业性的地方不多。。拿程序复杂度而言,它跟大型后端系统差不止一个量级(前端的难度在于工程上)。。好不容易有一个能体现专业素养的领域(语义化Web),为什么我们不抓住机会为自己正名呢。。

関連ラベル:
ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート