IRC log of css on 2011-06-03

Timestamps are in UTC.

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