-
Notifications
You must be signed in to change notification settings - Fork 791
Expand file tree
/
Copy pathOverview.bs
More file actions
2162 lines (1829 loc) · 75.6 KB
/
Overview.bs
File metadata and controls
2162 lines (1829 loc) · 75.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<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/2015/WD-css-text-4-20150922/
Editor
C02E
: 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: [=inline boxes=]
Inherited: yes
Percentages: N/A
Computed value: as specified (However, see special provision for unsupported <<lang>>)
Animation type: discrete
</pre>
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 & paste operation.
<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).
<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.
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 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 characters 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).
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>>
<i>canonicalized</i> and converted to <i>extlang form</i>
as per section 4.5 of [[!RFC5646]],
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.
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.
Inline box boundaries
and out-of-flow elements must be ignored
when determining word boundaries.
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.
<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><em>สวยงาม</em></code></pre>
The following example shows <em>incorrect</em> positions:
<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span>คือ<em><span style="color:red">|</span>สวยงาม</em></code></pre>
The following shows the correct positions in a more contrieved situation:
<pre><code highlight=html>กรุงเทพ<span style="color:red">|</span><b><u>คือ</u><span style="color:red">|</span><em>สวยงาม</em></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''.
<li>
immediately adjacent to a [=word-separator character=],
or an [=other space separator=],
or a ZERO WIDTH SPACE (U+200B) character.
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,
<li>
between a [=typographic letter unit=]
and a preceeding [=typographic character unit=] from the [[!UAX14]] OP line break class,
<li>
between a [=typographic letter unit=]
and an adjacent [=typographic character unit=] from the [[!UAX14]] GL, WJ, or ZWJ line break classes.
</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,
<li>
between a [=typographic letter unit=]
and a preceeding [=typographic character unit=] from the [[!UAX14]] PR line break class,
</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: [=inline boxes=]
Inherited: yes
Percentages: N/A
Computed value: as specified
Animation type: discrete
</pre>
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.
<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.
<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.
</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').
Instances of <{wbr}> are considered equivalent to U+200B,
and are also replaced,
as are [=virtual word boundaries=] inserted by 'word-boundary-detection'.
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.
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 & paste operation.
<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>
<p>むかしむかし、<wbr>あるところに、<wbr>おじいさんと<wbr>おばあさんが<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>
<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>
<p>らいしゅう<wbr>の<wbr>じゅぎょう<wbr>に<wbr class=p
>たいこ<wbr>と<wbr>ばち<wbr>を<wbr class=p
>もって<wbr>きて<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><
C026
/div>
</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: all elements
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> inside the element
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: all elements
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: <a>inline boxes</a> 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>
<footer>
<venue>27th Internationalization and Unicode Conference</venue>
&#8226; <date>April 7, 2005</date> &#8226;
<place>Berlin, Germany</place>
</footer>
</pre>
In a narrow window the footer could be broken as
<pre>
27th Internationalization and Unicode Conference •
April 7, 2005 • Berlin, Germany
You can’t perform that action at this time.