W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > January to March 2011

Fwd: [CSSWG] Minutes and Resolutions F2F Mountain View March 2011 Day 3: CSS3 Text

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Thu, 17 Mar 2011 03:14:16 +0900
Message-ID: <4D80FDF8.3000109@csail.mit.edu>
To: CJK discussion <public-i18n-cjk@w3.org>
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 &shy; 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 &shy;)
  <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 &shy; 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 March 2011 18:12:30 GMT