CSS 规范

[anjia]

理解 CSS 规范

要理解 CSS specifications，需要理解规范构建的 context, vocabulary 和 fundamental concepts。

1. 每个规范都有它的上下文，可以读 CSS Snapshot, 以及 CSS Design Principles
   • CSS Snapshot 2017 https://www.w3.org/TR/CSS/#css
   • CSS Snapshot 2017/2018
2. 规范是如何组织的，即规范的行文结构
3. 描述规范对实现者的期望的词汇，详细见 #18
   • eg. MUST, MUTS NOT, SHOULD, SHOULD NOT
4. 仔细阅读以下规范，里面有重要的 rules 和 concepts
   • Cascading and Inheritance
   • Display
   • Box dimensions
   • visual formatting model
   • Controlling box generation
   • positioning schemes
   • containing block

注意：

• errata 勘误表，在每个 spec 的顶部
• corrections 修正

另外：

• work with it
• write test cases, and explain why
  • 官方对规范的 conformance test https://www.w3.org/Style/CSS/Test/

https://www.w3.org/Style/CSS/read

[anjia]

如何阅读 W3C 规范

1. 规范不是用户手册
   • 目标用户是 Implementers，不是 end users
     • user manual/reference guide：寻找答案，看某个技术如何使用
     • spec：是告诉实现该技术的程序员，这个特性是什么样的以及怎么实现
   • 如果你想学最新的技术，规范文档可能是唯一可用的资料
     • 那此时，读规范就很必要了。
2. 规范的结构：大多数 W3C 规范都有一部分，专门解释文档本身
3. 如何读：泛读+精度
   • 碰到 Illustration 时，需细读，看看 labels 和 callouts（标签和标注）
   • 碰到有 Examples 的章节时，需细读
4. 规范里的词汇/术语 #18
5. namespaces，命名空间
6. BNF
7. DTD, Document Type Definition，帮助理解 syntax 问题（句法问题）
8. IDL, Interface Definition Language，eg.操作 DOM 的 API

https://alistapart.com/article/readspec

[anjia]

CSS Standardization 的过程

CSS 既是 standard 又是还在开发中的 technology。所以知道 CSS 的哪部分能用哪部分还不能用，挺重要的。这里聊下 CSS 工作组是如何追踪这些变动的。

找到最新的 CSS 状态

• 目前共有4个快照，最新的见 https://www.w3.org/TR/CSS/
  • https://www.w3.org/TR/css-2010/
  • https://www.w3.org/TR/css-2017/ 是当前最新的
  • 理论上每隔1-2年会出一个新的，这取决于期间有多少 CSS 变成了 stable 的
• 对新特性感兴趣的，可以看 https://www.w3.org/Style/CSS/current-work
  • 它展示了 CSS 所有现存部分的 current status，以及一小段描述
  • eg.各种 experimental features
• 对 CSS 的使用者来说，情况就不那么清晰了
  • 这里有全部的规范，可自行查看REC的，https://www.w3.org/TR/
  • 但问题是即便是REC了，只能说明在部分浏览器里实现了，而不是全部的浏览器
  • 所以...在编写 CSS 时需要考虑优雅降级

modules 和 snapshots

• modules
  • 每个 module 定义了 CSS 的一部分
  • 这让规范可管理，也让 CSS 能渐进式发展
• snapshots，是个独立的文档
  • 它定义了 CSS 的 current scope 和 state
  • 只包含了工作组认为 stable 的模块（有足够的开发经验能保证其的稳定性）
  • 但是，快照里列出的规范并未冻结
    • 还包含着CR的规范
    • 即便是REC的，也在接收着 errata

modules 和 snapshots 是两种类型的文档。
它们之间的不同，也仅仅是 CSS WG 内部的约定俗称罢了。
当然，其它工作组可能不这么用。

文档状态

• WD
• LC LCWD
• CR
• PR
• REC

适用于 W3C 的所有工作组，详细说明见 #18.状态缩写

规范的演进不是线性的

e.g.

• LCWD时期的广泛 review 经常会导致多个WD
• 很多规范会进入CR两次，因为测试未覆盖全，然后会被回退到WD
• 所以，CSS snapshot 不会包含全部的 CR

Levels

CSS 没有传统意义上的版本，但它有 levels。每个 level 都是在上一个 level 的基础上，refining 定义、添加 features。每个高 level 的 feature set 是任何低级别的超集，给定 feature 所允许的 behavior 是较低级别的子集。总之，向前兼容。

• CSS Level 1：已经 obsolete
• CSS Level 2
• CSS Level 3：按模块逐级构建。它们不会和 CSS 2.1 相矛盾，而只是添加功能、改进定义。让模块以不同的速度发展，根据工作组的优先级和功能本身的复杂性。

https://www.w3.org/Style/2011/CSS-process

[anjia]

W3C技术报告开发流程

1. 文档的状态码：描述规范的成熟度，详见 #18
2. 图1：标准演进过程，遵循的步骤
3. 图2：当要进行修改、重新编辑时

https://www.w3.org/2018/Process-20180201/#Reports

[anjia]

W3C

• W3C 的介绍，见 #28
• W3C 的使命和历史，见官网 https://www.w3.org/Consortium/

[anjia]

关于 CSS WG

• People and Roles
• Communication
• Making Decisions
• Modularization
• Spec Process
• Sources of Innovation

1. People and Roles

CSS WG 主要有三种角色：

• module editors
  • 工作内容
    • tracking issues
    • responding to feedback
    • editing the spec
    • driving progress on their modules
  • 自愿加入的
    • pre-existing members of the CSS WG
    • join it when taking editorship of a module
  • 有些模块只有一个 editor，有些有2-3个
• CSS WG members
  • 来自 W3C 会员单位里的
    • 代表公司的角色，但大部分都是作为个人来参与（方便讨论）
    • 桥梁作用，在 CSS WG 和他们的 developers and QA 之间
    • 所有 active members 都有改进 CSS 的 strong desire
  • 由 WG 邀请的 Invited Experts
    • 理论上，是由 CSS WG chairs 任命
    • 实际操作时，是由一名会员提名，并由 CSS WG 批准的
• www-style contributors（之前邮件沟通多些，现在 Github 也扮演类似的作用。并存）
  • 组成人员
    • CSS WG members
    • CSS implementation developers
    • other people with a deep technical interest in CSS
  • 邮件沟通内容/Issues
    • list members post and critique proposals 列出评论
    • make feature requests 提出功能
    • explain use cases 解释用例
    • ask and answer spec questions 问/回答规范相关问题
    • review the CSS WG's work 审核工作组的工作
    • post feedback to the spec editors 反馈问题给规范编辑

除此之外，co-chairs，除了作为工作组成员参与之外，负责：

• 协调会议
• 确保讨论进度
• 和 W3C 的其它组织之间的联系/沟通/互动/协调

2. Communication

定期沟通，都会存档到 www-style

• Mailing Lists, 成员+非成员
  • CSS specs www-style@w3.org
  • CSS test suites public-css-testsuite@w3.org
• Telecons, 约每周一次，一小时
  • 一个 chair（两个轮流），一个 scribe
  • IRC, scribing + links/proposals/code/correction/side comments/jokes
  • 三个 bots
    • RRSAgent 帮助 logging
    • Zakim 管理 phone
    • Trackbot 跟踪 action
• F2Fs, 方便处理 complicated, vague, conflict-ridden 的 issues/彼此了解，非正式互动
  • face-to-face, csswg meets in person
    • 每年3-4次
    • 地点在会员公司的会议室，大约一半在美国，一半在欧洲/亚洲
    • 一般持续3天，9:00am-6:00pm+
  • TPAC 期间，跨组沟通，联合会议
  • AC 会议

放资料的服务器

• www.w3.org
  • 官方CSS规范 w3.org/TR/#tr_CSS
  • CSS WG 主页 w3.org/Style/CSS
  • CSS WG 博客 w3.org/blog/CSS
• dev.w3.org
  • 半官方 ED，最新副本
  • 旧版本, diffs, change logs 通过 cvsweb 接口
• wiki.csswg.org, meetings, track issues, post test suite guidelines, ohter useful documents
• test.csswg.org, CSS test suites and associated systems

除了 WG-level 的讨论，co-editors 也会私下见面/讨论。形式不限

3. Making Decisions

主席主持，讨论。

• 若达成共识，则 RESOLVED
• 如未达成共识，则 straw poll（民意调查），随压倒性的主流
• 若无明显共识，要么 defer 要么 no change
• 最后协调/商讨之后依然无共识，那就 Formal Vote（CSS WG 至今还没用过）

其它：

• 维护现有标准，尽量保证规范的变动和已有实现之间，保持同步
• 制定新标准，需要大量的 brainstorming 和 revision，快速迭代，以响应各种反馈
• editors 会负责
  • editorial tasks
  • executing the WG's decisions
    • 将一定数量的权限委托给 module editor
    • 这样 editor 就能实时响应各种 feedback 了
  • bring the issue to the WG's attention at a meeting
    • 会议上需提出解决的建议/收到的反馈
    • 当 editor 不确定如何解决问题/希望从别人的经验和观点中收益

对于还在发展中的规范，editor 具有决策；
若是比较成熟的，则需要由 CSS WG 作为一个整体来决策

CSS WG review 不仅是 oversight，还算是 solving issues 和 making progress 的一个资源。

CSS WG 就是 CSS 的最高权威机构。

所有的 WG member 都能了解到 what's going on in all of CSS，也能有机会 review 和 comment。WG 重点关注 member 对问题的关注、利用其专业知识参与讨论，确保所有 implementors 都参与 CSS 的最新发展，避免繁琐的正式申诉流程，并确保 CSS 所有模块之间的一致性。

4. Modularization

5. Spec Process

W3C Recommendation Track, 官方有6个阶段。

CSS WG 只有3个正式阶段，其余3个都是正式之间的一个过渡。

从 2007 年实施至今。更精细更主观，也展示了规范如何随着时间的推移而发展的越稳定

1. WD
   • FPWD 第一个官方的WD。意味着工作组所为个整体同意采用此模块。大致如ED里描述的那样
   • WD 规范的 Design Phase，根据 internal and external feedback 进行规范迭代
   • LCWD
     • 一旦解决了所有已知问题，CSS WG 就要 transition WD了
       • 如果没有 building tests 和 implementations 的反馈，那它就算暂时性“死”了
     • 会指明解决所有 Issues 的 deadline，要求 WG 专门跟踪和处理反馈
       • DoC（Disposition of Comments）处理评论，会和 updated draft 一起提交给 Director，等待批准（approval）
2. CR
   • CR 是规范的 Testing Phase
     • 注意，这个阶段是使用 tests 和 implementations 来测试规范本身，而不是测规范的实现
     • 要退出CR，要演示每个特性的两个正确的独立实现
       • 所以在此阶段 WG 需要构建一个 test suites 并生成 implementation reports
   • PR 在此阶段，W3C AC（咨询委员会）会批准过渡到REC
3. REC
   • 这是 W3C 规范的完成状态，意味着 Maintainance
   • 在此阶段，WG 只维护勘误文档，偶尔发布 updated edition（是将勘误同步到规范里）
   • 不会有逻辑性的修改，若有，则须得到工作组的批准

采取哪种类型的改动，很大程度上取决于规范自身的成熟度：

• Exploring (pre-FPWD, early WD) 探索。不完整
• Revising (mid-WD) 修改。大部分完整，功能范围已经明确定义
• Refining (late WD, LCWD) 精炼。非常稳定，几乎可以用于CR
• Testing (early CR) 测试。力求完整、且精确到足以实施
• Stable (late CR) 稳定。稳定可靠，已有足够的测试和实施经验
• Completed (PR, REC) 完成

6. Sources of Innovation

复合体，彼此合作、螺旋发展。创新的来源：

• 从 implementations 派生出来
• 由 standards 驱动 implementations（CSS本身的创建，是这个例子）
• web designers 也来写 web standards

http://fantasai.inkedblade.net/weblog/2011/inside-csswg/