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

[CSSWG] Minutes and Resolutions Kyoto F2F Fri: Transitions, IVS, CSS3 Text, Floats and Exclusions, Regions, Pagination

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 11 Jun 2011 01:05:40 +0900
Message-ID: <4DF240D4.5090005@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Tab presented a proposal for dealing with shortcomings in the Transitions
     spec. < insert url here when Tab gets around to posting it :| >

Ideographic Variants

   - RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger
               requirements for sharing IVSes across IVD collections, and
               the creation of a mapping table among existing duplicate IVSes
               (and any matching CJK compatiblity ideographs). See UTS#37.

   - RESOLUTION: font fallback goes all the way to system fallback with the
                 IVS before repeating with base, will add a property to
                 switch between that and font-consistency-priority matching

CSS3 Text

   - Discussed Håkon's list of issues:

   - RESOLVED: Change 'bikeshedding' (previously known as 'white-space-collapsing')
               to 'text-space-collapse'.

   - RESOLVED: Mark 'line-break: loose' at-risk

   - Suggested to pull out codepoint lists from 'line-break' rules into an
     appendix and make it clearer that 'line-break' doesn't affect non-CJK
     codepoints except when the text is tagged as Chinese or Japanese.

   - Discussed 'text-spacing' property and 'text-justify' property, assigned
     many edits to the editors:
       - Make text-justify table use numbers/'never' instead of dots.
       - Add a footnote for the 'auto' column.
       - Add examples of text-justify usage from the minutes.
       - Make it clear that glyph substitution is neither required nor forbidden
       - Fix spec so that lower priority adjustment includes earlier priorities
       - Make punctuation justification priorities more clearly out-of-scope
       - Make it clear that TeX-style cost-based distribution is allowed and
         add an example with 'inter-word'

   - Discussed 'text-transform' property, assigned many edits to the editors:
       - Make a normative appendix with the order of all text operations
       - Define Unicode Database fields used for <wide> decomposition
       - Point more directly to Unicode case shifting algorithm
       - Make small kana mapping table
       - Remove note about font-variant-ruby (goes in ruby spec)
       - Add note about @text-transform possibility for future additions

   - RESOVLED: Drop 'hyphens: all' and switch properties currently marked
               optional to at-risk.

   - Discussed whether to rename 'word-wrap' to 'overflow-wrap'.
     The name 'overflow-wrap' is a much better description of what it does,
     but 'word-wrap' is already implemented across browsers (unprefixed).
     This remains an open issue pending feedback from WebKit and Opera.

   - RESOLVED: Drop 'text-outline' since the new spread argument to
               'text-shadow' can handle it.

Other: Charter, Floats, Regions

   - RESOLUTION: List CSS 2.0 as maintenance, asterisk saying to be obsoleted asap

   - RESOLVED: Make css3-floats module to bring together proposals for floats
               and exclusions

   - Discussed pagination and forced breaks across pages, regions, columns.

====== Full minutes below ======

   David Baron (Mozilla)
   Bert Bos (W3C)
   John Daggett (Mozilla)
   Daniel Davis (Opera)
   Arron Eicholz (Microsoft, via IRC)
   Elika Etemad (Invited Expert)
   Sylvain Galineau (Microsoft)
   Vincent Hardy (Adobe)
   Koji Ishii (invited Expert)
   Peter Linss (HP)
   Nat McCully (Adobe)
   Luke Macpherson (Google)
   Alex Mogilevsky (Microsoft)
   Shinyu Murakami (Antenna House)
   Ted O'Connor (Apple)
   Florian Rivoal (Opera)
   Shunchi Seko (NTT)
   Shane Stevens (Google)
   Taro Yamamoto (Adobe)
   Steve Zilles (Adobe)

<RRSAgent> logging to http://www.w3.org/2011/06/03-css-irc
Scribe: jdaggett

Transitions and Animations

   TabAtkins: talking about new directions for anim and transitions
   TabAtkins: current spec has limitations
   TabAtkins: transitions are only state-to-state
   TabAtkins: that's different from the animations spec
   shans: i've been messing around with ideas in js
   shans shows demo
   TabAtkins: note the weird interactions when hovering
   TabAtkins: want animations of all properties
   TabAtkins: make @transition rule
   TabAtkins: with over, from, to, and animation
   TabAtkins: syntax is at-rule with selector to identify the elements
              that the animation applies to
   alexmog: shouldn't that be the other way around?
   TabAtkins: current property is just simple syntax
   TabAtkins: this is the advanced version
   TabAtkins: we have some issues
   <smfr> is there a url for what's being discussed?
   TabAtkins: with complex animations, multiple states
   <discussion of where to stick the files so smfr can see it>
   jammering about www-archive
   <smfr> green on black?
   comic book ninjas
   more mumbling
   these folks need more coffee, much too slow
   cmon, going at web speed, blah, blah, blah...

   danield: there are just four states?
   TabAtkins: ... talking about various states...
   aw that's cute, screen sharing by pushing two pc's together
   TabAtkins: talking about states
   TabAtkins: back to the button example
   TabAtkins: number of states you go through
   TabAtkins: going through a to c you can still go through b
   florian: will non-defined paths be synthesized?
   TabAtkins: normal transition is just a jump
   TabAtkins: should be able to synthesize
   TabAtkins: it runs a shortest path algorithm on the graph
   TabAtkins: discussing missing legs
   TabAtkins: describes how the path graph is defined
   TabAtkins: wanted something that tells you what to do going between two states
   TabAtkins: similar to the data attributes in html
   TabAtkins: we can define a state family
   TabAtkins: should be able to define keyframe animations over transitions
   TabAtkins: everybody wanted something less weird but doesn't work
   TabAtkins: showing same example with condensed syntax
   <shans> @transition-graph #animateMe {
             over: state-path;
             @edge(A, B) {
               animation: transition(left, top, background-color, -webkit-border-radius, color) 0.5s;
               direction: both;
             @edge(B, C) {
               animation: transition(left, top, background-color, -webkit-border-radius, color) 1.0s;
               direction: both;
   sylvaing: hmmm, complicated...
   vhardy: why "state path" and not the property?
   TabAtkins: doesn't work well when defining multiple animations

   <sylvaing> wondering about the wisdom of overloading attribute selectors
   TabAtkins: problem of additive properties
   dbaron: need to adjust the way the cascade to fix
   dbaron: why should these be properties at all
   dbaron: rather than something that you match with selectors
   TabAtkins: working with selectors is hard to define
   dbaron: work selectors and declarations within the at-rule
   dbaron: put the selectors into the @transition-graph rule
   dbaron: then the cascade just works things out
   dbaron and TabAtkins discussing alternate syntax
   vhardy: seems to me you're defining a graph
   vhardy: the edges seem to be between paths which feels weird
   TabAtkins: we have a state called path
   chrome guys confess to abusing the use of 'path'

   TabAtkins: showing an even more complex example because complexity is my
              middle name
   TabAtkins: showing click-animate-click-animate-click-animate
   TabAtkins: you don't associate state with styles that apply to that state
   <shans> @transition-graph #animateMe {
             over: state-path;
             @edge(A, B) {
               animation: transition(left, top) 0.5s;
             @edge(B, C) {
               animation: transition(left, top) 1.0s;
             @edge(C, D) {
               animation: transition(left, top) 1.0s;
             @edge(D, A) {
               animation: transition(left, top) 1.0s;
   TabAtkins: multiple selectors could set the state to D
   TabAtkins: not sure what the correct answer is here
   TabAtkins: these are useful for UI's
   TabAtkins: people are trying to do complex things
   TabAtkins: this is simpler for those cases
   dbaron: weird that property values defined in one place and transitions
           in another place
   <smfr> i agree with dbaron
   dbaron: should be more like keyframes

   TabAtkins: defined by mixins
   TabAtkins shows example using @node
   <shans> @transition-graph #animateMe {
             over: state-path;
             @edge(A, B) {
               animation: transition(left, top) 0.5s;
             @edge(B, C) {
               animation: transition(left, top) 1.0s;
             @edge(C, D) {
               animation: transition(left, top) 1.0s;
             @edge(D, A) {
               animation: transition(left, top) 1.0s;
             @node(D) properties-for-D;
   TabAtkins: this creates a property bag in the transition graph
   TabAtkins shows demo passing through D node
   TabAtkins: this gives us a unified model
   TabAtkins: there are some issues
   TabAtkins: fertile ground

   smfr: tricky to talk about this in F2f format
   TabAtkins: will post examples to wiki
   vhardy: should we do this with the FX task force
   TabAtkins: not doing anything incompatible yet

   vhardy talking about state transition model
   vhardy: lots of animation models when include things like SMIL
   vhardy: i'm interested if we can more of the timing model of SMIL
   vhardy: sophisticated effects require better sync
   TabAtkins: we've thought about this a lot
   TabAtkins: we probably don't want to go too crazy in css
   TabAtkins: complex stuff should be done via a rich js api
   TabAtkins: dean is working on css om apis
   TabAtkins: go through there
   TabAtkins: this allows more powerful things
   TabAtkins: that's probably a better direction
   vhardy: may need some declarative syntax for that
   TabAtkins: hard to do with css model
   vhardy: how to deal with multiple animations
   TabAtkins: css model is that one animation wins
   TabAtkins: we know smil does that
   jdaggett: i'm worried about referring to smil
   the complexity of smil scares me
   vhardy: it's complex but it's doable
   <arronei> I'm worried that this is complicating CSS too much.
   sylvaing: the lack of an api is painful
   <jdaggett> arronei, +1
   sylvaing: for developers
   <arronei> We used to have a behaviors spec for CSS this might be worth
             moving in that direction.

Scribe: fantasai

IVS Policy

   <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0427.html
   fantasai: I think we should send a comment to Unicode saying that their
             policy of allowing different people to register different
             IVS's for the same exact glyph is a problem.
     <kojiishi> http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/
   jdaggett points to example in that page
   jdaggett: This is one single codepoint. The second codepoint listed is
             the IVS, which says which variant to use.
   jdaggett: If you look carefully, you can see he variations
   <dbaron> looking at variants of 邊
   jdaggett: There's a whole range of variations
   jdaggett: But what you'll start to notice is that if you look at fonts
             that support some of these variations, they map several IVSes
             to the same glyph
   <dbaron> fonts map E0100 and E0108 variants to same glyph, etc.
   jdaggett: The way this work is that different vendors can come to Unicode
             and register variants
   jdaggett: But there's no process that requires them to go through the
             existing registration to see which of their variations already
   jdaggett: That whole problem is foisted onto users and font developers
   jdaggett: the NTT guy said it's a lot of work to figure this out, but
             that's just foisting the job onto all the font developers
   Nat: It's in his interests to keep up the silos.
   jdaggett: They don't realize that the way in which they've done this,
             they're creating interop problems for authors and for
             implementers like us
   jdaggett: So there's that problem
   jdaggett: What fantasai has written up is a letter ..
   jdaggett: There are proposed changes to the process that would encourage
             vendors to share IVSes.
   jdaggett: fantasai's proposal is to make that stronger, that registrants
             must say what the differences are and write it in text in order
             to register a new IVS
   jdaggett: The differences can be very subtle. It's hard to tell, without
             prose, what differences are being registered, and which
             differences aren't being registered or whether this is just a
   Steve is concerned about being tactful

   jdaggett: Interop isn't something that exists only outside of Japan.
   Nat: This comes partly because of the silo issue, but also because it
        isn't articulated clearly enough what the main thing is you're
        trying to solve.
   Nat: I think what they saw with IVS was that they could encode all
        these incompatibilities in glyph shape into Unicode
   Nat: They see it as the opposite of what it's for, it's not your
        responsibility anymore, you can register any IVD registration
   Nat: what should have happened when the second IVD collection was
        registered was to say, "No, that's not what this is for."
   Nat: To have more than one collection means that you have a body
        that needs to determine the interactions between the collections.
   Nat: Why have more than one collection? Why not have only one collection?
   Nat: And have new glyphs interoperate with existing set
   Nat: If you're not having a flat model, then what are you trying to do?
   Nat: If I'm right and the original purpose was to solve interop, then
        we really need strong language
   Nat: Saying that itnerop is the main problem we're trying to solve,
        and explaining all the new problems, will help convince Japanese
        that this is the right way to go.
   Yamamoto: They tried to .. set of glyph, but they couldn't because the
             granularity changed.
   Yamamoto: For example, government needs more granularity for people's names
   Yamamoto: ...
   Yamamoto: So they reached conclusion that it's impossible to have one
             universal list of glyphs
   Yamamoto: So this was born, and that allows different parties to submit
             different IVD collections
   Yamamoto: But they're currently planning to amend the process to
             encourage sharing and coordination between groups with similar
   Yamamoto: That is the historical description.
   jdaggett: It's that proposal that we're suggesting to comment on

   jdaggett: Unless it's written more strongly, they won't bother. They
             should cooperate, but it takes too much time.
   jdaggett: I think the language proposed is good,
   jdaggett: I think we should take Steve's suggestion and also focus on
             the problem of interop within Japan

   Yamamoto talks about some committee about discussing IVS interop
   Yamamoto: At that meeting we will discuss ways to improve the current
   Yamamoto: Such as having a mapping table between different IVD collections
   Yamamoto: Or more documentation on granularity.
   fantasai: ...
   jdaggett: One issue here is is, look at these two differences -- this
             glyph has a concave stroke, the other one has a convex stroke
   jdaggett: These differences are erased in a gothic style
   Nat gives a history of a glyph diverging and merging and diverging
   jdaggett: This starts to get involved into font fallback
   jdaggett: A lot of gothic faces won't implement these differences
   jdaggett: In most web pages, if the font is a gothic style face, if you
             require fallback to that selector, you're going to see a run
             of text that's going to hit Mincho, and that difference is
             going to be far greater than any of the subtleties in these
   Nat: The gothic face will just unify the glyphs, have the same glyph
        for both codepoints
   jdaggett: There will be UAs that try to do the right thing and show
             the variant. That will look worse than UA that does the wrong

   RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger
             requirements for sharing IVSes across IVD collections.

font fallback with IVS

   jdaggett: My standpoint isn't that I want one way or another, but that
             there's a tension between doing the right thing and showing
             the correct variant, and keeping a consistent style of text.
   jdaggett: For a lot of users, the distinction is too subtle, which they
             won't notice, but they will pick up the style change.
   Yamamoto: There can be 2 different views on this issue.
   Yamamoto: If we have theoretical character model
   Yamamoto: Yes, there are exceptional cases such as Gothic and display
             faces, where such subtle details are gone
   Yamamoto: But there are a variety of typefaces in Mincho style, there
             are many different designs of Mincho categorized in Mincho style
   Yamamoto: In that scope, I think it is possible to notice the differences
             in these glyph shapes.
   Yamamoto: For example when the govt wants to use differences in glyph
             shapes for purposes of their database for people's names or
             place names, if they want to use IVSes to distinguish subtle
             differences based on Mincho style
   Yamamoto: They may think that oh, if one IVS and its glyph can be
             represented by different Mincho typeface, they may think this
             single IVS is slightly abstract nature as a glyph, abstracted
             glyph, and not the lowerlevel typeface-dependent glyph images
   Yamamoto: I think understanding of most ppl in govt and financial org
             where they need to distinguish such subtle differences, seems
             to be limited to scope of Mincho style. So important govt docs
             printed in Mincho typeface.
   Yamamoto: So I can agree with you, but there is another way of looking
             at this.

   Nat: One point you may want ot emphasize, is when doing fallback, when
        doing catastrophic fail of the system ...
   jdaggett: You said that yesterday, and I want to say this again -- on
             the Web, fallback is the normal thing.
   jdaggett: If you bring up Facebook, you'll see a bunch of languages.
             the only reason those are ever displayed is because UAs search
             through the system for a font to use to display them
   Koji: Even within Japanese, authors tend to want to show glyphs while
         designers want to use consistent typefaces. So it splits.
   jdaggett: I think that's not true. I think authors would like things
             displayed nicely, too.
   jdaggett: Kobayashi-san wants it one way, and person working at Magazine
             wants it another way
   Koji: If author things the difference is subtle, they shouldn't use IVS.
         It shouldn't be asked to decide, it should be author's  ...
   Koji: if author cares, the difference is important to him.
   Florian: It says the author cares. Doesn't say whether author cares enough
            to switch font.
   Nat: I'm concerned about author knowing so much about the encoding. They'd
        just pick from a glyph palette.

   Nat: When developing content that might involve font fallback, we should
        give the author ability to choose whether they care about the exact
        glyph shape or the font consistency.
   Nat: Because of the tension you menion, I think there should be
        infrastructure to support a preference of some kind.
   Nat: Author should know that UA might not be able to display things as desired
   Nat: All of these combine to make a situation.
   Nat: When there's a conflict, we should give them a choice.
   Yamamoto: govt or police or CIA may want abstract glyph instead of typeface
             consistency. But graphic designer or commercial advertisement,
             yeah, abstract glyph shape can be less important.
   Nat: I think also if we make that choice explicit, it will help ppl
        registering in the IVD to realize whether their variant is purely
        stylistic or whether it is more semantic.
   Nat: This font fallback scenario helps people understand that.

   jdaggett: One problem we have in CSS is, font fallback, we have a couple
             different flavors.
   jdaggett: A lot of discussion has been simplified or oversimplified.
   jdagget writes:
     font-family: fontA, fontB;
   jdaggett: So if I have a base character and a selector
   jdaggett: in an ideal world, you would ask if the sequence is in fontA,
             if in fontB, and then go into system fallback
   jdaggett: system fallback is a black box.
   jdaggett: That's not something that is explicitly specified.
   jdaggett: This is currently a one-pass process
   jdaggett: We haven't defined how to match clusters as opposed to single
             characters, but it's a character-based model, and it's a
             one-pass model
   jdaggett: You go through font list, and then you hit system fallback
   jdaggett: When you consider IVS, need to think maybe there's a 2-pass
             process tha needs to happen
   jdaggett: So, in many mailings that have been posted, appear to describe
             as 2 options:
               1. You take the combination of base character and selector,
                  go through the list looking for a match. If you don't find
                  one, you use base character and look for a match again
               2. Go got to first font and check for char + IVS, then check
                  for base character, then go to second font and ask for
                  base+IVS, etc.
   jdaggett: Those are just 2 of several options. Because you have this
             black box here.
   jdaggett: Question is, when do you hit the black box.
   jdaggett: In 1, do you hit the black box with the combo before going back
             with the base character?
   jdaggett: Or do you only hit system fallback if you can't find either
             the sequence or the base?
   Florian: Not sure this helps with having a choice
   jdaggett: ...
   jdaggett: This problem (points at IVS example) makes things even worse,
             do you look at interrelations between variants?

   Koji: I would like to show an example of how I would choose glyphs.
   Koji: It's not about IVS, but even before IVS we have some variants
   Koji: I'm going to show how I would type user name today.
   Koji: I'm typing watanabe, and this is the IME conversion.
   Koji: It's picking up from my Outlook contacts
   Koji: Different Watanabe's in my outlook contact have different glyph
   Koji: I don't remember which glyph, but it's in my contacts
   Koji: But it's important to get it correct for people names
   Koji: So this is built into IME.
   Florian: I think the point is that the person authoring the document
            might not realize that they're picking  a very particular glyph
   jdaggett: So you're saying you don't know whether this is using an IVS
             or not
   Koji: Right. If this displays different on his computer, I would be
         very disappointed.
   jdaggett: ...
   jdaggett: I think what Nat is suggesting is interesting, for example
             in a name list you would choose to show the correct glyph,
             but in a more general context you would choose to preserve
             the font style
   Yamamoto: ... family name distinction is done by subtle distinctions
             at abstract level, and that is important. For large group
             of ppl in Japan, they require what Ishii-san said.
   jdaggett: So the problem is, if the policeman has the Hanyo-Denshi
             font, and your system doesn't have it, what happens?

   jdaggett: There's a subtle point here wrt how UAs evolve.
   jdaggett: We all know that features have a way of going beyond what's in
             the spec very often
   jdaggett: My concern with this is that there'll be a natural temptation
             to do improvements, such as incorporating mappings between
             Hanyo-Denshi and Adobe Japan 1 and default glyph
   jdaggett: If one UA does that, then all UAs have to do that.
   jdaggett: So my idea is to disallow that in the spec.

   Nat: Same problem exists today with mobile phones
   Nat: When you send from NTT Docomo phone to ??, the SMS gets translated
        to something that will work.
   jdaggett: I want to put in that cmap tables are used, only.
   jdaggett: I don't want all implementations to cart around a mapping table.
   Steve: If the problem get solved at the registry level
   Steve: Then it's easy fo rpeople to be consistent because there is in
          theory only one sequence for each
   Steve: The next suggestion is to require font vendors to have mapping tables
   Steve: Then the user doesn't need to do it
   Steve: It could also be solved at the UA level
   jdaggett: For this version, those tables don't exist, and we create an
             interop problem if different UAs use different tables
   Steve: My final point is that somewhere some group should create that table
   Steve: Which will be copied everywhere.
   Nat: Fonts are a notoriously unreliable place to put such mapping table.s
   Nat: We are constantly updating our stupid Unicode tables in these fonts.
   Nat: There are so many inaccuracies in our font tables.
   Steve: Moving the solution to a different place doesn't solve the problem
          of building the table.
   jdaggett: My point is that it would be unfortunate for everyone if we
             tried to do the right thing, incorporating some complicated
             algorithm, and then that complicated algorithm, by user demand,
             gets foisted on other people.
   Nat: I think clear wording in the spec is good.
   Nat: With this issue, but there's a conflict between ppl wanting to use
        Adobe Japan 1 and Hanyo-Denshi
   Nat: I think there will be resistance for font vendors to use both mappings.
   Nat: Hanyo-Denshi variations are built for a certain user set in mind.
   Nat: And some of these variations are so subtle, that they are almost
        stylistic variations.
   Nat: They're provied for govt use or whatever
   Nat: Adobe-Japan 1 is not a government use table
   Nat: I think it'll be difficult for each font vendor to map to the govt
        glyph shape database
   Nat: Which is what it's becoming, instead of semantic-meaning database.
   Nat: So we need this table, maybe it goes in the black box, but then
        everyone has different black box

   jdaggett: I wanted to point out one thing Kawabata san put up on the board.
   jdaggett: One thing he put up was [base char][IVSx][IVSy]
   jdaggett: so that was fallback in the character stream
   jdaggett: This.. if you look at how this was defined, there's a single
             selector. You can't have multiple selectors.
   jdaggett: We should explicitly put in text saying the second selector
             is malformed.
   Nat: It's interesting thing he's decided is necessary. Points out that
        fallback.. because of the way IVD colections came about, fallback
        will have to be customizable
   Nat: Could be more fuel for your letter. Here is someone who wants to
        customize fallback. Obviously there's a problem here.

   Koji: I think there were two issues mixed.
   Koji: One is whether to fall back IVS first or font first
   Koji: Other is mapping between different IVD collections.
   Koji: For the latter, I don't think it's necessary. It's not application's
   jdaggett: I'm saying it's not just unnecessary, but we have to say it's
             not allowed. Otherwise some applications will include it in
             their black box.
   jdaggett: This table doesn't even exist, so ...
   Florian: Can we address separately the two issues?
   Koji: What I care is first one.
   jdaggett: I hadn't considered Nat's proposal to allow a choice
   Florian: We have a switch in CSS, and give an algorithm for each option.
   Florian: I think it's only possible to pick the best algorithm for each
   Florian: Not hard to decide on the algorithm once you have priority
   jdaggett: So my proposal would be to look for the correct sequence first,
             all the way to system fallback. Then go back and do base character.
   jdaggett: And have a switch for preferring font consistency.
   jdaggett: Keep in mind that the text includes the IVS, so if you cut and
             paste it you preserve this info

   Nat: Imagine a publishing-proofing system.
   Nat: In desktop systems, we want to make it really obvious when a glyph
        is missing.
   Nat: This way the proofer could immediately see that this character was
        missing or wrong
   Steve: You could use a font that maps every Unicode codepoint to the geta
          character (missing glyph thing)
   jdaggett: So, first point is, that's not a general feature. It's a
             user-agent level feature.
   Nat: ...
   jdaggett: Oh, you're talking about a Web-based authoring environment
   Steve: Just hijack it by using the fail-character font
   Nat: Ok, that works.
   Nat: U+3013

   jdaggett: Ok, so that's all I have to say. I'll work on adding the wording here.
   jdaggett: Unfortunate that this complicates font fallback, but that's par
             for the course.
   RESOLUTION: font fallback goes all the way to system fallback with the
               IVS before repeating with base, will add a property to
               switch between that and font-consistency-priority matching

   Nat brings up compatibility chars
   Koji: I think that's a separate topic, and not CSSWG responsibility
   Nat: No, but add to Unicode feedback from CSSWG.
   ACTION: fantasai mention compat characters in mapping table request
   <trackbot> Created ACTION-322

Scribe: Tab Atkins

CSS3 Text

   murakami: I think 'white-space-collapse' is a good name for the property.
   murakami: It's not a big problem for XSL-FO to have a property of the same
             name but different values, I think.
   murakami: They're sufficiently different.
   <fantasai> Note: Murakami-san is an implementer for Antenna House Formatter,
              which supports both CSS and XSLFO
   szilles: So what happens if I embed SVG in both?
   szilles: It makes sense for SVG to do whitespace collapsing.
   szilles: The agreement we had was that if we were going to change the
            property value, we should change the name.
   murakami: With 'white-space-collapsing', is the "ing" a big problem?
   fantasai: Just clumsy, especially with 'border-collapse' already existing.
   jdaggett: Why not just call it 'white-space-collapse' for now, mark an
             issue, and look at it later?
   fantasai: That just puts us in the same boat.
   jdaggett: Just to have it not be "bikeshedding".
   <TabAtkins> "whollapse-c-space"
   dbaron: 'collapse-white-space'?
   szilles: 'text-space-collapse'
   RESOLVED: Change to 'text-space-collapse'.

   fantasai: Let's look at the ToC and go through issues.
   Nat: My main priority is things to do with japanese punctuation adjustment.
   jdaggett: [explains the standard model of pruning specs after experimental
             impls start]
   fantasai: Let's start with linebreaking, then spacing, then text-justify.

CSS3 Text: line-break

   fantasai: ie6 implements line-break:normal and strict, and then we added
             another level, and an 'auto' value so the UA can pick whatever's
             appropriate (mobile phones want looser, probably)
   fantasai: The definition is fairly vague - lots of UA freedom.
   fantasai: In strict breaks are forbidden before small kana and some other marks.
   fantasai: [more description of the property in the spec]
   jdaggett: Is there stuff in the jltf recs that give you character classes
             for this info?
   fantasai: We do point to the jlreq document for recomendations, but...
   jdaggett: I'm looking for something more detailed.
   jdaggett: I'm fine with codepoints being listed as a character class in a
             normative appendix, so then we can just refer to character
             classes in the normal spec descriptions.
   fantasai: Ok.
   Nat: I don't think the jlreq character classes are used for linebreaking.
   szilles: They sometimes are, and sometimes aren't.
   kojiishi: Toppan said that they wanted to specify individual characters
             for "kinsoku rules" (characters you can't break on).
   florian: General interoperability concern - while this helps for cj, it
            potentially makes the interop bad for other types of languages.
   florian: Because there aren't any details other than the cj stuff.
   fantasai: Unfortunately, the rules for linebreaking are very specific
             to the language...
   fantasai: We're not trying to solve this, and exactly specify it, but in
             Japanese they care about having different levels of linebreaking.
   fantasai: We could specify that in languages other than cj, the property
             has no effect, or has no effect *right now*.
   jdaggett: Is this tied to the language tag?
   fantasai: Somewhat - there are several breaks that are based on the language.
   jdaggett: I ask becuase you can have mixed-language documents.
   jdaggett: So you shouldn't be using the japanese rules.  And there are
             English-breaking rules, where in japanese you'd instead do some
             relatively odd things (like breaking in the middle of an english
   fantasai: That's handled by the next property.
   florian: [something I missed]
   fantasai: Impls have a compromise breaking algorithm that tends to work
             decently on most languages as a default
   florian: So if you say 'strict', does it only work on japanese?
   fantasai: They work in all languages, but the rules specifically refer to
             japanese characters, so it won't effect other scripts.
   florian: If we extend this to other languages, we may not be able to use
            pure codepoints.  We may have to say "if in french, do this".
   fantasai: We already have that here - we have some rules that are specific
             to chinese-only or japanese-only.
   fantasai: The language-specific rules are orthogonal to the level you're
             working on.
   florian: But if we later let 'strict' work for English...
   fantasai: -- like, "only break at spaces"...
   florian: ...we'll have rules in Japanese that say "break at hyphens" and
            in English that say "don't break at hyphens".

   fantasai: We've got a division between the generic rules, which every
             language would do, and then the lang-specific rules
   fantasai: *Only* if you're language-tagged do you get the language-specific
   florian: So should we say that in "generic mode" there's no difference
            between levels?
   fantasai: There is a difference, but they're code-point specific, so they
             won't affect other scripts.
   szilles: I suggest we split it into "generic" which is just the 'normal'
            value, "code-point specific" which has the code-points for each
            level, and "lang-specific" has even more specific rules.
   [discussion about how specific it is to refer to code-points]

   fantasai: The point is that the linebreaking algorithm is defined across
             *all* of unicode.  Most languages that use a given codepoint
             use the same linebreaking for those codepoints. But there are
             exceptions where line breaking is language-specific.
   szilles: The point is that, in the generic set of rules, there is *no*
            strict category.  It is defined to be, by necessity, identical
            to 'normal'.
   szilles: So we should be absolutely clear that, in the generic case,
            there's only the one algorithm.

   Nat: Each publishing house has their own rules for what's appropriate.
        There's some consensus, producing some lists for what's appropriate.
   Nat: But here in this spec it's *so* vague.  'normal' is defined as
       "use the most common set of linebreaking rules", but what is "most common"?
   fantasai: So how should I define this without listing codepoints immediately?
   Nat: I suggest using very generic names - "level1", "level2", etc.
   fantasai: We can't change the value names - 'normal' and 'strict' have
             been implemented for a long time.  We only added 'loose' and 'auto'.
   Nat: Ok. So, given all the variability in what's going on here, why
        specify it at all?
   Nat: Anything other than 'strict' is basically meaningless, because it's
        far too varying.
   [some discussion I couldn't pick the point out of in time, so was lost]

   Nat: I think it's unfortunate that the spec, then, doesn't really improve
        on the situation as it currently exists.
   florian: I think the property is intended to help cjk without hurting
            anyone else, but according to Nat it's not helping all that much,
            because it's not clear enough.
   <florian> adding to my previous comment: and for the non cjk world, it
             risks ecouraging a proliferation of different algorythm where
             we didn't want one, and cause interoperability issues.
   fantasai: I can go copy someone's house rules and put them in the spec,
             if that's what's wanted.
   szilles: I think the point is that any solution that tries to do a halfway
            approach to the problem is going to fail.  It'll end up as a
            20/80 solution, instead of 80/20.
   szilles: What I'm hearing is that not having any variation at this level,
            and coming up with language-specific ways of putting stuff in
            (kinsoku tables, etc), is basically necessary here.

   fantasai: I believe that the specifics of the house rules aren't important.
             Authors won't care. Publishing houses do.
   fantasai: People using Word basically never alter the kinsoku tables.
   jdaggett: One problem is that you're talking about an application, where
             the same rules are used across all computers, but here we'll
             have browsers with multiple rules.
   szilles: I think that, if you're adopting MS's properties, you should
            just accept Microsoft's rules.  I'm not saying they're the best,
            but hey, consistency.
   fantasai: So, I went through the jlreq lists and pulled out the behavior
             that you must do generically, what you must do for certain
             languages, etc.
   fantasai: I can't be absolutely exhaustive because it keeps changing/growing

   kojiishi: Word has 3 levels for Japanese - normal/strict/custom - but only
             one for Korean - normal.  InDesign is similar.  We want to avoid
             the language-specific stuff as much as possible.
   szilles: I'm curious about who you're trying to satisfy.  The publishing
            houses aren't happy, and if the normal authors don't care, can't
            they just do 'normal'?
   kojiishi: Normal users *do* switch between normal and strict, though.
   florian: You're not saying that if you haven't labelled with a specific
            language, not to change anything.
   fantasai: So you're saying that it should only work if you have a language tag?

   florian: If someone has a single awesome linebreaking algo, that's okay.
            But do we want to invent four?
   fantasai: Yeah?
   Bert: Go ahead!  Invent as many awesome algorithms as you want. This is good!
   Bert: I think we only need two values - "auto" and "strict".  I usually want
         the best linebreaking algo the UA can figure out, but occasionally
         I'll want to specifically say "strict".
   Nat: I want an explicit control for "normal", because I may not want the
        UA to switch into strict/loose based on some arbitrary criteria.
   fantasai: let's say you're on desktop, but you want a newspaper-style
             presentation (multicol with narrow columns), you'll want very
             loose breaking, looser than normal content. That's why we have

   szilles: What I have trouble with is that any of the "loose"s are arbitrary.
   fantasai: They're all arbitrary.
   fantasai: We figured three was a workable number for most people.
   Nat: Ok, but we then need a way to explicitly specify some sets via an
        extension mechanism.  People that don't care will just use "auto".
   Nat: In InDesign there are four lists of rules - "can't begin", "can't end",
   szilles: For this round, we don't need the extension mechanism, we just
            need it to be possible to extend into that.
   szilles: Since we're stuck with two values (normal/strict), I just don't
            see why we need the third value (loose).
   Nat: I'm just sad about the name - "normal" basically means
        "sometimes loose".  ;_;

   fantasai: So I'm going to pull out the codepoints into an appendix and
             make it clear that non-CJK codepoints aren't affected, and will
             mark 'loose' as at-risk.

   Bert: I'd prefer not to extend this in the future.  I'd like to just
         finish it now with the features we need.
   szilles: There are people who need this now, without needing the specific
            kinsoku rules.  It would be a disservice to hold it back while
            we wait for that.

   sylvaing: I don't have exact numbers, but I know that usage of Word's
             normal/strict controls are relatively little-used.
   Nat: I think the property is fine because it matches the UI exposed by
        authoring tools.  I don't think it's as useful as those authoring
        tools, though, because it's more open-ended.
   <nmccully> About Kinsoku: We should admit that the spec as-is can only
              really give UA the ability to choose between arbitrary behaviors,
              without explicitly being able to define what those are.
   <nmccully> So, perhaps we should eliminate all language the describes
              the behaviors
   <nmccully> Just say you can pick between "normal" and "strict" and
              those behaviors are not defined currently
   <nmccully> in the future we will allow customization, which gets you
              what you want
   <nmccully> I think there is value in being able to differentiate between
              the two behaviors, so the above is preferable to me than
              dropping the feature entirely.

   ACTION fantasai: Pull out codepoint lists into an appendix and make it
                    clear that 'line-break' doesn't affect non-CJK codepoints
                    in language-generic mode
   RESOLVED: Mark 'loose' at-risk

<br type=lunch duration=1h/>

CSS3 Text: text-spacing

   fantasai: We've recast this feature multiple times.
   fantasai: One thing that happens when typesetting japanese is that when
             you have certain punc character together, their spacing is
   fantasai: another is that some people like to insert spaces between,
             frex, latin and ideographic chracters.
   florian: Why does this have to be automatic?
   fantasai: You switch scripts a lot in jp, without switching languages.
             Jp is basically made up of 4 scripts at this point.
   fantasai: trim-start/end removes spacing at first/last char on line to
             make it align closer to the line.
   fantasai: 'normal' is normal behavior.  'none' sets everything in 1em
   fantasai: And we have trim-start or space-start, which determines whether
             to do full-width or half-width on the starting edge of a line.
   fantasai: trim-end/space-end do the same for the end of a line.
   fantasai: And allow-end *allows* you to trim if the last char doens't
             fit, or make it fullwidth otherwise.
   fantasai: 'trim-adjacent/space-adjacent are similar, but within a line.
   fantasai: Then you have the values for spacing between alpha and
             ideographic characters.
   fantasai: That's almost a different feature.  You're adding space rather
             than taking away space.
   fantasai: But that depends on your mental model.
   florian: I ask if it's actually separate features because Håkon objects
            to the second feature, not the first one.
   florian: The french actually put spaces in their text when this sort
            of thing is desired.
   kojiishi: It's a stylistic variation only.

   fantasai: These used to be two features.  text-trim was the first several
             features, text-auto-space was the alpha/ideographic ones.
   Nat: I think it's okay to combine them.
   Nat: I think the property may not offer quite as much control as necessary
        to achieve pretty display, but otherwise it seems okay.
   Nat: Is there a concept of line compression?  How do you adjust the half-em
        space here?  Like if the line is too long and I need to compress the
        space, how do I do that?
   fantasai: By default, you can justify by adjusting those spaces, and we
             have an option to turn that off.
   Nat: Does that usually mean to expand the space, or can it compress the space?
   fantasai: Up to the UA.
   Nat: It seems that you're only talking about push-out style justification
        in the spec.
   kojiishi: The text-justify property allows you to do anything.

CSS3 Text: text-justify

   fantasai: [explains the text-justification property]
   Nat: If I want to, in a line of text with a japanese period, compress that
        space last, a good UA will do that by default, but a phone may not
        in a tight line.  I'd want to change that behavior.
   Nat: So it would be good to have some markup allowing me to specify whether
        that happens or not.

   florian: What are the priorities for things?
   fantasai: glyphs-shaping, for example, is listed as out-of-scope.
             UAs can do it if they want, but we don't have a control for it.
   fantasai: Frex, in Arabic you can do really beautiful justification by
             swapping out alternate forms.  But that's really sophisticated
             and font-specific, and I can't define that.
   fantasai: There are no controls or restrictions for priority within punctuation.
   kojiishi: We've brainstormed abilities for the future that would allow
             better priority-control, similar to what InDesign does now.

   fantasai: (to Nat) Are there particular controls you would find important
             to add?
   Nat: I don't think it's necssarily important to provide what InDesign has.
   Nat: But could you make it any simpler while achieving similar results?
   fantasai: What would you simplify?
   Nat: Right now what you're saying is that the line-ends are important for
        fullwidth punctuation.
   Nat: That is, lineend->punctuation is one pair, alpha->ideograph is one
        pair, etc.  Do you have ideograph->ideograph?
   fantasai: No.  That spacing can be justified, but you wouldn't do
             exceptional spacing by default.
   Nat: What about jp-en-jp in a line, and justify it?  Some justifiers
        will put all the spare space in the ideo->alpha spacing.  Others
        may space the jp and keep the alpha tight.  Others may space
   fantasai: We also have a letter-spacing and word-spacing property which
             lets you set the spacing defaults, and put limits on them.
   fantasai: So you can control that sort of thing more precisely with those
   fantasai: I think currently the spec would say that the space the cjk up
             to the limit, and then drop down to expanding the roman.
   fantasai: It sounds like you want to expand the cjk to max, and then
             expand both roman and cjk.
   Nat: Yeah, sometimes in these exceptional circumstances you just need
        to violate all the max constraints.
   fantasai: That makes sense, and I'll change the spec to say so.

   szilles: I think the spec should give these things as examples, and
            show how to use them together to get what you want.
   Content: CJK-Roman-CJK
              * expand only spaces
              * expand cjk and spaces
              * expand cjk first, then everything
   ^^^ needed examples

   Nat: Also, JIS has 18 classes of punctuation.  Here we simplify it down
        to one style of punctuation, which seems too simple.
   fantasai: In terms of punctuation, it's like glyphs substitution - it's
             out of scope for our controls, and UAs should do whatever is
   fantasai: I could *theoretically* get enough info from the japanese to
             get a spec for justification, but I couldn't get the necessary
             detail in any reasonable amount of time for any other language.
   fantasai: You could write several lifetimes of PhD theses on justification
             around the world.

   Nat: Ideally there should be a prioritization for how the existing spacing
        pairs (ideo->alpha, ideo->linestart, etc) get applied.
   Nat: In the justification table, it looks like spaces are always expanded
        first, and then everything else at the same time.
   fantasai: Normally you *do* always expand spaces as much as possible,
             and only do other justification if there's no spaces.
   Nat: God help anyone with spaces on their line.
   fantasai: And for cjk you may want to set a conservative limit on the
             space-size (with 'word-spacing'), so it'll exhaust the spacing
             expansion and switch to other things.
   Nat: So you require a cjk author to set a relatively small space max-length,
        which may justify roman text badly.
   fantasai: The default behavior for word-spacing takes "normal" for both
             min and max spacing, which can vary based on many factors including
             the language. Basically, UA-dependent.

   jdaggett: What's the column for 'auto' for text-justify?
   fantasai: It's the default, and lets the UA choose whatever is reasonable.
             What's suggested in the table is a simple universal compromise.
   [discussion about the presentation of the table for easier reading]
   fantasai: Okay, I'll change the 'auto' character to an asterisk with an
             explanation, and switch each column from 2-col to numbers.
   fantasai: And add glyph-scaling to the methods as "whenever".

   florian: Another comment from Håkon - this is meant for documents where
            authors care about pretty formatting.
   florian: But this reduces the ability of UAs to prettily justify by default.
            You can't do TeX justification.
   fantasai: No, you still can use TeX to determine the optimal compression
             and such.  This just tells you what's most important to expand,
             per the author's own preferences.
   florian: What's the best default value for English?
   fantasai: inter-word
   florian: But TeX won't expand spaces fully before switching to other spaces -
            it prefers to expand spaces, but will start expanding other things
            as well eventually, even when spaces can still be expanded.
   florian: That doesn't work here, if you have to set hard limits to make
            spaces stop expanding.
   szilles: Perhaps instead, the controls can be phrased as essentially hints,
            such that UAs *can* do more intelligent algorithms, as long as
            they take the preferences into account.
   fantasai: Yes, though the min-space is still a hard limit.

   ACTION fantasai: Make text-justify tables use numbers, footnote auto column
   ACTION fantasai: Add examples of text justify from minutes
   ACTION fantasai: Make text-justify tables use numbers/'never'
   ACTION fantasai: Make it clear that glyph substitution is neither
                    required nor forbidden
   ACTION fantasai: Fix spec so that lower priority includes earlier
   ACTION fantasai: Make punctuation justification priorities more
                    clearly out-of-scope
   ACTION fantasai: Make it clear that TeX-style cost-based distribution
                    is allowed and add an example with 'inter-word'

CSS3 Text: text-transform

   jdaggett: Now that fullwidth is in the property, what's its priority
             relative to uppercase/lowercase?
   fantasai: I think we talked about that, though I don't recall exactly.
   jdaggett: The case mapping rules here in the spec are woefully underdefined.
   fantasai: I think the bar is the full unicode casing algorithm.
   fantasai: But we want it to be able to be smarter than that.
   jdaggett: I want something testable.
   fantasai: Yeah.
   jdaggett: Also, what's the relative ordering of all of these properties?
             Some properties are based on character class, and text-transform
             is changing the character class.
   fantasai: Ok. I'll make a normative appendix specifying the order they're
   jdaggett: the order of value is fine with me:
             [ capitalize | uppercase | lowercase ] > fullwidth > fullsize-kana

   florian: Håkon wants to know what the <wide> tag is, that is mentioned
            there in the spec.
   [discussion about the <wide> reference]
   jdaggett: I want a clearer explanation of how to understand the unicode
             database file and map field X to field Y.
   dbaron: Like "the sixth field of the database (decomposition_mapping)", etc.
   <boblet> (Unicode data file using <wide> etc being referenced was
             http://unicode.org/Public/UNIDATA/UnicodeData.txt btw)

   wrt fullsize-kana
   Nat: You don't use small kana in ruby, for readability.  You always use
        large kana.
   Nat: When you author, you input large kana, not input small and then transform.
   Nat: For accessibility, I'd hope you don't look at the ruby data for
   szilles: People learn to interpret the large kana and small kana by context,
            but a screenreader needs additional info - one suggested additional
            info was to input small kana, but it's not good enough.
   kojiishi: Some ruby uses small kana for stylistic purposes.
   florian: But then they don't transform, they just scale it up to be readable.
   <dbaron> example of しゃ vs. しや
   <dbaron> (though Elika wrote them in the other order:  しや (shi ya) vs. しゃ (sha))
   fantasai: So, displaying ruby as large kana is a stylistic choice.
             You want the correct characters in the content, as the ruby
             may be displayed inline with parens, but you may want to
             transform it to large kana for readability (or scaled small
             kana) if the ruby is above/below the main text.
   murakami: And some publishers specifically want small ruby with small kana.
             Also, educational materials for proper teaching of pronunciation.
   florian: In this context, do we care about the codepoint switch, or is
            the glyph-switch sufficient?
   fantasai: I think glyph switch is sufficient.
   florian: Except for the 'fullwidth' value, because other properties change
            behavior there.
   fantasai: Well, you'd need to do a glyph switch *and* switch the behavior
             of those properties too.  But you don't strictly need to swap
            the codepoint for any value of text-transform.

   florian: There's a note that says "maybe use font-variant:ruby"
            is that something else?
   jdaggett: It's just another glyph that uses fatter strokes, specifically
             for ruby.
   jdaggett: [airs some concerns about the applicability of the fullsize-kana
             value, since it's pretty much only used for ruby]

   florian: Håkon suggested "text-transform-replace", basically identical to
            Perl's tr///
   fantasai: That would solve the case, yes, but it also adds a *lot* of
             complexity for solving this one case.
   florian: Håkon provides other use-cases for georgian, or to remove accents.
   fantasai: Removing accents is not that simple. You also need to normalize.
   fantasai: And nobody's actually asked for georgian transforms.

   szilles: What did we do for the list rule?
   fantasai: We defined a few in css2, then realized we had a *bunch* more
             that we wanted to define, so Tab made an at-rule and provided
             a UA stylesheet to provide a bunch of defaults.
   szilles: Why won't that work?
   fantasai: It would.  We could do that.  But I don't think it's worth it
             at this point.
   danield: Can we call it 'fullsize' instead of 'fullsize-kana'?
   fantasai: It *only* affects kana.  There are other types of characters
             that come in reduced and fullsize versions that we don't want
             to imply would change here.

   fantasai: It was also brought up that greek and cyrillic have fullwidth
             variants, so people sometimes use those for stylistic purposes.
             But there aren't any codepoints for those.
   fantasai: So we were wondering if it might make sense to let 'fullwidth'
             affect that.  There aren't codepoints to switch to, but it
             would affect the other behavior.
   Nat: This seems to be the sort of thing that *should* be happening in
        OpenType, properly.
   <Bert> [Discussion about "fake" fullwidth greek and cyriliic, because
           there is no actual fullwidth greek and cyrillic in Unicode.]
   Nat: That lets UAs do all this stylistic stuff without touching the
        underlying model.
   szilles: But you can't do linebreaking as an opentype feature.
   Nat: You can - you can't do linebreaking until you get glyphs.
   fantasai: How do you know whether you're linebreaking these characters
             as fullwidth or halfwidth?
   [possibly there was some confusion here, and fonts don't carry this information]
   jdaggett: I don't fully understand the problem you try to solve.
   jdaggett: I think putting behavior in text-transform that affects
             linebreaking, etc. is a really bad idea.
   jdaggett: This is supposed to be simple.
   Nat: Any of the transforms can have affects in some language and not
       in another.
   jdaggett: I understand, but from a user perspective, these subtle
             effects seem hard to understand and conceptualize.
   Nat: I think it would actually be hard for impls to do the fake
        characters without codepoints.
   jdaggett: [something about font features existing for uppercasing, etc.
              that I didn't get]

   fantasai: Why wouldn't you turn on uppercasing in the font when you
             have text-transform: uppercase?
   Nat: I think we should resolve not to do any font feature stuff in
        text-transform, and complain to Unicode that they should have
        made fullwidth variants for everything
   Bert: Wouldn't it make more sense to remove all fullwidth variants?
        It's a style issue isn't it?
   fantasai: I agree with Bert; it seems more like a style issue rather
             than something that should be separate codepoints.
   Nat: Get rid of the feature (text-transform) altogether and just use
        the font mechanism
   [ This discussion is mostly unminuted because Tab gave up and didn't say so
     and didn't get a replacement]

Scribe: dbaron

   Florian: request for tr feature for removal of accents
   fantasai: can't be done programmatically - requires a dictionary to
             do it right because there are some accents that have to
             be kept and some that don't
   (discussion about whether it's right or wrong to drop accents when
    uppercasing in French)
   Nat: sounds like the discussion about ruby
   fantasai: Whether you can do this with 'tr' depends on whether you're
             NFC or NFD.
   fantasai: Correct way to do it is probably do NFD and then remove the
   Steve: I'll observe that this is a case where you can't build in the
          transform (for the reasons fantasai cited), so having something
          like tr which doesn't work well in this case (unless you also
          have a normalize function) would allow the user to say what he
          wants for his text.
   Steve: So this is actually a case that drives the tr solution because
          it is different for possibly each document.
   Florian: Doesn't solve it universally, but tr is to solve it not universally.
   Peter: I think going down that path is out of scope for this discussion.
   Peter: Don't want to rathole into proposal for new features.

   DanielD: What about calling fullsize-kana fullsize-ruby?
   fantasai: No, it fullsizes the kana whether or not you're in ruby,
             though it is designed for ruby.

   ACTION fantasai/koji: Set minimum bar for case shifting by pointing
                         more directly to specific Unicode algorithm
   ACTION fantasai/koji: Add normative appendix for order of text operations
   ACTION fantasai/koji: Define fields used in fullwidth transformation
   ACTION fantasai/koji: Make small kana mapping table (reuse for line-break)
   ACTION fantasai/koji: Remove note about font-variant-ruby (goes in ruby spec)
   ACTION fantasai/koji: Add note about @text-transform possibility


   Sylvain: Some feedback from a colleague:  why are a bunch of the properties
            optional?  that's tricky from an interop standpoint
   Sylvain: "These controls are optional because for a low-end implementation
             of hyphenation, they are not critical enough; and for a high-end
             implementation of paragraph breaking (such as in Teχ) they are
             not considered especially useful. "
   Sylvain: Require them?  Not require them?
   dbaron: removing them?
   fantasai: Håkon wanted me to make things optional if they weren't
             required for all scripts.
   ACTION fantasai: Switch optional properties to at-risk

   Sylvain: What is the use case for hyphens: all other than debugging?
   Sylvain: I'd like to remove it.
   fantasai: Anybody object?
   Steve: The UA writer could have settings for that if desired.
   Sylvain: Yep, doesn't need to go in style sheet.
   Bert: I use show-hyphens in TeX a lot.
   John: Do we implement all?
   dbaron: No, just none manual auto.
   RESOLVED: Drop 'hyphens: all'

   Sylvain: word-wrap: hyphenate?  Interact with hyphens:none?  How does
            that work?
   fantasai: Only kicks in if there's no other break point on the line
   fantasai: Alan suggested dropping that and using hyphenate-zone:100%
   fantasai: word-wrap:hyphenate beats the hyphenation controls (hyphens:none)
   Peter: ... but only to prevent overflow
   Sylvain: What kind of hyphenation happens?
   Steve: It's forcing a line break, not really hyphenation
   fantasai: It's a forced line break at an appropriate hyphenation point
   Alex: ... choice of break anywhere or refer to dictionary ...
   (description of what's in the spec)
   Steve: It's not just if it's turned off... there are other things that
          inhibit hyphenation.
   ACTION: fantasai "even if hyphenation is turned off or otherwise restricted"
   <trackbot> Created ACTION-323
   Steve: If you say word-break, and hyphenation is on, are you allowed
          to hyphenate?
   (discussion of what characters to use for "TeX")


   Bert: Why is word-wrap not called emergency?
   fantasai: widely implemented unprefixed
   Everyone implements word-wrap: normal | break-word
   Peter: Bert has a point; you could add the standard name and keep
          implementing the nonstandard one
   Sylvain: There's content depending on it.
   Bert: Forget about the other one; it's not ours and we don't have to
         document it.
   Bert: It's confusing to have word-wrap and text-wrap etc. and they
         don't do the same thing.
   Alex: One point of standards is interop; if multiple vendors have
         agreed to do something they can get together and agree on what
         it is, regardless of the reasons.
   Alex: With a different name, we'll still have to define what the ugly
         old thing does just as we define how to parse invalid html.
   Florian: If your goal is interop, we do need to define how the thing
            everybody supports is actually supposed to work.
   Steve: Also defining things that can get through CR in a reasonable
          amount of time.
   Alex: We can say something is deprecated and define what it does.

   Peter: I think there's a valid request to rename the property; do we
          want to do that?
   Sylvain: The property or the value?
   Peter: the property
   fantasai: options are 'emergency-wrap' and 'word-wrap'
   fantasai: word-wrap is implemented by 4 browsers
   Steve: word-wrap seems fine
   Bert: It's only a second level option
   Peter: More of an overflow management property
   Steve: 'overflow-wrap'
   John: I don't like "emergency" at all.
   Florian: If we're going to rename it, word overflow should be in there.
   fantasai: Options: (1) keep as word-wrap (2) rename to overflow-wrap
             and document word-wrap as a deprecated alias

   dbaron: Need to define what alias means.
   dbaron: We have an aliasing mechanism for prefixed properties
   dbaron: but it's a parse-time thing
   dbaron: If we define an alias, we should make it clear that it's a
           parse-time thing
   Alex: In object model there will be word-wrap and overflow-wrap?
   dbaron: For us, word-wrap would not be exposed in the OM.
[Nat and Taro leave]
   dbaron: It would break scripts
   dbaron: I'm ok with that if it's not a long-term thing
   dbaron: and we don't have situation where things only break in Gecko
   Florian: Seems like switching names might be more trouble than it's worth
   Bert: more trouble for implementers, but we're thinking about authors
   dbaron: Actually, it does work for getPropertyValue() in Gecko, and we
           could make it work for CSS2Properties
   Peter: For people who don't understand English, using more consistent
          terms is probably a good thing.
   Peter: Are we ok with option (2)?
   Sylvain: Where do we define what alias means?
   Sylvain: Difference between saying there's a deprecated property there
            saying that if you support that deprecated property it must be
            an alias.
   Alex: [something about searching for things in Google and trying to find
          documentation, which currently is written for word-wrap]
   Bert: I'm more concerned about people seeing the property name and
         finding that it doesn't do what they expect.
   Peter: I've run into that.
   Alex: overflow-hyphenate or hyphenate-overflow?
   Florian: Put a note saying we're thinking about it?  I'm not sure without
            talking to Opera implementors.
   fantasai: I think we need feedback from WebKit and Opera implementors.

   ACTION fantasai: Mark 'word-wrap' -> 'overflow-wrap' as an issue

   Peter: break until 4pm

CSS3 Text: Other Features


   Florian: Håkon was wondering if we can move 11.2 (emphasis marks) to
            the same spec as ruby
   Florian: same interaction with line spacing
   (time limit on text discussion set to 4:30pm)
   fantasai: They are similar in terms of implementation effects but very
             different in terms of what they're used for; for authors
             they're an alternative to underlining.
   Florian: The way it interacts with ruby needs to be described
   Steve: Would Håkon like it better if we moved ruby to the text spec?
   fantasai: Two problems:  From an authoring perspective it's much more
             closely related to underlining, and the ruby spec needs a
             *lot* of work.
   fantasai: Ruby is missing the box model for ruby; the only thing that
             needs to be defined for text-emphasis is the interaction with
             line spacing; no need to worry about anonymous boxes, etc.,
             which ruby is missing.
   fantasai: Six months for the ruby spec would be optimistic; not many
             issues with text-emphasis.
   fantasai: Only concern is line spacing.
   Steve: i.e., the decision we made yesterday that it doesn't affect
          line spacing
   fantasai: I think it should stay in the spec.
   Florian: I think it was just a suggestion, not a strong request; I'm
            ok with that answer.

   Florian: Håkon suggests dropping text-outline; text-shadow is rich enough
   dbaron: Doesn't the addition of spread to text-shadow provide the same?
   fantasai: you can get the same effect
   Tab: What is done by text-outline that's not done by spread text-shadow?
   fantasai: nothing I know of; we didn't have spread when text-outline
             was added
   RESOLVED: drop text-outline

   Florian: Either Håkon or I is confused about the hanging punctuation...
   Florian: Håkon interpreted is a per-block.
   fantasai: It's each edge of each line
   fantasai: force-end doesn't actually stretch the content.  It doesn't
             force the content; it's just that if you justify the line
             you don't measure it.
   Florian: Can we clarify the wording?
   Florian: Was the image example of force-end added?
   Florian: only if there is justification... or does it force justification?
   fantasai reads from spec
   Florian: Can we add the piece of CSS that caused the example to look the
            way it is... so the CSS has the justification
   ACTION fantasai: Add CSS to the example
   <trackbot> Created ACTION-324

   Florian: Håkon: Instead of text-align-last I propose p::last-line
   fantasai: Doesn't work, since ::last-line applies only to last line
             of block, but text-align-last needs to apply for anonymous
             blocks, forced breaks, and other lines that can't be
             justified for other reasons

   Florian: Håkon proposes 'balance' as a new value for 'text-wrap' to
            prevent the last line from being too short.
   fantasai: I think it's a good idea; somebody previously suggested
             'last-line-length: <percent> | <length>', which I think
             is a better way of handling that because it gives more flexibility.
   Florian: This somewhat mirrors column-fill: balance
   fantasai: But I want to push that to the next level of text.
   Steve: I'd have interpreted balance (if comparable to columns) as
          something that makes all lines equal.
   Florian: Håkon was thinking all or the last few
   Steve: All is an expensive operation.
   fantasai: I think we could consider if we have willing implementors
   Steve: could list an issue that 'balance' has been proposed
   fantasai: Not sure I'd stick it in 'text-wrap'.
   Steve: Probably in justify
   Steve: Really applying to the paragraph as a whole.
   fantasai: You can have a centered paragraph with balanced lines.
   Bert: I think implementations should do this automatically -
         try not to make the last line too short or to long.
   fantasai: You usually don't want the whole paragraph to have equal lines
   Bert: You don't want the last line too short *or* too long
   Peter: Lots of other factors
   fantasai: We can put this in the wiki for things for future levels.
   Steve: There's a min length on last line proposal?

   Florian: Håkon proposes text-ident: each-line
   fantasai: That's in the spec already.
   Florian: How about renaming it to after-break
   fantasai: it's not just after-break; it's also at the start of the paragraph
   fantasai: It's intended, e.g., for source code or poetry.

   Florian: Håkon - I'm unsure if 'hanging' is needed given that negative values
   fantasai: negative values put you in the padding; shouldn't have to
             match the padding to text indent

   Florian: Last item from Håkon on 5.2 (word-break): this section
            should benefit from examples.  (quoting)
   fantasai: Agreed

   Florian: ... suggest defining shaping scripts in Appendix E. ... (reading)
   fantasai: Those things should be handled by the hyphenation engine,
             which should make appropriate spelling changes
   fantasai: That note is saying that, after the hyphenation engine,
             that Arabic is still *shaped* as though word was not broken.
   Steve: Should probably say explicitly that you use initial/medial rather
          than standalone/final before a break, and medial/final rather
          than standalone/initial after a break.
   fantasai: Actually, I think we shouldn't specify the rule because it'll
             be wrong; better to give example.
   Florian: That's the end of Håkon's issues.

   fantasai: I propose dropping hyphenate-resource
   Steve: Not now
   fantasai: I'll do it when we request last call.

Scribe: fantasai
Discussion of what to discuss


   <jdaggett> who needs a charter...?
   <Bert> -> http://www.w3.org/2010/09/CSSWG/charter.html draft charter

   Bert: 3 questions
   Bert: W3C Team looked at charter, esp list of modules
   Bert: Maybe Chris forgot to fix things,
   Bert: But wondering why Ruby Annotation REC is in the charter
   Everybody agrees that should be removed.

   Bert: Thinking to move JLREQ to Joint Work

   Bert: It says CSS1 in Maintenance, but not CSS2.
   Bert: CSS2 is not deprecated yet
   fantasai: So let's deprecate it
   <jdaggett> yes please
   Bert: But is everything there in a CSS3 spec?
   fantasai: well, the features there not in 2.1 are all in WDs
   fantasai: @font-face in the fonts spec, text-shadow in the CSS3 Text
             spec, list-styles in css3-lists
   fantasai: And some things we're not interested pursuing, like
             display: compact
   fantasai: display run-in needs to be put in css3-box spec...

   dbaron: fullscreen is styling things that are in fullscreen presentation
           and some associated DOM APIs
   dbaron: It says CSS UI is new when in fact it's in CR
   Tab: we have UI3 and UI4
   dbaron: oh, ok
   RESOLUTION: List CSS 2.0 as maintenance, asterisk saying to be obsoleted asap

   jdaggett: are we leaving priorites as is?
   dbaron: I'm a little worried about things being on the discontinued list
   dbaron: I'm working on a draft that's an extension of syntax
   dbaron: I'm not sure what to call this draft, right now calling it
           Conditional Group Rules
   dbaron: I pulled @media into it since it seemed to fit, and 2.1 only
           describes it in 2 lines
   dbaron: Also includes @supports and @document
   dbaron: It changes syntax by allowing @rules inside @media
   dbaron: I think it's worth keeping Syntax and Cascading within scope,
           even if we aren't committing to anything specific, so that
           we can pull out and progress pieces of them

   plinss: Need an item about regular snapshots, not just 2010
   plinss: I also want paged media to move from low priority to medium
   jdaggett: line layout should be medium, not low
   Alex: I want CSS3 Floats
   Alex: Floats and Exclusions
   discussion of some positioning modules
   no objection to line layout at medium
   <jdaggett> yay
   fantasai: maybe we should move Positioned Layout to low, since I'm not
             sure we'll get to LC in 2 years
   Tab: fine with that

   Alex: Can we work on things in 2.1?
   Bert: Charter allows us to work on anything as long as within scope for CSS

   <Bert> -> http://www.w3.org/Graphics/SVG/WG/charter/2010/Overview.html
             SVG draft charter
   Bert: SVG draft charter has some overlap with us via the task force
   Bert: We should make sure their high priority items match our high-priority
   Bert: SVG charter notes things that are supposed to be joint work
   Bert: Do we agree with all of those?
   Vincent: There is CSS animations and Web animations, some consideration
            of making them consistent
   Vincent: Does that need to be a work item?
   Vincent: Related to transforms, there are 3 specs for that
   Vincent: I think the goal for everybody is to work on FX taskforce spec
   Vincent: focus on convergence part
   Bert: Our charter mentions SVG in two places, joint work for filters
         and masking
   Bert: Then the dependencies section, which mentions ....
   Vincent makes a suggestion about a table or something
   Vincent: Cameron was listing filters, compositing as something to
            work with CSSWG
   Vincent: Makes sense to coordinate
   Vincent: Others were gradients, 2D, 3D transofrms, and web animations
   Vincent: I think all topics are touched on in charters except compositing
   Vincent: And from my end, only question is that we're clear on which
            spec we're working on
   Vincent: In some cases there's CSS spec, SVG spec, joint spec. Clear
            which one we're focused on

   fantasai: Who's editing the charter?
   Bert: Chris? Not sure if he can
   ACTION: Bert edit charter per notes above
   <trackbot> Created ACTION-325
   plinss: Anything else on Charter?

Regions Publication

   Vincent: So on the regions status, we have 2 documents css regions
            and css exclusions
   Vincent: For regions last we had a resolution during the concall
            to publish a WD when the updated eidtor's draft would be
            updated with comments incorporated.
   Vincent: I sent that earlier this week
   Vincent: Includes comments
   Vincent: Everything that happend until the WG resolution to publish
            is in the draft
   Vincent: Next step is to publish the WD
   Vincent: And discuss issues and resolve and prepare next WD
   Vincent: Think that's pretty much what we need to do

Exclusions and Floats

   Vincent: For Exclusions we went from original spec and split
            regions from exclusions
   Vincent: MS has alternate proposal called CSS3 Floats.
   Vincent: Plan is to merge spec
   Vincent: I'm happy to work with whoever wants to work on it
   Vincent: Scope right now for exclusions, there's issue of laying out
            content into arbitrary shape
   Vincent: Second issue is wrap around an arbitrary shape
   Vincent: THen there's extension to float model and positioning scheme
   Vincent: positioning floats with more flexibility
   Vincent: Make float have arbitrary shape
   Vincent: That's scope for current proposal
   Vincent: Some of those issues are orthogonal to each other
   Vincent: My proposal would be to do a new draft that covers all those
            topics, and next time have a review of that document and decide
            if some parts should be split into a different spec

   Florian: howcome says we're happy that we're working on this and working
            on it here, but it's too early to stop any spec
   Florian: or override others
   Alex: Neither we nor Adobe is planning to deprecate GCPM floats, unless
         other floats do everything in GCPM floats
   Alex: I think should be a single CSS3 Floats spec going forward not to
         override GCOMP floats, but to make sure we have compatible models
   Alex: We have new language for exclusions, e.g., we'll have difficult
         time merging together
   Alex: Better to put them together now
   fantasai: And merge with CSS2.1 floats and clearance

   Alex: In our draft we said, we had extension to CSS positioning
   Alex: There are number of pages, but one value that we wnat to add which
         is position: page, position thing relative to apge
   Alex: Not sure it's worth creating a spec for just that value, but it
         should go somewhere
   Alex: One approach could be to create a CSS3 Positioning spec, that
         includes abspos and all kinds of positioning from 2.1
   Alex: Have an effort to make CSS2 positioning better defined
   Alex: Arron is interested in that
   <dbaron> (e.g., top/left/right/bottom: auto)
   Alex: Not going to volunteer Arron to edit spec, but he was interested
         in that activity
   Alex: And having that spec
   Tab: I'd be happy to take Arron on as co-editor, that'd be fun
   Vincent: Should we have a resolution to move forward with new draft
            that includes all current proposals and has scope that we
     * content arbitrary shapes
     * exclusions arbitrary shapes
     * expanded float model
     * expanded float positioning model
   fantasai: Not sure about what you have on the slide, but what you
             said earlier sounds good to me
   RESOLVED: Make this spec as css3-floats

   Vincent asks about publishing css3-regions
   ACTION: Bert publish css3-regions as FPWD
   <trackbot> Created ACTION-326

   <alexmog> http://www.interoperabilitybridges.com/css3-floats/
   dbaron: This stuff seems scary. Scarier than GCPM stuff.
   dbaron: Just the notion of what flows around what, and not knowing
           what floats you're going to have to flow around...
   Alex: Yes, it is scary.
   Steve: That's what I think is the hardest part. Kindof like compositing.
          Have to define what makes up an entity
   Steve: When we were discussing this in February, there was ...
          interactions of floats from Apple
   Vincent: Right now just asking to merge into new proposal. Not even
            asking to move to WD.
   Murakami-san: I have one quesiton about CSS3 Floats
   Murakami-san: CSS3 Floats contains multicol floats, that spans multiple
   Murakami-san: That's now in GCPM
   fantasai: We might consider splitting these into CSS3 and CSS4 later,
             once they're merged and made consistent

   dbaron: I'm concerned that we're working on too many big layout systems
           all at once
   dbaron: I'd rather get flexbox and grid and vertical text done first
   Steve: I think the reason to do them simultaneously is to make sure we
          understand the interactions
   dbaron: exclusions I'm ok with, it's the positioned floats I'm concerned
   Steve: exclusions are just positioned float
   dbaron: It feels like a pretty big difference to me. Maybe I just don't
   Alex: Maybe you didn't read exclusions carefully enough
   dbaron: Exclusions seems clear about what you're applying the exclusions
           to and where it's coming from
   Vincent: My suggestion would be to put the new draft together..
   Vincent: I think you're right, some of these problems are fairly orthogonal.
            We could adopt current float model and see how to adapt exclusions
            to it
   Vincent: Another feature is positioned floats, which you're concerned about
   Vincent: I think there are various issues and they're not all as
   dbaron: I can see some ways to define positioned floats that aren't so
   Steve: My understanding of Alex's use of float is an object that intrudes
          on other object

   dbaron: What bugs me about positioned floats is that the existing float
           model has notions of document order, so wwith a float stuff
           after it floas around it and stuf before it does not
   dbaron: It also means that floats obey invariants wrt document order
           wrt other floats
   dbaron: This makes it relatively easy. And by relatively easy, I mean
           one of the most complicated pieces of code in a layout engine.
   dbaron: ... dynamically ..
   dbaron: But maintaining positioned floats at arbitrary positioning,
           where you have to track where it is in document order, and
           which text comes after it and which text wraps around it and
           which doesn't
   dbaron: or you have floats affecting stuff before it
   Alex: Can affect things before in document order, regarding what exactly
         the dfinition is, that's going to happen
   Alex: Challenge for us here is to come up with clear definition of what
         it means and something implementable and something that can be
         done without horrible perf penalty
   Alex: But since it still does that, it's either GCPM floats that goes
         to top right of page, or exclusions, or
   Alex: The dependency backwards is going to exist.
   dbaron: Part if it is that I really really don't like the absolute
           positioning model for layout.
   dbaron: I prefer Grid Layout

   <dbaron> http://dev.w3.org/csswg/css3-exclusions/
   <dbaron> http://www.interoperabilitybridges.com/css3-floats/

CSS Regions

   Vincent: Are there topics for regions and exclusions..
   Vincent: Here are the issues I have on the table
     - intrinsic sizing: height: 0 as well as width:0
     - auto-sizing and containing blocks
     - breaking rules and alignment with paged media and multicol
     - integration with css grid layout and multicol
     -regions styling
   Vincent: ? had some use cases for [something]

   Vincent: A lot of issues raised in CSS Regions exist already in paged
            media and sometimes in multicol
   Vincent: Something I'd like to talk about during this meeting
   Vincent: Another thing Steve mentioned is interdependencies with other
            specs, namely grid layout and multicol
   Vincent: Would be nice to make this work with grid layout and multicol
   Vincent: Some small things to do, integration
   Vincent: E.g. addressing grid cell and display values

   Vincent: Multicol doesn't have a way to address a column box, will be
            needed to make it a region
   Vincent: Have a demo of an implementation, one in Webkit and one
            scripted impl of that
   Vincent: Still a lot of concerns about it
   Bert: By regions styling, you mean not just background, but also the
         content of it?
   fantasai: If you're going to do that, please also write the spec for
   Vincent shows an example
   Vincent: So those are the larger issues.

   Vincent: Smaller issues
   Vincent: If you look at printed content, you get different widths
   Vincent: We actually break down that content, and split boxes, and
            they find themselves in varying size container boxes
   Vincent: Regions make that very obvious, you really ned to work that out
   Vincent: Issue of writing content from page to page is the same
   vincent: also projection in the specs, at least in all I've ben able
            to find, it refers to pages
   Vincent: But the thing that's unique about it is on the computer the
            browser has an infinite canvas, but projection is like printing,
            and what it let's you do is having pages that you flip and
            that's how you navigate your content
   Vincent: conceptually some implementers do it this way, those are kindof
            regions and you lay out content between regions that way
   Vincent: multicol is another example of the same issue, you break down
            content into set of containers. Regions is a variation on that
   Vincent: It's still the same concept of having on one hand content that
            needs to flow and of having different regions in the chain of
            regions to flow content into
   Vincent: And then the difference...
   Steve: Point being that there are a chained set of areas into which a
          continuous chunk of content is distributed in all of the regions

   plinss: The issue with all this is that we've punted on different-width
           containers, and we can't do that anymore
   Vincent: Shared issues with all these models are the natural breaking
            rules, this is common between columns and pages and regions
   Bert: There are some differences where breaks between columns can be
         less bad than between pages
   plinss: Interesitng thing with region is wide region, then other region,
           looks like columns
   plinss: might want different breaking depending on what type of regions
           you're breaking between
   Vincent: Issue of forced breaks, that we should treat as overall in
            general how does that work, for pages columns etc.
   Vincent: talked about varying widht container boxes for pages and regions
   Vincent: Region-based styling, should address it also for multicol etc.
            if we address it

   fantasai is deeply concerned about the number of tests that this will
            all require
   Vincent: Alan Stearns is working on that
   plinss: Breaking text flow is easy, floats and tables are hard
   dbaron: In theory you have that problem for multiple page sizes as well
   plinss: goes back to my point
   dbaron: You have two floats that fit side-by-side, and then flow them
           on the second page they don't fit side-by-side, what do you do?
   Alex: no good answer to that.
   Alex: In every layout engine at MS, we had an approach that we do layout
         on the first page we see these elements, and then continue that
         layout onto the next pages
   Alex: So that the table remains the same width on all pages
   Alex: We never had a user-facing product that would actually expose
         that functionality, so we don't have poof that that's the best
          approach to the problem
   Alex: So we need to experiment

   Steve: XSL has this property for a long time, do you implement it
   Murakami-san: Yes, we implemented XSL:FO
   Murakami-san: With multiple regions with multiple, the region width is
                 changed when the page is changed. That requires
                 reformatting process.
   Murakami-san: It's not very important for our product, but I think
                 it's hard to browsers that requires processing speed.
   Steve: To summarize, it's doable but expensive
   Murakami-san: We do expensive formatting.
   Alex: I'm not convinced it's doable.
   Alex: I'm convinced there is no optimal solution that will work, we'll
         have to come up with some kind of compromise

   Vincent: One thing that would be useful for moving along
   Vincent: you were mentioning multicol
   Vincent: On the float-breaking rules section..
   Vincent: I took the CSS2.1 precedent and modified wording to accomodate
   Vincent: I know we need to make all these things work together
   Vincent: One was the breaking rules. Tlaks about breaking properties
   Vincent: Orphans and widows etc.
   VIncent: fallback. I tihnk this needs to be reconciled and put in that
            spec or somewhere else
   Vincent: Talk about all cases where we have that issue
   Vincent: 2 sections that are important here are the breaking rules and
            the breaking properties
   Steve: By breaking properties do you include widows and rophans?
   Vincent: yes
   Alex: decision to be made here, does this belong in regions spec, or
         should it be a separate spec?
   fantasai: separate spec
   fantasai: affets columns pages equally
   dbaron: I think the worst cases for breaking are actually abspos
   Steve: Something has to be decided what they mean
   dbaron: the others I can come up with something reasonable, but abpos
           I have no idea what they should do
   Alex: Maybe resolve right now that we come up with a name for breaks
         or breaking spec?
   discussion of specs
   Steve: How about we stick it in Regions until we have a place to split
          it out into
   fantasai: make a separate section, note it will be split out later

   Alex: What's a page?
   (discussiong page break values)
   Alex: With regions there's no way to tell which of the hierarchy of
         regions is the page
   Alex: Can have regions within pages, regions that span pages
   Alex: region needs to understand that this region is on one page,
         that region is on another page
   Alex: Need to come up with a way of communicate that information to layout
   Alex: region on one page, next region on another page
   Alex: we have scenario where column break vs page break makes sense
         from design point of view
   Alex: I'm not sure I can come up with a compelling scenario where a
         region break vs page break is important to have
   Alex: Vincent has scenario where we create columns by creating regions,
         in which case a region break is a column break but then
   Alex: a page break is a higher-level break
   Steve: Example Vincent shows, when he reduced point size of styled
          regions, the heading at the top of the previous column
   Steve: And that's where you'd want a region break

   Alex: You can have regions within columns.  is the column break smaller
          or larger than the region?
   fantasai: could be either
   fantasai gives pathological example: regions 1 and 2 on page 2, with region
     2 continuing onto page 3, region 3 on page 1, region 4 on pages 3 and 4
   Vincent: There's clearly issues with breaks
   Vincent: I think there's odd cases we should clarify what happens
   alex: Nothing to guarantee that the sequence of regions and sequence of
         pages are going in the same directions.
   Alex: Could have region 1 on page 2, region 2 on page 1, and region 3 on
         page 3
   Steve: Question of how you would do that.
   Steve: Pagination, you don't know how many pages you need, need a way
          to add more pages when you find you haven't run out of content.
   Steve: That's why page templates were separate from content, and rules
          for how to choose a new page template as you walk down the content.
   Steve: Basically you can't use named regions b/c you don't know the names
          of the generated regions are (?)
   Steve: You need to be able to refer to the next instance in this whole thing.
   Alex: this is more complicated than I thought :)
   Vincent: There is a concept of a set of regions in which you're going
            to flow content, and that's nested
   Vincent: The variations as we said before is, sometimes you will actually
            generate regions as you go due to a template
   Vincent: You have that as an option
   (fantasai explained how to do a page break in alex's pathological case)
   Steve explains fantasai's example
   ACTION: fantasai define pagination behavior across different-sized pages
   <trackbot> Created ACTION-327
   <dbaron> (how to handle pagination of abs-pos with left:auto is fun)

   Steve: To summarize,
   Steve: There needs to be a mechanism for indicating intended containment
          structure if you're going to define interaction between breaks
          in container levels
   Steve: Pages and columns, we know that columns have to be within pages.
          But with regions we don't know that.
   fantasai is not so sure that this is needed
   Alex proposes something about using the CSSOM
   Alex: How do you define a next page? Where do these pages come from?
   Alex: We don't have a generic templating mechanism. don't know how soon
         or if ever we'll define that in CSS
   Alex: Ppl are going to be really creative in what they're going to use
   Alex: Best we can do is give them CSSOM to let them figure out what the
         content wanted there.
   Alex: Where is that page template coming from?
   Alex: If we add that object model to regions.. add .. to regions
   Alex: There was a request for page size, page name
   Alex: That will be way for somebody to write code that kind of thing.
   Steve: That's one way of capturing intended
   Alex: region break separate from page break
   Vincent: Containment model, I could take that action item

   fantasai: with multicol, you can reasonably assume that a col break wants
             to break the innermost column box
   fantasai: not so with regions
   Vincent explains example of multicol with headers that break across pages
   Vincent: Maybe tomorrow we could take smaller ones? Probably can be
            sorted pretty quickly

Meeting closed.
Received on Friday, 10 June 2011 16:06:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:46 UTC