Merge branch 'master' of github.com:w3c/csswg-drafts

Author: Greg Whitworth

Transitions.md

@@ -4,15 +4,18 @@
 
 ###Open
 
-CSS Table
-* [transition request](https://lists.w3.org/Archives/Member/chairs/2016OctDec/0027.html) 17 Oct 2016
-* investigate fix bikeshed link errors and crash :( (done)
-* next step: publication request
+
+_(none)_
 
 
 ###Closed
 
-_(none)_
+CSS Table
+* [transition request](https://lists.w3.org/Archives/Member/chairs/2016OctDec/0027.html) 17 Oct 2016
+* investigate fix bikeshed link errors and crash :( (done)
+* publication request done
+* [done] (https://www.w3.org/TR/2016/WD-css-tables-3-20161025/) 25 Oct 2016
+
 
 ##Candidate Recommendation
 

css-device-adapt/Overview.bs

@@ -524,7 +524,9 @@ Computed value: auto, or a non-negative number or percentage as specified
 Specifies the largest allowed zoom factor. It is used as input to the
 <a href="#constraining-procedure">constraining procedure</a> to constrain
 non-''zoom/auto'' 'zoom' values, but also to limit the allowed zoom factor
-that can be set through user interaction. The UA should also use this
+that can be set through user interaction. The UA may choose to ignore
+this limit for accessbility/usability reasons – see the relevant note in
+the 'user-zoom' section. The UA should also use this
 value as a constraint when choosing an actual zoom factor when the
 used value of 'zoom' is ''zoom/auto''.
 
@@ -578,6 +580,22 @@ Values have the following meanings:
     </dd>
 </dl>
 
+<div class="note">
+    Authors should not suppress (with <code>user-zoom: fixed</code>)
+    or limit (with <code>max-zoom</code>) the ability of users to resize
+    a document, as this causes accessibility and usability issues.
+
+    There may be specific use cases where preventing users from zooming 
+    may be appropriate, such as map applications – where custom zoom 
+    functionality is handled via scripting. However, in general this 
+    practice should be avoided.
+
+    Most user agents now allow users to always zoom, regardless 
+    of any restrictions specified by web content – either by default, or 
+    as a setting/option (which may however not be immediately apparent
+    to users).
+</div>
+
 <h3 id="orientation-desc">
 The 'orientation' descriptor</h3>
 

css-inline/Overview.bs

@@ -499,10 +499,11 @@ Creating Initial Letters: the 'initial-letter' property</h3>
 		<pre>p::first-letter { initial-letter: 2; }</pre>
 	</div>
 
-	Issue: Define interaction with <a>ruby</a>. Easiest is to make it not apply to/within <a>ruby</a>.
-
 	The 'initial-letter' property does not apply to boxes
-	that are not positioned at the start of the line due to bidi reordering.
+	that are not positioned at the start of the line due to bidi reordering. 
+	
+	The 'initial-letter' property is undefined on children of <a>ruby</a> base container boxes 
+	and on <a>ruby</a> container boxes. 
 
 <h4 id="initial-letter-properties">
 Properties</h4>

css-values/Overview.bs

@@ -1133,10 +1133,10 @@ Absolute lengths: the ''cm'', ''mm'', ''q'', ''in'', ''pt'', ''pc'', ''px'' unit
 		<li>by relating the <a value>pixel unit</a> to the <a>reference pixel</a>.
 	</ol>
 
-	For print media and similar high-resolution devices,
+	For print media,
 	the anchor unit should be one of the standard physical units (inches, centimeters, etc).
-	For lower-resolution devices,
-	and devices with unusual viewing distances,
+	For screen media (including high-resolution devices, lower-resolution devices,
+	and devices with unusual viewing distances),
 	it is recommended instead that the anchor unit be the pixel unit.
 	For such devices it is recommended that the pixel unit
 	refer to the whole number of device pixels that best approximates the reference pixel.