W3C中国

W3C发布XSL转换(XSLT)3.0版标准草案最终征求意见稿

2013年12月12日,W3C的XSLT工作组发布了XSL转换 3.0版(XSL Transformation, XSLT 3.0)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了XSLT 3.0的语法和语义。XSLT是一个XML文档格式转换的语言,定义从一个XML文档格式转换到另一个XML文档格式的转换规则。XSLT语言的转换采用良构的XML格式的样式单(Stylesheet)方式定义。欢迎您于2014年2月10日前提交对该标准草案的意见和建议。

更多信息,请参阅W3C的可扩展标记语言标准计划(Extensible Markup Language/XML Activity)。 查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。  

W3C发布DOM解析和序列化的标准草案最终征求意见稿

2013年12月10日,W3C的Web应用工作组(Web Applications Working Group)发布了文档对象模型解析和序列化(DOM Parsing and Serialization)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了各种API,允许Web应用通过编程方式访问HTML及通用的XML的解析器,对DOM节点(DOM nodes)进行解析和序列化。欢迎您于2014年1月7日前提出您对该标准草案的意见和建议。 

更多相关信息,请参阅该消息的英文摘要,及W3C的富Web客户端标准计划(Rich Web Clients Activity)。 

W3C发布跨源资源共享的提案推荐标准 向公众征求意见

2013年12月5日,W3C的Web应用工作组(Web Applications Working Group)Web应用安全工作组(Web AppSec)联合发布了跨源资源共享(Cross-Origin Resource Sharing)的提案推荐标准(Proposed Recommendation)。该标准定义了在必须访问跨域资源时,浏览器与服务端应该如何沟通,它提供一种机制,允许客户端(如浏览器)对非源站点的资源发出访问请求。所有提供跨源资源请求的API都可以使用本规范中定义的算法。
 

处于安全性的考虑,用户代理(如浏览器)通常拒绝跨站的访问请求,但这会限制运行在用户代理的Web应用通过Ajax或者其他机制从另一个站点访问资源、获取数据。跨源资源共享(CORS)扩充了这个模型,通过使用自定义的HTTP响应头部(HTTP Response Header),通知浏览器资源可能被哪些跨源站点以何种HTTP方法获得。例如,浏览器在访问 http://example.com 站点的Web应用时,Web应用如果需要跨站访问另一站点的资源 http://hello-world.example,就需要使用该标准。http://hello-world.example 在HTTP的响应头部中定义 Access-Control-Allow-Origin: http://example.org,通知浏览器允许 http://example.org 跨源从 http://hello-world.example上获取资源。


欢迎您在2014 年1月14日前提出对于该标准的意见和建议。关于跨源资源共享的更多信息,请参阅 CORS W3C Wiki。更多信息请参考W3C的安全标准计划(Security Acitivity)富Web客户端标准计划(Rich Web Client Activity)。我们非常期待听到您的意见。

提案推荐标准是W3C标准制定流程的一个环节,指标准的技术性和可实现性已经经过广泛的审查和验证,W3C正式将标准文本提交给W3C顾问委员会作最后批准。经过批准后,W3C将发布正式的推荐标准(REC)。查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。   

W3C发布CSS Shapes的标准草案最终征求意见稿

12月3日,W3C的级联样式单(CSS)工作组发布了CSS形状(CSS Shapes Module Level 1)的标准草案最终征求意见稿(Last Call Working Draft)。CSS Shapes允许开发者用CSS定义一个几何形状,在Level 1中,CSS Shapes可以,定义非矩形的形状,提供围绕指定形状的浮动布局(floats)能力。一般的盒模型(Box)允许内容围绕给定的矩形区域布局,而一个圆形形状的浮动布局,将使内容环绕所定义的圆形形状区域布局。CSS欢迎您于2014年1月7日提交对该标准草案的意见和建议。

更多信息,请参阅W3C的样式标准计划(Style Activity)。 

查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。  

W3C发布High Resolution Time的标准草案最终征求意见稿

12月3日,W3C的Web性能工作组(Web Performance Working Group)发布了高解析度时间(High Resolution Time Level 2)的标准草案最终征求意见稿(Last Call Working Draft)。该规范定义了一个JavaScript接口,为Web应用提供亚毫秒级(sub-millisecond)解析度的当前时间信息格式。此类信息可以用于应用程序的性能调试或时间同步。欢迎您于2014年1月8日前提交您对该标准草案的意见和建议。

更多信息,请参阅W3C的富客户端标准计划(Rich Web Clients Activity)。 

查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。   

GB/T 15834-2011 Part 5: Positioning of Punctuation Mark

GB/T 15834—2011出版物上数字的用法(General Rules for Writing numberals in Public Text

本文部分翻译了国标GB/T 15834-2011中关于标点符号位置的内容。该国标的中文全文,可以在互联网上找到。


5. Positioning of Punctuation Mark.

5.1 Positioning of Punctuation Mark in Horizontal Writing Mode

5.1.1 Full stops(U+3002), commas(U+FF0C), ideographic commas(U+3001), semicolons(U+FF1B), colons(U+FF1A) should all be after the corresponding text, and carry one em space. They should be placed in the lower left corner, and could not be the start of a line.

5.1.2 Question marks(U+FF1F), exclamation marks(U+FF01) should all be after the corresponding text, and carry one em space. They should be placed in the left side, and could not be the start of a line. When two question marks(or exclamation marks) are used together, they should only carry one em space; when three question marks(or exclamation marks) are used together, they should only carry two em space; when one question mark and exclamation mark are used together, they should only carry one em space.

5.1.3 Left quotation marks(U+2018, U+201C), left brackets(U+FF08, U+3014, U+3010), left double angle brackets(U+300A), and left angle brackets(U+3008) should be placed on the left side of the relative characters and could not be the end of a line, while right quotation marks(U+2019, U+201D), right brackets(U+FF09, U+3015, U+3011), right double angle brackets(U+300B), and left angle brackets(U+3009) should be placed on the right side of the relative characters and could not be the start of a line. Each of these marks should carry one em space.

5.1.4 A double dash(U+2014) is between the two corresponding words, and carry two em space. It should be aligned to the vertical center of the corresponding base character, could not be separated into 2 parts nor to be the start and the end of a line at the same time(原文是“不能中间断开分处上行之末和下行之首”). 

5.1.5 A double ellipsis(U+2026) should carry two em space. When 2 double ellipsis are used together, they should carry 4 em space and make a independent line. A double ellipsis could not be separated into 2 parts nor to be the start and the end of a line at the same time.

5.1.6 The en dash of hyphens(U+2013) is a little shorter than the Chinese character "one" and should carry half an em space; the dash of the hyphens(U+2010) is a little longer than the Chinese character "one" and should carry one em space; the wave dash(U+301C) of the hyphens should carry one em space. All of the hyphens should be aligned to the vertical center of the corresponding base character and should not be the start of a line.

5.1.7 Interpuncts(U+00B7) are between the two corresponding words and carry half an em space. They should be aligned to the vertical center of the corresponding base character and should not be the start of a line.

5.1.8 Emphasis dots and proper marks(underline) should be underneath the characters.

5.1.9 Slash marks(U+002F) carry half an em space and could not be the start not the end of a line.

5.1.10 When a punctuation mark is at the end of the line, to beautify the whole composition, even if it's a full-width character, it should carry the same em space of a half-width character.

5.1.11 In the practice of composition, for a better composition or reading experience, or to avoid the line-breaking of the last character of a bottom paragraph or a new page cause by the last character(which will result in a wasteful and ugly layout), we could reasonably reduce the space of the punctuation mark.

5.2 Positioning of Punctuation Mark in Vertical Writing Mode

5.2.1 Full stops(U+FE12), commas(U+FE10), question marks(U+FE16), exclamation marks(U+FE15), ideographic commas(U+FE11), semicolons(U+FE14), colons(U+FE13) should all be placed in right corner under the corresponding text.

5.2.2 Double dashs(U+2014), double ellipsis(U+2026), interpuncts(U+00B7), slash marks(U+002F) and hyphens should be placed in the middle under the corresponding text, in a vertical writing mode;

5.2.3 Quotation marks(U+FE41, U+FE42, U+FE43, U+FE44) and brackets(U+FE35, U+FE36, U+FE37, U+FE38, U+FE39, U+3A) should be up or down the corresponding text.

5.2.4 Presentation form for vertical wavy low lines(U+FE34) should be on the left side of the the corresponding text.

5.2.5 Sesame dots(U+FE51) should be on the right side while the presentation form for vertical low lines(U+FE33) should be on the left side of the corresponding text.

5.2.6 The rules about whether a certain punctuation mark could be the start or the end of a line in Horizontal Writing Mode are also required in Vertical Writing Mode.

此外,还有相关的GB/T 15835—2011
5.1.7 Line-breaking
An Arabic number in Chinese should stay in one line and never be broken.

[1] CJK标点符号 http://www.unicode.org/charts/PDF/U3000.pdf
[2] 中文竖排标点 http://www.unicode.org/charts/PDF/UFE10.pdf
[3] CJK兼容符号(竖排变体、下划线、顿号)http://www.unicode.org/charts/PDF/UFE30.pdf

感谢Xiaoqian Wu提供翻译文字。

W3C发布Web MIDI API的标准工作草案

W3C的音频工作组(Audio Working Group)于11月26日发布了Web MIDI API的标准工作草案(Working Draft)。该规范定义了支持MIDI协议的API,Web客户端应用可以通过该接口枚举和选择MIDI的输入和输出设备,以及发送和接受 MIDI消息。通过提供底层接入,该API可以使音乐和非音乐MIDI应用访问MIDI设备。Web MIDI API不定义音乐和控制输入的语义,它主要定义MIDI输入和输出接口结构,以及如何发送和接收MIDI消息,而不必识别这些消息/动作的具体含义。 Web MIDI API通常与其它web平台的API和元素联合使用,如Web Audio API。其它系统的MIDI API用户,如Apple CoreMIDI和微软Windows MIDI API用户,将来也应熟悉此API。
 

更多信息请参考W3C的富Web客户端标准计划(Rich Web Client Activity)

W3C发布Filter Effects, CSS Transforms的标准工作草案

W3C的级联样式单(CSS)工作组可扩展矢量图(SVG)工作组于11月26日联合发布了滤镜效果模块(Filter Effects Module Level 1)和CSS变换模块(CSS Transforms Module Level 1)的标准工作草案。

-  滤镜效果模块(Filter Effects Module Level 1): 滤镜效果是在文档显示时对元素进行渲染的处理方式。通常,通过CSS或SVG渲染一个元素的过程如下:元素首先被绘制到一个图像绘制缓冲区中,然后将缓冲区的图像合并到父节点中。滤镜效果可以在缓冲区图像被合并前对图像内容进行处理(如锐化、改变颜色的饱和度等)。尽管滤镜效果最初设计用于SVG图像的处理,但它也可适用于其他的表现环境(如CSS等)。滤镜效果由filter属性中的样式指令触发。

- CSS变换模块(CSS Transforms Module Level 1):该规范允许对经过CSS设定样式的元素,在二维或三维空间中进行变换。该文档定义了一组CSS属性,指导元素在绘制时通过二维或三维转换呈现某些特定效果(如立体效果),该文档是CSS 2D变换(2D transforms)、CSS 3D变换(3D transforms) 和SVG变换的合并。

CSS是描述结构化文本(如HTML、XML等)在屏幕、纸张、语音上如何绘制和展现的语言。更多信息,请参阅W3C的样式标准计划(Style Activity)图形标准计划(Graphics Activity)

 

W3C发布CSS书写模式(Writing Modes)的标准草案最终征求意见稿

11月26日,W3C的级联样式单(CSS)工作组发布了CSS书写模式(CSS Writing Modes Level 3)的标准草案最终征求意见稿(Last Call Working Draft)。CSS Writing Modes Level 3在CSS中对多种不同的国际化书写模式提供支持,如采用从左向右书写的拉丁文字和印度文字、从右向左的希尔伯特语文字或阿拉伯语文字、多语言的双向混合书写,以及部分亚洲语言从上向下的竖排书写文字等。在这一版本中,并未提供自下向上的反向竖排书写文字模式。欢迎您在2013年12月24日前反馈您对该标准草案的意见和建议。

更多信息,请参阅W3C的样式标准计划(Style Activity)

查看更多征集公众意见的标准草案,请参阅目前正在征求意见的标准草案及文档。   

W3C发布CSS样式属性的正式推荐标准

W3C的级联样式单(CSS)工作组11月7日正式发布了CSS样式属性(CSS Style Attribute)的W3C正式推荐标准(W3C Recommendation)。HTML、SVG等标记语言可以为大部分元素提供style属性,用于以内嵌(in-line)的方式定义适用于这些元素的样式说明。该文档定义了用于这些style属性的CSS片段的语法及其解释规则。

更多信息,请参阅W3C的样式标准计划(Style Activity)

查看W3C的所有正式W3C推荐标准(W3C Recommendations),请参阅W3C正式推荐标准列表。   

站内搜索

万维网联盟(World Wide Web Consortium, W3C)是Web领域的国际标准化组织,致力开发开放Web标准确保Web的长期发展,实现“尽展Web无限潜能”的使命。

更多内容>>

近期活动

更多内容>>

W3Cx 开放课程

W3C技术标准

查看Web技术标准
- 所有标准
■ Web与产业融合 ■
- 汽车 | 数字出版 | Web与电信
- 娱乐与广播电视 | Web支付 | Web数据
- 物联万维网(WoT) | Web安全
■ Web For All ■
- Web无障碍 | 国际化 | 索引(A to Z)
■ 社区组与商务组 ■
- 所有社区组 | 新建社区组
■ 标准工作组 ■
- 所有标准小组 | 参与指南

更多内容>>

W3C标准翻译

欢迎您加入W3C翻译计划,了解W3C标准和文档翻译情况,帮助提供不同语言的W3C标准规范及文档的志愿者翻译及W3C授权翻译,惠及全球技术社区。

更多内容>>

贡献榜

我们通过贡献榜,感谢您积极参与W3C的标准制定及审阅工作、提供标准及技术文章的中文翻译、参与各类技术研讨会。

更多内容>>

W3C 中文开发者社区

W3C中国目前正在不断加大全球W3C工作的参与力度,并推动了一系列以了解中国行业需求、引导标准制定为主要目的的工作组(WG)、兴趣组(IG)和社区组(CG)。
Web中文兴趣组 | MiniApps工作组 | MiniApps生态社区组 | 弹幕特别任务组 | 中国信息无障碍社区组 | 中文数字出版社区组 | 数据可视化社区组 | 中文文字布局需求特别任务组

更多内容>>

会员链接

相关资源需要使用 W3C账号登录后使用

首页 | 加入工作组 | 申请W3C账号 | 最新会员消息

开发者资源

合作伙伴

  • 北京航空航天大学
  • 北航计算机学院
  • w3ctech