Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CSS 规范 #17

Open
anjia opened this issue Sep 30, 2018 · 5 comments
Open

CSS 规范 #17

anjia opened this issue Sep 30, 2018 · 5 comments
Labels
CSS cascading style sheets W3C

Comments

@anjia
Copy link
Owner

anjia commented Sep 30, 2018 •
edited
Loading

理解 CSS 规范

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

  1. 每个规范都有它的上下文，可以读 CSS Snapshot, 以及 CSS Design Principles
  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 修正

另外：

https://www.w3.org/Style/CSS/read
@anjia anjia added CSS cascading style sheets W3C doing labels Sep 30, 2018
@anjia
Copy link
Owner Author

anjia commented Sep 30, 2018 •
edited
Loading

如何阅读 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 anjia changed the title 理解 CSS 规范 CSS 规范 Sep 30, 2018
@anjia
Copy link
Owner Author

anjia commented Sep 30, 2018 •
edited
Loading

CSS Standardization 的过程

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

找到最新的 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 anjia mentioned this issue Sep 30, 2018
Open
@anjia
Copy link
Owner Author

anjia commented Oct 10, 2018 •
edited
Loading

W3C技术报告开发流程

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

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

@anjia anjia removed the doing label Oct 10, 2018
@anjia
Copy link
Owner Author

anjia commented Oct 11, 2018 •
edited
Loading

W3C

@anjia
Copy link
Owner Author

anjia commented Nov 10, 2018 •
edited
Loading

关于 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, 成员+非成员
  • Telecons, 约每周一次，一小时
    • 一个 chair（两个轮流），一个 scribe
    • IRC, scribing + links/proposals/code/correction/side comments/jokes
    • 三个 bots
  • F2Fs, 方便处理 complicated, vague, conflict-ridden 的 issues/彼此了解，非正式互动
    • face-to-face, csswg meets in person
      • 每年3-4次
      • 地点在会员公司的会议室，大约一半在美国，一半在欧洲/亚洲
      • 一般持续3天，9:00am-6:00pm+
    • TPAC 期间，跨组沟通，联合会议
    • AC 会议

放资料的服务器

除了 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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CSS cascading style sheets W3C
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@anjia