/irc-logs / w3c / #css / 2011-06-03 / end

Options:

# Session Start: Fri Jun 03 00:00:00 2011
# Session Ident: #css
# [00:11] * Joins: szilles (chatzilla@219.127.245.113)
# [00:17] * Joins: myakura (myakura@118.111.219.27)
# [00:19] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [00:33] * Quits: sylvaing (sylvaing@219.127.109.10) (Ping timeout)
# [00:33] * Joins: boblet (Adium@122.27.197.150)
# [00:38] * Joins: sylvaing (sylvaing@219.127.109.10)
# [00:41] * Quits: sylvaing (sylvaing@219.127.109.10) (Ping timeout)
# [00:41] * Quits: Sidnicious (sidney@184.75.21.194) (Quit: Sidnicious)
# [00:41] * Quits: boblet (Adium@122.27.197.150) (Ping timeout)
# [00:46] * Joins: dbaron (dbaron@222.151.136.131)
# [00:47] * Quits: plinss (plinss@61.214.117.102) (Ping timeout)
# [00:56] * Joins: homata (homata@58.158.182.50)
# [01:04] * Quits: dbaron (dbaron@222.151.136.131) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [01:06] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [01:14] * Joins: arno (arno@192.150.10.201)
# [01:25] * Joins: szilles (chatzilla@219.127.245.113)
# [01:32] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [01:40] * Quits: myakura (myakura@118.111.219.27) (Client exited)
# [01:57] * Joins: TabAtkins (tabatkins@125.207.177.35)
# [02:01] * Joins: dbaron (dbaron@125.207.177.35)
# [02:02] * Joins: sylvaing (sylvaing@125.207.177.35)
# [02:03] * Joins: sgalineau (sylvaing@125.207.177.35)
# [02:03] * Joins: szilles (chatzilla@125.207.177.35)
# [02:03] * Quits: sgalineau (sylvaing@125.207.177.35) (Quit: sgalineau)
# [02:04] * Joins: plinss (plinss@125.207.177.35)
# [02:05] * Joins: florian (florianr@58.1.224.28)
# [02:06] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [02:07] * Joins: hober (ted@125.207.177.35)
# [02:07] * Joins: danield (danield@125.207.177.35)
# [02:08] * Joins: macpherson (qw3birc@128.30.52.28)
# [02:08] * Joins: shans (qw3birc@128.30.52.28)
# [02:08] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [02:08] * Joins: alexmog (qw3birc@128.30.52.28)
# [02:09] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [02:09] * Joins: kojiishi (kojiishi@125.207.177.35)
# [02:10] * Joins: jdaggett (jdaggett@125.207.177.35)
# [02:10] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [02:10] * Joins: vhardy (vhardy@125.207.177.35)
# [02:10] <jdaggett> ScribeNick: jdaggett
# [02:10] <jdaggett> topic: Transitions and Animations
# [02:11] * Joins: myakura (d2e8220d@78.129.202.38)
# [02:11] * arronei morning all
# [02:11] <alexmog> hi Arron
# [02:12] * Joins: konaya (konaya@83.251.16.72)
# [02:13] <arronei> I'll be here most of the day.
# [02:13] <jdaggett> TabAtkins: talking about new directions for anim and transitions
# [02:13] * dbaron generally wants them to move to the left
# [02:13] <jdaggett> TabAtkins: current spec has limitations
# [02:14] <jdaggett> TabAtkins: transitions are only state-to-state
# [02:14] * Joins: smfr (smfr@17.203.14.12)
# [02:14] * arronei wonders if Tab ever thinks a spec doesn't have limitations. :)
# [02:14] <jdaggett> TabAtkins: that's different from the animations spec
# [02:14] * jdaggett heh
# [02:15] <jdaggett> shans: i've been messing around with ideas in js
# [02:15] * Joins: murakami (murakami@118.154.209.3)
# [02:15] <jdaggett> shans: shows demo
# [02:16] <jdaggett> TabAtkins: note the weird interactions when hovering
# [02:16] <jdaggett> TabAtkins: want animations of all properties
# [02:17] <jdaggett> TabAtkins: make @transition rule
# [02:17] <jdaggett> TabAtkins: with over, from, to, and animation
# [02:17] * sylvaing I think Tab wants to animate the current CSS level to follow the Chrome version number.
# [02:18] <jdaggett> TabAtkins: syntax is at-rule with selector to identify the elements that the animation applies to
# [02:19] <jdaggett> alexmog: shouldn't that be the other way around
# [02:19] <jdaggett> ?
# [02:19] <jdaggett> TabAtkins: current property is just simple syntax
# [02:19] <jdaggett> TabAtkins: this is the advanced version
# [02:20] * Joins: nmccully (nmccully@202.32.93.230)
# [02:20] <jdaggett> TabAtkins: we have some issues
# [02:20] <smfr> is there a url for what's being discussed?
# [02:20] <jdaggett> TabAtkins: with complex animations, multiple states
# [02:21] <jdaggett> <discussion of where to stick the files so smfr can see it>
# [02:21] * Parts: florian (florianr@58.1.224.28)
# [02:21] * Joins: florian (florianr@58.1.224.28)
# [02:22] <jdaggett> jammering about www.archive
# [02:22] * jdaggett wow, tab has the world's ugliest gmail customization
# [02:22] <smfr> green on black?
# [02:23] <jdaggett> comic book ninjas
# [02:23] * jdaggett sorry that comment applied to shans
# [02:23] <jdaggett> more mumbling
# [02:23] <jdaggett> these folks need more coffee, much too slow
# [02:24] * Joins: arno (arno@192.150.10.201)
# [02:24] <jdaggett> cmon, going at web speed, blah, blah, blah...
# [02:25] <jdaggett> danield: there are just four states?
# [02:25] <jdaggett> TabAtkins: ... talking about various states...
# [02:26] <jdaggett> aw that's cute, screen sharing by pushing two pc's together
# [02:26] * jdaggett sylvaing from ms taking picture with ipad
# [02:26] <jdaggett> TabAtkins: talking about states
# [02:27] <jdaggett> TabAtkins: back to the button example
# [02:27] <jdaggett> TabAtkins: number of states you go through
# [02:28] <jdaggett> TabAtkins: going through a to c you can still go through b
# [02:29] <jdaggett> florian: will non-defined paths be synthesized?
# [02:29] <jdaggett> TabAtkins: normal transition is just a jump
# [02:29] <jdaggett> TabAtkins: should be able to synthesize
# [02:29] <dbaron> TabAtkins: it runs a shortest path algorithm on the graph
# [02:30] <jdaggett> TabAtkins: discussing missing legs
# [02:31] <jdaggett> TabAtkins: describes how the path graph is defined
# [02:32] <jdaggett> TabAtkins: wanted something that tells you what to do going between two states
# [02:32] <jdaggett> TabAtkins: similar to the data attributes in html
# [02:32] <jdaggett> TabAtkins: we can define a state family
# [02:33] * Joins: szilles (chatzilla@125.207.177.35)
# [02:33] <jdaggett> TabAtkins: should be able to define keyframe animations over transitions
# [02:34] <jdaggett> TabAtkins: everybody wanted something less weird but doesn't work
# [02:34] <jdaggett> TabAtkins: showing same example with condensed syntax
# [02:34] <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; } }
# [02:35] <jdaggett> sylvaing: hmmm, complicated...
# [02:36] <jdaggett> vhardy: why "state path" and not the property
# [02:36] <jdaggett> ?
# [02:36] <jdaggett> TabAtkins: doesn't work well when defining multiple animations
# [02:37] <sylvaing> wondering about the wisdom of overloading attribute selectors
# [02:37] <jdaggett> TabAtkins: problem of additive properties
# [02:37] <jdaggett> dbaron: need to adjust the way the cascade to fix
# [02:37] <jdaggett> dbaron: why should these be properties at all
# [02:37] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# [02:37] * Quits: nmccully (nmccully@202.32.93.230) (Connection reset by peer)
# [02:37] <jdaggett> dbaron: rather than something that you match with selectors
# [02:38] <jdaggett> TabAtkins: working with selectors is hard to define
# [02:38] * Joins: nmccully (nmccully@202.32.93.230)
# [02:38] <jdaggett> dbaron: work selectors and declarations within the at-rule
# [02:39] <jdaggett> dbaron: put the selectors into the @transition-graph rule
# [02:39] <jdaggett> dbaron: then the cascade just works things out
# [02:39] * smfr suggests some examples on the wiki perhaps
# [02:40] <jdaggett> dbaron and TabAtkins discussing alternate syntax
# [02:40] <jdaggett> vhardy: seems to me you're defining a graph
# [02:40] <jdaggett> vhardy: the edges seem to be between paths which feels weird
# [02:41] <jdaggett> TabAtkins: we have a state called path
# [02:41] <jdaggett> chrome guys confess to abusing the use of 'path'
# [02:41] * sylvaing smfr, +1
# [02:42] <jdaggett> TabAtkins: showing an even more complex example because complexity is my middle name
# [02:43] <jdaggett> TabAtkins: showing click-animate-click-animate-click-animate
# [02:44] * Joins: shans (qw3birc@128.30.52.28)
# [02:44] <jdaggett> TabAtkins: you don't associate state with styles that apply to that state
# [02:44] <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; } }
# [02:44] <jdaggett> TabAtkins: multiple selectors could set the state to D
# [02:45] <jdaggett> TabAtkins: not sure what the correct answer is here
# [02:45] <jdaggett> TabAtkins: these are useful for UI's
# [02:45] * sylvaing If Daniel were here he'd be renaming BlueGriffon to OhMyGod
# [02:46] <jdaggett> TabAtkins: people are trying to do complex things
# [02:46] <jdaggett> TabAtkins: this is simpler for those cases
# [02:47] <jdaggett> dbaron: weird that property values defined in one place and transitions in another place
# [02:47] <smfr> i agree with dbaron
# [02:47] <jdaggett> dbaron: should be more like keyframes
# [02:48] <jdaggett> TabAtkins: defined by mixins
# [02:48] * jdaggett mixins, weeee
# [02:48] * Quits: sylvaing (sylvaing@125.207.177.35) (Quit: sylvaing)
# [02:48] <jdaggett> TabAtkins shows example using @node
# [02:48] <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; }
# [02:49] <jdaggett> TabAtkins: this creates a property bag in the transition graph
# [02:50] <jdaggett> TabAtkins shows demo passing through D node
# [02:50] <jdaggett> TabAtkins: this gives us a unified model
# [02:50] <jdaggett> TabAtkins: there are some issues
# [02:50] <jdaggett> TabAtkins: fertile ground
# [02:51] * jdaggett ah, fertility
# [02:51] <jdaggett> smfr: tricky to talk about this in F2f format
# [02:51] <jdaggett> TabAtkins: will post examples to wiki
# [02:52] <jdaggett> vhardy: should we do this with the FX task force
# [02:52] <jdaggett> TabAtkins: not doing anything incompatible yet
# [02:52] <jdaggett> vhardy talking about state transition model
# [02:52] <jdaggett> vhardy: lots of animation models when include things like SMIL
# [02:53] <jdaggett> vhardy: i'm interested if we can more of the timing model of SMIL
# [02:53] <jdaggett> vhardy: sophisticated effects require better sync
# [02:53] <jdaggett> TabAtkins: we've thought about this a lot
# [02:53] <jdaggett> TabAtkins: we probably don't want to go too crazy in css
# [02:54] <jdaggett> TabAtkins: complex stuff should be done via a rich js api
# [02:55] <jdaggett> TabAtkins: dean is working on css om apis
# [02:55] <jdaggett> TabAtkins: go through there
# [02:55] <jdaggett> TabAtkins: this allows more powerful things
# [02:55] <jdaggett> TabAtkins: that's probably a better direction
# [02:55] <jdaggett> vhardy: may need some declarative syntax for that
# [02:56] <jdaggett> TabAtkins: hard to do with css model
# [02:56] <jdaggett> vhardy: how to deal with multiple animations
# [02:56] <jdaggett> TabAtkins: css model is that one animation wins
# [02:57] <jdaggett> TabAtkins: we know smil does that
# [02:57] * Joins: stearns (qw3birc@128.30.52.28)
# [02:57] <jdaggett> jdaggett: i'm worried about referring to smil
# [02:58] <jdaggett> the complexity of smil scares me
# [02:58] <jdaggett> vhardy: it's complex but it's doable
# [02:58] <arronei> I'm worried that this is complicating CSS too much.
# [02:59] <jdaggett> sylvaing: the lack of an api is painful
# [02:59] <jdaggett> arronei, +1
# [02:59] <jdaggett> sylvaing: for developers
# [03:00] <fantasai> ScribeNick: fantasai
# [03:00] * Joins: sylvaing (sylvaing@125.207.177.35)
# [03:00] <arronei> We used to have a behaviors spec for CSS this might be worth moving in that direction.
# [03:01] <fantasai> Topic: IVS
# [03:01] <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011AprJun/0427.html
# [03:02] <dbaron> 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.
# [03:02] <kojiishi> http://itpro.nikkeibp.co.jp/article/COLUMN/20110124/356398/
# [03:03] <fantasai> jdaggett points to example in that page
# [03:03] <fantasai> jdaggett: This is one single codepoint. The second codepoint listed is the IVS, which says which variant to use.
# [03:03] <fantasai> jdaggett: If you look carefully, you can see he variations
# [03:03] <dbaron> looking at variants of 邊
# [03:03] <fantasai> jdaggett: There's a whole range of variations
# [03:04] <fantasai> 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
# [03:04] <dbaron> fonts map E0100 and E0108 variantns to same glyph, etc.
# [03:04] <fantasai> jdaggett: The way this work is that different vendors can come to Unicode and register variants
# [03:04] <fantasai> jdaggett: But there's no process that requires them to go through the existing registration to see which of their variations already exist
# [03:05] <fantasai> jdaggett: That whole problem is foisted onto users and font developers
# [03:05] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [03:05] <fantasai> 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
# [03:06] <fantasai> Nat: It's in his interests to keep up the silos.
# [03:06] <fantasai> jdaggett: They don't realize that the way in which they've done ths, they're creating interop problems for authors and for implementers like us
# [03:06] <fantasai> jdaggett: So there's that problem
# [03:06] <fantasai> jdaggett: What fantasai has written up is a letter ..
# [03:07] <fantasai> jdaggett: There are proposed changes to the process that would encourage vendors to share IVSes.
# [03:07] * Joins: szilles (chatzilla@125.207.177.35)
# [03:07] <fantasai> 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
# [03:08] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [03:08] <fantasai> jdaggett: The differences can be very subtle. It's hard to tell, without prose, what differences are being registered, and which differences are being registered or whether this is just a duplicate
# [03:08] * Joins: konaya (konaya@83.251.16.72)
# [03:08] <fantasai> Steve is concerned about being tactful
# [03:09] <fantasai> jdaggett: Interop isn't something that exists only outside of Japan.
# [03:09] <fantasai> 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.
# [03:10] <fantasai> Nat: I think what they saw with IVS was that they could encode all these incompatibilities in glyph shape into Unicode
# [03:10] <fantasai> Nat: They see it as the opposite of what it's for, it's not your responsibility anymore, you can register any IVD registration
# [03:10] <fantasai> Nat: what should have happened when the second IVD collection was registered was to say, No, that's not what this is for.
# [03:10] <fantasai> Nat: To have more than one collection means that you have a body that needs to determine the interactions between the collecitons.
# [03:11] <fantasai> Nat: Why have more than one collection? Why not have only one collection?
# [03:11] <fantasai> Nat: And have new glyphs interoperate with existing set
# [03:11] <fantasai> Nat: If you're not having a flat model, then what are you trying to do?
# [03:11] <fantasai> Nat: If I'm right and the original purpose was to solve interop, then we really need strong language
# [03:12] <fantasai> 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.
# [03:12] <fantasai> Yamamoto: They tried to .. set of glyph, but they couldn't because the granularity changed.
# [03:13] <fantasai> Yamamoto: For example, government needs more granularity for people's names
# [03:13] <fantasai> Yamamoto: ...
# [03:13] <fantasai> Yamamoto: So they reached conclusion that it's impossible to have one universal list of glyphs
# [03:13] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [03:14] * Joins: konaya (konaya@83.251.16.72)
# [03:14] <fantasai> Yamamoto: So this was born, and that allows different parties to submit different IVD collections
# [03:14] <fantasai> Yamamoto: But they're currently planning to amend the process to encourage sharing and coordination between groups with similar glyphs
# [03:14] <fantasai> Yamamoto: That is the historical description.
# [03:14] <fantasai> jdaggett: It's that proposal that we're suggesting to comment on
# [03:15] <fantasai> jdaggett: Unless it's written more strongly, they won't bother. They should cooperate, but it takes too much time.
# [03:15] <fantasai> jdaggett: I think the language is good,
# [03:15] <fantasai> jdaggett: I think we should take Steve's suggestion and also focus on the problem of interop within Japan
# [03:16] <fantasai> Yamamoto talks about some committee about discussing IVS interop
# [03:16] <fantasai> Yamamoto: At that meeting we will discuss ways to improve the current situation.
# [03:17] <fantasai> Yamamoto: Such as having a mapping table between different IVD collections
# [03:17] <fantasai> Yamamoto: Or more documentation on granularity.
# [03:20] <fantasai> fantasai: ...
# [03:20] <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
# [03:20] <fantasai> jdaggett: These differences are erased in a gothic style
# [03:21] <fantasai> Nat gives a history of a glyph diverging and merging and diverging
# [03:22] <fantasai> jdaggett: This starts to get involved into font fallback
# [03:22] <fantasai> jdaggett: A lot of gothic faces won't implement these differences
# [03:22] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [03:23] * Joins: konaya (konaya@83.251.16.72)
# [03:23] <fantasai> 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 variations
# [03:24] <fantasai> Nat: The gothic face will just unify the glyphs, have the same glyph for both codepoints
# [03:24] <fantasai> 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 thing
# [03:26] <fantasai> RESOLVED: Send comment to Unicode on behalf of CSSWG requesting stronger requirements for sharing IVSes across IVD collections.
# [03:26] <fantasai> Topic: font fallback with IVS
# [03:26] <fantasai> 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.
# [03:26] <fantasai> jdaggett: For a lot of users, the distinction is too subtle, which they won't notice, but they will pick up the style change.
# [03:27] <fantasai> Yamamoto: There can be 2 different views on this issue.
# [03:27] <fantasai> Yamamoto: If we have theoretical character model
# [03:27] <fantasai> Yamamoto: Yes, there are exceptional cases such as Gothic and display faces, where such subtle details are gone
# [03:27] <fantasai> Yamamoto: But there are a variety of typefaces in Mincho style, there are many different designs of Mincho categorized in Mincho style
# [03:28] <fantasai> Yamamoto: In that scope, I think it is possible to notice the differences in these glyph shapes.
# [03:28] <fantasai> 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
# [03:29] <fantasai> 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
# [03:30] <fantasai> 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.
# [03:30] <fantasai> Yamamoto: So I can agree with you, but there is another way of looking at this.
# [03:30] <fantasai> Nat: One point you may want ot emphasize, is when doing fallback, when doing catastrophic fail of the system ...
# [03:30] <fantasai> jdaggett: You said this yesterday, and I want to say this again -- on the Web, fallback is the normal thing.
# [03:31] <fantasai> 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
# [03:31] <fantasai> Koji: Even within Japanese, authors tend to want to show glyphs while designers want to use consistent typefaces. So it splits.
# [03:31] <fantasai> jdaggett: I think that's not true. I think authors would like things displayed nicely, too.
# [03:32] <fantasai> jdaggett: Kobayashi-san wants it one way, and person working at Magazine wants it another way
# [03:32] <fantasai> 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 ...
# [03:32] <fantasai> Koji: if author cares, the difference is important to him.
# [03:33] <fantasai> Florian: It says the author cares. Doesn't say whether author cares enough to switch font.
# [03:33] <fantasai> Nat: I'm concerned about author knowing so much about the encoding. They'd just pick from a glyph palette.
# [03:34] <fantasai> 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.
# [03:34] <fantasai> Nat: Because of the tension you menion, I think there should be infrastructure to support a preference of some kind.
# [03:34] <fantasai> Nat: Author should know that UA might not be able to display things as desired
# [03:34] <fantasai> Nat: All fo these combine to make situation.
# [03:35] <fantasai> Nat: When there's a conflict, we should give them a choice.
# [03:35] <fantasai> 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.
# [03:36] <fantasai> 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.
# [03:36] <fantasai> Nat: This font fallback scenario helps people understand that.
# [03:36] <fantasai> jdaggett: One problem we have in CSS is, font fallback, we have a couple different flavors.
# [03:37] <fantasai> jdaggett: A lot of discussion has been simplified or oversimplified.
# [03:37] <fantasai> jdagget writes:
# [03:37] <fantasai> font-family: fontA, fontB;
# [03:37] <fantasai> jdaggett: So if I have a base character and a selector
# [03:37] <fantasai> jdaggett: in an ideal world, you would ask if the sequence is in fontA, if in fontB, and then go into system fallback
# [03:37] * Quits: smfr (smfr@17.203.14.12) (Quit: smfr)
# [03:38] <fantasai> jdaggett: system fallback is a black box.
# [03:38] <fantasai> jdaggett: That's not something that is explicitly specified.
# [03:38] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [03:38] <fantasai> jdaggett: This is currently a one-pass process
# [03:38] <fantasai> 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
# [03:38] <fantasai> jdaggett: You go through font list, and then you hit system fallback
# [03:38] <fantasai> jdaggett: When you consider IVS, need to think maybe there's a 2-pass process tha needs to happen
# [03:39] <fantasai> jdaggett: So, in many mailings that have been posted, appear to describe as 2 options
# [03:39] <fantasai> 1. You take the combination of base character and selector, go through the list looking for a match.
# [03:40] <fantasai> If you don't find one, you use base character and look for a match again
# [03:40] <fantasai> 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.
# [03:40] <fantasai> jdaggett: Those are just 2 of several options. Because you have this black box here.
# [03:40] * Joins: konaya (konaya@83.251.16.72)
# [03:40] <fantasai> jdaggett: Question is, when do you hit the black box.
# [03:41] <fantasai> jdaggett: In 1, do you hit the black box with the combo before going back with the base character?
# [03:41] <fantasai> jdaggett: Or do you only hit system fallback if you can't find either the sequence or the base?
# [03:41] <fantasai> Florian: Not sure this helps with having a choice
# [03:42] <fantasai> jdaggett: ...
# [03:43] <fantasai> jdaggett: This problem (points at IVS example) makes things even worse, do you look at interrelations between variants?
# [03:43] <fantasai> Koji: I would like to show an example of how I would choose glyphs.
# [03:43] <fantasai> Koji: It's not about IVS, but even before IVS we have some variants
# [03:43] <fantasai> Koji: I'm going to show how I would type user name today.
# [03:44] <fantasai> Koji: I'm typing watanabe, and this is the IME conversion.
# [03:44] <fantasai> Koji: It's picking up from my Outlook contacts
# [03:44] <fantasai> Koji: Different Watanabe's in my outlook contact have different glyph differences
# [03:44] <fantasai> Koji: I don't remember which glyph, but it's in my contacts
# [03:44] * Joins: shepazu (schepers@128.30.52.169)
# [03:44] <fantasai> Koji: But it's important to get it correct for people names
# [03:44] <fantasai> Koji: So this is built into IME.
# [03:44] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [03:45] <fantasai> Florian: I think the point is that the person authoring the document might not realize that they're picking a very particular glyph
# [03:45] <fantasai> jdaggett: So you're saying you don't know whether this is using an IVS or not
# [03:46] <fantasai> Koji: Right. If this displays different on his computer, I would be very disappointed.
# [03:46] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [03:47] <fantasai> jdaggett: ...
# [03:47] <fantasai> 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
# [03:48] <fantasai> 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.
# [03:48] <fantasai> jdaggett: So the problem is, if the policeman has the Hanyo-Denshi font, and your system doesn't have it, what happens?
# [03:48] * Joins: szilles (chatzilla@125.207.177.35)
# [03:48] <fantasai> jdaggett: There's a subtle point here wrt how UAs evolve.
# [03:48] <fantasai> jdaggett: We all know that features have a way of going beyond what's in the spec very often
# [03:49] <fantasai> jdaggett: My concern with this is that there' be a natural temptation to do improvements, such as incorporating mappings between Hanyo-Denshi and Adobe Japan 1 and default glyph
# [03:49] <fantasai> jdaggett: If one UA does that, then all UAs have to do that.
# [03:49] <fantasai> jdaggett: So my idea is to disallow that in the spec.
# [03:50] <fantasai> Nat: Same problem exists today with mobile phones
# [03:50] * shepazu waves from the beach
# [03:50] <fantasai> Nat: When you send from NTT Docomo phone to ??, the SMS gets translated to something that will work.
# [03:50] <fantasai> jdaggett: I want to put in that cmap tables are used, only.
# [03:51] <fantasai> jdaggett: I don't want all implementations to cart around a mapping table.
# [03:51] <fantasai> Steve: If the problem get solved at the registry level
# [03:51] <fantasai> Steve: Then it's easy fo rpeople to be consistent because there is in theory only one sequence for each
# [03:51] <fantasai> Steve: The next suggestion is to require font vendors to have mapping tables
# [03:51] <fantasai> Steve: Then the user doesn't need to do it
# [03:52] <fantasai> Steve: It could also be solved at the UA level
# [03:52] <fantasai> jdaggett: For this version, those tables don't exist, and we create an interop problem if different UAs use different tables
# [03:52] <fantasai> Steve: My final point is that somewhere some group should create that table
# [03:53] <fantasai> Steve: Which will be copied everywhere.
# [03:53] <fantasai> Nat: Fonts are a notoriously unreliable place to put such mapping table.s
# [03:53] <fantasai> Nat: We are constantly updating our stupid Unicode tables in these fonts.
# [03:53] <fantasai> Nat: There are so many inaccuracies in our font tables.
# [03:53] <fantasai> Steve: Moving the solution to a different place doesn't solve the problem of building the table.
# [03:54] <fantasai> 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.
# [03:55] <fantasai> ...
# [03:55] <fantasai> Nat: I think clear wording in the spec is good.
# [03:55] <fantasai> Nat: With this issue, but there's a conflict between ppl wanting to use Adobe Japan 1 and Hanyo-Denshi
# [03:55] <fantasai> Nat: I think there will be resistance for font vendors to use both mappings.
# [03:55] <fantasai> Nat: Hanyo-Denshi variations are built for a certain user set in mind.
# [03:56] <fantasai> Nat: And some of these variations are so subtle, that they are almost stylistic variations.
# [03:56] <fantasai> Nat: They're provied for govt use or whatever
# [03:56] <fantasai> Nat: Adobe-Japan 1 is not a government use table
# [03:57] <fantasai> Nat: I think it'll be difficult for each font vendor to map to the govt glyph shape database
# [03:57] <fantasai> Nat: Which is what it's becoming, instead of semantic-meaning database.
# [03:57] <fantasai> Nat: So we need this table, maybe it goes in the black box, but then everyone has different black box
# [03:58] <fantasai> jdaggett: I wanted to point out one thing Kawabata san put up on the board.
# [03:58] <fantasai> jdaggett: One thing he put up was [base char][IVSx][IVSy]
# [03:58] <fantasai> jdaggett: so that was fallback in the character stream
# [03:58] <fantasai> jdaggett: This.. if you look at how this was defined, there's a single selector. You can't have multiple selectors.
# [03:59] <fantasai> jdaggett: We should explicitly put in text saying the second selector is malformed.
# [03:59] <fantasai> Nat: It's interesting thing he's decided is necessary. Points out that fallback.. becaus eof hte way IVD colections came about, fallback will have to be customizable
# [03:59] <fantasai> Nat: Could be more fuel for your letter. Here is someone who wants to customize fallback. Obviously there's a problem here.
# [04:00] <fantasai> Koji: I think there were two issues mixed.
# [04:00] <fantasai> Koji: One is whether to fall back IVS first or font first
# [04:00] <fantasai> Koji: Other is mapping between different IVD collections.
# [04:00] <fantasai> Koji: For the latter, I don't think it's necessary. It's not application's responsibility
# [04:00] <fantasai> jdaggett: I'm saying it's not just unnecessary, but we have to say it's not allowed. OTherwise some applications will includde it in their black box.
# [04:01] <fantasai> jdaggett: This table doesn't even exist, so ...
# [04:01] <fantasai> Florian: Can we address separately the two issues?
# [04:01] <fantasai> Koji: What I care is first one.
# [04:01] <fantasai> jdaggett: I hadn't considered Nat's proposal to allow a choice
# [04:02] <fantasai> Florian: We have a switch in CSS, and give an algorithm for each option.
# [04:02] <fantasai> Florian: I think it's only possible to pick the best algorithm for each priority
# [04:03] <fantasai> Florian: Not hard to decide on the algorithm once you have priority
# [04:03] <fantasai> 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.
# [04:03] <fantasai> jdaggett: And have a switch for preferring font consistency.
# [04:04] <fantasai> jdaggett: Keep in mind that the text includes the IVS, so if you cut and paste it you preserve this info
# [04:04] <fantasai> Nat: Imagine a publishing-proofing system.
# [04:05] <fantasai> Nat: In desktop systems, we want to make it really obvious when a glyph is missing.
# [04:05] <fantasai> Nat: This way the proofer could immediately see that this character was missing or wrong
# [04:06] <fantasai> Steve: You could use a font that maps every Unicode codepoint to the geta character (missing glyph thing)
# [04:07] <fantasai> jdaggett: So, first point is, that's not a general feature. It's a user-agent level feature.
# [04:07] <fantasai> Nat: ...
# [04:07] <fantasai> jdaggett: Oh, you're talking about a Web-based authoring environment
# [04:08] <fantasai> Steve: Just hijack it by using the fail-character font
# [04:08] <fantasai> Nat: Ok, that works.
# [04:08] * Quits: arno (arno@192.150.10.201) (Quit: Leaving.)
# [04:09] <fantasai> Nat: U+3013
# [04:09] <fantasai> jdaggett: Ok, so that's all I have to say. I'll work on adding the wording here.
# [04:09] <fantasai> jdaggett: Unfortunate that this complicates font fallback, but that's par for the course.
# [04:10] <fantasai> 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
# [04:10] * Zakim excuses himself; his presence no longer seems to be needed
# [04:10] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [04:11] <fantasai> Nat brings up compatibility chars
# [04:11] <fantasai> Koji: I think that's a separate topic, and not CSSWG responsibility
# [04:12] <fantasai> Nat: No, but add to Unicode feedback from CSSWG.
# [04:12] <fantasai> ACTION: fantasai mention compat characters in mapping table request
# [04:12] * trackbot noticed an ACTION. Trying to create it.
# [04:12] * RRSAgent records action 2
# [04:12] <trackbot> Created ACTION-322 - Mention compat characters in mapping table request [on Elika Etemad - due 2011-06-10].
# [04:14] * Quits: vhardy (vhardy@125.207.177.35) (Quit: vhardy)
# [04:22] <szilles> RRSAgent: pointer
# [04:22] <RRSAgent> See http://www.w3.org/2011/06/03-css-irc#T02-19-35
# [04:27] * Joins: boblet (Adium@125.207.177.35)
# [04:31] <TabAtkins> ScribeNick: TabAtkins
# [04:32] <TabAtkins> murakami: I think 'white-space-collapse' is a good name for the property.
# [04:32] <TabAtkins> murakami: It's not a big problem for XSL-FO to have a property of the same name but different values, I think.
# [04:32] <TabAtkins> murakami: They're sufficiently different.
# [04:32] <TabAtkins> szilles: So what happens if I embed SVG in both?
# [04:32] <TabAtkins> szilles: It makes sense for SVG to do whitespace collapsing.
# [04:32] <fantasai> Note: Murakami-san is an implementer for Antenna House Formatter, which supports both CSS and XSLFO
# [04:33] <TabAtkins> szilles: The agreement we had was that if we were going to change the property value, we should change the name.
# [04:33] <TabAtkins> murakami: With 'white-space-collapsing', is the "ing" a big problem?
# [04:33] <TabAtkins> fantasai: Just clumsy, especially with 'border-collapse' already existing.
# [04:34] <TabAtkins> jdaggett: Why not just call it 'white-space-collapse' for now, mark an issue, and look at it later?
# [04:34] <TabAtkins> fantasai: That just puts us in the same boat.
# [04:35] <TabAtkins> jdaggett: Just to have it not be "bikeshedding".
# [04:35] <TabAtkins> "whollapse-c-space"
# [04:35] <dbaron> dbaron: 'collapse-white-space'?
# [04:35] <dbaron> szilles: 'text-space-collapse'
# [04:36] <TabAtkins> RESOLVED: Change to 'collapse-white-space'.
# [04:36] <TabAtkins> RESOLVED: Strike last resolution
# [04:36] <TabAtkins> RESOLVED: Change 'bikeshedding' to 'text-space-collapse'
# [04:37] <TabAtkins> fantasai: Let's look at the ToC and go through issues.
# [04:38] <TabAtkins> Nat: My main priority is things to do with japanese punctuation adjustment.
# [04:40] <TabAtkins> jdaggett: [explains the standard model of pruning specs after experimental impls start]
# [04:41] <TabAtkins> fantasai: Let's start with linebreaking, then spacing, then text-justify.
# [04:42] <TabAtkins> 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)
# [04:42] <TabAtkins> fantasai: The definition is fairly vague - lots of UA freedom.
# [04:42] <TabAtkins> fantasai: In strict breaks are forbidden before small kana and some other marks.
# [04:43] <TabAtkins> fantasai: [more description of the property in the spec]
# [04:43] <TabAtkins> jdaggett: Is there stuff in the jltf recs that give you character classes for this info?
# [04:43] <TabAtkins> fantasai: We do point to the jlreq document for recomendations, but...
# [04:43] <TabAtkins> jdaggett: I'm looking for something more detailed.
# [04:44] <TabAtkins> 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.
# [04:44] <TabAtkins> fantasai: Ok.
# [04:44] <TabAtkins> Nat: I don't htink the jlreq character classes are used for linebreaking.
# [04:44] <TabAtkins> szilles: They sometimes are, and sometimes aren't.
# [04:46] <TabAtkins> kojiishi: Topan said that they wanted to specify individual characters for "kinsoku rules" (characters you can't break on).
# [04:46] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [04:46] <TabAtkins> florian: General interoperability concern - while this helps for cj, it potentially makes the interop bad for other types of languages.
# [04:46] <TabAtkins> florian: Because there aren't any details other than the cj stuff.
# [04:47] <TabAtkins> fantasai: Unfortunately, the rules for linebreaking are very specific to the language...
# [04:47] <TabAtkins> fantasai: We're not trying to solve this, and exactly specify it, but in Japanese they care about having different levels of linebreaking.
# [04:47] <TabAtkins> fantasai: We could specify that in languages other than cj, the property has no effect, or has no effect *right now*.
# [04:47] <TabAtkins> jdaggett: Is this tied to the language tag?
# [04:48] <TabAtkins> fantasai: Somewhat - there are several breaks that are based on the language.
# [04:48] <TabAtkins> jdaggett: I ask becuase you can have mixed-language documents.
# [04:48] <TabAtkins> 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 middl eof an english word).
# [04:48] <TabAtkins> fantasai: That's handled by the next property.
# [04:48] <TabAtkins> florian: [something I missed]
# [04:49] <TabAtkins> fantasai: Impls have a compromise breaking algorithm that tends to work decently on most languages.
# [04:49] <TabAtkins> florian: So if you say 'strict', does it only work on japanese?
# [04:49] <TabAtkins> fantasai: They work in all languages, but the rules specifically refer to japanese characters, so it won't effect other scripts.
# [04:49] <TabAtkins> 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".
# [04:50] <TabAtkins> fantasai: We already have that here - we have some rules that are specific to chinese-only or japanese-only.
# [04:50] <TabAtkins> fantasai: The language-specific rules are independent of the level you're working on.
# [04:50] <TabAtkins> florian: But if we later let 'strict' work for English...
# [04:50] <TabAtkins> fantasai: --like, "only break at spaces"...
# [04:51] <TabAtkins> florian: ...we'll have rules in Japanese that say "break at hyphens" and in English that say "don't break at hyphens".
# [04:52] <TabAtkins> fantasai: We've got a division between the generic rules, which every language would do, and then the lang-specific rules that are tied to a strictness level.
# [04:52] <TabAtkins> fantasai: *Only* if you're language-tagged do you get the language-specific rules.
# [04:53] <TabAtkins> florian: So should we say that in "generic mode" there's no difference?
# [04:53] <TabAtkins> fantasai: There is a difference, but they're code-point specific, so they won't affect other scripts.
# [04:53] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [04:54] <TabAtkins> 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.
# [04:55] <TabAtkins> [discussion about how specific it is to refer to code-points]
# [04:57] <TabAtkins> 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. There's only a few exceptions.
# [04:58] <TabAtkins> 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'.
# [04:58] <TabAtkins> szilles: So we should be absolutely clear that, in the generic case, there's only the one algorithm.
# [04:59] <TabAtkins> Nat: Each publishing house has their own rules for what's appropriate. There's some consensus, producing some lists for what's appropriate.
# [04:59] <TabAtkins> 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"?
# [05:00] <TabAtkins> fantasai: So how should I define this without listing codepoints immediately?
# [05:00] <TabAtkins> Nat: I suggest using very generic names - "level1", "level2", etc.
# [05:01] <TabAtkins> fantasai: We can't change the value names - 'normal' and 'strict' have been implemented for a long time. We only added 'loose' and 'auto'.
# [05:01] <TabAtkins> Nat: Ok. So, given all the variability in what's going on here, why specify it at all?
# [05:02] <TabAtkins> Nat: Anything other than 'strict' is basically meaningless, because it's far too varying.
# [05:03] <TabAtkins> [some discussion I couldn't pick the point out of in time, so was lost]
# [05:04] <TabAtkins> Nat: I think it's unfortunate that the spec, then, doesn't really improve on the situation as it currently exists.
# [05:05] <TabAtkins> 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.
# [05:05] <TabAtkins> fantasai: I can go copy someone's house rules and put them in the spec, if necessary.
# [05:05] <TabAtkins> 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.
# [05:06] <TabAtkins> 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.
# [05:06] <TabAtkins> fantasai: I believe that the specifics of the house rules aren't important. Authors won't care. Publishing houses do.
# [05:07] <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.
# [05:07] <TabAtkins> fantasai: People using Word basically never alter the kinsoku tables.
# [05:07] <TabAtkins> 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.
# [05:08] <TabAtkins> 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.
# [05:09] <TabAtkins> 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.
# [05:09] <TabAtkins> fantasai: I can't be absolutely exhaustive because it keeps changing/growing
# [05:10] <TabAtkins> 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.
# [05:10] <TabAtkins> 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'?
# [05:10] <TabAtkins> kojiishi: Normal users *do* switch between normal and strict, though.
# [05:12] <TabAtkins> florian: You're not saying that if you haven't labelled with a specific language, not to change anything.
# [05:12] <TabAtkins> fantasai: So you're saying that it should only work if you have a language tag?
# [05:14] <TabAtkins> florian: If someone has a single awesome linebreaking algo, that's okay. But do we want to invent four?
# [05:14] <TabAtkins> fantasai: Yeah?
# [05:14] <TabAtkins> Bert: Go ahead! Invent as many awesome algorithms as you want. This is good!
# [05:16] <TabAtkins> 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".
# [05:17] <TabAtkins> 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.
# [05:18] <TabAtkins> 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.
# [05:18] <TabAtkins> szilles: What I have trouble with is that any of the "loose"s are arbitrary.
# [05:18] <TabAtkins> fantasai: They're all arbitrary.
# [05:19] <TabAtkins> fantasai: We figured three was a workable number for most people.
# [05:19] <TabAtkins> 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".
# [05:20] <TabAtkins> Nat: In InDesign there are four lists of rules - "can't begin", "can't end", etc.
# [05:21] <TabAtkins> szilles: For this round, we don't need the extension mechanism, we just need it to be possible to extend into that.
# [05:21] <TabAtkins> szilles: Since we're stuck with two values (normal/strict), I just don't see why we need the third value (loose).
# [05:21] <TabAtkins> Nat: I'm just sad about the name - "normal" basically means "sometimes loose". ;_;
# [05:23] <TabAtkins> fantasai: So I'm going to pull out the codepoints and make it clear that non-CJK codepoints aren't affected, and will mark 'loose' as at-risk.
# [05:24] <TabAtkins> Bert: I'd prefer not to extend this in the future. I'd like to just finish it now with the features we need.
# [05:25] <TabAtkins> 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.
# [05:25] <TabAtkins> sylvaing: I don't have exact numbers, but I know that usage of Word's normal/strict controls are relatively little-used.
# [05:27] <TabAtkins> 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' smore open-ended.
# [05:29] <TabAtkins> <br type=lunch duration=1h>
# [05:30] * Quits: florian (florianr@58.1.224.28) (Ping timeout)
# [05:32] * Parts: danield (danield@125.207.177.35)
# [05:36] * Joins: arron (arronei@166.205.143.98)
# [05:36] * Joins: danield (danield@125.207.177.35)
# [05:46] <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.
# [05:47] <nmccully> So, perhaps we should eliminate all language the describes the behaviors
# [05:47] <nmccully> Just say you can pick between "normal" and "strict" and those behaviors are not defined currently
# [05:47] <nmccully> in the future we will allow customization, which gets you what you want
# [05:49] <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.
# [05:50] * Joins: florian (florianr@125.207.177.35)
# [05:53] * Quits: florian (florianr@125.207.177.35) (Ping timeout)
# [06:02] * Joins: florian (florianr@58.1.224.28)
# [06:02] * Joins: szilles (chatzilla@125.207.177.35)
# [06:12] * Joins: futhark (rune@213.236.208.22)
# [06:14] <TabAtkins> Topic: text-spacing
# [06:15] <TabAtkins> fantasai: We've recast this feature multiple times.
# [06:16] <TabAtkins> fantasai: One thing that happens when typesetting japanese is that when you have certain punc character together, they sorta combine.
# [06:16] <TabAtkins> fantasai: another is that some people like to insert spaces between, frex, latin and ideographic chracters.
# [06:16] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [06:16] <TabAtkins> florian: Why does this have to be automatic?
# [06:17] <TabAtkins> fantasai: You switch scripts a lot in jp, but not languages. Jp is basically made up of 4 scripts at this point.
# [06:18] * Joins: arron_ (Arron@24.17.123.244)
# [06:18] <TabAtkins> fantasai: trim-start/end removes spacing at first/last char on line to make it align closer to the line.
# [06:18] <TabAtkins> fantasai: 'normal' is normal behavior. 'none' sets everything in 1em squares.
# [06:18] <TabAtkins> 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.
# [06:19] <TabAtkins> fantasai: trim-end/space-end do the same for the end of a line.
# [06:19] <TabAtkins> fantasai: And allow-end *allows* you to trim if the last char doens't fit, or make it fullwidth otherwise.
# [06:19] * Quits: arron (arronei@166.205.143.98) (Ping timeout)
# [06:19] * arron_ is now known as arron
# [06:19] <TabAtkins> fantasai: 'trim-adjacent/space-adjacent are the same, but within a line.
# [06:20] <TabAtkins> fantasai: Then you have the values for spacing between alpha and ideographic characters.
# [06:20] <TabAtkins> fantasai: That's almost a different feature. You're adding space rather than taking away space.
# [06:20] <TabAtkins> fantasai: But that depends on your mental model.
# [06:21] <TabAtkins> florian: I ask if it's actually separate features because hakon objects to the second feature, not the first one.
# [06:22] <TabAtkins> florian: The french actually put spaces in their text when this sort of thing is desired.
# [06:22] * Joins: szilles (chatzilla@125.207.177.35)
# [06:22] <TabAtkins> kojiishi: It's a stylistic variation only.
# [06:23] <TabAtkins> fantasai: These used to be two features. text-trim was the first several features, text-auto-space was the alpha/ideographic ones.
# [06:23] <TabAtkins> Nat: I think it's okay to combine them.
# [06:26] <TabAtkins> Nat: I think the property may not offer quite as much control as necessary to achieve pretty display, but otherwise it seems okay.
# [06:26] <TabAtkins> 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?
# [06:26] <TabAtkins> fantasai: By default, you can justify by adjusting those spaces, and we have an option to turn that off.
# [06:26] <TabAtkins> Nat: Does that usually mean to expand the space, or can it compress the space?
# [06:27] <TabAtkins> fantasai: Up to the UA.
# [06:27] <TabAtkins> Nat: It seems that you're only talking about push-out style justification in the spec.
# [06:27] <TabAtkins> kojiishi: The text-justify property allows you to do anything.
# [06:28] <TabAtkins> fantasai: [explains the text-justification property]
# [06:32] <TabAtkins> 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.
# [06:32] <TabAtkins> Nat: So it would be good to have some markup allowing me to specify whether that happens or not.
# [06:33] <TabAtkins> florian: What are the priorities for things?
# [06:33] <TabAtkins> fantasai: glyphs-shaping, for example, is listed as out-of-scope. UAs can do it if they want.
# [06:34] <TabAtkins> 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.
# [06:36] <TabAtkins> fantasai: There are no controls for priority beyond punctuation.
# [06:36] <TabAtkins> kojiishi: We've brainstormed abilities for the future that would allow better priority-control, similar to what InDesign does now.
# [06:37] <TabAtkins> fantasai: Are there particular controls you would find important to add?
# [06:37] <TabAtkins> Nat: I don't think it's necssarily important to provide what InDesign has.
# [06:37] <TabAtkins> Nat: But could you make it any simpler while achieving similar results?
# [06:37] <TabAtkins> fantasai: What would you simplify?
# [06:39] <TabAtkins> Nat: Right now what you're saying is that the line-ends are important for fullwidth punctuation.
# [06:40] <TabAtkins> Nat: That is, lineend->punctuation is one pair, alpha->ideograph is one pair, etc. Do you have ideograph->ideograph?
# [06:40] <TabAtkins> fantasai: No. That spacing can be justified, but you wouldn't do exceptional spacing by default.
# [06:41] <TabAtkins> 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 everything.
# [06:42] <TabAtkins> fantasai: We also have a letter-spacing and word-spacing property which lets you set the spacing defaults, and put limits on them.
# [06:42] <TabAtkins> fantasai: So you can control that sort of thing more precisely with those properties.
# [06:44] <TabAtkins> 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.
# [06:44] <TabAtkins> fantasai: It sounds like you want to expand the cjk to max, and then expand both roman and cjk.
# [06:45] <TabAtkins> Nat: Yeah, sometimes in these exceptional circumstances you just need to violate all the max constraints.
# [06:45] <TabAtkins> fantasai: That makes sense, and I'll change the spec to say so.
# [06:45] <TabAtkins> szilles: I think the spec should give these things as examples, and show how to use them together to get what you want.
# [06:46] <TabAtkins> Content: CJK-Roman-CJK * expand only spaces * expand cjk and spaces * expand cjk first, then everything
# [06:46] <TabAtkins> ^^^ needed examples
# [06:46] <TabAtkins> Nat: Also, JIS has 18 classes of punctuation. Here we simplify it down to one style of punctuation, which seems too simple.
# [06:47] <TabAtkins> fantasai: In terms of punctuation, it's like glyphs substitution - it's out of scop efor our controls, and UAs should do whatever is intelligent.
# [06:47] <TabAtkins> 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 anything else.
# [06:49] <TabAtkins> Nat: Ideally there should be a prioritization for how the existing spacing pairs (ideo->alpha, ideo->linestart, etc) get applied.
# [06:51] <TabAtkins> Nat: In the justification table, it looks like spaces are always expanded first, and then everything else at the same time.
# [06:51] <TabAtkins> fantasai: Normally you *do* always expand spaces as much as possible, and only do other justification if there's no spaces.
# [06:51] <TabAtkins> Nat: God help anyone with spaces on their line.
# [06:52] <TabAtkins> 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.
# [06:52] <TabAtkins> Nat: So you require a cjk author to set a relatively small space max-length, which may justify roman text badly.
# [06:53] <TabAtkins> fantasai: The default behavior for word-spacing takes "normal" for both min and max spacing, which can vary based on many factors. Basically, UA-dependent.
# [06:56] <TabAtkins> jdaggett: What's the value of 'auto' for word-spacing?
# [06:57] <TabAtkins> fantasai: It's the default, and lets the UA choose whatever is reasonable. I think there is a reasonable compromise, which is suggested in the table.
# [06:57] <TabAtkins> [discussion about the presentation of the table for easier reading]
# [06:58] <TabAtkins> fantasai: Okay, I'll change the 'auto' character to an asterisk with an explanation, and switch each column from 2-col to numbers.
# [06:58] <TabAtkins> fantasai: And add glyph-scaling to the methods as "whenever".
# [06:58] <TabAtkins> florian: Another comment from hakon - this is meant for documents where authors care about pretty formatting.
# [06:59] <TabAtkins> florian: But this reduces the ability of UAs to prettily justify by default. You can't do TeX justification.
# [07:00] <TabAtkins> 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.
# [07:01] <TabAtkins> florian: What's the best default value for English?
# [07:01] <TabAtkins> fantasai: inter-word
# [07:02] <TabAtkins> 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.
# [07:02] <TabAtkins> florian: That doesn't work here, if you have to set hard limits to make spaces stop expanding.
# [07:03] <TabAtkins> 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.
# [07:03] <TabAtkins> fantasai: Yes, though the min-space is still a hard limit.
# [07:04] * Joins: nmccully_ (nmccully@125.207.177.35)
# [07:06] <TabAtkins> Topic: text-transform
# [07:06] <TabAtkins> jdaggett: Now that fullwidth is in the property, what's its priority relative to uppercase/lowercase?
# [07:06] <TabAtkins> fantasai: I think we talked about that, though I don't recall exactly.
# [07:07] * Quits: nmccully (nmccully@202.32.93.230) (Ping timeout)
# [07:07] * nmccully_ is now known as nmccully
# [07:07] <TabAtkins> jdaggett: The case mapping rules here in the spec are woefully underdefined.
# [07:07] <TabAtkins> fantasai: I think the bar is the full unicode casing algorithm.
# [07:07] <TabAtkins> fantasai: But we want it to be able to be smarter than that.
# [07:08] <TabAtkins> jdaggett: I want something testable.
# [07:08] <TabAtkins> fantasai: Yeah.
# [07:09] <TabAtkins> jdaggett: Also, what's the relative ordering of all of these properties? Some proeprties are based on character class, and text-transform is changing the character class.
# [07:09] <TabAtkins> fantasai: Ok. I'll make a normative appendix specifying the order they're applied.
# [07:11] <TabAtkins> florian: Hakon wants to know what the <wide> tag is, that is mentioned there in the spec.
# [07:13] <TabAtkins> [discussion about the <wide> reference]
# [07:16] * Parts: florian (florianr@58.1.224.28)
# [07:16] * Joins: florian (florianr@58.1.224.28)
# [07:20] <TabAtkins> jdaggett: I want a clearer explanation of how to understand the unicode database file and map field X to field Y.
# [07:20] <TabAtkins> dbaron: Like "the sixth field of the database (decomposition_mapping)", etc.
# [07:22] <kojiishi> jdaggett: the order of value is fine with me: [ capitalize | uppercase | lowercase ] > fullwidth > fullsize-kana
# [07:26] <TabAtkins> Nat: You don't use small kana in ruby, for readability. You always use large kana.
# [07:27] <TabAtkins> Nat: When you author, you input large kana, not input small and then transform.
# [07:27] <TabAtkins> Nat: For accessibility, I'd hope you don't look at the ruby data for screenreading.
# [07:27] <TabAtkins> 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.
# [07:28] <TabAtkins> kojiishi: Some ruby uses small kana for stylistic purposes.
# [07:28] <TabAtkins> florian: But then they dont' transform, they just scale it up to be readable.
# [07:28] <boblet> (Unicode data file using <wide> etc being referenced was http://unicode.org/Public/UNIDATA/UnicodeData.txt btw)
# [07:30] * myakura heard from my colleague who works on a11y that some Japanese voice browsers can be configured to read ruby (content <rt>) instead of base text.
# [07:30] <dbaron> example of しゃ vs. しや
# [07:31] <dbaron> (though Elika wrote them in the other order: しや (shi ya) vs. しゃ (sha))
# [07:31] <TabAtkins> 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.
# [07:32] <TabAtkins> murakami: And some publishers specifically want small ruby with small kana. Also, educational materials for proper teaching of pronunciation.
# [07:34] <TabAtkins> florian: In this context, do we care about the codepoint switch, or is the glyph-switch sufficient?
# [07:34] <TabAtkins> fantasai: I think glyph switch is sufficient.
# [07:35] <TabAtkins> florian: Except for the 'fullwidth' value, because other properties change behavior there.
# [07:35] <TabAtkins> 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.
# [07:36] <TabAtkins> florian: There's a note that says "maybe use font-variant:ruby". is that something else?
# [07:36] <TabAtkins> jdaggett: It's just another glyph that uses fatter strokes, specifically for ruby.
# [07:40] <TabAtkins> jdaggett: [airs some concerns about the applicability of the fullsize-kana value, since it's pretty much only used for ruby]
# [07:40] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [07:42] * Joins: r12a (rishida@128.30.52.169)
# [07:44] <TabAtkins> florian: hakon suggested "text-transform-replace", basically identical to Perl's tr///
# [07:45] <TabAtkins> fantasai: That would solve the case, yes, but it also adds a *lot* of complexity for solving this one case.
# [07:45] <TabAtkins> florian: Hakon provides other use-cases for georgian, for example, to transform to remove accents.
# [07:46] <TabAtkins> szilles: What did we do for the list rule?
# [07:47] <TabAtkins> 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.
# [07:47] <TabAtkins> szilles: Why won't that work?
# [07:47] * Joins: vhardy (vhardy@125.207.177.35)
# [07:49] <TabAtkins> fantasai: It would. We could do that. But I don't think it's worth it.
# [07:51] * Joins: szilles (chatzilla@125.207.177.35)
# [07:53] <TabAtkins> ???: Can we call it 'fullsize' instead of 'fullsize-kana'?
# [07:53] <jdaggett> s/???/danield
# [07:54] <TabAtkins> 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.
# [07:56] <TabAtkins> 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.
# [07:56] <TabAtkins> 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.
# [07:56] <florian> s/georgian, for example, to transform to/georgian, or to/
# [07:56] * hober with text-transform: fullsize-kana & the Speech module I can implement my mother's pronounciation of きょうと as きようと. :)
# [08:00] <TabAtkins> Nat: This seems to be the sort of thing that *should* be happening in OpenType, properly.
# [08:00] <Bert> [Discussion about "fake" fullwidth greek and cyriliic, because there is no actual fullwidth greek and cyrillic in Unicode.]
# [08:01] <TabAtkins> Nat: That lets UAs do all this stylistic stuff without touching the underlying model.
# [08:01] <TabAtkins> szilles: But you can't do linebreaking as an opentype feature.
# [08:01] <TabAtkins> Nat: You can - you can't do linebreaking until you get glyphs.
# [08:01] <TabAtkins> fantasai: How do you know whether you're linebreaking these characters as fullwidth or halfwidth?
# [08:02] <TabAtkins> [possibly there was some confusion here, and fonts don't carry this information]
# [08:03] <TabAtkins> jdaggett: I don't fully understand the problem you try to solve.
# [08:03] <TabAtkins> jdaggett: I think putting behavior in text-transform that affects linebreaking, etc. is a really bad idea.
# [08:03] <TabAtkins> jdaggett: This is supposed to be simple.
# [08:04] * Quits: vhardy (vhardy@125.207.177.35) (Ping timeout)
# [08:04] <TabAtkins> Nat: Any of the transforms can have affects in some language and not in another.
# [08:04] <TabAtkins> jdaggett: I understand, but from a user perspective, these subtle effects seem hard to understand and conceptualize.
# [08:06] <TabAtkins> Nat: I think it would actually be hard for impls to do the fake characters without codepoints.
# [08:08] <TabAtkins> jdaggett: [something about font features existing for uppercasing, etc. that I didn't get]
# [08:13] <fantasai> fantasai: Why wouldn't you turn on uppercasing in the font when you have text-transform: uppercase?
# [08:13] <fantasai> 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
# [08:13] <fantasai> Bert: Wouldn't it make more sense to remove all fullwidth variants? It's a style issue isn't it?
# [08:14] <dbaron> fantasai: I agree with Bert; it seems more like a style issue rather than something that should be separate codepoints.
# [08:14] <dbaron> Nat: Get rid of the feature (text-transform) altogether and just use the font mechanism
# [08:17] <fantasai> This discussion is mostly unminuted because Tab gave up and didn't say so and didn't get a replacement
# [08:18] <dbaron> Florian: request for tr feature for removal of accents
# [08:18] <dbaron> 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
# [08:19] <dbaron> (discussion about whether it's right or wrong to drop accents when uppercasing in French)
# [08:19] <dbaron> Nat: sounds like the discussion about ruby
# [08:19] <dbaron> fantasai: Whether you can do this with 'tr' depends on whether you're NFC or NFD.
# [08:20] <dbaron> fantasai: Correct way to do it is probably do NFD and then remove the diacritics.
# [08:20] <dbaron> 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.
# [08:20] <dbaron> Steve: So this is actually a case that drives the tr solution because it is different for possibly each document.
# [08:21] <dbaron> Florian: Doesn't solve it universally, but tr is to solve it not universally.
# [08:21] <dbaron> Peter: I think going down that path is out of scope for this discussion.
# [08:21] <dbaron> Peter: Don't want to rathole into proposal for new features.
# [08:21] <dbaron> DanielD: What about calling fullsize-kana fullsize-ruby?
# [08:21] <dbaron> fantasai: No, it fullsizes the kana whether or not you're in ruby, though it is designed for ruby.
# [08:22] <dbaron> Sylvain: Some feedback from a colleague: why are a bunch of the properties optional? that's tricky from an interop standpoint
# [08:22] * Bert thinks, once CSS can import Perl modules, it will be simple to call Unicode::NFD, then remove all accents :-)
# [08:23] <dbaron> 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. "
# [08:23] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# [08:23] <dbaron> Sylvain: Require them? Not require them?
# [08:24] <dbaron> dbaron: removing them?
# [08:24] <dbaron> fantasai: Håkon wanted me to make things optional if they weren't required for all scripts.
# [08:24] * Joins: shans (qw3birc@128.30.52.28)
# [08:24] <dbaron> Sylvain: What is the use case for hyphens: all other than debugging?
# [08:24] <dbaron> Sylvain: I'd like to remove it.
# [08:24] <dbaron> fantasai: Anybody object?
# [08:25] <dbaron> Steve: The UA writer could have settings for that if desired.
# [08:25] <dbaron> Sylvain: Yep, doesn't need to go in style sheet.
# [08:25] <dbaron> Bert: I use show-hyphens in TeX a lot.
# [08:26] <dbaron> John: Do we implement all?
# [08:26] <dbaron> David: No, just none manual auto.
# [08:26] <dbaron> Sylvain: word-wrap: hyphenate? Interact with hyphens:none? How does that work?
# [08:26] <dbaron> fantasai: Only kicks in if there's no other break point on the line
# [08:27] <dbaron> fantasai: Alan suggested dropping that and using hyphenate-zone:100%
# [08:27] <dbaron> fantasai: word-wrap:hyphenate beats the hyphenation controls (hyphens:none)
# [08:27] <dbaron> Peter: ... but only to prevent overflow
# [08:27] <dbaron> Sylvain: What kind of hyphenation happens?
# [08:27] <dbaron> Steve: It's forcing a line break, not really hyphenation
# [08:27] <dbaron> fantasai: It's a forced line break at an appropriate hyphenation point
# [08:28] <dbaron> Alex: ... choice of break anywhere or refer to dictionary ...
# [08:29] <dbaron> (description of what's in the spec)
# [08:30] <dbaron> Steve: It's not just if it's turned off... there are other things that inhibit hyphenation.
# [08:30] <fantasai> Action: fantasai "even if hyphenation is turned off or otherwise restricted"
# [08:30] * trackbot noticed an ACTION. Trying to create it.
# [08:30] * RRSAgent records action 3
# [08:30] <trackbot> Created ACTION-323 - "even if hyphenation is turned off or otherwise restricted" [on Elika Etemad - due 2011-06-10].
# [08:31] <dbaron> Steve: If you say word-break, and hyphenation is on, are you allowed to hyphenate?
# [08:32] <dbaron> (discussion of what characters to use for "TeX"
# [08:32] <dbaron> )
# [08:32] <dbaron> Bert: Why is word-wrap not called emergency?
# [08:33] <dbaron> fantasai: widely implemented unprefixed
# [08:33] <dbaron> Mozilla implements word-wrap: normal | break-word
# [08:34] <dbaron> Peter: Bert has a point; you could add the standard name and keep implementing the nonstandard one
# [08:34] * Quits: nmccully (nmccully@125.207.177.35) (Quit: nmccully)
# [08:34] <dbaron> Sylvain: There's content depending on it.
# [08:34] <dbaron> Bert: Forget about the other one; it's not ours and we don't have to document it.
# [08:34] <dbaron> Bert: It's confusing to have word-wrap and text-wrap etc. and they don't do the same thing.
# [08:35] <dbaron> 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.
# [08:35] <dbaron> 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.
# [08:36] <dbaron> Florian: If your goal is interop, we do need to define how the thing everybody supports is actually supposed to work.
# [08:36] <dbaron> Steve: Also defining things that can get through CR in a reasonable amount of time.
# [08:36] <dbaron> Alex: We can say something is deprecated and define what it does.
# [08:36] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [08:36] <dbaron> Peter: I think there's a valid request to rename the property; do we want to do that?
# [08:37] <dbaron> Sylvain: The property or the value?
# [08:37] <dbaron> Peter: the property
# [08:37] * Joins: szilles (chatzilla@125.207.177.35)
# [08:37] <dbaron> fantasai: options are 'emergency-wrap' and 'word-wrap'
# [08:37] <dbaron> fantasai: word-wrap is implemented by 4 browsers
# [08:37] <dbaron> Steve: word-wrap seems fine
# [08:38] <dbaron> Bert: It's only a second level option
# [08:38] <dbaron> Peter: More of an overflow management property
# [08:38] <dbaron> Steve: 'overflow-wrap'
# [08:38] <dbaron> John: I don't like "emergency" at all.
# [08:38] <dbaron> Florian: If we're going to rename it, word overflow should be in there.
# [08:39] <dbaron> fantasai: Options: (1) keep as word-wrap (2) rename to overflow-wrap and document word-wrap as a deprecated alias
# [08:40] <fantasai> dbaron: Need to define what alias means.
# [08:40] <fantasai> dbaron: We have an aliasing mechanism for prefixed properties
# [08:40] <fantasai> dbaron:but it's a parse-time thing
# [08:40] <fantasai> dbaron: If we define an alias, we should make it clear that it's a parse-time thing
# [08:40] <fantasai> Alex: In object model there will be word-wrap and overflow-wrap?
# [08:40] * Joins: Ms2ger (Ms2ger@91.181.137.121)
# [08:41] <dbaron> dbaron: For us, word-wrap would not be exposed in the OM.
# [08:42] <dbaron> [Nat and Taro leave]
# [08:42] <fantasai> dbaron: It would break scripts
# [08:43] <fantasai> dbaron: I'm ok with that if it's not a long-term thing
# [08:43] <fantasai> dbaron: and we don't have situation where things only break in Gecko
# [08:44] <fantasai> Florian: Seems like switching names might be more trouble than it's worth
# [08:44] <fantasai> Bert: more trouble for implementers, but we're thinking about authors
# [08:44] <dbaron> dbaron: Actually, it does work for getPropertyValue() in Gecko, and we could make it work for CSS2Properties
# [08:45] <dbaron> Peter: For people who don't understand English, using more consistent terms is probably a good thing.
# [08:45] * Quits: jdaggett (jdaggett@125.207.177.35) (Quit: jdaggett)
# [08:45] <dbaron> Peter: Are we ok with option (2)?
# [08:45] <dbaron> Sylvain: Where do we define what alias means?
# [08:46] <dbaron> Sylvain: Difference between saying there's a deprecated property there saying that if you support that deprecated property it must be an alias.
# [08:46] * Quits: stearns (qw3birc@128.30.52.28) (Quit: Page closed)
# [08:47] <dbaron> Alex: [something about searching for things in Google]
# [08:48] <dbaron> Bert: I'm more concerned about people seeing the property name and finding that it doesn't do what they expect.
# [08:48] <dbaron> Peter: I've run into that.
# [08:48] <dbaron> Alex: overflow-hyphenate or hyphenate-overflow?
# [08:49] <dbaron> Florian: Put a note saying we're thinking about it? I'm not sure without talking to Opera implementors.
# [08:49] <dbaron> fantasai: I think we need feedback from WebKit and Opera implementors.
# [08:49] <dbaron> Peter: break until 4pm
# [09:06] <dbaron> ScribeNick: dbaron
# [09:06] <dbaron> Florian: Håkon was wondering if we can move 11.2 (emphasis marks) to the same spec as ruby
# [09:07] <dbaron> Florian: same interaction with line spacing
# [09:08] <dbaron> (time limit on text discussion set to 4:30pm)
# [09:09] <dbaron> 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.
# [09:09] <dbaron> Florian: The way it interacts with ruby needs to be described
# [09:09] <dbaron> Steve: Would Håkon like it better if we moved ruby to the text spec?
# [09:09] <dbaron> fantasai: Two problems: From an authoring perspective it's much more closely related to underlining, and the ruby spec needs a *lot* of work.
# [09:10] <dbaron> fantasai: Ruby is missing the box model for ruby; the only thing that needs to be defined is the interaction with line spacing; no need to worry about anonymous boxes, etc., which ruby is missing.
# [09:10] <dbaron> fantasai: Six months for the ruby spec would be optimistic; not many issues with text-emphasis.
# [09:10] <dbaron> fantasai: Only concern is line spacing.
# [09:11] <dbaron> Steve: i.e., the decision we made yesterday that it doesn't affect line spacing
# [09:11] <dbaron> fantasai: I think it should stay in the spec.
# [09:11] <dbaron> Florian: I think it was just a suggestion, not a strong request; I'm ok with that answer.
# [09:11] <dbaron> Florian: Håkon suggests dropping text-outline; text-shadow is rich enough
# [09:12] <dbaron> dbaron: Doesn't the addition of spread to text-shadow provide the same?
# [09:12] <dbaron> fantasai: you can get the same effect
# [09:13] <dbaron> Tab: What is done by text-outline that's not done by spread text-shadow?
# [09:13] <dbaron> fantasai: nothing I know of; we didn't have spread when text-outline was added
# [09:13] <dbaron> RESOLVED: drop text-outline
# [09:13] <dbaron> Florian: Either Håkon or I is confused about the hanging punctuation...
# [09:13] * Joins: vhardy (vhardy@192.150.10.201)
# [09:14] <dbaron> Florian: Håkon interpreted is a per-block.
# [09:14] <dbaron> fantasai: It's each edge of each line
# [09:14] <dbaron> 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.
# [09:15] <dbaron> Florian: Can we clarify the wording?
# [09:15] <dbaron> Florian: Was the image example of force-end added?
# [09:15] <dbaron> Florian: only if there is justification... or does it force justification?
# [09:15] <dbaron> fantasai reads from spec
# [09:16] <dbaron> Florian: Can we add the piece of CSS that caused the example to look the way it is... so the CSS has the justification
# [09:16] <dbaron> ACTION fantasai: Add CSS to the example
# [09:16] * trackbot noticed an ACTION. Trying to create it.
# [09:16] * RRSAgent records action 4
# [09:16] <trackbot> Created ACTION-324 - Add CSS to the example [on Elika Etemad - due 2011-06-10].
# [09:16] * Joins: alexmog (qw3birc@128.30.52.28)
# [09:16] <dbaron> Florian: Håkon: Instead of text-align-last I propose p::last-line
# [09:17] <dbaron> 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
# [09:17] <dbaron> Florian: Håkon proposes 'balance' as a new value for 'text-wrap' to prevent the last line from being too short.
# [09:18] <dbaron> 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.
# [09:18] <dbaron> Florian: This somewhat mirrors column-fill: balance
# [09:18] <dbaron> fantasai: But I want to push that to the next level of text.
# [09:18] <dbaron> Steve: I'd have interpreted balance (if comparable to columns) as something that makes all lines equal.
# [09:19] <dbaron> Florian: Håkon was thinking all or the last few
# [09:19] <dbaron> Steve: All is an expensive operation.
# [09:19] <dbaron> fantasai: I think we could consider if we have willing implementors
# [09:19] <dbaron> Steve: could list an issue that 'balance' has been proposed
# [09:19] <dbaron> fantasai: Not sure I'd stick it in 'text-wrap'.
# [09:19] <dbaron> Steve: Probably in justify
# [09:19] <dbaron> Steve: Really applying to the paragraph as a whole.
# [09:20] <dbaron> fantasai: You can have a centered paragraph with balanced lines.
# [09:20] <dbaron> Bert: I think implementations should do this automatically - try not to make the last line too short or to long.
# [09:20] * Joins: jdaggett (jdaggett@222.151.136.131)
# [09:20] <dbaron> fantasai: You usually don't want the whole paragraph to have equal lines
# [09:21] <dbaron> Bert: You don't want the last line too short *or* too long
# [09:21] <dbaron> Peter: Lots of other factors
# [09:21] <dbaron> fantasai: We can put this in the wiki for things for future levels.
# [09:21] <dbaron> Steve: There's a min length on last line proposal?
# [09:21] <dbaron> Florian: Håkon proposes text-ident: each-line
# [09:21] <dbaron> fantasai: That's in the spec already.
# [09:22] <dbaron> Florian: How about renaming it to after-break
# [09:22] <dbaron> fantasai: it's not just after-break; it's also at the start of the paragraph
# [09:22] <dbaron> fantasai: It's intended, e.g., for source code or poetry.
# [09:22] <dbaron> Florian: Håkon - I'm unsure if 'hanging' is needed given that negative values
# [09:23] <dbaron> fantasai: negative values put you in the padding; shouldn't have to match the padding to text indent
# [09:23] <dbaron> Florian: Last item from Håkon on 5.2 (word-break): this section should benefit from examples. (quoting)
# [09:23] <dbaron> Florian: ... suggest defining shaaping scripts in Appendix E. ... (reading)
# [09:24] <dbaron> (traffikkonstabel)
# [09:24] <dbaron> fantasai: Those things should be handled by the hyphenation engine, which should make appropriate spelling changes
# [09:24] <dbaron> fantasai: That note is saying that, after the hyphenation engine, that Arabic is still *shaped* as though word was not broken.
# [09:26] <dbaron> 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.
# [09:26] <dbaron> fantasai: Actually, I think we shouldn't specify the rule because it'll be wrong; better to give example.
# [09:26] <dbaron> Florian: That's the end of Håkon's issues.
# [09:26] <dbaron> fantasai: I propose dropping hyphenate-resource
# [09:26] <dbaron> Steve: Not now
# [09:27] <dbaron> fantasai: I'll do it when we request last call.
# [09:28] <fantasai> ScribeNick: fantasai
# [09:28] <fantasai> Discussion of what to discuss
# [09:31] * Quits: hober (ted@125.207.177.35) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [09:31] <fantasai> Topic: Charter
# [09:31] * Joins: hober (ted@125.207.177.35)
# [09:31] <jdaggett> who needs a charter...?
# [09:32] * fantasai waves to jdaggett
# [09:32] <Bert> -> http://www.w3.org/2010/09/CSSWG/charter.html draft charter
# [09:32] <fantasai> Bert: 3 questions
# [09:32] <fantasai> Bert: W3C Team looked at charter, esp list of modules
# [09:32] * Ms2ger suggests adding widgets
# [09:32] <fantasai> Bert: Maybe Chris forgot to fix things,
# [09:33] <fantasai> Bert: But wondering why Ruby Annotation REC is in the spec
# [09:33] <fantasai> Everybody agrees that should be removed
# [09:33] <fantasai> s/spec/charter/
# [09:33] <fantasai> Bert: Thinking to move JLREQ to Joint Work
# [09:34] <fantasai> Agreed
# [09:34] * jdaggett nods in agreement
# [09:34] <fantasai> Bert: It says CSS1 in Maintenance, but not CSS2.
# [09:34] <fantasai> Bert: CSS2 is not deprecated yet
# [09:34] <fantasai> fantasai: So let's deprecate it
# [09:34] <jdaggett> yes please
# [09:35] <fantasai> Bert: But is everything there in a CSS3 spec?
# [09:35] <fantasai> fantasai: well, the features there not in 2.1 are all in WDs
# [09:35] * jdaggett wonders what css3 fullscreen is...
# [09:35] <fantasai> fantasai: @font-face in the fonts spec, text-shadow in the CSS3 Text spec, list-styles in css3-lists
# [09:35] <fantasai> fantasai: And some things we're not interested pursuing, like display: compact
# [09:36] <fantasai> fantasai: display run-in needs to be put in css3-box spec...
# [09:36] <fantasai> dbaron: fullscreen is styling things that are in fullscreen presentation and some associated DOM APIs
# [09:36] <fantasai> dbaron: It says CSS UI is new when in fact it's in CR
# [09:36] <fantasai> Tab: we have UI3 and UI4
# [09:36] <fantasai> dbaron: oh, ok
# [09:37] <fantasai> RESOLUTION: List 2.0 as maintenance, asterisk saying to be obsoleted asap
# [09:37] <jdaggett> jdaggett: are we leaving priorites as is?
# [09:37] <fantasai> s/2.0/CSS 2.0/
# [09:37] <fantasai> dbaron: I'm a little worried about things being on the discontinued list
# [09:38] <fantasai> dbaron: I'm not sure what to call this draft, right now calling it Conditional Group Rules
# [09:38] <fantasai> dbaron: I pulled @media into it since it seemed to fit, and 2.1 only describes it in 2 lines
# [09:38] <fantasai> dbaron: Also includes @supports and @document
# [09:38] <fantasai> dbaron: It changes syntax by allowing @rules inside @media
# [09:39] <fantasai> 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
# [09:40] <fantasai> plinss: Need an item about regular snapshots, not just 2010
# [09:40] <fantasai> plinss: I also want paged media to move from low priority to medium
# [09:41] <fantasai> Alex: I want CSS3 Floats
# [09:41] * Joins: nmccully (nmccully@114.51.64.187)
# [09:41] <jdaggett> jdaggett: line layout should be medium, not low
# [09:41] <fantasai> Alex: Floats and Exclusions
# [09:42] <fantasai> discussion of some positioning modules
# [09:42] <fantasai> no objection to line layout at medium
# [09:42] <jdaggett> yay
# [09:43] <fantasai> fantasai: maybe we should move Positioned Layout to low, since I'm not sure we'll get to LC in 2 years
# [09:43] <fantasai> Tab: fine with that
# [09:43] <fantasai> Alex: Can we work on things in 2.1?
# [09:44] <Bert> -> http://www.w3.org/Graphics/SVG/WG/charter/2010/Overview.html SVG draft charter
# [09:44] <fantasai> Bert: Charter allows us to work on anything as long as within scope for CSS
# [09:44] <fantasai> Bert: SVG draft charter has some overlap with us via the task force
# [09:45] <fantasai> Bert: We should make sure their high priority items match our high-priority items
# [09:45] <fantasai> Bert: SVG charter notes things that are supposed to be joint work
# [09:45] <fantasai> Bert: Do we agree with all of those?
# [09:46] <fantasai> Vincent: There is CSS animations and Web animations, some consideration of making them consistent
# [09:46] <fantasai> Vincent: Does that need to be a work item?
# [09:46] <fantasai> Vincent: Related to transforms, there are 3 specs for that
# [09:46] <fantasai> Vincent: I think the goal for everybody is to work on FX taskforce spec
# [09:46] <fantasai> Vincent: focus on convergence part
# [09:47] <fantasai> Bert: Our charter mentions SVG in 2 places, joint work for filters and masking
# [09:47] * Quits: nmccully (nmccully@114.51.64.187) (Connection reset by peer)
# [09:47] <fantasai> Bert: Then the coordination section, which mentions ....
# [09:47] * Joins: nmccully (nmccully@114.51.194.148)
# [09:47] <fantasai> s/coordination/dependencies/
# [09:48] <fantasai> Vincent makes a suggestion about a table or something
# [09:49] <fantasai> Vincent: Cameron was listing filters, compositing as something to work with CSSWG
# [09:49] <fantasai> Vincent: Makes sense to coordinate
# [09:49] <fantasai> Vincent: Others were gradients, 2D, 3D transofrms, and web animations
# [09:49] <fantasai> Vincent: I think all topics are touched on in charters except compositing
# [09:49] <fantasai> Vincent: And from my end, only question is that we're clear on which spec we're working on
# [09:50] <fantasai> Vincent: In some cases there's CSS spec, SVG spec, joint spec. Clear which one we're focused on
# [09:50] * Quits: nmccully (nmccully@114.51.194.148) (Ping timeout)
# [09:50] <fantasai> Bert: I think we're out of charter officially, so shouldn't take too long to finish this
# [09:51] <fantasai> fantasai: Who's editing the charter?
# [09:52] <fantasai> Bert: Chris? Not sure if he can
# [09:52] * Joins: konaya (konaya@83.251.16.72)
# [09:52] <fantasai> ACTION: Bert edit charter per notes above
# [09:52] * trackbot noticed an ACTION. Trying to create it.
# [09:52] * RRSAgent records action 5
# [09:52] <trackbot> Created ACTION-325 - Edit charter per notes above [on Bert Bos - due 2011-06-10].
# [09:53] <fantasai> plinss: Anything else on Charter?
# [09:54] <fantasai> Topic: Regions and Exclusions
# [09:56] * Quits: vhardy (vhardy@192.150.10.201) (Ping timeout)
# [09:56] * Joins: nmccully (nmccully@114.51.86.41)
# [09:56] <fantasai> Vincent: So on the regions status, we have 2 documents css regions and css exclusions
# [09:56] <fantasai> Vincent: For regions last we had a resolution during the concall to publish a WD
# [09:57] <fantasai> Vincent: When the updated eidtor's draft would be updated with comments incorporated.
# [09:57] <fantasai> Vincent: I sent that earlier this week
# [09:57] <fantasai> Vincent: Includes comments
# [09:57] <fantasai> Vincent: Everything that happend until the WG resolution to publish is in the draft
# [09:57] <fantasai> Vincent: Next step is to publish the WD
# [09:57] <fantasai> Vincent: And discuss issues and resolve and prepare next WD
# [09:57] <fantasai> Vincent: Think that's pretty much what we need to do
# [09:58] <fantasai> Vincent: For Exclusions we went from original spec and split regions from exclusions
# [09:58] <fantasai> Vincent: MS has alternate proposal called CSS3 Floats.
# [09:58] <fantasai> Vincent: Plan is to merge spec
# [09:58] <fantasai> Vincent: I'm happy to work with whoever wants to work on it
# [09:58] <fantasai> Vincent: Scope right now for exclusions, there's issue of laying out content into arbitrary shape
# [09:59] <fantasai> Vincent: Second issue is wrap around an arbitrary shape
# [09:59] <fantasai> Vincent: THen there's extension to float model and positioning scheme
# [09:59] <fantasai> Vincent: positioning floats with more flexibility
# [09:59] <fantasai> Vincent: Make float have arbitrary shape
# [09:59] <fantasai> Vincent: That's scope for current proposal
# [09:59] <fantasai> Vincent: SOme of those issues are orthogonal to each other
# [10:00] <fantasai> Vincent: My rpoposal 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
# [10:00] <fantasai> 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
# [10:00] <fantasai> Florian: or override others
# [10:00] <fantasai> Alex: Neither we nor Adobe is planning to deprecate GCPM floats, unless other floats do everything in GCPM floats
# [10:01] <fantasai> 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
# [10:01] <fantasai> Alex: We have new language for exclusions, e.g., we'll have difficult time merging together
# [10:01] <fantasai> Alex: Better to put them together now
# [10:01] <fantasai> fantasai: And merge with CSS2.1 floats and clearance
# [10:02] <fantasai> Alex: In our draft we said, we had extension to CSS positioning
# [10:02] <fantasai> Alex: There are number of pages, but one value that we wnat to add which is position: page, position thing relative to apge
# [10:02] <fantasai> Alex: Not sure it's worth creating a spec for just that value, but it should go somewhere
# [10:02] <fantasai> Alex: One approach could be to create a CSS3 Positioning spec, that includes abspos and all kinds of positioning from 2.1
# [10:03] <fantasai> Alex: Have an effort to make CSS2 positioning better defined
# [10:03] <fantasai> Alex: Arron is interested in that
# [10:03] <dbaron> (e.g., top/left/right/bottom: auto)
# [10:03] <fantasai> Alex: Not going to volunteer Arron to edit spec, but he was interested in that spec
# [10:03] <fantasai> s/spec/activity/
# [10:03] <fantasai> Alex: And having that spec
# [10:04] <fantasai> Tab: I'd be happy to take Arron on as co-editor, that'd be fun
# [10:04] <fantasai> Vincent: Should we have a resolution to move forward with new draft that includes all current proposals and has scope that we described.
# [10:04] <fantasai> Slid:
# [10:04] <fantasai> * content arbitrary shapes
# [10:04] <fantasai> * exclusions arbitrary shapes
# [10:04] <fantasai> * expanded float model
# [10:04] <fantasai> * expanded float positioning model
# [10:05] <fantasai> fantasai: Not sure about what you have on the slide, but what you said earlier sounds good to me
# [10:06] <fantasai> RESOLVED: Make this spec as css3-floats
# [10:07] <alexmog> http://www.interoperabilitybridges.com/css3-floats/
# [10:08] <fantasai> Vincent asks about publishing css3-regions
# [10:08] <fantasai> ACTION: Bert publish css3-regions as FPWD
# [10:08] * trackbot noticed an ACTION. Trying to create it.
# [10:08] * RRSAgent records action 6
# [10:08] <trackbot> Created ACTION-326 - Publish css3-regions as FPWD [on Bert Bos - due 2011-06-10].
# [10:09] <fantasai> dbaron: This stuff seems scary. Scarier than GCPM stuff.
# [10:10] <fantasai> dbaron: Just the notion of what flows around what, and not knowing what floats you're going to have to flow around...
# [10:10] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [10:10] <fantasai> Alex: Yes, it is scary.
# [10:10] <fantasai> Steve: That's what I think is the hardest part. Kindof like compositing. Have to define what makes up an entity
# [10:10] <fantasai> Steve: When we were discussing this in February, there was ... interactions of floats from Apple
# [10:11] <fantasai> Vincent: Right now just asking to merge into new proposal. Not even asking to move to WD.
# [10:11] <fantasai> Murakami-san: I have one quesiton about CSS3 Floats
# [10:11] <fantasai> Murakami-san: CSS3 Floats contains multicol floats, that spans multiple colu,mns
# [10:11] <fantasai> Murakami-san: That's now in GCPM
# [10:13] <fantasai> fantasai: We might consider splitting these into CSS3 and CSS4 later, once they're merged and made consistent
# [10:13] <fantasai> dbaron: I'm concerned that we're working on too many big layout systems all at once
# [10:13] <fantasai> dbaron: I'd rather get flexbox and grid and vertical text done first
# [10:13] <fantasai> Steve: I think the reason to do them simultaneously is to make sure we understand the interactions
# [10:14] <fantasai> dbaron: exclusions I'm ok with, it's the positioned floats I'm concerned about
# [10:14] <fantasai> Steve: exclusions are just positioned float
# [10:14] <fantasai> dbaron: It feels like a pretty big difference to me. Maybe I just don't understand
# [10:14] <fantasai> Alex: Maybe you didn't read exclusions carefully enough
# [10:15] <fantasai> dbaron: Exclusions seems clear about what you're applying the exclusions to and where it's coming from
# [10:15] * Quits: nmccully (nmccully@114.51.86.41) (Client exited)
# [10:15] <fantasai> Vincent: My suggestion would be to put the new draft together..
# [10:15] * Quits: jdaggett (jdaggett@222.151.136.131) (Quit: jdaggett)
# [10:15] <fantasai> 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
# [10:15] <fantasai> Vincent: Another feature is positioned floats, which you're concerned about
# [10:15] <fantasai> Vincent: I think there are various issues and they're not all as objectionable
# [10:16] <fantasai> dbaron: I can see some ways to define positioned floats that aren't so horrible
# [10:16] <fantasai> Steve: My understanding of Alex's use of float is an object that intrudes on other object
# [10:16] * Joins: nmccully (nmccully@114.51.86.41)
# [10:16] <fantasai> 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
# [10:17] <fantasai> dbaron: It also means that floats obey invariants wrt document order wrt other floats
# [10:17] <fantasai> dbaron: This makes it relatively easy. And by relatively easy, I mean one of the most complicated pieces of code in a layout engine.
# [10:17] <fantasai> dbaron: ... dynamically ..
# [10:18] <fantasai> 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
# [10:18] <fantasai> dbaron: or you have floats affecting stuff before it
# [10:18] <fantasai> Alex: Can affect things before in document order, regarding what exactly the dfinition is, that's going to happen
# [10:18] <fantasai> 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
# [10:19] <fantasai> Alex: But since it still does that, it's either GCPM floats that goes to top right of page, or exclusions, or
# [10:19] <fantasai> Alex: The dependency backwards is going to exist.
# [10:19] * Joins: nmccully_ (nmccully@114.51.69.159)
# [10:19] * Quits: nmccully (nmccully@114.51.86.41) (Ping timeout)
# [10:19] * nmccully_ is now known as nmccully
# [10:19] <fantasai> dbaron: Part if it is that I really really don't like the absolute positioning model for layout.
# [10:20] <fantasai> dbaron: I prefer Grid Layout
# [10:21] <fantasai> Vincent: Are there topics for regions and exclusions..
# [10:21] <fantasai> Vincent: Here are the issues I have on the table
# [10:21] <fantasai> Slide:
# [10:21] <fantasai> - intrinsic sizing: height: 0 as well as width:0
# [10:21] <fantasai> - auto-sizing and containing blocks
# [10:21] * Joins: nmccully_ (nmccully@114.51.11.152)
# [10:21] <fantasai> - breaking rules and alignment with paged media and multicol
# [10:21] <fantasai> - integration with css grid layout and multicol
# [10:21] <fantasai> -regions
# [10:22] <fantasai> styling
# [10:22] <fantasai> Vincent: ? had some use cases for [something]
# [10:22] <fantasai> Vincent: A lot of issues raised in CSS Regions exist already in paged media and sometimes in multicol
# [10:22] <fantasai> Vincent: Something I'd like to talk about during this meeting
# [10:22] * Quits: nmccully (nmccully@114.51.69.159) (Ping timeout)
# [10:22] * nmccully_ is now known as nmccully
# [10:22] <fantasai> Vincent: Another thing Steve mentioned is interdependencies with other specs, namely grid layout and multicol
# [10:22] <fantasai> Vincent: Would be nice to make this work with grid layout and multicol
# [10:23] <fantasai> Vincent: Some small things to do, integration
# [10:23] <fantasai> Vincent: E.g. addressing grid cell and display values
# [10:23] <fantasai> Vincent: Multicol doesn't have a way to address a column box, will be needed to make it a region
# [10:23] <fantasai> Vincent: Have a demo of an implementation, one in Webkit and one scripted impl of that
# [10:23] <fantasai> Vincent: Still a lot of concerns about it
# [10:23] <fantasai> Bert: By regions styling, you mean not just background, but also the content of it?
# [10:24] <dbaron> http://dev.w3.org/csswg/css3-exclusions/
# [10:24] <dbaron> http://www.interoperabilitybridges.com/css3-floats/
# [10:24] <fantasai> fantasai: If you're going to do that, please also write the spec for ::first-line
# [10:24] <fantasai> Vincent shows an example
# [10:29] <fantasai> Vincent: So those are the larger issues.
# [10:29] <fantasai> Vincent: Smaller issues
# [10:29] <fantasai> - CSSOM View extensions
# [10:30] <fantasai> - content-order: <number> or <integer>
# [10:30] <fantasai> ...
# [10:30] <fantasai> Vincent: If you look at printed content, you get different widths
# [10:30] <fantasai> Vincent: We actually break down that content, and split boxes, and they find themselves in varying size container boxes
# [10:30] <fantasai> Vincent: Regions make that very obvious, you really ned to work that out
# [10:30] <fantasai> Vincent: Issue of writing content from page to page is the same
# [10:31] <fantasai> vincent: also projection in the specs, at least in all Iv'e ben able to find, it refers to pages
# [10:31] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [10:31] <fantasai> 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
# [10:31] <fantasai> VIncent: conceptually some implementers do it this way, those are kindof regions and you lay out content between regions that way
# [10:32] <fantasai> Vincent: multicol is another example of the same issue, you break down content into set of containers. Regions is a variation on that
# [10:32] <fantasai> Vincent: It's still the same concept of having on one hand content that needs to flow and of having different regions
# [10:32] <fantasai> the chain of regions to flow content into
# [10:32] <fantasai> Vincent: And then the difference...
# [10:33] <fantasai> Steve Point being that there are a chained set of areas into which a continuous chunk of content is distributed
# [10:33] <fantasai> in all of the regions
# [10:33] <fantasai> plinss: The issue with all this is that we've punted on different-width containers, and we can't do that anymore
# [10:34] <fantasai> Vincent: Shared issues with all these models are the natural breaking rules, this is common between columns and pages and regions
# [10:34] <fantasai> Bert: There are some differences where breaks between columns can be less bad than between pages
# [10:35] <fantasai> plinss: Interesitng thing with region is wide region, then other region, looks like columns
# [10:35] <fantasai> plinss: might want different breaking depending on what type of regions you're breaking between
# [10:36] <fantasai> Vincent: Issue of forced breaks, that we should treat as overall in general how does that work, for pages columns etc.
# [10:36] <fantasai> Vincent: talked about varying widht container boxes for pages and regions
# [10:36] <fantasai> Vincent: Region-based styling, should address it also for multicol etc. if we address it
# [10:37] <fantasai> fantasai is deeply concerned about the number of tests that this will all require
# [10:38] <fantasai> Vincent: Alan Stearns is working on that
# [10:38] <fantasai> plinss: Breaking text flow is easy, floats and tables are hard
# [10:38] <fantasai> dbaron: In theory you have that problem for multiple page sizes as well
# [10:39] <fantasai> plinss: goes back to my point
# [10:40] <fantasai> 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?
# [10:40] <fantasai> Alex: no good answer to that.
# [10:40] <fantasai> 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
# [10:40] <fantasai> Alex: So that the table remains the same width on all pages
# [10:41] <fantasai> 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
# [10:41] <fantasai> Alex: So we need to experiment
# [10:41] <fantasai> Steve: XSL has this property for a long time, do you implement it
# [10:41] <fantasai> Murakami-san: Yes, we implemented XSL:FO
# [10:42] <fantasai> Murakami-san: With multiple regions with multiple, the region width is changed when the page is changed. That requires reformatting process.
# [10:42] <fantasai> Murakami-san: It's not very important for our product, but I think it's hard to browsers that requires processing speed.
# [10:42] <fantasai> Steve: To summarize, it's doable but expensive
# [10:42] <fantasai> Murakami-san: We do expensive formatting.
# [10:42] <fantasai> Alex: I'm not convinced it's doable.
# [10:43] <fantasai> Alex: I'm convinced there is no optimal solution that will work, we'll have to come up with some kind of compromise
# [10:43] <fantasai> Vincent: One thing that would be useful for moving along
# [10:43] <fantasai> Vincent: you were mentioning multicol
# [10:43] <fantasai> Vincent: On the float-breaking rules section..
# [10:43] <fantasai> Vincent: I took the CSS2.1 precedent and modified wording to accomodate regions
# [10:43] <fantasai> Vincent: I know we need to make all these things work together
# [10:43] <fantasai> Vincent: One was the breaking rules. Tlaks about breaking properties
# [10:43] <fantasai> Vincent: Orphans and widows etc.
# [10:44] <fantasai> VIncent: fallback. I tihnk this needs to be reconciled and put in that spec or somewhere else
# [10:44] <fantasai> Vincent: Talk about all cases where we have that issue
# [10:45] * Quits: nmccully (nmccully@114.51.11.152) (Ping timeout)
# [10:46] <fantasai> Vincent: 2 sections that are important here are the breaking rules and the breaking properties
# [10:46] <fantasai> Steve: By breaking properties do you include widows and rophans?
# [10:46] <fantasai> Vincent: yes
# [10:46] <fantasai> Alex: decision to be made here, does this belong in regions spec, or should it be a separate spec?
# [10:46] <fantasai> fantasai: separate spec
# [10:46] <fantasai> fantasai: affets columns pages equally
# [10:47] <fantasai> dbaron: I think the worst cases for breaking are actually abspos
# [10:47] <fantasai> Steve: Something has to be decided what they mean
# [10:47] <fantasai> dbaron: the others I can come up with something reasonable, but abpos I have no idea what they should do
# [10:47] <fantasai> Alex: Maybe resolve right now that we come up with a name for breaks or breaking spec?
# [10:48] <fantasai> discussion of specs
# [10:49] <fantasai> Steve: How about we stick it in Regions until we have a place to split it out into
# [10:49] <fantasai> fantasai: make a separate section, note it will be split out later
# [10:50] <fantasai> Alex: What's a page?
# [10:50] <fantasai> (discussiong page break values)
# [10:52] <fantasai> Alex: With regions there's no way to tell which of the hierarchy of regions is the page
# [10:52] <fantasai> Alex: Can have regions within pages, regions that span pages
# [10:53] <fantasai> Alex: region needs to understand that this region is on one page, that region is on another page
# [10:53] <fantasai> Alex: Need to come up with a way of communicate that information to layout
# [10:53] <fantasai> Alex: region on one page, next region on another page
# [10:54] <fantasai> Alex: we have scenario where column break vs page break makes sense from design point of view
# [10:54] <fantasai> Alex: I'm not sure I can come up with a compelling scenario where a region break vs page break is important to have
# [10:55] <fantasai> Alex: Vincent has scenario where we create columns by creating regions, in which case a region break is a column break but then
# [10:55] <fantasai> Alex: a page break is a higher-level break
# [10:55] <fantasai> Steve: Example Vincent shows, when he reduced point size of styled regions, the heading at the top of the previous column
# [10:55] <fantasai> Steve: And that's where you'd want a region break
# [10:57] <fantasai> ...
# [10:57] <fantasai> Alex: You can have regions within columns. is the column break smaller or larger than the region?
# [10:57] <fantasai> fantasai: could be either
# [10:57] <fantasai> fantasai gives pathological example
# [10:58] <fantasai> Vincent: There's clearly issues with breaks
# [10:58] <fantasai> Vincent: I think there's odd cases we should clarify what happens
# [10:58] <fantasai> alex: Nothing to guarantee that the sequence of regions and sequence of pages are going in the same directions.
# [10:58] <fantasai> Alex: Could have region 1 on page 2, region 2 on page 1, and region 3 on page 3
# [10:58] * Joins: nmccully (nmccully@114.51.157.146)
# [10:59] <fantasai> Steve: Question of how you would do that.
# [10:59] <fantasai> 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.
# [10:59] <fantasai> Steve: That's why page templates were separate from content, and rules for how to cchoose a new page template as you walk down the content.
# [11:00] <fantasai> Steve: Basically oyou can't use named regions b/c you don't know the names of the generated regions are (?)
# [11:00] <fantasai> Steve: You need to be able to refer to the next instance in this whole thing.
# [11:01] <fantasai> ....
# [11:01] <fantasai> Alex: this is more complicated than I thought :)
# [11:02] * Quits: nmccully (nmccully@114.51.157.146) (Client exited)
# [11:02] <fantasai> Vincent: There is a concept of a set of regions in which you're going to flow content, and that's nested
# [11:02] * Joins: nmccully (nmccully@114.51.157.146)
# [11:02] <fantasai> Vincent: The variations as we said before is, sometimes you will actually generate regions as you go due to a template
# [11:02] <fantasai> Vincent: YOu have that as an option
# [11:02] <fantasai> (fantasai explained how to do a page break in alex's pathological case)
# [11:03] <fantasai> Steve explains fantasai's example
# [11:04] <fantasai> ACTION: fantasai define pagination behavior across different-sized pages
# [11:04] * trackbot noticed an ACTION. Trying to create it.
# [11:04] * RRSAgent records action 7
# [11:04] <trackbot> Created ACTION-327 - Define pagination behavior across different-sized pages [on Elika Etemad - due 2011-06-10].
# [11:04] <fantasai> Steve: To summarize,
# [11:04] <dbaron> (how to handle pagination of abs-pos with left:auto is fun)
# [11:05] <fantasai> Steve: There needs to be a mechanism for indicating intended containment structure if you're going to define interaction between breaks in container levels
# [11:05] <fantasai> Steve: Pages and columns, we know that columns have to be within pages. But with regions we don't know that.
# [11:06] <fantasai> fantasai is not so sure that this is needed
# [11:06] <fantasai> Alex proposes something about using the CSSOM
# [11:07] <fantasai> Alex: How do you define a next page? Where do these pages come from?
# [11:07] * Quits: nmccully (nmccully@114.51.157.146) (Ping timeout)
# [11:07] <fantasai> Alex: We don't have a generic templating mechanism. don't know how soon or if ever we'll define that in CSS
# [11:07] <fantasai> Alex: Ppl are going to be really creative in what they're going to use
# [11:07] <fantasai> Alex: Best we can do is give them CSSOM to let them figure out what the content wanted there.
# [11:08] <fantasai> Alex: Where is that page template coming from?
# [11:08] <fantasai> Alex: If we add that object model to regions.. add .. to regions
# [11:08] <fantasai> Alex: There was a request for page size, page name
# [11:08] <fantasai> Alex: That will be way for somebody to write code that kind of thing.
# [11:08] <fantasai> Steve: That's one way of capturing intended
# [11:08] <fantasai> Steve: region break separate from page break
# [11:08] <fantasai> s/Steve/Alex/
# [11:09] <fantasai> Vincent: Containment model, I could take that action item
# [11:10] <fantasai> fantasai: with multicol, you can reasonably assume that a col break wants to break the innermost column box
# [11:10] <fantasai> fantasai: not so with regions
# [11:11] <fantasai> Vincent explains example of multicol with headers that break across pages
# [11:11] <fantasai> Vincent: Maybe tomorrow we could take smaller ones? Probably can be sorted pretty quickly
# [11:13] <fantasai> Meeting closed
# [11:13] * Quits: hober (ted@125.207.177.35) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [11:13] <fantasai> RRSAgent: make logs public
# [11:13] <RRSAgent> I have made the request, fantasai
# [11:13] <fantasai> RRSAgent: pointer
# [11:13] <RRSAgent> See http://www.w3.org/2011/06/03-css-irc#T09-09-59
# [11:13] * Joins: szilles (chatzilla@125.207.177.35)
# [11:13] * Quits: boblet (Adium@125.207.177.35) (Quit: Leaving.)
# [11:13] * Parts: danield (danield@125.207.177.35)
# [11:13] * Quits: plinss (plinss@125.207.177.35) (Quit: plinss)
# [11:14] * Quits: sylvaing (sylvaing@125.207.177.35) (Quit: sylvaing)
# [11:14] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [11:15] * Quits: florian (florianr@58.1.224.28) (Ping timeout)
# [11:16] * Quits: szilles (chatzilla@125.207.177.35) (Ping timeout)
# [11:16] * Quits: dbaron (dbaron@125.207.177.35) (Connection reset by peer)
# [11:16] * Joins: kojiishi_ (kojiishi@125.207.177.35)
# [11:17] * Joins: dbaron (dbaron@125.207.177.35)
# [11:17] * Quits: kojiishi (kojiishi@125.207.177.35) (Ping timeout)
# [11:17] * Quits: macpherson (qw3birc@128.30.52.28) (Ping timeout)
# [11:17] * Quits: shans (qw3birc@128.30.52.28) (Ping timeout)
# [11:17] * Quits: TabAtkins (tabatkins@125.207.177.35) (Ping timeout)
# [11:21] * Quits: dbaron (dbaron@125.207.177.35) (Ping timeout)
# [11:21] * Quits: kojiishi_ (kojiishi@125.207.177.35) (Ping timeout)
# [11:21] * Quits: myakura (d2e8220d@78.129.202.38) (Quit: http://www.mibbit.com ajax IRC Client)
# [11:22] * Parts: futhark (rune@213.236.208.22)
# [11:38] * Joins: konaya (konaya@83.251.16.72)
# [12:16] * Quits: homata (homata@58.158.182.50) (Ping timeout)
# [12:24] * Joins: homata (homata@58.158.182.50)
# [12:43] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# [12:45] * Joins: myakura (myakura@118.111.219.27)
# [13:44] * Quits: arron (Arron@24.17.123.244) (Quit: arron)
# [13:51] * Joins: karl (karlcow@128.30.54.58)
# [14:14] * Quits: myakura (myakura@118.111.219.27) (Client exited)
# [15:13] * Joins: szilles (chatzilla@219.127.245.113)
# [15:29] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [15:30] * Joins: plinss (plinss@61.214.117.102)
# [15:30] * Joins: szilles (chatzilla@219.127.245.113)
# [15:39] * Joins: dbaron (dbaron@222.151.136.131)
# [15:47] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# [15:56] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
# [16:12] * Joins: nmccully (nmccully@124.144.75.245)
# [16:14] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
# [16:19] * Quits: dbaron (dbaron@222.151.136.131) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [16:21] * Quits: konaya (konaya@83.251.16.72) (Ping timeout)
# [16:34] * Joins: nmccully (nmccully@124.144.75.245)
# [16:39] * Joins: boblet (Adium@122.27.197.150)
# [16:49] * Quits: boblet (Adium@122.27.197.150) (Quit: Leaving.)
# [17:00] * Quits: nmccully (nmccully@124.144.75.245) (Client exited)
# [17:00] * Joins: nmccully (nmccully@124.144.75.245)
# [17:27] * shepazu is now known as shepazu_vacation
# [17:30] * Joins: arronei_ (arron.eich@131.107.0.87)
# [17:31] * Quits: arronei (arron.eich@131.107.0.115) (Ping timeout)
# [18:17] * Joins: myakura (myakura@118.111.219.27)
# [18:21] * Joins: konaya (konaya@83.250.39.172)
# [18:31] * Joins: boblet (Adium@122.27.197.150)
# [18:31] * Parts: boblet (Adium@122.27.197.150)
# [19:38] * Quits: myakura (myakura@118.111.219.27) (Client exited)
# [20:37] * Joins: arno (arno@192.150.10.200)
# [20:43] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [20:50] * Joins: arno (arno@192.150.10.201)
# [21:17] * Quits: Ms2ger (Ms2ger@91.181.137.121) (Quit: nn)
# [22:01] * Quits: arno (arno@192.150.10.201) (Ping timeout)
# [22:49] * Joins: arno (arno@192.150.10.201)
# [23:14] * Quits: arno (arno@192.150.10.201) (Ping timeout)
# [23:42] * Joins: szilles (chatzilla@219.127.245.113)
# [23:53] * Quits: szilles (chatzilla@219.127.245.113) (Ping timeout)
# Session Close: Sat Jun 04 00:00:00 2011

The end :)