[css-ruby] Add issue for limiting L1 to two levels. Explain what's complicated and why it's tough to remove those bits.

--HG--
extra : rebase_source : 62dc93de31178937ec09005c413ae37a7dde64be

Author: fantasai

css-ruby/Overview.html

@@ -192,6 +192,26 @@ <h2 class="heading settled heading" data-level=1 id=intro><span class=secno>1 </
 
 	<p><em>This section is not normative.</em>
 
+	<div class=issue id=issue-8c07d92e><a class=self-link href=#issue-8c07d92e></a>
+		<p>Depending on how implementers feel about it,
+		we might want to limit (via the at-risk list) CSS Ruby Layout Level 1, like HTML5,
+		to two levels of annotation.
+		Subsequent levels would be inlined immediately after their ruby segment.
+		(Not sure how to represent that limitation in <code>@supports</code>, though.)
+
+		<p>FWIW, the main complexity item of concern with &gt;2 levels is nested ruby.
+		The next most complex feature, after nested ruby,
+		is allowing two levels of ruby on the same side of the text.
+		Removing either of these features, however, boxes us into a corner.
+		By removing nested ruby handling,
+		we’d create a dependency on nested ruby not being handled optimally
+		(unless we did something dumb and always obviously broken somehow).
+		By forcing a second annotation to be on the opposite side of the first,
+		we create an assumption that it can never be placed on the same side,
+		and that <a class=property data-link-type=propdesc href=#propdef-ruby-position title=ruby-position>ruby-position</a> rules that would place the second annotation
+		on the same side as the first have no effect.
+	</div>
+
 <h3 class="heading settled heading" data-level=1.1 id=placement><span class=secno>1.1 </span><span class=content>
 Module interactions</span><a class=self-link href=#placement></a></h3>
 
@@ -1616,7 +1636,27 @@ <h2 class="no-num no-ref heading settled heading" id=property-index><span class=
 <tr><th scope=row><a class=css-code data-link-type=property href=#propdef-ruby-align title=ruby-align>ruby-align</a><td>start | center | space-between | space-around<td>space-around<td>ruby bases, ruby annotations, ruby base containers, ruby annotation containers<td>yes<td>N/A<td>visual<td><td><td>specified value (except for initial and inherit)<td></table></div>
 
 
-<h2 class="no-num heading settled" id=issues-index><span class=content>Issues Index</span><a class=self-link href=#issues-index></a></h2><div style="counter-reset: issue"><div class=issue>The goal of this is to simplify the layout model by suppressing any line breaks within ruby annotations.
+<h2 class="no-num heading settled" id=issues-index><span class=content>Issues Index</span><a class=self-link href=#issues-index></a></h2><div style="counter-reset: issue"><div class=issue>
+		<p>Depending on how implementers feel about it,
+		we might want to limit (via the at-risk list) CSS Ruby Layout Level 1, like HTML5,
+		to two levels of annotation.
+		Subsequent levels would be inlined immediately after their ruby segment.
+		(Not sure how to represent that limitation in <code>@supports</code>, though.)
+
+		<p>FWIW, the main complexity item of concern with &gt;2 levels is nested ruby.
+		The next most complex feature, after nested ruby,
+		is allowing two levels of ruby on the same side of the text.
+		Removing either of these features, however, boxes us into a corner.
+		By removing nested ruby handling,
+		we’d create a dependency on nested ruby not being handled optimally
+		(unless we did something dumb and always obviously broken somehow).
+		By forcing a second annotation to be on the opposite side of the first,
+		we create an assumption that it can never be placed on the same side,
+		and that <a class=property data-link-type=propdesc href=#propdef-ruby-position title=ruby-position>ruby-position</a> rules that would place the second annotation
+		on the same side as the first have no effect.
+	</p><a href=#issue-8c07d92e> ↵ </a></div>
+
+<div class=issue>The goal of this is to simplify the layout model by suppressing any line breaks within ruby annotations.
 			Alternatively we could try to define some kind of acceptable behavior for them.
 	<a href=#issue-8af70305> ↵ </a></div><div class=issue>Make this into an example:
 		<img src=http://lists.w3.org/Archives/Public/www-archive/2014Jun/att-0027/PastedGraphic-1.png style="display: block; width: 100%">

css-ruby/Overview.src.html

@@ -32,6 +32,26 @@ <h2 id="intro">
 
 	<p><em>This section is not normative.</em>
 
+	<div class="issue">
+		<p>Depending on how implementers feel about it,
+		we might want to limit (via the at-risk list) CSS Ruby Layout Level 1, like HTML5,
+		to two levels of annotation.
+		Subsequent levels would be inlined immediately after their ruby segment.
+		(Not sure how to represent that limitation in <code>@supports</code>, though.)
+
+		<p>FWIW, the main complexity item of concern with >2 levels is nested ruby.
+		The next most complex feature, after nested ruby,
+		is allowing two levels of ruby on the same side of the text.
+		Removing either of these features, however, boxes us into a corner.
+		By removing nested ruby handling,
+		we'd create a dependency on nested ruby not being handled optimally
+		(unless we did something dumb and always obviously broken somehow).
+		By forcing a second annotation to be on the opposite side of the first,
+		we create an assumption that it can never be placed on the same side,
+		and that 'ruby-position' rules that would place the second annotation
+		on the same side as the first have no effect.
+	</div>
+
 <h3 id="placement">
 Module interactions</h3>