SV_MEETING_TITLE -- 23 Sep 2010

CSS3 Text

<scribe> Scribe: fantasai

<scribe> ScribeNick: fantasai

M: The line breaking strictness and word-break should be separate properties
... The old version is better, with two properties

M shows a proposal from Toppan Printing and Sony Corp for EPUB requirements

M: They propos characters-not-starting-line property and characters-not-ending-line property

f: um.....

M: They have a default 'none' value. I think the default value should be 'auto'

f: I would prefer to have Kobayashi-sensei define several levels of strictness
... If individual character control is needed by some people, that can be an additional level of control.

I: If I think about authors writing HTML with text editors, I agree with you.
... But if I assume most users will be using editing tools, each can have different preset

f argues that CSS is a dynamic layout format, and this level of control is excessive when you can't even control the font size

[unminuted discussion]

also that authors shouldn't have to deal with this low-level of control

discuss having line-break: loose \ normal | strict and having a separate property as a diff against the default set of restrictions

We study a matrix of breaking options

CJK breaking restrictions on one axis, non-CJK breaking restrictions on another

question is, do we need two properties, or is one linear axis of strictness enough

Current proposal:

break-non-CJK: break-all | hyphenate | keep-together

break-CJK: newspaper | normal | strict | keep-together

defaults are

break-non-CJK: keep-together

break-CJK: normal
... keep-together is used for Korean and (known to be) non-CJK texts

Discuss naming and IE compat

Current proposal:

word-break: break-all | hyphenate | normal

line-break: newspaper | normal | strict | keep-all

This is compatible with IE except that IE's "word-break: keep-all" is "line-break: keep-all"

The change is so that one property deals only with non-CJK and one property deals with only CJK -- it is a more logical division

Question: how are fullwidth characters treated? As CJK or non-CJK?

Murakami-san and Ishii-san suspect as CJK. UAX14 confirms.

M and I are studying the white-space controls in css3-text

text-emphasis

fantasai reviewed Ken Lunde's chart of emphasis shapes

suggested syntax:

[ filled | open ] || [ dot | circle | double-circle | triangle | sesame ]

Suggestion to rename "filled" to "solid"

But it is confusing with double-circle

Ishii-san also points out it could be confused with a solid-stroke circle vs. dotted-stroke circle

Seem to be settling on "filled"

Filled is the default

If the shape is left out, then it computes to "dot" in horizontal writing mode and "sesame" in vertical writing mode

Murakami-san notes that we need text-emphasis-color

Discussing options for text-emphasis-position

current values in the spec are before | after

but does this make sense in Mongolian writing mode, where the before edge doesn't coincide with the "top" edge of the line?

Ishii-san suggests an 'auto' value, that maps from the language to the correct side

Japanese uses above in horizontal; Chinese uses below

We would need a chart in the spec

probably use "before" for Japanese and traditional chinese, "after" for everything else

(We have examples of Tibetan text using after.)

Question: Should text-emphasis marks be applied to punctuation?

JLTF document says not to apply them to commas, full stops, opening brackets (cl-01) or closing brackets (cl-02)

should also skip spaces

If text-emphasis dots conflict with ruby, they should be skipped

alternatively, the ruby or dots sides can be switched?

Settled on making the dots go away; it's the author's responsibility to use text-emphasis-position or ruby-position to avoid such conflicts

Proposed starting point: follow suggested rules for which punctuation gets emphasized in JLTF document. All punctuation not mentioned in that document gets skipped.

Back to text-emphasis-position

and the fact that in Mongolian text the before edge is on the left but the top of a line is on the right

Suggestion:

text-emphasis-position: above | below

to avoid confusion with 'before' and 'after' terminology

Changed to above | below, marked as issue for feedback

Would need corresponding changes to css3-ruby, though.

Question: should emphasis dots factor into the line height?

f suggests it should follow the same rules as for ruby, whatever those are

<shepazu> fantasai: just turning in, though... attending Web Directions USA in Atlanta

<shepazu> that makes sense... I personally don't think that any glyph characteristics should factor into line height, only the "glyph/character cell" and the font size

Discussing justification now

M asks what inter-word is for. It's for e.g. Latin texts, where CJK should not space out

M and I want more details for auto

f suggests providing examples; doesn't want to recommend anything because there are many different ways of being smart

Discuss kashida value.

It's for Arabic, which has two methods of justification: stretching glyphs, or stretching spaces

"clustered" should probably shift to 3rd priority

Everything except those two would be a fallback case

Discussion of what would be a good default justification algorithm for all scripts

Probably like distribute, but with "discrete" dropped to 2nd priority

Ishii-san suggests having that as an example for 'auto' to encourage UAs to do something that works better for non discrete scripts

Murakami-san draws up the chart for this

M: This should be the baseline. The UA can do better, but this would be the suggestion in the chart

fantasai notes to self that the "connected" and "cursive" categories probably should be last priority for all groups...

Note to previous discussion: add <string> as possible value for text-emphasis-style

short break

punctuation-trim

<kennyluck> fantasai, can I make the log public?

yeah

I forgot to do that

<kennyluck> RSSAgent, make log public.

It's publicly logged at krijnh's site anyway :)

RRSAgent: make logs public

M: Current draft is ok, but we need more options

M writes "start-except-first-line"

f: We had a previous version that had none | start | start-edge | end-edge | hyphens
... oh wait, that's hanging-punctuation

M pulls up an example

M: Here is some plaintext. Paragraph breaks represented by line breaks, indent represented as space
... Open parentheses replaces the indent space

f: you could handle that type of formatting, if you had markup, with hanging-idnent: first

p {

margin: 0;

text-indent: 1em;

hanging-punctuation: first;

punctuation-trim: start adjacent end;

}

(M writing into his notebook)

M: This works if I have correct markup with <p> and use text-indent for indentation

But if someone is using ideographic space for indentation

Then a fullwidth opening bracket should not be trimmedon the first page

Ishii-san, fantasai: This is incorrect markup. The space should not be there. The text should be transformed to correct markup.

Ishii-san, fantasai: Run a preprocessor.

on the source

text-justify-trim

http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-justify-trim-prop

f: How does this interact with punctuation-trim?

M: This interacts with line-breaking

whiteboard work

Draw a bunch of boxes. One half-width box with a bracket followed by a fullwidth bracket

one box on the second line

two half-shaded boxes (trimmable) on the first line

Notes on conclusions:

* First, apply punctuation-trim. (This is like kerning; it effectively changes the width of the characters.)

* If everything fits perfectly, no text-justify-trim

* If hanging punctuation solves the gapping problem, no tjt

* If tjt would prevent gap at end of line, apply tjt. Does not have to be in fixed increments: arbitrary trimming amounts ok.

* Q: relative priority to other justification methods?

Suggestion: text-justify: inter-ideograph punctuation-trim;

Define relative priority in text-justify definition/charts

* Japanese (CJK?) favors compression. Other scripts favor expansion.

* tjt might be applied even when not justifying

text-justify: punctuation-trim; ?

i.e. if text-align is not justify and text-justify has punctuation-trim, apply the trim?

RRSAgent: make minutes

kennyluck: he's fussy about punctuation :)

<kennyluck> RRSAgent、make minutes

<kennyluck> Huh

kennyluck: that looks like ideographic comma.
... try ascii comma

M: Maybe text-justify: avoid-trim;
... Allow punctuation-trim by default

f: Doesn't make sense for most other scripts.

Do we want inter-ideograph to punctuation-trim by default?

f: What if you want inter-ideograph without punctuation-trim?
...

M: Default of punctuation-trim is 'none'. That's not good for Japanese layout. You want "start adjacent end"
... You also would want text-justify: inter-ideograph punctuation-trim; for Japanese
... But that doesn't need to be the default

Looking at punctuation-trim. Is there a problem with making the default not 'none'?

Some trimmed characters are not FULLWIDTH characters, but are stndard punctuation, which may not be full width

:lang(ja) { punctuation-trim: start adjacent end; }

We should add an Appendix with suggested rules for the default style sheet

this can be one of them

We could even do this instead of the 'auto' value for text-emphasis

although that might not work so well if we have a shorthand that resets text-emphasis-position...

Murakami-san writes into his notebook:

text-justify: auto | [ [inter-word|...] || trim ]
... trim; means prefer trimming, but do auto

auto is allowed to use trim, although it should be careful about when it does so

trim means prefer compression to expansion

and allows trimming of punctuation

text-justify: inter-word trim; means trim punctuation and compress spaces first priority; if that doesn't work, then expand spaces

text-autospace

(to close previous discussion, Ishii-san and fantasai will draft something based on above notes, and we will review again with Murakami-san next week)

Looking at definition in old css3-text CR. Not sure what values are needed. Text needs more details (e.g. how much space)

Also doesn't explain what happens when there's punctuation involved at the boundary

IE apparently implements all values (according to MSDN)

This property should have some values to handle French punctuation's non-breaking-thin-space before ! ? and guillemots

U+202F

http://unicode.org/udhr/n/notes_fra.html

Random notes:

add text-transform: fullwidth; to transform letters to fullwidth

e.g. acronym { text-transform: fullwidth; }

fantasai asks if text-transform: katakana; is needed to transform hiragana to katakana

Murakami-san doesn't think so

but notes that translating small kana to full-size kana might be necessary for ruby

fantasai: jdaggett mentioned that a good font would have a variant for use in Ruby. Wouldn't it take care of this?

M: rt { text-transform: large-kana; }

Murakami-san notes that automatic transformation of numbers is also needed

e.g. from ASCII to Fullwidth or ASCII to ideographic

fantasai: we also have a font-variant-numeric property

I'm not sure if that's more appropriate or not

We could put it in text-transform and ask jdaggett for comments

side conversation about <acronym>

Would be useful if it didn't use the dictionary to define its meaning

http://en.wikipedia.org/wiki/Acronym_and_initialism

<anne> note that <acronym> is gone from HTML5

yes, I know

<anne> there's only <abbr>

It would be useful if <acronym> were defined in a way that it could be used for all abbreviations that get capital letters

because those are styled specially sometimes

sometimes in small-caps in western typography

usually in fullwidth variants in eastern typography

etc.

<anne> yeah maybe, people hardly use these elements though

<anne> and <abbr class=caps></abbr> is only three characters longer

Yeah, if <acronym> didn't already exist I probably wouldn't think of it

but it does already exist and is implemented,

would be useful in some cases we're discussing

Ok, so summary is new values for text-transform

fullwidth | large-kana | fullwidth-digits | ideographic-digits

Ishii-san is skeptical that the *-digits values are needed

fantasai doesn't have an opinion

Ishii-san: If you convert digits, would you also convert punctuation like commas and slashes?

OS/2

21,200

'98

text-transform: fullwidth transforms anything that has a fullwidth variant into that variant

use markup to restrict scope

text-transform: fullwidth | large-kana

f: could add note wrt large-kana to look into whether font can handle it

break

Murakami-san shows implementation of vertical text with rotated layout

width and height are swapped

except for replaced elements

due to UA stylesheet img { writing-mode: horizontal; }

which prevents the rotation of its contents

and the swapping of its width and height properties

correction - the contents dont' rotate if the writing mode stays vertical; the width and height properties just swap

Ishii-san thinks it makes sense for the contents to rotate too

Murakami-san shows floats to the left and right

they float to the top and bottom

we probably have to do this even in an absolute coordinate system, because there are no top/bottom floats

(except in gcpm, but most implementations don't support those)

Murakami-san shows repeat-x

in this implementation it stays as repeat-x

which gives a very different effect...

Murakami-san: Have a sizing problem with background-size as well
... and the implementor thinks the image might need to be rotated

fantasai, Ishii-san: whether background image is rotated depends on the image

Ishii-san: If there are rules for transforming, they should transform everything to be consistent and easy to understand.
... The author can then predict what will happen and tweak the style sheet accordingly.

Murakami-san writes: image-orientation-vertical: upright | 90deg

fantasai: You want to control image rotation per image, not per element

Murakami-san: page-break-before: left and right would need to swap
... In this implementation, "right" is "odd-page"

Murakami-san draws a horizontal writing mode box with a top-border inside a vertical text flow

How do the margins map?

How do the borders map?

fantasai: block formatting context is horizontal, box behaves as vertical box

Ishii-san: what about tables? want borders to match contents there.
... Maybe make the boundary the border edge
... so margins match outer context, borders and padding match inner context
... width and height follow inner context, just like replaced elements.

fantasai: Another thing about tables is that there's an outer box and an inner box.
... so treating the table borders the same as the inner context would not be inconsistent.

Murakami-san: The box with writing-mode change is a very special box.

Murakami-san proposes an anonymous box.

for the writing-mode-switching div.

Murakami-san: outer box has outer writing mode
... The margin is on the outer box
... borders and padding are set on the inner box

Ishii-san: I made a list of properties that could possibly be affected.
... We talked about border and padding and backgrounds
... also have box-shadow
... position
... caption-side could also be an issue
... clear is ok, just like floats
... clip needs discussion
... multi-column is not a problem
... crop is like clip

fantasai: crop?

Ishii-san: css3-content

fantasai: Oh, we're going to cut that out.

Along with most of the rest of the spec :)

Ishii-san: object-position
... float-offset might not need anything
... width/height/etc we discussed
... image-orientation should be discussed
... overflow-x/y needs discussion
... @page size, I think we can easily agree not to rotate in this case
... Do we need to discuss css-3d-transform perspective-origin?

don't know

Ishii-san: rotation, rotation-point
... And template layout

fantasai: uhh, you'd need to transpose the layout......

Ishii-san: text-align is ok. Text-shadow similar to box-shadow
... form elements and object elements, do they rotate?
... Tables would transpose.

fantasai: yes, certainly

Ishii-san: So basically my idea is that since there are so many properties, and future properties coming every year, just transform the axis and think everything rotates 90deg
... easier than picking which property to rotate

Murakami-san: writing-mode: vertical-transform would mean changing the coordinate system, not just the properties

Ishii-san: My idea is to also rotate the image contents, so it's more than that.

fantasai: whether we define this rotation as a layout thing or as part of a style sheet transformation process, we still have to deal with all these issues
...
... If your replaced element is a Flash application, you can't just rotate it like you can with an image

Ishii-san: Back to the image

fantasai writes:

html {

transform: rotate(90deg);

font-variant: vertical;

}

<scribe> Done.

If we're rotating everything, why don't we actually rotate everything

full-on graphical transform should do the trick

just reset the font

to pretend its vertical

<kennyluck> RRSAgent: make minutes

- DRAFT -

SV_MEETING_TITLE

23 Sep 2010

Attendees

Contents

CSS3 Text

text-emphasis

punctuation-trim

text-justify-trim

text-autospace

Summary of Action Items

Scribe.perl diagnostic output