W3C home > Mailing lists > Public > www-style@w3.org > March 2011

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 14 Mar 2011 14:33:13 -0700
Message-ID: <4D7E8999.6020004@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 Monday, 14 March 2011 21:33:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT