Overview.bs

<pre class='metadata'>
Title: CSS Text Module Level 4
Shortname: css-text
Level: 4
Status: ED
Work Status: Exploring
Group: csswg
ED: https://drafts.csswg.org/css-text-4/
TR: https://www.w3.org/TR/css-text-4/
Previous Version: https://www.w3.org/TR/2019/WD-css-text-4-20191113/
Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact, w3cid 35400
Editor: Koji Ishii, Google, kojiishi@gmail.com, w3cid 45369
Editor: Alan Stearns, Adobe Systems, stearns@adobe.com, w3cid 46659
Editor: Florian Rivoal, Invited Expert, https://florian.rivoal.net, w3cid 43241
Abstract: This module defines properties for text manipulation and specifies their processing model. It covers line breaking, justification and alignment, white space handling, and text transformation.
Ignored terms: segment break, segment breaks
</pre>

<pre class='link-defaults'>
spec: css-text-3; type: property
	text: text-align
	text: letter-spacing
	text: word-spacing
spec: css-text-3; type: dfn
	text: forced line break
	text: word-separator character
	text: other space separator
</pre>

<h2 id="intro">
Introduction</h2>

	Issue: Add final level 3 content

<h2 id="transforming">
Transforming Text</h2>

<h3 id="text-transform-property" oldids="text-transform, caps-prop">
Case Transforms: the 'text-transform' property</h3>

	Issue: Add final level 3 content

<h3 id=word-boundaries>
Word Boundaries</h3>

	In a number of languages and writing system,
	such as Japanese or Thai,
	words are not deliminated by spaces (or any other character)
	as is the case in English
	(See <a href="https://www.w3.org/International/articles/typography/linebreak">Approaches to line breaking</a>
	for a discussion the approach various languages take to word separation and line breaking).

	However, even if text without spaces is the dominant style in such languages,
	there are cases where making word boundaries (or phrase boundaries) visible
	through the use of spaces
	is desired.
	This is a purely stylistic effect,
	with no implication on the semantics of the text.

	In Japan for instance, this is commonly done in books for people learning the language--
	young children or foreign students.
	People with dyslexia also tend to find this style easier to read.

	The mechanism described in this specification builds upon the existing use
	of the <{wbr}> element
	or of U+200B ZERO WIDTH SPACE
	(See [[UNICODE]])
	in the document markup as a word (or phrase) delimiter.

	Issue: Should we have a shorthand
	for the following two properties?

<h4 id=word-boundary-detection>
Detecting Word Boundaries: the 'word-boundary-detection' property</h4>

	<pre class="propdef">
	Name: word-boundary-detection
	Value: normal | manual | auto(<<lang>>)
	Initial: normal
	Applies to: text
	Inherited: yes
	Percentages: N/A
	Computed value: as specified (However, see special provision for unsupported <<lang>>)
	Animation type: discrete
	</pre>

	<wpt>
		css/css-text/parsing/word-boundary-detection-computed.html
		css/css-text/parsing/word-boundary-detection-invalid.html
		css/css-text/parsing/word-boundary-detection-valid.html
	</wpt>

	This property allows the author to decide
	whether and how
	the User Agent must analyse the content
	to determine where word boundaries are,
	and to insert [=virtual word boundaries=] accordingly.

	A <dfn data-dfn-for='' data-dfn-type=dfn>virtual word boundary</dfn> is similar to the presence
	of the ZERO WIDTH SPACE (U+200B) character:
	it introduces a [=soft wrap opportunity=]
	and is affected by the 'word-boundary-expansion' property.
	Its presence has no effect on text shaping,
	nor on 'word-spacing'.
	However, inserting [=virtual word boundaries=] must have no effect on the underlying content,
	and must not affect the content of a plain text copy &amp; paste operation.

	<wpt>
		css/css-text/word-boundary/word-boundary-109.html
		css/css-text/word-boundary/word-boundary-110.html
		css/css-text/word-boundary/word-boundary-111.html
		css/css-text/word-boundary/word-boundary-112.html
	</wpt>
	<!-- tests missing for "has no effects on...", but it's hard to prove a negative -->

	<dl dfn-type=value dfn-for=word-boundary-detection>
		<dt><dfn>manual</dfn>
		<dd>
			Linguistic analysis is <em>not</em> used
			in any language or writing system
			to determine line wrapping opportunities not indicated by the markup or characters of the element.

			The User Agent must not insert [=virtual word boundaries=].

			[=Typographic character units=] with class SA in [[!UAX14]]
			must be treated as if they had class AL
			(i.e. assuming ''word-break: normal''
			and a value of 'line-break' other than ''line-break/anywhere'',
			there is no [=soft wrap opportunity=]
			between pairs of such characters).

			<wpt>
				css/css-text/word-boundary/word-boundary-101.html
				css/css-text/word-boundary/word-boundary-105.html
				css/css-text/word-boundary/word-boundary-106.html
				css/css-text/word-boundary/word-boundary-115.html
			</wpt>

			<div class=advisement>
				Authors using this value for Southeast Asian languages
				are expected to manually indicate word boundaries,
				for instance using <{wbr}> or U+200B.
				Otherwise, there will be no [=soft wrap opportunity=]
				and the text may overflow.
			</div>

		<dt><dfn>normal</dfn>
		<dd>
			The User Agent must not insert [=virtual word boundaries=],
			except within runs of characters belonging to Southeast Asian languages,
			where content analysis must be performed
			to determine where to insert [=virtual word boundaries=].

			As with ''word-boundary-detection/manual'',
			[=typographic character units=] with class SA in [[!UAX14]]
			must be treated as if they had class AL;
			however, the User Agent must additionally
			analyse the content of a run of such characters
			and insert [=virtual word boundaries=] where appropriate.
			Within the constraints set by this specification,
			the specific algorithm used is UA-dependent.

			<wpt>
				css/css-text/word-boundary/word-boundary-102.html
				css/css-text/word-boundary/word-boundary-103.html
				css/css-text/word-boundary/word-boundary-104.html
			</wpt>

			As various languages can be written in scripts
			which use the characters with class SA,
			if the [=content language=] is known,
			the User Agent should use this information
			to tailor its analysis.

			In order to avoid unexpected overflow,
			if the User Agent is unable to perform this analysis
			for any subset of the characters with class SA--
			for example due to lacking a dictionary for certain languages--
			there must be a [=soft wrap opportunity=]
			between pairs of [=typographic letter units=] in that subset.

			Note: This [=soft wrap opportunity=] is not
			a [=virtual word boundary=],
			and is ignored by 'word-boundary-expansion'.

			Note: This provision is not triggered merely when
			the UA fails to find a word boundary in a particular text run;
			the text run may well be a single unbreakable word.
			It applies for example
			when a text run is composed of Khmer characters (U+1780 to U+17FF)
			if the User Agent does not know how to determine
			word boundaries in Khmer.

		<dt><dfn>auto(<<lang>>)</dfn>
		<dd>
			This value directs the User Agent to perform language-specific content analysis
			to determine where to insert [=virtual word boundaries=].

			<dfn dfn-type=type><<lang>></dfn> must be a valid CSS <<ident>> or <<string>>.
			It represents an IETF BCP 47 language range
			(see [[BCP47]]).
			If the UA does not support word-boundary detection
			for <em>all</em> languages represented by the specified range,
			that specified value is invalid
			(and will cause the declaration to be ingored).

			<wpt>
				css/css-text/word-boundary/word-boundary-105.html
				css/css-text/word-boundary/word-boundary-106.html
				css/css-text/word-boundary/word-boundary-107.html
				css/css-text/word-boundary/word-boundary-108.html
				css/css-text/word-boundary/word-boundary-109.html
				css/css-text/word-boundary/word-boundary-110.html
				css/css-text/word-boundary/word-boundary-111.html
				css/css-text/word-boundary/word-boundary-112.html
				css/css-text/word-boundary/word-boundary-113.html
				css/css-text/word-boundary/word-boundary-114.html
				css/css-text/word-boundary/word-boundary-115.html
				css/css-text/word-boundary/word-boundary-116.html
				css/css-text/word-boundary/word-boundary-117.html
				css/css-text/word-boundary/word-boundary-118.html
				css/css-text/word-boundary/word-boundary-119.html
				css/css-text/word-boundary/word-boundary-120.html
				css/css-text/word-boundary/word-boundary-121.html
				css/css-text/word-boundary/word-boundary-122.html
				css/css-text/word-boundary/word-boundary-123.html
				css/css-text/word-boundary/word-boundary-124.html
				css/css-text/word-boundary/word-boundary-125.html
				css/css-text/word-boundary/word-boundary-126.html
				css/css-text/word-boundary/word-boundary-127.html
			</wpt>

			Note: Wildcards <em>in the language subtag</em> would imply
			support for detecting word boundaries in an undefined and effectively unlimited set of languages.
			As this this is not possible,
			wildcards in the language subtag always result in the declaration
			being treated as invalid.

			Note: Whether a word boundary detection system designed for one language
			is suitable for some or all dialects of that language is somewhat subjective,
			and this specifications leaves it at the discretion of the User Agent.
			Even if a detection system is not able to cope with all nuances of a particular dialect,
			it may be reasonable to claim support
			if the detection correctly recognizes word boundaries most of the time.
			However, the User Agent would do a disservice to authors and users
			if it claimed support for languages
			where it fails to detect most word boundaries
			or has a high error rate.

			If the element’s [=content language=],
			as represented in BCP 47 syntax [[BCP47]],
			does <em>not</em> match the language range described by the computed value's <<lang>>
			in an extended filtering operation
			per [[RFC4647]] <cite>Matching of Language Tags</cite> (section 3.3.2)
			with both the [=content language=] and <<lang>>
			then the [=used value=] is ''word-boundary-detection/normal'',
			and this property has no effect on this element.
			Otherwise,
			the User Agent must insert a [=virtual word boundary=]
			at each detected word boundary
			within the [=text run=] children of this element.
			Within the constraints set by this specification,
			the specific algorithm used is UA-dependent.

			<wpt>
				css/css-text/word-boundary/word-boundary-105.html
				css/css-text/word-boundary/word-boundary-106.html
				css/css-text/word-boundary/word-boundary-107.html
				css/css-text/word-boundary/word-boundary-108.html
				css/css-text/word-boundary/word-boundary-109.html
				css/css-text/word-boundary/word-boundary-110.html
				css/css-text/word-boundary/word-boundary-111.html
				css/css-text/word-boundary/word-boundary-112.html
			</wpt>

			Note: This is the same matching logic as the one used for the '':lang()'' selector.
	</dl>

	<div class=example>
		If a User Agent has a word-boundary detection system for Cantonese
		that is not suitable for the broader set of Chinese languages,
		it is expected to accept ''auto(yue)'', ''auto(zh-yue)'', or ''auto(zh-HK)'',
		but not ''auto(zh)'' or ''auto(zh-Hant)''.

		However, if the User Agent supports a generic word-boundary detection system
		that is suitable for Chinese in general,
		it is expected to accept the broad ''auto(zh)'' characterization,
		as well as any more specific ones,
		such as ''auto(zh-yue)'', ''auto(zh-Hant-HK)'', ''auto(zh-Hans-SG)'', or ''auto(zh-hak)''.
	</div>

	<div class=example>
		Specifying the language for which the word boundary detection is to be performed
		and making unsupported language ranges invalid
		is required in order to make this feature meaningfully testable with ''@supports''.

		For example, Japanese text normally allows line breaking between letters of a word
		(see ''word-break: normal'').
		The following code disables that in <code>h1</code> elements,
		and only allows line breaking at autodetected word boundaries instead,
		without requiring the author to manually indicate word boundaries in the markup.
		However, if word boundary detection is not supported for Japanese,
		this change is not applied,
		as ''word-break: keep-all'' could remove all line breaking opportunities from the element,
		and risk causing overflow.
		<pre><code class=lang-css>
		@supports (word-boundary-detection: auto(ja)) {
			h1:lang(ja) {
				word-boundary-detection: auto(ja);
				word-break: keep-all;
			}
		}
		</code></pre>
	</div>

	User Agents may activate
	language-specific content analysis
	in response to user preferences.
	User Agents with this behavior must do this
	by setting the [=declared value=] of 'word-boundary-detection' to ''word-boundary-detection/auto(<<lang>>)''
	in the [=User Origin=].
	User Agents that do not support the [=User Origin=]
	may use the [=User Agent Origin=] instead.

	<div class=advisement>
		Manual analysis of the content can be more reliable than UA heuristics.
		For best results, authors who can perform this analysis are encouraged to markup their documents
		using <{wbr}> or U+200B
		to exhaustively indicate word boundaries.

		Authors who prepare their content in this manner
		should not rely on the initial value, and
		should explicitely specify ''word-boundary-detection: manual'' on the relevant parts of the content,
		in order to override a potential ''word-boundary-detection: auto(<<lang>>)''
		in the [=User Origin=] or [=User Agent Origin=].
	</div>

	[=Virtual word boundary=] insertion happens before [[CSS-TEXT-3#white-space-phase-1]]
	and before [[#word-boundary-expansion]].
	Later operations
	(including [[CSS-TEXT-3#white-space-rules]], [=line breaking=], and [=intrinsic sizing=])
	must take the presence of the [=virtual word boundary=] into account.
	[=Selectors=] are not affected.

	<wpt>
		css/css-text/word-boundary/word-boundary-109.html
		css/css-text/word-boundary/word-boundary-110.html
		css/css-text/word-boundary/word-boundary-111.html
		css/css-text/word-boundary/word-boundary-112.html
		css/css-text/word-boundary/word-boundary-113.html
		css/css-text/word-boundary/word-boundary-114.html
		css/css-text/word-boundary/word-boundary-115.html
		css/css-text/word-boundary/word-boundary-116.html
		css/css-text/word-boundary/word-boundary-117.html
		css/css-text/word-boundary/word-boundary-118.html
		css/css-text/word-boundary/word-boundary-119.html
		css/css-text/word-boundary/word-boundary-120.html
		css/css-text/word-boundary/word-boundary-121.html
		css/css-text/word-boundary/word-boundary-122.html
		css/css-text/word-boundary/word-boundary-123.html
		css/css-text/word-boundary/word-boundary-124.html
		css/css-text/word-boundary/word-boundary-125.html
		css/css-text/word-boundary/word-boundary-126.html
		css/css-text/word-boundary/word-boundary-127.html
	</wpt>

	Inline box boundaries
	and out-of-flow elements must be ignored
	when determining word boundaries.

	<wpt>
		css/css-text/word-boundary/word-boundary-113.html
		css/css-text/word-boundary/word-boundary-114.html
	</wpt>

	If a word boundary is found at the same position as
	one or more inline box boundaries,
	the [=virtual word boundary=] must be inserted
	in the outermost element that participates in this inline box boundary.

	<wpt>
		css/css-text/word-boundary/word-boundary-113.html
		css/css-text/word-boundary/word-boundary-114.html
	</wpt>

	<div class=example>
		In the following example,
		the red “<code><span style="color:red">|</span></code>” indicates
		reasonable positions for a User Agent to insert virtual word boundaries:
		<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span>คือ<span style="color:red">|</span>สวยงาม</code></pre>
		If that sentence had contained some inline markup,
		the following example shows the correct position to insert the virtual word boundaries:
		<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span>คือ<span style="color:red">|</span>&lt;em>สวยงาม&lt;/em></code></pre>
		The following example shows <em>incorrect</em> positions:
		<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span>คือ&lt;em><span style="color:red">|</span>สวยงาม&lt;/em></code></pre>
		The following shows the correct positions in a more contrieved situation:
		<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span>&lt;b>&lt;u>คือ&lt;/u><span style="color:red">|</span>&lt;em>สวยงาม&lt;/em>&lt;/b></code></pre>
	</div>

	The User Agent may tailor its word boundary detection algorithm
	depending on whether 'line-break' is
	''loose''/''line-break/normal''/''line-break/strict''.

	The User Agent must not insert a [=virtual word boundary=]:
	<ul>
		<li>
			at the beginning or end of any box
			(including [=inline boxes=])
			whose parent box has a [=used value=]
			of ''word-boundary-detection/manual''.

			<wpt>
				css/css-text/word-boundary/word-boundary-115.html
			</wpt>

		<li>
			immediately adjacent to a [=word-separator character=],
			or an [=other space separator=],
			or a ZERO WIDTH SPACE (U+200B) character.

			<wpt>
				css/css-text/word-boundary/word-boundary-116.html
				css/css-text/word-boundary/word-boundary-117.html
				css/css-text/word-boundary/word-boundary-118.html
			</wpt>

			Note: This implies that for languages such as English
			where words are separated by spaces or other separating characters,
			''word-boundary-detection/auto(<lang>)'' has no effect.

		<li>
			between characters that compose a single [=typographic character unit=].

		<li>
			between a [=typographic letter unit=]
			and a subsequent [=typographic character unit=] from the [[!UAX14]] CL, CP, IS, or EX line break classes,

			<wpt>
				css/css-text/word-boundary/word-boundary-122.html
				css/css-text/word-boundary/word-boundary-123.html
				css/css-text/word-boundary/word-boundary-124.html
				css/css-text/word-boundary/word-boundary-125.html
			</wpt>

		<li>
			between a [=typographic letter unit=]
			and a preceeding [=typographic character unit=] from the [[!UAX14]] OP line break class,

			<wpt>
				css/css-text/word-boundary/word-boundary-126.html
			</wpt>

		<li>
			between a [=typographic letter unit=]
			and an adjacent [=typographic character unit=] from the [[!UAX14]] GL, WJ, or ZWJ line break classes.

			<wpt>
				css/css-text/word-boundary/word-boundary-119.html
				css/css-text/word-boundary/word-boundary-120.html
				css/css-text/word-boundary/word-boundary-121.html
			</wpt>
	</ul>

	The User Agent should not insert a [=virtual word boundary=]:
	<ul>
		<li>
			between a [=typographic letter unit=]
			and a subsequent [=typographic character unit=] from the [[!UAX14]] PO, NS line break classes,

			<wpt>
				css/css-text/word-boundary/word-boundary-127.html
				css/css-text/word-boundary/word-boundary-128.html
			</wpt>

		<li>
			between a [=typographic letter unit=]
			and a preceeding [=typographic character unit=] from the [[!UAX14]] PR line break class,

			<wpt>
				css/css-text/word-boundary/word-boundary-129.html
			</wpt>
	</ul>

<h4 id=word-boundary-expansion>
Makig Word Boundaries Visible: the 'word-boundary-expansion' property</h4>

	<pre class="propdef">
	Name: word-boundary-expansion
	Value: none | space | ideographic-space
	Initial: none
	Applies to: text
	Inherited: yes
	Percentages: N/A
	Computed value: as specified
	Animation type: discrete
	</pre>

	<wpt>
		css/css-text/parsing/word-boundary-expansion-computed.html
		css/css-text/parsing/word-boundary-expansion-invalid.html
		css/css-text/parsing/word-boundary-expansion-valid.html
		css/css-text/word-boundary/word-boundary-003.html
		css/css-text/word-boundary/word-boundary-005.html
		css/css-text/word-boundary/word-boundary-006.html
	</wpt>

	Issue: This name is quite long, we may want to find a better one.
	We should also consider how we may want to add values to this property,
	so that the name is compatible with them.
	For example,
	it has been suggested that we may want to use this
	to turn visible “spaces” such as the ETHIOPIC WORD SPACE (U+1361)
	into an ordinary SPACE (U+0020).

	This property allows transforming certain word-separating characters
	into other word-separating characters,
	to accomodate variant typesetting styles.

	<dl dfn-for="word-boundary-expansion" dfn-type="value">
		<dt><dfn>none</dfn>
		<dd>This property has no effect.

			<wpt>
				css/css-text/word-boundary/word-boundary-004.html
				css/css-text/word-boundary/word-boundary-005.html
			</wpt>

		<dt><dfn>space</dfn>
		<dd>
			Instances of U+200B ZERO WIDTH SPACE
			within the [=text run=] children of this element
			are replaced by U+0020 SPACE.

			<wpt>
				css/css-text/word-boundary/word-boundary-002.html
				css/css-text/word-boundary/word-boundary-004.html
				css/css-text/word-boundary/word-boundary-005.html
				css/css-text/word-boundary/word-boundary-006.html
				css/css-text/word-boundary/word-boundary-007.html
				css/css-text/word-boundary/word-boundary-008.html
				css/css-text/word-boundary/word-boundary-009.html
				css/css-text/word-boundary/word-boundary-014.html
				css/css-text/word-boundary/word-boundary-015-manual.html
			</wpt>

		<dt><dfn>ideographic-space</dfn>
		<dd>
			Instances of U+200B ZERO WIDTH SPACE
			within the [=text run=] children of this element
			are replaced by U+3000 IDEOGRAPHIC SPACE.

			<wpt>
				css/css-text/word-boundary/word-boundary-001.html
				css/css-text/word-boundary/word-boundary-003.html
				css/css-text/word-boundary/word-boundary-010.html
				css/css-text/word-boundary/word-boundary-011.html
				css/css-text/word-boundary/word-boundary-012.html
				css/css-text/word-boundary/word-boundary-013.html
			</wpt>
	</dl>

	The User Agent must not replace
	instances of U+200B immediately preceding or following
	a [=forced line break=]
	(ignoring any intervening inline box boundaries,
	and associated 'margin'/'border'/'padding').

	<wpt>
		css/css-text/word-boundary/word-boundary-010.html
		css/css-text/word-boundary/word-boundary-011.html
		css/css-text/word-boundary/word-boundary-012.html
	</wpt>

	Instances of <{wbr}> are considered equivalent to U+200B,
	and are also replaced,
	as are [=virtual word boundaries=] inserted by 'word-boundary-detection'.

	<wpt>
		css/css-text/word-boundary/word-boundary-001.html
		css/css-text/word-boundary/word-boundary-002.html
		css/css-text/word-boundary/word-boundary-003.html
		css/css-text/word-boundary/word-boundary-004.html
		css/css-text/word-boundary/word-boundary-006.html
		css/css-text/word-boundary/word-boundary-007.html
		css/css-text/word-boundary/word-boundary-008.html
		css/css-text/word-boundary/word-boundary-009.html
		css/css-text/word-boundary/word-boundary-010.html
		css/css-text/word-boundary/word-boundary-011.html
		css/css-text/word-boundary/word-boundary-012.html
		css/css-text/word-boundary/word-boundary-013.html
		css/css-text/word-boundary/word-boundary-014.html
		css/css-text/word-boundary/word-boundary-015-manual.html
	</wpt>

	Unlike 'text-transform',
	this substitution happens before [[CSS-TEXT-3#white-space-phase-1]]
	so that later operations that depend on the characters in the content
	(including [[CSS-TEXT-3#white-space-rules]], [=line breaking=], and [=intrinsic sizing=])
	use that character instead of the original U+200B.

	<wpt>
		css/css-text/word-boundary/word-boundary-007.html
		css/css-text/word-boundary/word-boundary-008.html
		css/css-text/word-boundary/word-boundary-009.html
	</wpt>

	Like 'text-transform', this property transforms text for styling purposes.
	It has no effect on the underlying content,
	and must not affect the content of a plain text copy &amp; paste operation.

	<wpt>
		css/css-text/word-boundary/word-boundary-015-manual.html
	</wpt>

	<div class=note>Note: The effects of this property are similar
	to those of the 'text-transform' property.
	However, it is defined as a separate property
	rather than additional values to 'text-transform' because:
	* This property needs to take effect before [[CSS-TEXT-3#white-space-rules]],
		but 'text-transform' happens after that.
		This is needed so that the spaces inserted by this property
		behave as normal spaces for text layout purposes,
		and can collapse with other collapsible spaces
		or participate in [[css-text-3#white-space-phase-2|Trimming and Positioning]].
	* The uses cases for this property and 'text-transform',
		and the author's decision to apply either or both,
		are independent,
		making it desirable for these two properties to cascade separately.

	</div>

	<div class=example id=wakachigaki>
		<style>
		#wakachigaki samp
		{
			max-width: 18em;
			line-height: 2;
			padding: 1em;
			display: block;
			margin: auto;
			border: solid gray 1px;
			background: white;
		}
		</style>

		Unlike books for adults, Japanese books for young children often feature spaces between sentence segments,
		to facilitate reading.

		Absent any particular styling, the following sentence would be rendered as depicted below.

		<pre><code highlight=markup>
		&lt;p>むかしむかし、&lt;wbr>あるところに、&lt;wbr>おじいさんと&lt;wbr>おばあさんが&lt;wbr>すんでいました。
		</code></pre>

		<samp lang=ja>
		むかしむかし、あるところに、おじいさんとおばあさんがすんでいました。
		</samp>

		<hr>

		Phrase-based spacing can be achieved with the following css:

		<pre><code highlight=css>
		p {
			word-boundary-expansion: ideographic-space;
		}
		</code></pre>

		<samp lang=ja>
		むかしむかし、　あるところに、　おじいさんと　おばあさんが　すんでいました。
		</samp>

		<hr>

		Another common variant additionally restricts the allowable line breaks to these phrase boundaries.
		Using the same markup, this is easily achieved with the following css:

		<pre><code highlight=css>
		p {
			word-break: keep-all;
			word-boundary-expansion: ideographic-space;
		}
		</code></pre>

		<samp style="word-break:keep-all" lang=ja>
		むかしむかし、　<wbr>あるところに、　<wbr>おじいさんと　<wbr>おばあさんが　<wbr>すんでいました。
		</samp>

	</div>

	<wpt>
		css/css-text/word-boundary/word-boundary-013.html
		css/css-text/word-boundary/word-boundary-014.html
	</wpt>

	<div class=example id=classes>
		<style>
		#classes samp
		{
			max-width: 18em;
			line-height: 2;
			padding: 1em;
			display: block;
			margin: auto;
			border: solid gray 1px;
			background: white;
			text-align: left;
		}
		</style>

		In addition to making the source code more readable,
		using <{wbr}> rather than U+200B in the markup
		also allow authors to classify the delimiters into different groups.

		In the following example,
		<{wbr}> elements are either
		unmarked when they delimit a word,
		or marked with class <code>p</code> when they also delimit a phrase.

		<pre><code highlight=markup>
		&lt;p>らいしゅう&lt;wbr>の&lt;wbr>じゅぎょう&lt;wbr>に&lt;wbr class=p
		>たいこ&lt;wbr>と&lt;wbr>ばち&lt;wbr>を&lt;wbr class=p
		>もって&lt;wbr>きて&lt;wbr>ください。
		</code></pre>

		Using this, it is possible not only to enable the rather common phrase-based spacing,
		but also word-by-word spacing
		that is likely to be preferred
		by people with dyslexia to reduce ambiguities,
		or other variants
		such as a combination of phrase-based spacing and of word-based wrapping.

		<figure>
			<figcaption>Usual rendering</figcaption>

			<samp>
			らいしゅう<wbr>の<wbr>じゅぎょう<wbr>に<wbr class=p>たいこ<wbr>と<wbr>ばち<wbr>を<wbr class=p>もって<wbr>きて<wbr>ください。
			</samp>
		</figure>
		<hr>
		<figure>
			<figcaption>Phrase spacing</figcaption>

			<pre><code highlight=css>
			p wbr.p {
				word-boundary-expansion: ideographic-space;
			}
			</code></pre>

			<samp>
			らいしゅう<wbr>の<wbr>じゅぎょう<wbr>に　<wbr class=p>たいこ<wbr>と<wbr>ばち<wbr>を　<wbr class=p>もって<wbr>きて<wbr>ください。
			</samp>
		</figure>
		<hr>
		<figure>
			<figcaption>Word spacing</figcaption>

			<pre><code highlight=css>
			p wbr {
				word-boundary-expansion: ideographic-space;
			}
			</code></pre>

			<samp>
			らいしゅう　<wbr>の　<wbr>じゅぎょう　<wbr>に　<wbr class=p>たいこ　<wbr>と　<wbr>ばち　<wbr>を　<wbr class=p>もって　<wbr>きて　<wbr>ください。
			</samp>
		</figure>
		<hr>
		<figure>
			<figcaption>Phrase spacing, word wrapping</figcaption>

			<pre><code highlight=css>
			p {
				word-break: keep-all;
			}
			p wbr.p {
				word-boundary-expansion: ideographic-space;
			}
			</code></pre>

			<samp style="word-break: keep-all">
			らいしゅう<wbr>の<wbr>じゅぎょう<wbr>に　<wbr class=p>たいこ<wbr>と<wbr>ばち<wbr>を　<wbr class=p>もって<wbr>きて<wbr>ください。
			</samp>
		</figure>
		<hr>
		<figure>
			<figcaption>Word spacing and wrapping</figcaption>

			<pre><code highlight=css>
			p {
				word-break: keep-all;
			}
			p wbr {
				word-boundary-expansion: ideographic-space;
			}
			</code></pre>

			<samp style="word-break: keep-all">
			らいしゅう　<wbr>の　<wbr>じゅぎょう　<wbr>に　<wbr class=p>たいこ　<wbr>と　<wbr>ばち　<wbr>を　<wbr class=p>もって　<wbr>きて　<wbr>ください。
			</samp>
		</figure>
	</div>

<h2 id="white-space-processing">
White Space Processing</h2>

	Issue: Add final level 3 tab-size and processing details

<h3 id="white-space-collapsing">
White Space Collapsing: the 'text-space-collapse' property</h3>

	ISSUE: This section is still under discussion and may change in future drafts.

	<pre class="propdef">
	Name: text-space-collapse
	Value: collapse | discard | preserve | preserve-breaks | preserve-spaces
	Initial: collapse
	Applies to: text
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	This property declares whether and how
	<a href="#white-space-processing">white space</a>
	is collapsed.
	Values have the following meanings,
	which must be interpreted according to the white space processing rules:

	<dl dfn-for=text-space-collapse dfn-type=value>
		<dt><dfn>collapse</dfn>
		<dd>
			This value directs user agents to collapse sequences of white space
			into a single character
			(or <a href="https://www.w3.org/TR/css-text/#line-break-transform">in some cases</a>, no character).

		<dt><dfn>preserve</dfn>
		<dd>
			This value prevents user agents
			from collapsing sequences of white space.
			<a>Segment breaks</a> are preserved as forced line breaks.

		<dt><dfn>preserve-breaks</dfn>
		<dd>
			This value collapses white space as for ''collapse'', but preserves
			<a>segment breaks</a> as forced line breaks.

		<dt><dfn>preserve-spaces</dfn>
		<dd>
			This value prevents user agents
			from collapsing sequences of white space,
			and converts tabs and <a>segment breaks</a> to spaces.
			(This value is intended to match the behavior
			of <code>xml:space="preserve"</code> in SVG.)

		<dt><dfn>discard</dfn>
		<dd>
			This value directs user agents to “discard”
			all white space in the element.

			Issue: Does this preserve line break opportunities or no? Do we need a "hide" value?
	</dl>

	<div class="example">

		The following style rules implement MathML's white space processing:

		<pre>
			@namespace m "http://www.w3.org/1998/Math/MathML";
			m|* {
				text-space-collapse: discard;
			}
			m|mi, m|mn, m|mo, m|ms, m|mtext {
				text-space-trim: trim-inner;
			}
		</pre>
	</div>

<h3 id="white-space-trim">
White Space Trimming: the 'text-space-trim' property</h3>

	<pre class="propdef">
	Name: text-space-trim
	Value: none | trim-inner || discard-before || discard-after
	Initial: none
	Applies to: [=inline boxes=]
	Inherited: no
	Percentages: n/a
	Computed value: specified keyword(s)
	Animation type: discrete
	</pre>

	This property allows authors to specify trimming behavior
	at the beginning and end of a box.
	Values have the following meanings,
	which must be interpreted according to the white space processing rules:

	<dl dfn-for=text-space-trim dfn-type=value>
		<dt><dfn>trim-inner</dfn>
		<dd>
			For block containers this value directs UAs to discard
			all whitespace at the beginning of the element up to and including
			the last <a>segment break</a> before the first non-white-space character in the element
			as well as to discard all white space at the end of the element
			starting with the first <a>segment break</a> after the last non-white-space character in the element.
			For other elements this value directs UAs to discard
			all whitespace at the beginning and end of the element.

		<dt><dfn>discard-before</dfn>
		<dd>
			This value directs the UA to collapse all collapsible whitespace
			immediately before the start of the element.

		<dt><dfn>discard-after</dfn>
		<dd>
			This value directs the UA to collapse all collapsible whitespace
			immediately after the end of the element.
	</dl>

	<div class="example">
		<p>The following style rules render DT elements as a comma-separated list:
		<pre>
			dt { display: inline; }
			dt + dt:before { content: ", "; text-space-trim: discard-before; }
		</pre>
	</div>

<h2 id="line-breaking">
Line Breaking and Word Boundaries</h2>

	Issue: Add final level 3 content

<h2 id="wrapping">
Text Wrapping</h2>

	Text wrapping is controlled by the 'text-wrap',
	'wrap-before',
	'wrap-after',
	'wrap-inside',
	and overflow-wrap properties:

	Issue: Add final level 3 overflow-wrap

<h3 id="text-wrap">
Text Wrap Settings: the 'text-wrap' property</h3>

	<pre class="propdef">
	Name: text-wrap
	Value: wrap | nowrap | balance | stable | pretty
	Initial: wrap
	Applies to: text and <a>block containers</a>
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	This property specifies the mode for text wrapping.
	Possible values:

	<dl dfn-for=text-wrap dfn-type=value>
		<dt><dfn>wrap</dfn>
		<dd>
			Inline-level content may break across lines
			at allowed <a>soft wrap opportunities</a>,
			as determined by the line-breaking rules in effect
			in order to minimize <a>inline-axis</a> overflow.

			The exact algorithm is UA-defined.
			The algorithm <em>may</em> consider multiple lines
			when making break decisions.
			The UA <em>may</em> bias for speed over best layout.
			The UA <em>must not</em> attempt to even out all lines
			(including the last) as for ''text-wrap/balance''.
			This value selects the UA’s preferred (or most Web-compatible)
			wrapping algorithm.

		<dt><dfn>nowrap</dfn>
		<dd>
			Inline-level content does not break across lines;
			content that does not fit within the block container overflows it.

		<dt><dfn>balance</dfn>
		<dd>
			Same as ''text-wrap/wrap'' for <a>inline boxes</a>.
			For <a>block containers</a> that
			establish an <a>inline formatting context</a>,
			line breaks are chosen to balance
			the remaining (empty) space in each line box,
			if better balance than ''text-wrap/wrap'' is possible.
			This must not change the number of line boxes
			the block would contain
			if 'text-wrap' were set to ''text-wrap/wrap''.

			The remaining space to consider
			is that which remains after placing floats and inline content,
			but before any adjustments due to text justification.
			Line boxes are balanced when the standard deviation
			from the average <a>inline-size</a> of the remaining space in each line box
			is reduced over the block
			(including lines that end in a forced break).

			The exact algorithm is UA-defined.

			UAs may treat this value as ''text-wrap/wrap'' if there are more than ten lines to balance.

		<dt><dfn>stable</dfn>
		<dd>
			When applied to a <a>block container</a>
			that establishes an <a>inline formatting context</a>,
			specifies that content on subsequent lines
			<em>should not</em> be considered when making break decisions
			so that when editing text any content before the cursor
			remains stable;
			otherwise equivalent to ''text-wrap/wrap'',

		<dt><dfn>pretty</dfn>
		<dd>
			When applied to a <a>block container</a>
			that establishes an <a>inline formatting context</a>,
			specifies the UA <em>should</em> bias for better layout over speed,
			and is expected to consider multiple lines,
			when making break decisions.
			Otherwise equivalent to ''text-wrap/wrap'',
	</dl>

	Regardless of the 'text-wrap' value,
	lines always break at forced breaks:
	for all values,
	line-breaking behavior defined
	for the BK, CR, LF, CM, NL, and SG line breaking classes
	in [[!UAX14]] must be honored.
	Additionally, if wrapping is allowed (i.e. 'text-wrap' is not ''text-wrap/none''),
	line breaking behavior defined
	for the WJ, ZW, and GL line-breaking classes
	in [[!UAX14]] must be honored.

	UAs that allow breaks at punctuation other than spaces
	should prioritize breakpoints.
	For example,
	if breaks after slashes have a lower priority than spaces,
	the sequence “check /etc”
	will never break between the ‘/’ and the ‘e’.
	The UA may use the width of the containing block,
	the text's language,
	and other factors in assigning priorities.
	As long as care is taken to avoid such awkward breaks,
	allowing breaks at appropriate punctuation other than spaces
	is recommended,
	as it results in more even-looking margins,
	particularly in narrow measures.

	<!-- add a sample prioritization algorithm -->

	Note: The ''text-wrap/wrap'' value is will typically map
	to Web browsers’ speedy legacy line breaking,
	which has so far used first-fit/greedy algorithms
	that can often give sub-optimal results. 
	UAs can experiment with better line breaking algorithms
	with this default value, 
	but as optimal results often take more time,
	''text-wrap/pretty'' is offered as an opt-in
	to take more time for better results.
	The ''text-wrap/pretty'' value is intended for body text,
	where the last line is expected to be a bit shorter than the average line;
	the ''text-wrap/balance'' value is intended for titles and captions,
	where equal-length lines of text tend to be preferred;
	and the ''text-wrap/stable'' is intended for sections that are,
	or are likely become toggled as,
	editable.
<h3 id="wrap-before">
Inline breaks between boxes: the 'wrap-before'/'wrap-after' properties</h3>

	<pre class="propdef">
	Name: wrap-before, wrap-after
	Value: auto | avoid | avoid-line | avoid-flex | line | flex
	Initial: auto
	Applies to: <a>inline-level</a> boxes and <a>flex items</a>
	Inherited: no
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	These properties specify modifications to break opportunities
	in line breaking (and <a>flex line</a> breaking [[CSS3-FLEXBOX]]).
	Possible values:

	<dl dfn-for="wrap-before, wrap-after" dfn-type=value>
		<dt><dfn>auto</dfn>
		<dd>
			Lines may break at allowed break points
			before and after the box,
			as determined by the line-breaking rules in effect.

		<dt><dfn>avoid</dfn>
		<dd>
			Line breaking is suppressed immediately before/after the box:
			the UA may only break there
			if there are no other valid break points
			in the line.
			If the text breaks,
			line-breaking restrictions are honored as for
			''wrap-before/auto''.

		<dt><dfn>avoid-line</dfn>
		<dd>
			Same as ''wrap-before/avoid'',
			but only for line breaks.

		<dt><dfn>avoid-flex</dfn>
		<dd>
			Same as ''wrap-before/avoid'',
			but only for flex line breaks.

		<dt><dfn>line</dfn>
		<dd>
			Force a line break immediately before/after the box
			if the box is an <a>inline-level</a> box.

		<dt><dfn>flex</dfn>
		<dd>
			Force a <a>flex line</a> break immediately before/after the box
			if the box is a <a>flex item</a>
			in a <a>multi-line flex container</a>.
	</dl>

	Forced line breaks on <a>inline-level</a> boxes propagate upward
	through any parent <a>inline boxes</a>
	the same way forced breaks on <a>block-level</a> boxes propagate upward
	through any parent <a>block boxes</a>
	in the same <a>fragmentation context</a>.
	[[!CSS3-BREAK]]

<h3 id="wrap-inside">
Line breaks within boxes: the 'wrap-inside' property</h3>

	<pre class="propdef">
	Name: wrap-inside
	Value: auto | avoid
	Initial: auto
	Applies to: <a>inline boxes</a>
	Inherited: no
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	<dl dfn-for=wrap-inside dfn-type=value>
		<dt><dfn>auto</dfn>
		<dd>
			Lines may break at allowed break points
			within the box,
			as determined by the line-breaking rules in effect.

		<dt><dfn>avoid</dfn>
		<dd>
			Line breaking is suppressed within the box:
			the UA may only break within the box
			if there are no other valid break points in the line.
			If the text breaks,
			line-breaking restrictions are honored as for
			''wrap-inside/auto''.

			If boxes with ''wrap-inside/avoid'' are nested
			and the UA must break within these boxes,
			a break in an outer box must be used
			before a break within an inner box may be used.
	</dl>

<h4 id="example-avoid">
Example of using 'wrap-inside: avoid' in presenting a footer</h4>

	<div class="example">

		The priority of breakpoints can be set
		to reflect the intended grouping of text.

		Given the rules

		<pre>
			footer { wrap-inside: avoid; }
			venue { wrap-inside: avoid; }
			date { wrap-inside: avoid; }
			place { wrap-inside: avoid; }
		</pre>

		and the following markup:

		<pre>
			&lt;footer>
			&lt;venue>27th Internationalization and Unicode Conference&lt;/venue>
			&amp;#8226; &lt;date>April 7, 2005&lt;/date> &amp;#8226;
			&lt;place>Berlin, Germany&lt;/place>
			&lt;/footer>
		</pre>

		In a narrow window the footer could be broken as

		<pre>
			27th Internationalization and Unicode Conference &#8226;
			April 7, 2005 &#8226; Berlin, Germany
		</pre>

		or in a narrower window as

		<pre>
			27th Internationalization and Unicode
			Conference &#8226; April 7, 2005 &#8226;
			Berlin, Germany
		</pre>

		but not as

		<pre>
			27th Internationalization and Unicode Conference &#8226; April
			7, 2005 &#8226; Berlin, Germany
		</pre>
	</div>

<h2 id="last-line-limits">
Last Line Minimum Length</h2>

	<div class="issue">
		See <a href="http://www.w3.org/mid/0BD85DFF-A147-44EF-B18A-FF03C3D67EF0@verou.me">thread</a>.
		Issue is about requiring a minimum length for lines.
		Common measures seem to be

		<ul>
			<li>At least as long as the text-indent.
			<li>At least X characters.
			<li>Percentage-based.
		</ul>

		Suggestion for value space is ''match-indent | <<length>> | <<percentage>>''
		(with ''Xch'' given as an example to make that use case clear).
		Alternately <<integer>> could actually count the characters.

		It's unclear how this would interact with text balancing (above);
		one earlier proposal had them be the same property
		(with ''100%'' meaning full balancing).

		People have requested word-based limits, but since this is really
		dependent on the length of the word, character-based is better.
	</div>

<h2 id="white-space-property">
Shorthand for White Space and Wrapping: the 'white-space' property</h2>


	<pre class="propdef shorthand">
	Name: white-space
	Value: normal | pre | nowrap | pre-wrap | pre-line
	Initial: auto
	Applies to: See individual properties
	Inherited: yes
	Percentages: n/a
	Animation type: discrete
	</pre>

	This property is a shorthand for 'text-space-collapse', 'text-wrap', and 'text-space-trim'.

	Note: This shorthand combines both inheritable and non-inheritable properties.
	If this is a problem, please inform the CSSWG.

	The following table gives the mapping of the values of the shorthand to its longhands.

	<table class="data">
		<colgroup class="header"></colgroup>
		<colgroup span=3></colgroup>
		<thead>
			<tr>
				<th>'white-space'
				<th>'text-space-collapse'
				<th>'text-wrap'
				<th>'text-space-trim'
		</thead>
		<tbody>
		<tr>
			<th>''white-space/normal''
			<td>''text-space-collapse/collapse''
			<td>''text-wrap/wrap''
			<td>''text-space-trim/none''
		<tr>
			<th>''pre''
			<td>''text-space-collapse/preserve''
			<td>''text-wrap/nowrap''
			<td>''text-space-trim/none''
		<tr>
			<th>''nowrap''
			<td>''text-space-collapse/collapse''
			<td>''text-wrap/nowrap''
			<td>''text-space-trim/none''
		<tr>
			<th>''pre-wrap''
			<td>''text-space-collapse/preserve''
			<td>''text-wrap/wrap''
			<td>''text-space-trim/none''
		<tr>
			<th>''pre-line''
			<td>''text-space-collapse/preserve-breaks''
			<td>''text-wrap/wrap''
			<td>''text-space-trim/none''
		</tbody>
	</table>

	Issue: Add details from level 3

<h2 id="hyphenation">
Breaking Within Words</h2>

	Issue: Add final level 3 content

<h3 id="hyphenate-character">
Hyphens: the 'hyphenate-character' property</h3>

	<pre class="propdef">
	Name: hyphenate-character
	Value: auto | <<string>>
	Initial: auto
	Applies to: text
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	This property specifies the string that is shown
	between parts of hyphenated words.
	Values have the following meanings:

	<dl dfn-for=hyphenate-character dfn-type=value>
		<dt><dfn>auto</dfn>
		<dd>
			Specifies that the user agent should find an appropriate string
			based on the <a>content language</a>’s typographic conventions,
			possibly from the same source as the hyphenation dictionary.
		<dt><dfn><<string>></dfn>
		<dd>
			Specifies the string that appears
			at the end of the line before a hyphenation break.
			The UA <em>may</em> truncate the <a>used value</a>
			to a limited number of <a>typographic character units</a>.
			(It must not truncate only part of a <a>typographic character unit</a>.)
	</dl>

	<div class="example">
		The hyphen character (U+2010) is most typically used
		to indicate that a word has been split.
		However, 'hyphenate-character' can be used
		to specify a different type of hyphen when necessary.
		<pre>
			article { hyphenate-character: "᐀" /* CANADIAN SYLLABICS HYPHEN (U+1400) */ }
		</pre>
	</div>

	Note: Both hyphens triggered by automatic hyphenation
	and hyphens triggered by soft hyphens
	are rendered according to 'hyphenate-character'.

<h3 id="hyphenate-size-limits">
Hyphenation Size Limit: the 'hyphenate-limit-zone' property</h3>

	<pre class="propdef">
	Name: hyphenate-limit-zone
	Value: <<length-percentage>>
	Initial: 0
	Applies to: [=block containers=]
	Inherited: yes
	Percentages: refers to length of the line box
	Computed value: computed <<length-percentage>> value
	Animation type: by computed value type
	</pre>

	<p class="issue">Is 'hyphenate-limit-zone' a good name? Comments/suggestions?

	This property specifies the maximum amount of unfilled space
	(before justification)
	that may be left in the line box before hyphenation is triggered
	to pull part of a word from the next line back up into the current line.

<h3 id="hyphenate-char-limits">
Hyphenation Character Limits: the 'hyphenate-limit-chars' property</h3>

	<pre class="propdef">
	Name: hyphenate-limit-chars
	Value: [ auto | <<integer>> ]{1,3}
	Initial: auto
	Applies to: text
	Inherited: yes
	Percentages: n/a
	Computed value: three values, each either the ''hyphenate-limit-chars/auto'' keyword or an integer
	Animation type: by computed value type
	</pre>

	This property specifies the minimum number of characters
	in a hyphenated word.
	If the word does not meet the required minimum number of characters
	in the word / before the hyphen / after the hyphen,
	then the word must not be hyphenated.
	Nonspacing combining marks (<span class="issue">Unicode class</span>)
	and intra-word punctuation (Unicode classes P*)
	do not count towards the minimum.

	If three values are specified,
	the first value is the required minimum for the total characters in a word,
	the second value is the minimum for characters before the hyphenation point,
	and the third value is the minimum for characters after the hyphenation point.
	If the third value is missing, it is the same as the second.
	If the second value is missing, then it is ''hyphenate-limit-chars/auto''.
	The <dfn dfn-type=value dfn-for=hyphenate-limit-chars>auto</dfn> value means that
	the UA chooses a value that adapts to the current layout.

	Note: Unless the UA is able to calculate a better value,
	it is suggested that ''hyphenate-limit-chars/auto'' means
	2 for before and after, and 5 for the word total.

	<div class="example">
		In the example below,
		the minimum size of a hyphenated word is left to the UA
		(which means it may vary depending on the language,
		the length of the line, or other factors),
		but the minimum number of characters
		before and after the hyphenation point
		is set to 3.
		<pre>
			p { hyphenate-limit-chars: auto 3; }
		</pre>
	</div>

<h3 id="hyphenate-line-limits">
Hyphenation Line Limits: the 'hyphenate-limit-lines' and 'hyphenate-limit-last' properties</h3>

	<pre class="propdef">
	Name: hyphenate-limit-lines
	Value: no-limit | <<integer>>
	Initial: no-limit
	Applies to: block containers
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword or integer
	Animation type: by computed value type
	</pre>

	This property indicates the maximum number of
	successive hyphenated lines in an element.
	The ''no-limit'' value means that there is no limit.

	In some cases, user agents may not be able to honor the specified value.
	(See overflow-wrap.)
	It is not defined whether hyphenation introduced by such emergency breaking
	influences nearby hyphenation points.

	<pre class="propdef">
	Name: hyphenate-limit-last
	Value: none | always | column | page | spread
	Initial: none
	Applies to: [=block containers=]
	Inherited: yes
	Percentages: n/a
	Computed value: specified keyword
	Animation type: discrete
	</pre>


	This property indicates hyphenation behavior at the end
	of elements, column, pages, and spreads.
	A spread is a set of two pages
	that are visible to the reader at the same time.
	Values have the following meanings:

	<dl dfn-for=hyphenate-limit-lines dfn-type=value>
		<dt><dfn>none</dfn>
		<dd>
			No restrictions imposed.

		<dt><dfn>always</dfn>
		<dd>
			The last full line of the element,
			or the last line before any column, page, or spread break inside the element
			should not be hyphenated.

		<dt><dfn>column</dfn>
		<dd>
			The last line before any column, page, or spread break inside the element
			should not be hyphenated.

		<dt><dfn>page</dfn>
		<dd>
			The last line before page or spread break inside the element
			should not be hyphenated.

		<dt><dfn>spread</dfn>
		<dd>
			The last line before any spread break inside the element
			should not be hyphenated.
	</dl>

	<div class=example>
		<pre>
			p { hyphenate-limit-last: always }
			div.chapter {	hyphenate-limit-last: spread }
		</pre>
	</div>

	<div class=example>

		A paragraph may be formatted like this
		when ''hyphenate-limit-last: none'' is set:
		<pre>
			This is just a
			simple example
			to show Antarc-
			tica.
		</pre>

		With 'hyphenate-limit-last: always' one would get:

		<pre>
			This is just a
			simple example
			to        show
			Antarctica.
		</pre>
	</div>

<h2 id="alignment">
Alignment and Justification</h2>

<h3 id="text-align-property">
Text Alignment: the 'text-align' shorthand</h3>

	Issue: Add final level 3 content

	Add this value to 'text-align'

	<dl dfn-for=text-align dfn-type=value>
		<dt><dfn><<string>></dfn></dt>
		<dd>
			The string must be a single character;
			otherwise the declaration is invalid and must be
			<a href="https://www.w3.org/TR/CSS21/conform.html#ignore">ignored</a>.
			When applied to a table cell, specifies the <dfn>alignment character</dfn>
			around which the cell's contents will align.
			See <a href="#character-alignment">below</a> for further details
			and how this value combines with keywords.
	</dl>

<h3 id="character-alignment">
Character-based Alignment in a Table Column</h3>

	When multiple cells in a column have an alignment character specified,
	the alignment character of each such cell in the column
	is centered along a single column-parallel axis
	and the rest of the text in the column shifted accordingly.
	(Note that the strings do not have to be the same for each cell,
	although they usually are.)

	<p class="issue">Is this intended to say that it's the centers
	of the alignment characters that should be aligned?
	It's not clear that's what it says,
	but that (or a different behavior) needs to be specified,
	to describe what happens
	when different occurrences of the alignment character
	are in different fonts.
	(Further, is that the intended behavior?  Probably the most
	significant use case to consider is bold vs. non-bold text,
	which only varies slightly in width.)
	[<a href="https://lists.w3.org/Archives/Public/www-style/2016Jan/0233.html">feedback</a>]
	[minutes face-to-face 2016-02-02 10:00 AM]


	<div class="example">

		The following style sheet:

		<pre>
			TD { text-align: "." center }
		</pre>

		will cause the column of dollar figures in the following HTML table:

		<pre class="html-example">
			&lt;TABLE&gt;
			&lt;COL width="40"&gt;
			&lt;TR&gt; &lt;TH&gt;Long distance calls
			&lt;TR&gt; &lt;TD&gt; $1.30
			&lt;TR&gt; &lt;TD&gt; $2.50
			&lt;TR&gt; &lt;TD&gt; $10.80
			&lt;TR&gt; &lt;TD&gt; $111.01
			&lt;TR&gt; &lt;TD&gt; $85.
			&lt;TR&gt; &lt;TD&gt; N/A
			&lt;TR&gt; &lt;TD&gt; $.05
			&lt;TR&gt; &lt;TD&gt; $.06
			&lt;/TABLE&gt;
		</pre>

		to align along the decimal point. The table might be rendered as
		follows:

		<pre>
			+---------------------+
			| Long distance calls |
			+---------------------+
			|         $1.30       |
			|         $2.50       |
			|        $10.80       |
			|       $111.01       |
			|        $85.         |
			|        N/A          |
			|          $.05       |
			|          $.06       |
			+---------------------+
		</pre>
	</div>

	A keyword value may be specified in conjunction with the <<string>> value;
	if it is not given, it defaults to ''text-align/right''.
	This value is used:

	<ul>
		<li>
			when character-based alignment is applied
			to boxes that are not table cells.
		<li>
			when the text wraps to multiple lines (at unforced break points).
		<li>
			when a character-aligned cell spans more than one column.
			In this case the keyword alignment value is used
			to determine which column's axis to align with:
			the leftmost column for ''text-align/left'',
			the rightmost column for ''text-align/right'' and ''text-align/center'',
			the startmost column for ''text-align/start'',
			the endmost column for ''text-align/end''.
		<li>
			when the column is wide enough that the character alignment alone
			does not determine the positions of its character-aligned contents.
			In this case the keyword alignment of the first cell in the column
			with a specified alignment character
			is used to slide the position of the character-aligned contents
			to match the keyword alignment
			insofar as possible without changing the width of the column.
			For ''text-align/center'',
			the UA may center the aligned contents using its extremes,
			center the alignment axis itself (insofar as possible),
			or optically center the aligned contents some other way
			(such as by taking a weighted average
			of the extent of the cells' contents to either side of the axis).
	</ul>

	Note: Right alignment is used by default for character-based alignment
	because numbering systems are almost all left-to-right
	even in right-to-left writing systems,
	and the primary use case of character-based alignment
	is for numerical alignment.

	If the alignment character appears more than once in the text,
	the first instance is used for alignment.
	If the alignment character does not appear in a cell at all,
	the string is aligned as if
	the alignment character had been inserted at the end of its contents.

	<p class="issue">This needs to specify what text is searched
	for the alignment character.
	Is it only in-flow text whose containing block is the cell?
	Or is text within any in-flow descendants
	in the block formatting context established by the cell considered?
	If so, is it considered only as long as its 'text-align' property
	is consistent with the cell's?
	(Consistent in the alignment character, or fully consistent?)

	<p class="issue">This behavior of aligning as though he alignment character
	had been inserted at the end of the contents of the cell,
	combined with center-of-character alignment,
	will produce gaps on the end-side of lines
	that are alone on a line with <<string>> text-alignment,
	when none of the lines of the column has the alignment character,
	or, more importantly, when some of the lines
	do have the alignment character,
	but the column is not laid out at its max-content width.
	This is probably undesirable.

	<p class="issue">When the alignment character is inserted
	at the end of the contents,
	which font is used?
	(In particular, if the alignment character might be within a descendant block,
	is it the font of the block or the font of the table cell?
	Or if the insertion is at a forced break within an inline,
	does it use the font of the inline or the font of the block or cell?)

	Character-based alignment occurs before table cell width computation
	so that auto width computations can leave enough space for alignment.
	Whether column-spanning cells participate in the alignment
	prior to or after width computation is undefined.
	If width constraints on the cell contents prevent
	full alignment throughout the column,
	the resulting alignment is undefined.

	<p class="issue">This should have a formal definition
	of how character alignment affects
	the min-content and max-content intrinsic widths
	(of table columns and all content that can be inside table columns).
	Max-content intrinsic widths need to be split
	into three numbers (assuming that it's the centers of the
	alignment character that are aligned):
	one for widths without alignment characters,
	one for widths on the inline-start side
	of the center of the alignment character,
	one for widths on the inline-end side
	of the center of the alignment character.
	This operates based on all segments of text
	between forced breaks for max-content widths.
	For min-content widths, segments of text between forced breaks
	that contain optional breaks within them should clearly contribute
	only to the without-alignment-character width.
	However, it's less clear
	whether all min-content widths should work this way,
	or whether segments between forced breaks
	that do not have optional breaks
	(and perhaps only those that actually contain the alignment character)
	should contribute to start-side-of-alignment-character
	and end-side-of-alignment-character min-content widths instead;
	this choice is a tradeoff between the meaning of min-content
	sizing of a table meaning the narrowest reasonable size versus
	honoring alignment characters in more cases.
	Another option might be to use whether line-breaking of optional breaks
	is allowed as a control for which behavior to use.

	<p class="issue">Formally defining the intrinsic width contributions
	of column-spanning cells with <<string>> values of
	'text-align' is a complicated (although straightforward) extension
	of the decisions made for intrinsic width contributions
	of non-column-spanning cells;
	this should also be formally defined.
	Contributions end up being made to the split intrinsic widths
	of the startmost or endmost column (whichever is used for alignment),
	and to the without-alignment-character intrinsic widths
	of the other spanned columns.

<h3 id="text-group-align-property">
Aligning a block of text within its container: the 'text-group-align' property</h3>

	<pre class="propdef">
	Name: text-group-align
	Value: none | start | end | left | right | center
	Initial: none
	Applies to: <a>block containers</a>
	Inherited: no
	Percentages: N/A
	Computed value: specified keyword
	Animation type: discrete
	</pre>

	This property aligns the contents of the line boxes as a group
	while maintaining their text alignment.

	<dfn lt="group alignment | group-align | group-aligned">Group alignment</dfn>
	is performed by finding the line box with the shortest remaining space
	and adding that amount of space as padding to one or both sides of the line box,
	reducing the amount of space available for its contents;
	<a href="#text-align-property">text alignment</a> is then applied
	to its contents within the remaining space.
	All descendant [=in-flow=] line boxes within the same [=block formatting context=]
	are considered
	both when searching for the shortest remaining space
	and when adding the padding;
	the contents of descendants that establish [=independent formatting contexts=]
	are skipped.

	Issue: A variant of this property is inherited,
	and applies on each block container individually,
	only affecting the line boxes that are direct children of that block.
	This is less useful, but probably easier to implement.

	Issue: Somehow also moving the floats that originate in the same block container
	by the same amount
	would make things line up more nicely,
	which would be especially valuable in CJK layout.
	Exactly how that works, and how it interacts with intruding floats
	from ancestor elements is left as an exercise for the reader.

	Values have the following meanings:

	<dl dfn-for=text-group-align dfn-type=value>
		<dt><dfn>none</dfn>
		<dd>Text alignment happens normally: [=group alignment=] is not performed.

		<dt><dfn>start</dfn>
		<dd>Inline-level content is [=group-aligned=] to the [=inline start=] side,
		    by padding the [=inline end=] side of each line box.
		<dt><dfn>end</dfn>
		<dd>Inline-level content is [=group-aligned=] to the [=inline end=] side,
		    by padding the [=inline start=] side of each line box.
		<dt><dfn>left</dfn>
		<dd>Inline-level content is [=group-aligned=] to the [=line-left=] side,
		    by padding the [=line-right=] side of each line box.
		<dt><dfn>right</dfn>
		<dd>Inline-level content is [=group-aligned=] to the [=line-right=] side,
		    by padding the [=line-left=] side of each line box.
		<dt><dfn>center</dfn>
		<dd>Inline-level content is [=group-aligned=] to the center,
		    by padding both sides of each line box,
		    half the spacing to each side.
	</dl>




<h2 id="spacing">
Spacing</h2>

	Issue: Add final level 3 word-spacing, letter-spacing

<h3 id="line-padding-property">
Line Start/End Padding: the 'line-padding' property</h3>

	<pre class="propdef">
	Name: line-padding
	Value: <<length>>
	Initial: 0
	Applies to: <a>inline boxes</a>
	Inherited: yes
	Percentages: N/A
	Computed value: absolute length
	Animation type: by computed value type
	</pre>

	Whereas 'letter-spacing' adjusts spacing
	between <a>typographic letter units</a>
	and does not apply at the start or end of a line,
	this property adjusts spacing only at the start/end of a line.
	The extra spacing is applied only
	by the <em>innermost</em> <a>inline box</a>
	at the start/end of the line box,
	and is inserted between that <a>inline box</a>’s content edge
	and the adjacent <a>inline-level</a> content
	(text run <em>or</em> <a>atomic inline</a>).
	This extra space is not a <a>justification opportunity</a>.

	<div class="example">
		Given the following HTML and CSS:
		<xmp>
			p    { line-padding: 0.5em; line-height: 1; text-align: center }
			span { background: black; color: white; }
			em   { background: green; color: white; }

			<p><span>Here is <em>some text</em></span>
		</xmp>

		Line-padding will be inserted such that
		an extra 0.5em of inline background will be visible
		on each side of each line.
		If it renders such that there is a break between “some” and “text”,
		the the additional padding will be:
		on the first line, black on the left and green on the right,
		and on the second line, green on both sides.

		<style>
			#line-padding-rendering         { line-height: 1; text-align: center; color: white; }
			#line-padding-rendering span    { background: black; padding-left: 0.5em; }
			#line-padding-rendering em      { background: green; padding-right: 0.5em; }
			#line-padding-rendering em + em { padding-left: 0.5em; }
		</style>
		<pre class="figure" id="line-padding-rendering">
			<span>Here is <em>some</em>
			<em>text</em></span>
		</pre>
	</div>

<h3 id="text-spacing-property">
Character Class Spacing: the 'text-spacing' property</h3>

	<pre class="propdef">
	Name: text-spacing
	Value: normal | none | auto |
	       [ trim-start | space-start | space-first ] ||
	       [ trim-end | space-end | allow-end ] ||
	       [ trim-adjacent | space-adjacent ] ||
	       no-compress || ideograph-alpha || ideograph-numeric || punctuation
	Initial: normal
	Applies to: block containers
	Inherited: yes
	Percentages: N/A
	Computed value: specified keyword(s)
	Animation type: discrete
	</pre>

	This property controls spacing between adjacent characters
	on the same line within the same inline formatting context
	using a set of character-class-based rules.
	Such spacing can either be created between or trimmed from the affected glyphs.
	Values are defined as follows:

	<dl dfn-for=text-spacing dfn-type=value>
		<dt><dfn>normal</dfn>
		<dd>
			Specifies the baseline behavior,
			equivalent to ''space-start allow-end trim-adjacent''.

		<dt><dfn>none</dfn>
		<dd>
			Turns off all text-spacing features.
			All fullwidth characters are set with full-width glyphs.

		<dt><dfn>auto</dfn>
		<dd>
			The user agent chooses a set of typographically high quality spacing values.
                        Different user agents running on different platforms may pick different values.

                        Note: These spacing values may or may not match OS platform conventions.

                        Note: The behavior of ''auto'' might not be achievable with any combination of other values of 'text-spacing'.

		<dt><dfn>ideograph-alpha</dfn>
		<dd>
			Creates 1/4em extra spacing between runs of
			<a>ideographs</a> and <a>non-ideographic letters</a>.

			Note: A commonly used algorithm for determining this behavior is specified in [[JLREQ]].

		<dt><dfn>ideograph-numeric</dfn>
		<dd>
			Creates 1/4em extra spacing between runs of
			<a>ideographs</a> and <a>non-ideographic numerals</a> glyphs.

			Note: A commonly used algorithm for determining this behavior is specified in [[JLREQ]].

		<dt><dfn>punctuation</dfn>
		<dd>
			Creates extra non-breaking spacing around punctuation as required by language-specific typographic conventions.

			In this level, if the element's content language is French,
			narrow no-break space (U+202F) and no-break space (U+00A0) is inserted
			where required by <a href="http://unicode.org/udhr/n/notes_fra.html">French typographic guidelines</a>.
			Otherwise this value has no effect.
			However future specifications may add automatic spacing behavior for other languages.

			ISSUE: Integrate rules for correcting incorrect spaces?
			<a href="https://github.com/w3c/csswg-drafts/issues/318">Issue 318</a>

		<dt><dfn>space-start</dfn>
		<dd>
			Set <a>fullwidth opening punctuation</a> with full-width glyphs (spaced)
			at the start of each line.

		<dt><dfn>trim-start</dfn>
		<dd>
			Set <a>fullwidth opening punctuation</a> with half-width glyphs (flush)
			at the start of each line.

		<dt><dfn>space-first</dfn>
		<dd>
			Behaves as ''space-start'' on the first line the block container
			and each line after a <a>forced line break</a>
			but as ''trim-start'' on all other lines.

			<details class="note">
				<summary>This value exists for UA compat requirements,
				and is not recommended for general authoring use.</summary>
				This value exists to improve formatting of existing Japanese ePUB content,
				for which ''trim-start'' would have been appropriate typographically,
				except that they are typeset
				to expect the first line to be set as ''space-first''.

				Specifically,
				due to the lack of reliable 'hanging-punctuation' support across ePUB readers,
				such content uses U+3000 ideographic space in place of 'text-indent',
				but omits it when the paragraph begins with punctuation
				that is desired to hang in the indent
				in order to create the hanging punctuation effect.
				Using ''trim-start'' on the first line
				would thus trim away the effective indent in such content
				and thus obscure that line's distinction
				as the first line of a new paragraph.

				Note that this ePUB typesetting practice
				is not recommended for CSS in general
				(i.e. where not dictated by compat):
				authors should use 'hanging-punctuation' and 'text-indent'
				to control paragraph formatting
				rather than tweaking the text content of the document.
				This preserves the text’s true semantics in the document source
				and allows the style sheet designer
				to freely switch among the various spacing/indentation styles
				without needing to alter the content.
				See [[#japanese-start-edges]] for examples.

				UAs are encouraged to use this value
				as part of their UA default style sheet for Japanese ePUB content:
				to preserve the paragraph distinctions in such content
				while applying ''trim-start'' behavior to wrapped lines
				(which creates better optical alignment along the start edge
				and helps emphasize paragraph breaks denoted by indentation).

				ISSUE: Whether this value should also be part of the UA defaults for Web content
				is <a href="https://github.com/w3c/csswg-drafts/issues/2462">currently under discussion</a>.
			</details>

		<dt><dfn>allow-end</dfn>
		<dd>
			Set <a>fullwidth closing punctuation</a> with half-width glyphs (flush)
			at the end of each line
			if it does not otherwise fit prior to justification;
			otherwise set the punctuation with full-width glyphs.

		<dt><dfn>space-end</dfn>
		<dd>
			Set <a>fullwidth closing punctuation</a> with full-width glyphs (spaced)
			at the end of each line.

		<dt><dfn>trim-end</dfn>
		<dd>
			Set <a>fullwidth closing punctuation</a> with half-width glyphs (flush)
			at the end of each line.

		<dt><dfn>space-adjacent</dfn>
		<dd>
			Set <a>fullwidth opening punctuation</a> with full-width glyphs (spaced)
			when not at the start of the line.
			Set <a>fullwidth closing punctuation</a> with full-width glyphs (spaced)
			when not at the end of the line.

		<dt><dfn>trim-adjacent</dfn>
		<dd>
			Collapse spacing between punctuation glyphs
			<a href="#fullwidth-collapsing">as described below</a>.

		<dt><dfn>no-compress</dfn>
		<dd>
			Justification may not compress text-spacing.
			(If this value is not specified, the justification process may reduce autospacing
			except when the spacing is at the start or end of the line.)

			Note: An example of compression rules is given for Japanese
			in 3.8 Line Adjustment in [[JLREQ]].
	</dl>

	This property is additive with the 'word-spacing' and 'letter-spacing' properties.
	That is, the amount of spacing contributed by the 'letter-spacing' setting (if any)
	is added to the spacing created by 'text-spacing'.
	The same applies to 'word-spacing'.

	At element boundaries, the amount of extra spacing introduced between characters
	is determined by and rendered within the innermost element that contains the boundary.
	If the extra spacing is applied to a particular glyph,
	then the spacing is determined by the innermost element containing that glyph.

	Note: Values other than ''text-spacing/normal'', ''text-spacing/none'', ''trim-start'', ''trim-end'', and ''space-end''
	are at-risk and may be dropped from this level of CSS.
	They are defined here currently to help work out a complete design of this feature.

	Support for this property is <em>optional</em>.
	It is strongly recommended for UAs that wish to support CJK typography.

	Issue: It was requested to add a value for doubling the space after periods.

<h4 id="fullwidth-collapsing">
Fullwidth Punctuation Collapsing</h4>

	Typically, fullwidth characters have glyphs with the same advance width
	as a standard Han character (e.g. 水 U+6C34).
	However, many fullwidth punctuation glyphs only take up part of the fullwidth design space.
	Thus such punctuation are not always set fullwidth.
	Several values of 'text-spacing' allow the author to control
	when such characters are set half-width (typically half the width of an ideograph)
	and when they are set full-width.

	In order to set the text as specified, the UA will need to either
	<ul>
		<li>
			trim (kern) the blank half of the glyphs,
			if they are given full-width and must be set half-width, or
		<li>
			add space to the glyphs,
			if they are given half-width and must be set full-width.
	</ul>

	The UA <em>may</em> use the OpenType <code>halt</code> and <code>vhal</code> features
	if implemented by a font
	in order to perform the requisite trimming of a particular glyph.
	The UA <em>must not</em> use the <code>hwid</code> feature
	or otherwise substitute halfwidth forms
	as switching to halfwidth glyphs can change the glyph shape
	which is not acceptable here.

	Some fonts use proportional glyphs for fullwidth punctuation characters.
	If there is no support in the font for distinguishing
	fullwidth vs halfwidth glyph shapes
	(e.g. through font features),
	then for such proportional glyphs,
	the given advance width is considered
	simultaneously full-width and half-width:
	the UA must not add or remove space to these glyphs.

	Note: The advance width of a standard Han character
	can be determined either from font metrics
	such as the OpenType <code>ideo</code> and <code>idtp</code> baselines for the opposite writing mode,
	or by taking the advance width of a Han character such as 水 U+6C34.
	(The opposite writing mode must be used because some fonts are compressed
	so that the characters are not square.)
	More information on OpenType metrics can be found
	<a href="https://docs.microsoft.com/en-us/typography/opentype/spec/baselinetags#ideoembox">in the OpenType spec</a>.
	Note that if 水 U+6C34, 卜 U+535C, and 一 U+4E00 do not all have the same advance width,
	the font has proportional ideographs
	and the fullwidth advance width cannot be reliably determined by measuring glyphs.

	Unless 'text-spacing' is set to ''space-adjacent'' or ''text-spacing/none''
	(or the font has proportional fullwidth punctuation glyphs),
	the UA must collapse the space typically associated with such full width glyphs
	when placed adjacently on a line
	as follows:

	<ul>
		<li>
			Set <a>fullwidth opening punctuation</a> half-width if the previous character is
			a <a>fullwidth opening punctuation</a>,
			<a>fullwidth middle dot punctuation</a>,
			or ideographic space (U+3000),
			or if the previous character is a <a>fullwidth closing punctuation</a>
			of an equivalent or larger 'font-size'.
			Else set it full-width.
		<li>
			Set <a>fullwidth closing punctuation</a> half-width if the next character is
			a <a>fullwidth closing punctuation</a>,
			<a>fullwidth middle dot punctuation</a>,
			or ideographic space (U+3000),
			or if the next character is a <a>fullwidth opening punctuation</a>
			of a larger 'font-size'.
			Else set it full-width.
	</ul>

	<div class="example">
		The following example table lists the punctuation pairs
		affected by adjancent-pairs trimming.
		It uses halfwidth equivalents to approximate the trimming effect.

		<style>
			.char { border: 1px dotted gray; }
			.quarter { font-size: 25%; }
			samp[lang="ja"] { font-family: "MS Gothic", "Osaka-Mono", monospace }
		</style>
		<table class="data">
			<caption>Demonstration of adjacent-pairs punctuation trimming</caption>
			<thead>
				<tr><th>Combination
						<th>Sample Pair
						<th>Looks Like
			<tbody>
				<tr><th scope=row>Opening&#8212;Opening
						<td><samp lang="ja" class="char">〔</samp>+<samp lang="ja" class="char">（</samp>
						<td><samp lang="ja" class="char">〔</samp><samp lang="ja" class="char half-r">(</samp>
				<tr><th scope=row>Middle Dot&#8212;Opening
						<td><samp lang="ja" class="char">・</samp>+<samp lang="ja" class="char">（</samp>
						<td><samp lang="ja" class="char">・</samp><samp lang="ja" class="char">(</samp>
				<tr><th scope=row>Closing&#8212;Opening
						<td><samp lang="ja" class="char">〕</samp>+<samp lang="ja" class="char">（</samp>
						<td><samp lang="ja" class="char">〕</samp><samp lang="ja" class="char">(</samp>
				<tr><th scope=row>Ideographic Space&#8212;Opening
						<td><samp lang="ja" class="char">　</samp>+<samp lang="ja" class="char">（</samp>
						<td><samp lang="ja" class="char">　</samp><samp lang="ja" class="char">(</samp>
				<tr><th scope=row>Closing&#8212;Closing
						<td><samp lang="ja" class="char">）</samp>+<samp lang="ja" class="char">〕</samp>
						<td><samp lang="ja" class="char">)</samp><samp lang="ja" class="char">〕</samp>
				<tr><th scope=row>Closing&#8212;Middle Dot
						<td><samp lang="ja" class="char">）</samp>+<samp lang="ja" class="char">・</samp>
						<td><samp lang="ja" class="char">)</samp><samp lang="ja" class="char">・</samp>
				<tr><th scope=row>Closing&#8212;Ideographic Space
						<td><samp lang="ja" class="char">）</samp>+<samp lang="ja" class="char">　</samp>
						<td><samp lang="ja" class="char">)</samp><samp lang="ja" class="char">　</samp>
		</table>
	</div>

<h4 id="text-spacing-classes">
Text Spacing Character Classes</h4>

	In the context of this property the following definitions apply:

	Issue: Classes and Unicode code points need to be reviewed.

	<dl>
		<dt><dfn>ideographs</dfn>
		<dd>Includes all typographic character units [[CSS3TEXT]] whose base character is listed below:
			<ul>
				<li>All characters in the range of U+3041 to U+30FF,
					except those that belong to Unicode Punctuation [P*] category.
				<li>CJK Strokes (U+31C0 to U+31EF).
				<li>Katakana Phonetic Extensions (U+31F0 to U+31FF).
				<li>All characters that belongs to Han Unicode Script Property [[!UAX24]].
			</ul>

		<dt><dfn>non-ideographic letters</dfn>
		<dd>
			Includes all typographic character units that
			belong to Unicode Letters [L*] and Mark [M*] category,
			except when any of the following conditions are met:
			<ul>
				<li>is defined as <a>ideograph</a>.
				<li>is categorized as East Asian Fullwidth (F) by [[!UAX11]].
				<li>is upright in vertical text flow using the 'text-orientation' property
					or the 'text-combine-upright' property.
			</ul>

		<dt><dfn>non-ideographic numerals</dfn>
		<dd>
			Includes all typographic character units that
			belong to the Unicode Decimal Digit Number [Nd] category,
			except when any of the following conditions are met:
			<ul>
				<li>is categorized as East Asian Fullwidth (F) by [[!UAX11]].
				<li>is upright in vertical text flow using the 'text-orientation' property
					or the 'text-combine-upright' property.
			</ul>

		<dt><dfn>fullwidth opening punctuation</dfn>
		<dd>
			Includes any opening punctuation character (Unicode category <code>Ps</code>)
			that belongs to the CJK Symbols and Punctuation block (U+3000&#8211;U+303F)
			or is categorized as East Asian Fullwidth (F) by [[!UAX11]].
			Also includes LEFT SINGLE QUOTATION MARK (U+2018) and LEFT DOUBLE QUOTATION MARK (U+201C).
			When trimmed, the left (for horizontal text) or top (for vertical text) half is kerned.

		<dt><dfn>fullwidth closing punctuation</dfn>
		<dd>
			Includes any closing punctuation character (Unicode category <code>Pe</code>)
			that belongs to the CJK Symbols and Punctuation block (U+3000&#8211;U+303F)
			or is categorized as East Asian Fullwidth (F) by [[!UAX11]].
			Also includes RIGHT SINGLE QUOTATION MARK (U+2019) and RIGHT DOUBLE QUOTATION MARK (U+201D).
			May also include [=fullwidth colon punctuation=] and/or [=fullwidth dot punctuation=]
			(<a href="#fullwidth-ambiguous">see below</a>).
			When trimmed, the right (for horizontal text) or bottom (for vertical text) half is kerned.

		<dt><dfn>fullwidth middle dot punctuation</dfn>
		<dd>
			Includes MIDDLE DOT (U+00B7), HYPHENATION POINT (U+2027), and KATAKANA MIDDLE DOT (U+30FB).
			May also include [=fullwidth colon punctuation=] and/or [=fullwidth dot punctuation=]
			(<a href="#fullwidth-ambiguous">see below</a>).

		<dt><dfn>fullwidth colon punctuation</dfn>
		<dd>
			Includes FULLWIDTH COLON (U+FF1A) and FULLWIDTH SEMICOLON (U+FF1B).

		<dt><dfn>fullwidth dot punctuation</dfn>
		<dd>
			Includes
			IDEOGRAPHIC COMMA (U+3001),
			IDEOGRAPHIC FULL STOP (U+3002),
			FULLWIDTH COMMA (U+FF0C),
			FULLWIDTH FULL STOP (U+FF0E).
	</dl>

	<p id=fullwidth-ambiguous>
	Whether [=fullwidth colon punctuation=] and [=fullwidth dot punctuation=]
	should be considered [=fullwidth closing punctuation=] or [=fullwidth middle dot punctuation=]
	depends on where in the glyph's box the punctuation is drawn.
	If the punctuation is centered,
	then it should be considered middle dot punctuation.
	If the punctuation is drawn to one side (left in horizontal text, top in vertical text)
	and the other half is therefore blank
	then the punctuation should be considered closing punctuation and trimmed accordingly.

	The UA must classify [=fullwidth colon punctuation=] and [=fullwidth dot punctuation=]
	under either the [=fullwidth closing punctuation=] category or the [=fullwidth middle dot punctuation=] category
	as appropriate.
	The UA may rely on language conventions and the writing mode (horizontal vs. vertical),
	and/or font information to determine this categorization.
	The UA may also add additional characters to any category as appropriate.

	<div class="note">
		The following informative table summarizes language conventions
		for classifying fullwidth colon and dot punctuation:

		<table class="data">
			<colgroup class="header"></colgroup>
			<colgroup span=2></colgroup>
			<thead>
				<tr><td> <th>colon punctuation <th>dot punctuation
			<tbody>
				<tr><th>Simplified Chinese (horizontal) <td>closing <td>closing
				<tr><th>Simplified Chinese (vertical) <td>closing <td>closing
				<tr><th>Traditional Chinese <td>middle dot <td>middle dot
				<tr><th>Korean <td>middle dot <td>closing
				<tr><th>Japanese <td>middle dot <td>closing
		</table>

		Note that for Chinese fonts at least,
		the author observes that the standard convention is often not followed.
	</div>

<h4 id="japanese-start-edges">
Japanese Paragraph-start Conventions in CSS</h4>

	<div class="example">
		Japanese has three common start-edge typesetting schemes,
		which are distinguished by their handling of opening brackets.

		<div class="figure">
			<img src="images/opening-brackets-at-line-head.png"
				width="646" height="360"
				alt="The first scheme aligns opening brackets flush with the indent edge
						 on the first line and with the start edge of other lines.
						 The second scheme gives the opening bracket its full width,
						 so that it is effectively indented half an em from the indent edge
						 and from the start edge of other lines.
						 The third scheme aligns the opening brackets flush with the
						 start edge of lines, but hangs them inside the indent on the
						 first line (resulting in an effective half-em indent instead
						 of the full em for paragraphs that begin with an opening bracket).">
			<p class="caption">Positioning of opening brackets at line head [[JLREQ]]
		</div>

		Assuming a UA style sheet of <code>p { margin: 1em 0; }</code>,
		CSS can achieve the Japanese typesetting styles with the following rules:

		<ul>
			<li>
				Brackets flush with indent, flush with other lines (first scheme):
				<pre>
					p { /* Flush alignment */
						margin: 0;
						text-indent: 1em;
						text-spacing: trim-start;
					}
				</pre>

			<li>
				Brackets preserve fullwidth spacing on all lines (second scheme):
				<pre>
					p { /* Fullwidth alignment */
						margin: 0;
						text-indent: 1em;
						text-spacing: normal;
					}
				</pre>

			<li>
				Brackets hang in indent, flush with other lines (third scheme):
				<pre>
					p { /* Hanging alignment */
						margin: 0;
						text-indent: 1em;
						text-spacing: trim-start;
						hanging-punctuation: first;
					}
				</pre>

		</ul>
	</div>

<h2 id="edge-effects">
Edge Effects</h2>

	Note: Add final level 3 content

<h2 class="no-num" id="acknowledgements">
Acknowledgements</h2>

	Note: Add final level 3 list, with Randy Edmunds, Florian Rivoal, and Pierre-Anthony Lemieux added.

<h2 class="no-num" id="changes">
Changes</h2>

	Changes since the last Working Draft publication include:
	<ul>
		<li>Adding 'line-padding'.
		<li>Adding 'text-group-align'.
		<li>Adding ''text-spacing: space-first''.
		<li>Allow truncating the 'hyphenate-character'.
		<li>Rename ''text-wrap: normal'' to ''text-wrap: wrap'' for consistency with 'flex-wrap'.
		<li>Drop ''preserve-auto'' and ''preserve-trim'' from 'text-space-collapse'.
		<li>Redefine ''text-wrap: balance'' in terms of remaining space.
		<li>Note various issues on ''text-wrap: <<string>>''.
		<li>Miscellaneous minor fixes.
	</ul>