- From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
- Date: Thu, 17 Mar 2011 03:14:16 +0900
- To: CJK discussion <public-i18n-cjk@w3.org>
- Message-ID: <4D80FDF8.3000109@csail.mit.edu>
FYI. CSS3 Text addresses many CJK requirements and hence this mail
should be forwarded here.
-------- Original Message --------
Subject: [CSSWG] Minutes and Resolutions F2F Mountain View March 2011
Day 3: CSS3 Text
Resent-Date: Mon, 14 Mar 2011 21:34:51 +0000
Resent-From: www-style@w3.org
Date: Mon, 14 Mar 2011 14:33:13 -0700
From: fantasai <fantasai.lists@inkedblade.net>
To: www-style@w3.org <www-style@w3.org>
Summary:
- Reviewed CSS3 Text draft.
- RESOLVED: drop unrestricted value from text-wrap
- RESOLVED: use 'inter-character' instead of 'bopomofo' for ruby-position
- RESOLVED: add 'hyphenate', don't add 'none', to 'word-wrap'
- RESOLVED: Make percentages on hyphenation-limit-zone relative to line box
- RESOLVED: rename white-space-collapsing to bikeshedding
====== Full minutes ======
CSS3 Text
---------
fantasai: There's a bunch of marked issues, so we'll scroll through them
and try to resolve.
<smfr> http://dev.w3.org/csswg/css3-text/
fantasai: For text-transform, we're adding "fullwidth" and "large-kana".
fantasai: [explains the two values]
jdaggett: I think the name here is bad.
jdaggett: "large" implies incorrect size - there's really just "normal"
and "small" kana.
jdaggett: I think "fullsized-kana" would be better.
jdaggett: You're sort of pointing at various unicode documents, and
there's too much ambiguity.
fantasai: What's the delta you want?
jdaggett: Frex, for fullwidth, this should probably only apply to the
chars in the Unicode database marked with Y, and only to
letters and numbers.
fantasai: Okay.
<dbaron> letters and numbers, and not punctuation and whitespace.
jdaggett: the idea is that you want to take text that appears with
halfwidth chars in horizontal text, and do fullwidths in
vertical text.
jdaggett: So (1) have a specific algorithm, identifying the characters
this should apply to
kojiishi: It's already defined in unicode, right?
jdaggett: A lot of things are defined in unicode. We need to be specific
about what is being talked about here.
jdaggett: I don't think you want *all* halfwidths to change to fullwidth -
only letter and numbers, not punctuation and whitespace
kojiishi: No, we want all halfwidths to map to fullwidth
kojiishi: primary use-case is use in vertical text flow, to ensure that
every alphabetic and punctuation character to take up the full
space
jdaggett: Unicode doesn't define the transformation algorithm, it just
identifies the classes. You need to define the transform.
jdaggett: If you want to transform all of them, then say so explicitly.
fantasai: So you want a codepoint-to-codepoint transformation algorithm.
I'll mark an issue about it.
szilles: I'd like a note about this, because I wouldn't think a priori
that you'd transform whitespace and punctuation.
jdaggett: Yes.
kojiishi: What's the use-case? I've done some interviews in Japan,
and nobody has requested different treatment for those classes.
jdaggett: When you're going between horizontal and vertical, you want
the fullwidth in vert.
jdaggett: Ideally we want the author to write using the standard
codepoints, but it displays with teh fullwidth forms in
vertical text.
jdaggett: But if you mark a span with this, and it transforms the
punctuation, but other parts of your text aren't being
transformed, it'll be different.
fantasai: I think the question of which should be done is a question
for the jlreq people, not us.
<fantasai> jdaggett's concern is that punctuation forms won't match
between fullwith and halfwidth forms used in the same paragraph
szilles: Under orientation, we said upright.
fantasai: Right, but it doesn't change the glyph shape or the linebreaking
behavior.
fantasai: If you don't want the changed shape and behavior, just use
text-orientation.
fantasai: [gives use-case for why both options are useful]
szilles: But in Korean they're happy breaking arbitrarily
fantasai: That's handled with word-break, for breaking arbitrarily in
normal text
fantasai: But that won't get you fullwidth glyph shapes.
[discussion about use-cases]
* smfr suggests we move this discussion to www-style
jdaggett: So, last comment, this just needs to be tightened up a lot.
fantasai: In whitespace processing, the issue is control characters.
fantasai: Ones other than tab, line feed, space, and bidi formatting chars,
2.1 says to treat them as characters to render in the same way
as normal chars.
fantasai: But what does that mean?
jdaggett: Render as missing character if it doesn't exist.
Arron: Almost all browsers treat them as zero-width characters.
fantasai: So I have three options
fantasai: (1) render them as unknown chars if the font doesn't have them
fantasai: (2) treat them as zero-width all the time
fantasai: (3) Allow both
dbaron: If so, you should be explicit in what char classes you're talking
about.
Arron: I would prefer zero-width.
szilles: I'd prefer something that makes it not useful for people to have
put them in.
<dbaron> Seems to be character class Cc
szilles: Rendering them as zero-width has *some* use, but it's close
enough to useless.
fantasai: Okay, (2) it is.
fantasai: Next is white-space-collapsing property
fantasai: In a lot of flux
fantasai: I think we'll probably wind up dropping down to just the first
four values, but I've temporarily got a larger list to collect
ideas.
fantasai: The main issue for me is that I think the name sucks.
szilles: Was this inherited from XSL?
fantasai: This is different.
szilles: Why is 'collapse' better than 'collapsing'?
fantasai: Parallel naming with our other properties.
[name bikeshedding]
<fantasai> RESOLVED: rename white-space-collapsing to bikeshedding
<stearns> :)
szilles: I think tab-size is a bad idea.
jdaggett: Wait, this is for tab-stops, not a transform on tabs themselves?
bradk: Can we implement a length?
dbaron: It would be trivial to use a length.
Bert: Why do we need this?
TabAtkins: Because tabs in preformatted text are super-huge by default.
<dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=517882
glazman: I'll use this immediately in my source-view of my editor.
dbaron: For the record, Moz implemented this to change the size of tabs
in our view-source
<Bert> (It's useful to have tab stops and align the start of a SPAN to
it, e.g., in a ToC, but tab-size won't do that.)
<Arron> I think tab-stop should allow '0' as a valid value
fantasai: Now, 'line-break'.
fantasai: [describes the values]
szilles: How do you get interop on these?
fantasai: There are recommendations, but it doesnt' cover all cases.
fantasai: We don't cover line-breaking anyway, which is apparently okay,
and I'm not going to solve this problem by June.
szilles: How will you exit CR?
fantasai: There's enough there to test, and the rest is undefined.
fantasai: [describes word-break]
fantasai: We'll drop the 'keep-words' value if there's no implementers
interested.
fantasai: [describes the hyphenation property]
smfr: [question about displaying soft hyphens in an editting environment]
fantasai: I think we should drop the 'all' value.
fantasai: Or I can mark this as at-risk.
szilles: Does this show the soft-hyphens, or what the dict would have given
me as hypenation opportunities?
fantasai: Both.
szilles: And I can't tell which is which?
fantasai: UA-dependent.
fantasai: Okay, I'm marking as at-risk.
fantasai: Now, hyphenate-character property.
fantasai: Do we need the second hyphenation character?
szilles: I thought there was some language where the "beginning of line"
hyphenation char is used.
fantasai: I dunno, I don't have any examples of it being used.
Bert: This may have come from some languages where, when you break words,
you replace certain characters. But that's a different concept.
fantasai: Okay, I'm dropping the second character.
fantasai: [describes the hyphenate-limit properties]
jdaggett: Are these different ways of controlling hyphenation? Would
you use these all together?
fantasai: No idea. They are indeed different, though.
<stearns> I think they would be used together
jdaggett: Trying to understand the algorithm here.
jdaggett: Where's the language sensitivity, and where's the dictionary
come from?
fantasai: That's further down.
<stearns> you might only specify one or two that you're really concerned
with, but some authors would apply values for all
bradk: Can we combine the hyphenate-limit properties into one?
fantasai: I think -zone should be separate, but -before and -after are
combinable.
<johnjan> I don't think they should be combined. I don't know why you
would ever want them combined.
<johnjan> That was from Christian Stockwell, a PM on the IE team.
fantasai: There was a proposal on the list to add a hyphenate-limit-*
property that would limit the length of the word.
<TabAtkins> johnjan, We mean specifying them both in one property, rather
than having them cascading separately.
<TabAtkins> johnjan, not providing a single value that means both.
<johnjan> ah, like hyphenate-limit: 4 5; ?
<TabAtkins> johnjan, yeah.
Scribe: fantasai
jdaggett: asks what the priority is among the various limit properties
[discussion about how the properties work together]
fantasai, plinss: The limits combine: as soon as one limit applies, you
can't break there
jdaggett: Is that good enough? Do we need priorities of some kind?
jdaggett: Would that overconstrain?
Steve: ...
Steve: In practice it doesn't overconstrain
fantasai: There was also a proposal on www-style for a control to limit
the size of the word that gets hyphenated, so for example if I
set that to 5, "modal" would not break but "unconditional" would
...
<stearns> that would be quite useful
Alex: Knuth's paper says that once you do optimial paragraph breaking,
the hyphenation controls don't really make much of a difference
<johnjan> I think optimal paragraph is orthogonal to this conversation.
[argument about whether to combine -before and -after]
<stearns> could combine minimum, before and after
* fantasai thinks so too, steve zilles is not agreed
<stearns> I don't know of a use case where one would vary while keeping
the others set
dbaron: I don't think other systems have the same concept of properties
that CSS has
plinss: I think we should combine them and mark it as an issue. If someone
responds with a use case and says "no I really want them separate",
then we split them again
fantasai: Should we include the word limit in there?
arron: The word limit sounds very useful
<stearns> If we do, a suggested value for 'auto' is 5, going by InDesign's
defaults
<br duration=10min>
<johnjan> I've been trying to come up with a use case, but have not been
able to. It feels weird to me, but I'm ok with combining.
<johnjan> InDesign's default sounds good. (for word limit, right?)
<stearns> right
<johnjan> I believe my use case is to set word limit, before and after to
consistent values, so it's highly unlikely one would change at all,
let alone independent of the others.
Arron: It would be nice to put a note that ­ in a word disables
auto-hyphenation in favor of that breakpoint
Arron: since that would be the best way to do word-by-word tweaks
<johnjan> also explicit hypens would disable auto-hypenation as well.
(in addition to ­)
<fantasai> johnjan, I'm less sure of that
<fantasai> johnjan, since hyphens are part of the spelling of a word
<fantasai> johnjan, they're not there to control hyphenation
<johnjan> if I use the word 'auto-hyphenate' (even if I say limit-before: 6;)
I'd expect you to break on auto-
<stearns> back to hyphenate-character, unicode.org mentions the possibility
of putting a hyphen at the beginning of the line, but does not
provide an example
<stearns> http://unicode.org/reports/tr14/tr14-14.html
<johnjan> < leaving to catch a bus
<stearns> Another possible note could be that ­ at the beginning of a
word disables hyphenation altogether for that word
fantasai> hyphenation-limit-word?
fantasai: So question on hyphenation-limit-zone was should it be relative
to line box or block?
howcome: Line box
RESOLVED: Make percentages on hyphenation-limit-zone relative to line box
Scribe: Tab Atkins
fantasai: We also talked about -before and -after, and someone suggested
a minimum word length as well.
fantasai: [explains why this can't just be done through -zone]
howcome: Christian proposed something that sounded like -zone.
fantasai: [draws a pretty picture explaining why you can't do it through
-zone]
<bradk> hyphenation-limit-chars:<before> <min> <after>
* fantasai really really likes bradk's proposal!
* fantasai would put <min> first, though, so you can make <before> and
<after> the same easily
<bradk> hyphenation-limit-character-count:<before> <min> <after>
Bert: -zone sounds like it may be capturing the wrong concept - you want
something that measures more the tension imposed by justification -
with less spaces, you should be stricter about pulling words up.
fantasai: I think that'll be much harder to calculate.
Bert: Doing -zone assumes that every line has about the same number of
spaces, which may not be the case.
fantasai: Yes.
Bert: Also, if on the preceding line all the spaces were stretched, you
don't want to shrink the next line's spaces.
<bradk> I think all these properties should begin with hyfN8- instead of
hyphenation- so that we don't have to type as much.
<stearns> hy8n - hy(8 characters)n
<stearns> ideally it should be relative to the line's measure (how many
characters fit). I would specify using ems
howcome: This gets into the micro-typography issue that we don't want to
get into, too, where you might want to change the shape of
letters to better fit things to the line.
<fantasai> stearns, we have % defined to do that
<fantasai> % is relative to the measure of the line
Bert: Perhaps the badness-factor can be captured with the number of
spaces in the line, and the number of successive hyphenated lines.
fantasai: This sounds very complicated. For now let's just keep the
hyphens property.
* sylvaing ...or we could have a badness-factor property !
fantasai: And maybe drop the rest for now.
howcome: I was happy with the state of this section at the time it
transferred into this draft.
fantasai: we could mark everything at risk and see what ppl implement
howcome: About hyphenate resource, it seems there are two formats.
howcome: Kew has done some work cleaning up the dictionaries used.
howcome: There is a set of freely-available dictionaries.
howcome: The format isn't described anywhere.
howcome: They're derived from TeX's format, without the macros.
howcome: Does Apple have their own format?
<dbaron> he was trying to clean them up so they didn't depend on TeX macros
smfr: We use built-in system resources, but don't plan on implementing
hyphenation-resource soon.
smfr: I think we just purely go off the lang of the element.
howcome: Yeah, often you want to attach this to lang.
howcome: Though often when comparing content that's hyphenated, you want
to compare different dictionaries.
howcome: What I'm arguing against is to hinge this off the @lang attribute.
howcome: If you're laying out a book, frex, you want to lay it out, same
content, with two different hyphenations and compare.
TabAtkins: Since you're just debugging, can't you just tag one with a bogus
language or something?
jdaggett: What about topic-specific things?
szilles: And shouldn't you want to key it off of lang?
howcome: Yes, definitely, so by default authors should use :lang(). They
just shoulnd't be limited to only using :lang().
smfr: I think it's okay for CSS to point to a dict, as long as we agree
on a description of the format.
smfr: We're fine with the built-in resources for now, though.
jdaggett: I suspect you'll need it when, say, iBooks needs to display a
medical textbook.
fantasai: [something about formats]
jdaggett: Just glancing over the TeX dict, it looked like there were some
subtle important details in there.
jdaggett: Didn't AH point to a TeX dictionary?
jdaggett: If you follow the indirections in their reference, it's TeX-based.
<fantasai> Do we want to use a format key, like @font-face? Because a lot
of these formats are similar but not quite the same, so if you
tried doing content-sniffing, you'd probably slurp up the
dictionary and choke on something later because it's not quite
the format you expected.
howcome: The TeX algorithm is widely described, and there are impls of it.
jdaggett: If it's a straightforward thing for someone to look at the format
and implement, that's fine.
howcome: [comment about the format describing weights]
jdaggett: Right, and that makes implications about how to implement it.
howcome: I think a reference to TeX would be okay.
jdaggett: Without a format and the semantics for it defined, this entire
property can't be interoperable.
howcome: You could similarly argue for OT, which has parts that aren't
well-described.
jdaggett: You're talking about language handling? Yeah, but that's just
specific areas of OT, not the entire spec itself.
howcome: I think if we try to describe this directly, instead of just
referring to TeX, it'll be a lot of work.
szilles: So you're proposing we reference the spec. Is it a book, or a
stable website, or...?
<dbaron> http://www.tug.org/docs/liang/
howcome: It's called [TeX algorithm], and it's published in a collection
of algorithms called "Digital Typography".
szilles: The general rule is that references must be a public document
that people can follow.
howcome: It's a research paper.
szilles: That's probably okay. I just suggest you do the homework to get
us that reference.
<bradk> open office has this list that includes teX based hyphenation
dictionaries: http://wiki.services.openoffice.org/wiki/Dictionaries
fantasai: So the format we're standardizing on is the TeX hyphenation format,
along with macros?
howcome: Not macros.
fantasai: Okay, then we need to specify that.
howcome: Okay. But this should be a soft recommendation, not a strict
requirement.
fantasai: Okay, we just need a way to specify what exactly is being
requested to be implemented.
<bradk> GNU LGPL license is OK for hyphenation dictionaries?
jdaggett: If we're describing something where every impl uses their own
format, we should just throw out this property and let UAs do
what they want.
howcome: I think we just need to put into writing the principles used
when Kew & others were cleaning up the TeX files.
ACTION howcome Come up with a precise spec (reference or reference + prose)
for the hyphenation format
<trackbot> Created ACTION-313
smfr: Another problem - you'll get a flash of unhyphenated text before the
dict is downloaded, and people may want control over the timeout here.
howcome: We've discussed this relative to font-face, right?
smfr: Yes.
howcome: I think we decided then not to do anything, and we shouldn't do
anything here.
howcome: If you're concerned, you could just download the dicts in the
stylesheet before displaying anything.
Arron: No, they can take a long time.
fantasai: I think it should be a user pref.
howcome: I agree; it's a user thing.
* fantasai is impatient, would set it to a very short timeout :)
fantasai: next is whether to do @hyphenate-resource or 'hyphenate-resource'.
Advantage of former is less storage, and maybe more intelligent
langauge mapping.
fantasai: [shows example of using multiple dicts in @hy-res]
jdaggett: I think the common case is authors within a single language
needing multiple dicts for specialized texts.
fantasai: Right, you can juts provide multiple dictionaries, so medical
texts would have words in the first dict.
fantasai: The issue here is how you bind the dict to the element.
howcome: Impls, if there isn't a value for the prop on an element, they
don't use space for it.
fantasai: Yes they do.
howcome: Not a ton of space.
plinss: Is there a need to specify a dict on a per-element basis?
howcome: Yes, for example when debugging.
Tab: Debugging doesn't need to be elegant, just possible.
szilles: I think there are valid reasons to use different technical dicts
on different things in the same language.
fantasai: Generally you'd just concat the dictionaries.
fantasai: Only case where you need per-element is when you want to hyphenate
a single word differently based on the context.
fantasai: You can soft-hyphenate that, or specify it as a variant language.
szilles: I guess I can live with it, because I can't think of any other
property to control hyphenation with.
szilles: Besides, you can open separate windows anyway (for debugging).
howcome: I just think it's too much of a restriction to key off the lang.
fantasai: You want the @lang anyway, so UAs that don't support external
hyphenation resources have a clue what to use.
howcome: Medical, technical things in the same document, but only medical
for the medical section and technical for the technical section.
plinss: I think if you can find examples where you actually need this,
find them and bring them back in.
howcome: We already have impls. Why are we changing this?
fantasai: Space savings, frex. @-rule is relative to the size of the table
only, while another per-element rule is more memory per element.
[discussion about how much space would be saved]
<stearns> as far as I know, medical and legal dictionaries are more about
spelling than hyphenation
smfr: I thought @hy-res would be like @font-face, which would describe
the resource only, and then we link it to elements.
fantasai: The reason you fold them together is because there's generally
no need for the additional targetting.
howcome: You don't necessarily want to run through every dictionary to
hyphenate normal words.
TabAtkins: Do we actually think that imlementing hyphenation is going to
involve walking a linear list for every word?
dbaron: [talking about the dict format that TeX uses]
<dbaron> at least as documented in http://www.tug.org/docs/liang/
[architectural argument about property vs @-rule]
howcome: We already have implemenations, Prince does it with the property.
kojiishi: I dunno what AH does.
fantasai: Antenna House supports custom dictionaries, but not via
hyphenation-resource property
jdaggett: What does Adobe think about this?
szilles: I've sent an email to try and find an answer.
szilles: My belief is that we're lacking somewhat in experience in the
room for some of these questions.
jdaggett: Okay. i think it would be useful ot have feedback from adobe
szilles: Yes. And MS, too, as they have publishing stuff.
plinss: We have spent too much time on this, and aren't coming to a
conclusion. We need to table this for now and come back with
information later.
plinss: We'll leave this open for now.
fantasai: Next is 'text-wrap'
fantasai: I can't find a usecase for 'unrestricted' so far. Thinking of
removing it.
dbaron: How is this different from word-wrap: break-word?
fantasai: That's only for emergency breaking. This is all-the-time breaking.
dbaron: Might be useful for ancient greek or roman, but I don't think I care.
plinss: Might be useful for URLs
dbaron: That's emergency breaking, with word-wrap.
bradk: How does this interact with white-space?
fantasai: white-space is now a shorthand property for text-wrap and
white-space-collapse
szilles: It would be nice to point out that one of the line-breaking rules
was controlled by the word-break property.
fantasai: i can point that out.
RESOLVED: drop unrestricted value from text-wrap
fantasai: next is the word-wrap property. This is emergency-wrapping.
fantasai: We could add a 'hyphenate' value that turns on hyphenation only
for emergency breaking.
smfr: If word-wrap breaks a word, do you insert a hyphen?
fantasai: Not with break-word. Yes with theoretical hyphenate value.
Arron: If the hyphen isn't selectable, I think the 'hyphenate' value is okay.
bradk: Seems to be confusing with word-break and this.
fantasai: Seems that way only because of the names. This should be called
'emergency-wrap'
<TabAtkins> (Emergency rap)
<smfr> in-case-of-emergency-wrap-word
(For when you absolutely need to stop and hammer-time.)
plinss: Did this property go to CR?
fantasai: No, but there are tons of unprefixed impls unfortunately.
dbaron: I think IE had this since IE4...
<dbaron> IE4 or something else old
fantasai: other question is whether to have a keyword that starts turning
off the break restrictions in emergency.
fantasai: Usually you want to break when absolutely necessary, but if you
really really want overflow...
szilles: 'hyphenate' makes sense, because it just says "if you can do a
better-than-arbitrary job, do so"
Arron: note in the spec that hyphenation hyphen isn't selectable
bradk: I can't think of when you'd want 'none'.
fantasai: It's when, frex, you have hyphenation turned on, but limits are
preventing a break. 'normal' would relax these limits, but maybe
you want to still honor them.
[talk about priority]
RESOLVED: add 'hyphenate', don't add 'none'
fantasai: next is text-align
fantasai: There was request to specify first line separately from rest,
for spanish poetry, for example
dbaron: We're doing first-line align in text-align, but last-line in a
new property?
fantasai: yes, because... [trails off]
szilles: We can do this with ::first-line
fantasai: Ooh, maybe.
fantasai: Ok, so the problem with that is
fantasai: 1. The primarily alignment is the first-line alignment, the
rest of the lines wrapping around are a fallback case.
If you specify text-align: end; text-align-first: start; then
old UAs end align everything, which is not what you want
fantasai: 2. Other issue is that this affects the first line and every
line after a hard break: only wrapped lines get the fallback
alignment
fantasai: Also, I pulled in <string> alignment from CSS2.0
jdaggett: I don't see a good use-case for <string> alignment
dbaron: This makes the table-width calculation algorithm substantially
more expensive.
smfr: You want to align the decimal point to a length, not necessarily the
center, right?
dbaron: In most cases, the whole column will have this, and so it won't
matter - then its width will be shrink-to-fit.
fantasai: And I put the default to be right-align
dbaron: Often in tables you'll have a long header, and then many short
numbers which should be aligned and centered.
fantasai: You can do that by also specifying 'center'.
plinss: If there are multiple instances of the string, which is aligne?
fantasai: The first one.
szilles: Particularly the "N/A" in the example is very useful, and matches
what spreadsheets do.
dbaron: This affects preferred width of table columns. Open question of
whether it should affect min-width, and how.
fantasai: I think the cost there becomes a CR issue - if people don't
implement due to this, we'll drop it.
fantasai: But I think this is well-specified and good.
dbaron: [describes passage in his intrinsic-with paper concerning this]
dbaron: I don't think you can compute a min-width.
dbaron: I think the dfn is wrong in the case where there's not enough room.
dbaron: I think your def assumes there is enough room to do the alignment.
dbaron: If may be there is no wrapping of text, but simultaneously not
enough room to align all of it.
fantasai: Spec says that in that case the alignment is undefined.
szilles: Undefined, or stop aligning?
dbaron: You'd prefer continuous behavior when possible, not just it suddenly
dropping the alignment when the cell gets too small.
[discussion about min-width support on cells]
dbaron: Maybe the min-width computation needs even more controls...
<dbaron> It would split pref-width into three different values (pref before
alignment, pref of alignment marker (zero when none present), and
pref after alignment)
<dbaron> and it would split min-width into four, those three for cells
that are unbreakable and then a fourth for cells that have
breakpoints in them
howcome: I'd like to talk about match-parent.
howcome: Seems like a slim use-case.
fantasai: No, it's significant for bidi cases.
fantasai: Say you have a list, or <select>, and they're mixed direction,
typically you want them all aligned to a consistent side, based
on the nearest lang.
fantasai: So 'match-parent' is like 'start', but computes against the
parents direction, and computes to 'left' or 'right' to keep
children on the same side.
howcome: Why not 'inherit'?
fantasai: That will inherit 'start' from its parent, which gives us the
same problem.
howcome: So adding 'start' and 'end' caused the problem that we're solving
with 'match-parent'?
fantasai: 'start' is the default value in 2.1, it's just not stated.
howcome: how about ol:lang(en) > li, and set the property using that
selector?
fantasai: I don't think that works. One of the cases is the defualt UA
stylesheet for <option>.
fantasai: In that case you don't know what the direction property of
<select> will be, or the language.
fantasai: You can't make a list of all the languages. The i18n group
said that directly. That's why we have 'dir' attribute.
fantasai: So you just can't write a selector in the UA stylesheet that
will get you the right behavior here.
fantasai: next is text-align-last
fantasai: It's also used when you can't justify a line.
szilles: Thing that's not clear, if I have an anonymous block, the last
line in that gets this property?
fantasai: Yes, any time the break isn't a soft wrap.
szilles: Feedback I got was that text-align-justify is complicated, but
not sufficiently useful.
fantasai: I've changed some things since I got that feedback. More
specific problems?
szilles: The JL task force came up with a way to scribe, for japanese,
how they would end up justifying things.
fantasai: You have japanese, latin, and various punctuation.
fantasai: Punctuation is ua-defined and special.
fantasai: But this tells you how to prioritize other things.
szilles: But yo uhavne't gone far enough to get reasonable results.
fantasai: [explanation of using the values]
howcome: What if you specify one of the cjk values on non-cjk content?
fantasai: You get what it says on the tin.
fantasai: It's specified in the table in the spec.
fantasai: If you don't put any punctuation in your paragraph, you'll
get interoperable results.
fantasai: That's the best I can do.
fantasai: What I have are the main ways of prioritizing things.
fantasai: Please send specific comments to www-style.
szilles: So this property is just talking about different prioritizations
of a number of techniques that could be used.
szilles: That's fine, but the exact details of who punctuation interacts
still aren't defined.
fantasai: Yeah, because punctuation has all kinds of crazy special
behavior in some languages (like japanese).
howcome: If we can't define this behavior, we shouldn't have these values in.
fantasai: There are valid distinctions to be made, which are captured here.
fantasai: I could take out the descriptions and just say "figure out what
these mean".
howcome: We need to get interop, though.
szilles: I don't think we should prevent good typesetting just because we
can't get exact interop.
fantasai: What you're tweaking is described . The things that we won't
get interop on aren't described.
jdaggett: Can't we infer this from content?
fantasai: How?
jdaggett: I don't see a clear path to implementation here.
jdaggett: You still need to define the bounds of where UAs need to be
consistent.
fantasai: I did. If you'd like to improve that...
howcome: I think it's possible to do fine typography when you encounter
languages. But by putting these knobs in, we're raising the bar
for implementors.
szilles: We need a way to distinguish english-in-japanese and
japanese-in-english.
szilles: We can sorta say "what's the lang on the paragraph", but that's
a weak approximation.
fantasai: I'd like to get to text-decoration before we wrap up this meeting.
szilles: Can you stick an issue in the spec here about "Maybe give better
advice?"
fantasai: I can mark an issue for the WG to review and come up with
suggestions.
ACTION to WG: Review the text-justify section for improvements.
fantasai: There was a request to do each-line indentation, for source code
or poetry. Done with "each-line" keyword on 'text-indent'
fantasai: For text-decoration, I copies over the lines from XSL.
fantasai: People want to turn off decoration in descendants.
fantasai: I put in a rule that a text can have at most one of each type
of line.
szilles: If you have transparent colors, you can tell which is done.
fantasai: yeah, or if the font-size is differnt
dbaron: Or the baseline is different, like superscripts
dbaron: With an underlined superscript in an underlined link, you don't
want to break the link's underline where the superscript happens.
fantasai: then we have controls over style, color, and which line,
controlled separately.
fantasai: What if you wanted to inhibit your ancestor's decoration, but
add your own?
fantasai: Like you wanted to stop the underline and create your own.
dbaron: Just allow all the stuff. "underline no-underline" to inhibit
the parent's, and then draw your own.
szilles: You can do it yourself with nested spans.
szilles: So might as well do it here.
howcome: I don't like the combination of names.
[discussion about a keyword that kills all three decorations at once]
howcome: cancel
Arron: Is cancel per-decoration, or all of them?
fantasai: I think you want to do both.
<dbaron> cancel, cancel-underline, cancel-overline, cancel-strike-through
fantasai: next is text-decoration-skip
fantasai: Controls whether it's painted on images or spaces, or on top
of glyph ink.
fantasai: Do we need one that doesn't skip margins and padding? They're
skipped by default.
Arron: Don't see a use for that.
fantasai: next is text-underline-position
fantasai: alphabetic is default, then we have below-left and below-right
szilles: For rotated vertical test, I say "below right"...
<bradk> text-decoration: dashed([<dash-width>,<dash-space>]+[,<dash-width>,<dash-space>]*)
fantasai: You do below.
dbaron: Why is this a pair of keywords and not just a hyphenated keyword?
fantasai: To be consistent with text-emphasis-position
dbaron: random naming question - text-underline-style: wave or wavy?
fantasai: I have no opinion.
<Xaxio> noun or adjective? text-decoration: underline is a noun, so I'd
vote for noun
fantasai: [overview of text-emphasis]
szilles: The feedback I got is "draw marks", with the implication that
this is done as a graphic process.
szilles: So rather than "draw small circles as marks", say "use XXX character"
fantasai: The UA is allowed to use other characters, or draw its own.
smfr: We implement this, but use the chars.
szilles: So require using the chars.
fantasai: [points out passage talking about glyph usage]
szilles: Given that text, just say to use XXX character and then the prose
overrides that when necessary.
<fantasai> Suggestion: s/Draw/Display/
szilles: that's better, but I want to emphasize using the glyph
fantasai: [describes text-emphasis-position]
ruby-position
-------------
fantasai: Something to address is that epub has ruby-position, which isn't
in this module.
fantasai: It's the one thing from Ruby that epub needs.
fantasai: And they'll put it in, prefixed, if necessary.
fantasai: If we're planning to change things here with ruby, that
conversation needs to happen sooner rather than later.
fantasai: Koji and I noticed that 'before' and 'after' aren't accurate
on ruby-position here, due to vertical-lr writing mode.
jdaggett: I think bopomofo is peculiar.
fantasai: yeah, I disagree with that change.
szilles: I recommend 'inter-character'
RESOLVED: use 'inter-character' instead of 'bopomofo'.
fantasai: and Koji and I think we should use the text-emphasis-position
values for ruby-position as well.
szilles: If you have emphasis and ruby, do you stack or not, and in what
order?
fantasai: Some pubs will stack it, some will swap the sides one is on,
and some will drop one or the other.
Arron: I think we shouldn't worry about this today.
szilles: Let's just note that there may be a need for a control here.
<jdaggett> yes
szilles: I'd like to see an example of underlines in mongolian.
fantasai: The problem is putting chinese in mongolian, which is surprisingly
common
[talk about underlines in chinese/mongolian]
* Bert is at SFO. You're still meeting?
* TabAtkins_ Yes, Bert.
* TabAtkins_ O_o
* jdaggett elika and steve are trying to keep us here until 10pm, at which
point the CSS3 Text sleepover starts
* sylvaing shudders
* jdaggett mongolian pillow fight!!!
* sylvaing didn't know there was a CSS3 Text Sleepover module
* Bert thinks that's the one with the Cascading Bed Sheets
howcome: There seem to be some general properties here that apply to every
language.
howcome: And then there are some that apply to only a few languages
(important ones, but still)
howcome: I suggest we separate out the script-specific stuff from the
generic stuff.
szilles: That's not fantastically attractive because the bidi and vertical
issues aren't script-specific, but they're driven by non-western
usage.
fantasai: It would be a ton of work for little benefit.
[talk about relative value]
* sylvaing bets that howcome is about to suggest text-replace again
* jdaggett all problems can be resolved with text-replace
* sylvaing interpreted 'from 8,000ft to below sea level' as 'GCPM'
* TabAtkins is dying.
Scribe: fantasai
howcome: I think we should split the spec
plinss: I challenge howcome to come up with the split
plinss: One way we can split is to mark them all at-risk and push to CR,
see if we get implementations
jdaggett: I'm concerned that they'll get implemented, but implemented wrong
Steve: You've got to have an architectural base into which to put things
<howcome> The scope of this spec is very large, and goes to great depths
in some areas, while shallow in others. I suggest splitting out
the script- or language-specific issues into separate modules.
This will also allow us to address other languages, like Mongolian,
in the future.
Meeting closed.
Received on Wednesday, 16 March 2011 18:12:29 UTC