/irc-logs / w3c / #css / 2013-02-05 / end

Options:

# Session Start: Tue Feb 05 00:00:00 2013
# Session Ident: #css
# [00:00] <sylvaing> florian, we already have concrete proposals. some of them are even implemented. last, i don't understand the need to rush this. confusion and lack of consensus are not good reasons to speed up
# [00:03] * Joins: mollyholzschlag (~mholzsch@public.cloak)
# [00:04] <florian> sylvaing, Point taken. It is a bit harder to read the mood of the wg via irc, so I'll use that as an excuse.
# [00:08] * plinss_away is now known as plinss
# [00:12] * florian falls asleep
# [00:16] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
# [00:20] * Joins: plinss_ (~plinss@public.cloak)
# [00:20] * Quits: tantek (~tantek@public.cloak) (Client closed connection)
# [00:21] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
# [00:22] <dbaron> sylvaing, do you have animations issues you want us to talk about?
# [00:23] <sylvaing> the main one for a f2f is the ongoing discussion about animations in the cascade
# [00:23] <sylvaing> I believe the action was on dean to explain WebKit's model?
# [00:23] <fantasai> TabAtkins, see also http://lists.w3.org/Archives/Public/www-style/2008Mar/0308.html
# [00:23] <dbaron> sylvaing, we'll have jdaggett's microphone/speaker device tomorrow, but we don't have it today
# [00:24] <dbaron> sylvaing, so we're inclined to postpone any call-in things to tomorrow/Wednesday
# [00:24] <sylvaing> fine by me
# [00:24] <TabAtkins_> ScribeNick: TabAtkins_
# [00:25] * Joins: glazou (~glazou@public.cloak)
# [00:25] <TabAtkins_> Rossen: We resolved to drop background-repeat:space from level 3.
# [00:25] <TabAtkins_> Rossen: But that's something that IE and Opera actually support.
# [00:25] <TabAtkins_> Rossen: I was looking at border-image-repeat, which we dont' support.
# [00:25] <TabAtkins_> Rossen: So I'd like to separate the issue. I'm okay with dropping the border-image-repeat, but not background-image-repeat.
# [00:25] * mollyholzschlag remember we break at 5PM AZ time tomorrow, 4PM CA/WA/OR time
# [00:26] <TabAtkins_> Bert: I think both of them do "the right thing" - the background is spaced to the edges, border-image is away from the edges. Both cases are "the right thing", but they're inconsistent.
# [00:26] <TabAtkins_> fantasai: That's probably alright.
# [00:26] <TabAtkins_> plinss: So do we still want to drop the border-image value? Or mark it as at-risk?
# [00:27] <dbaron> Bert: the more we keep, the better
# [00:27] <dbaron> dbaron: the more we drop, the better
# [00:27] <TabAtkins_> Rossen: We have three impls, actually - webkit does background-repeat:space too.
# [00:28] * Joins: tantek (~tantek@public.cloak)
# [00:28] <TabAtkins_> Rossen: If dropping it is done simply to move the spec forward, I'm for it.
# [00:28] <TabAtkins_> Rossen: But I don't see a reason to drop the already-implemented part.
# [00:28] * sylvaing with three implementations we should be renaming, not dropping....*cough*
# [00:29] * fantasai we could rename it to space-between, to be consistent with flexbox :)
# [00:29] <TabAtkins_> fantasai: We could mark it at-risk
# [00:29] <TabAtkins_> plinss: Andn put the reasons in the spec.
# [00:29] * sylvaing fantasai, wait to teach me about trolling...
# [00:29] <TabAtkins_> s/space-between/space-around/
# [00:30] * TabAtkins_ It was for border-image-repeat. ^_^
# [00:30] * sylvaing ah, never mind then. rock on with your bad selves
# [00:30] <TabAtkins_> RESOLVED: Keep background-repeat:space, drop border-image-repeat:space.
# [00:33] <fantasai> Topic: Tab Atkins presents fantasai's crazy proposal from the break wrt placeholder styling
# [00:33] <TabAtkins_> s/crazy//
# [00:33] <fantasai> TabAtkins: Idea was to do the placeholder pseudo-class, do fill-opacity, and ignore the rest of it for later
# [00:33] <fantasai> TabAtkins: Those two would solve all the problems we have right now.
# [00:33] <fantasai> dbaron: How do you just "do" fill-opacity?
# [00:33] <fantasai> dbaron: One of the questions wrt fill-opacity is, if we eventually do fill and fill-opacity for text,
# [00:33] * Joins: liam (liam@public.cloak)
# [00:33] <fantasai> dbaron: presumably there's some tradeoff where in some cases we do the color property, and others use text
# [00:34] <fantasai> TabAtkins: No, we just always use 'fill', and 'fill' defaults to 'currentColor'. SVG is already OK with adding a UA style rule setting it to black for SVG elements.
# [00:34] <fantasai> fantasai: It would default to black, but initial value would be currentColor.
# [00:35] <stearns> if we do weird things for :placeholder pseudo-class, will there then be an expectation that this hack should work for other pseudo-classes?
# [00:35] <fantasai> dbaron: we don't even know if the new inheriting behavior of currentColor is Web-compatible.
# [00:35] * Quits: mollyholzschlag (~mholzsch@public.cloak) ("sleeping computer is sleeping")
# [00:36] <fantasai> TabAtkins: Could fix it in 'fill' in multiple ways. Could use 'auto' as the initial value. If necessary.
# [00:36] <fantasai> TabAtkins: But don't have to worry about 'fill' right now. Just have to know there's a path forward. And deal with 'fill-opacity' now.
# [00:36] <fantasai> dbaron: If we don't do that model, and we have a different one where...
# [00:37] <fantasai> dbaron: using fill in some cases and color in others...
# [00:37] <fantasai> TabAtkins: Is there a reason to do that?
# [00:37] <fantasai> dbaron: Are we sure we can do the other thing compatibly?
# [00:37] <fantasai> dbaron: Two models for dealing with fallback
# [00:37] * Joins: mollyholzschlag (~mholzsch@public.cloak)
# [00:37] <fantasai> dbaron: One is fill always works, but defaults to color.
# [00:38] * Parts: mollyholzschlag (~mholzsch@public.cloak) (mollyholzschlag)
# [00:38] <fantasai> dbaron: other is fill has a "pass" value that says, don't do any filling, just use color like you used to.
# [00:38] <fantasai> fantasai: Ah, and in that case 'fill-opacity' wouldn't work.
# [00:38] <fantasai> SimonSapin: What's the difference?
# [00:38] <fantasai> TabAtkins: First one could be incompatible with Web, while second is not. Second prevents you from using fill-opacity in general, because if you use pass value, it fill-opacity wouldn't apply.
# [00:39] <fantasai> dbaron: Also kindof odd to have fill-opacity but not fill
# [00:39] <fantasai> TabAtkins: But plan to add fill soon
# [00:39] <fantasai> dbaron: Don't think it's high enough priority
# [00:39] <fantasai> TabAtkins: Ok...
# [00:40] <fantasai> TabAtkins: [...]
# [00:41] <fantasai> TabAtkins: Alternatively, add foreground-opacity, which does opacity for my contents but not for me.
# [00:41] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [00:41] <fantasai> TabAtkins: Reasonable thing people have asked for.
# [00:41] <fantasai> szilles: Doesn't that fall out of composition?
# [00:41] <fantasai> SimonSapin: That's only for backgrounds.
# [00:42] <fantasai> fantasai: Seems somewhat reasonable, but I would be less comfortable doing that with a week's notice than adding just fill-opacity....
# [00:43] <fantasai> Bert: I'm not sure what I want, but going back a step, because we were talking about :placeholder
# [00:43] <fantasai> Bert: The :placeholder idea seems bad idea to me UI-wise
# [00:44] <dbaron> s/:placeholder/placeholder/
# [00:44] <fantasai> Bert: Either should leave it to UAs, or alternatively go all the way and give people alternative ways to show it
# [00:45] <fantasai> Bert: Don't have control over tooltip styling either
# [00:47] <glenn> opacifying?
# [00:47] <fantasai> fantasai: Just to go back a bit, one of my concerns with having both pseudo-class and pseudo-element is that authors will be confused when to use which one and how they interact. Because when there's only one, the cascade is obvious, but when both are there, rules intended to style the placeholder could interact in unexpected ways depending on which selector was used.
# [00:48] <fantasai> smfr: Why add fill-opacity, avoids pseudo-element?
# [00:48] <fantasai> TabAtkins: That and, it's useful generally.
# [00:48] <fantasai> [Explanation of why opacity is desired styling of placeholders: it preserves contrast no matter which colors/backgrounds author chose, while dimming the contrast slightly to distinguish from actual value]
# [00:49] <fantasai> s/preserves/preserves having/
# [00:50] <fantasai> >______<
# [00:50] <glenn> contrasty?
# [00:51] <Rossen> contracity!
# [00:51] <SimonSapin> constratificationement
# [00:51] <fantasai> Topic: Writing Modes
# [00:52] <fantasai> http://dev.w3.org/csswg/css3-writing-modes/#text-combine-horizontal
# [00:52] <dbaron> should we wait for jdaggett?
# [00:53] <jdaggett> how about tomorrow for writing modes?
# [00:53] <jdaggett> i haven't looked over the changes in that section yet
# [00:53] <fantasai> Rossen gives a history of various values for text-combine-horizontal
# [00:53] <fantasai> http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
# [00:54] <fantasai> Rossen: Lot of feature creep for not much benefit.
# [00:54] <fantasai> Rossen: most of the content that requires this has 2 or at most 4 ascii digits
# [00:54] <fantasai> Rossen: That's 90% use case
# [00:54] <jdaggett> oh well, guess i'll just review the discussion and reopen issues if need be
# [00:54] <fantasai> Rossen: Decision was to retract back on adding explicit markup around horizontal bits in order to style individually
# [00:54] <fantasai> Rossen: Which seems like underkill
# [00:55] <fantasai> Rossen: Proposal is to go back to what is that we really want to accomplish here.
# [00:55] * sylvaing underkill?
# [00:55] <fantasai> Rossen: Original idea was pretty good, want to have automatic display of horizontal-in-vertical
# [00:55] <fantasai> Rossen: If most widely used cases is 2-4 digit ascii numbers, then let's do that, have that be possible
# [00:56] <fantasai> Rossen: So add back the 'ascii-digits' value.
# [00:56] <jdaggett> text-combine-horizontal: none | all | digits
# [00:56] <jdaggett> covers 99% of the use cases
# [00:56] <fantasai> Rossen: Let's specify ascii digits only
# [00:56] <fantasai> Rossen: as 'digits'
# [00:56] <fantasai> Rossen: If we want more, then add 'digits-extended' or something.
# [00:56] <fantasai> Rossen: That's the digits value
# [00:57] <fantasai> Rossen: Then the discussion went on to well, we also hate the name it's quite verbose
# [00:57] <fantasai> Rossen: text-combine has some historical bad connotations
# [00:57] <jdaggett> i agree
# [00:57] <fantasai> Rossen: so apparently we should stay away from that
# [00:57] <jdaggett> exactly what Rossen is saying...
# [00:57] <fantasai> Rossen: Our proposal was instead of text-combine-horizontal, just go with text-horizontal
# [00:57] <fantasai> Rossen: When text is horizontal, it has no effect
# [00:57] <fantasai> Rossen: when its vertical, it keeps the text horizontal
# [00:58] <fantasai> dbaron: text-horizontal: none; makes no sense to me
# [00:58] <fantasai> dbaron: Maybe use 'normal', or 'auto', but text-horizontal: none sounds like asking for vertical text....
# [00:59] * TabAtkins_ thinks we should avoid using 'auto' too early in a property's lifecycle.
# [00:59] * fantasai text-horizontal: whatever
# [00:59] <TabAtkins_> glenn: I like the 'combine' in the property name.
# [00:59] <jdaggett> or text-inline?
# [00:59] * sylvaing detects a match for the :bikeshedding state
# [00:59] * stearns why not tate-chuu-yoko? It's got hyphens in the name and everything
# [01:00] * jdaggett oh the peanut gallery is full today
# [01:00] <fantasai> Glenn: 'all' value says that if there's an element boundary between, reverts to none. Why does it prevent combination if I want to color one of the characters?
# [01:00] <fantasai> szilles: That's a separate issue.
# [01:01] <fantasai> fantasai: That was for implementation simplicity.
# [01:01] <fantasai> Rossen: Let's go issue by issue
# [01:01] <fantasai> szilles: If I put a block in, and make it switch direction, then I can do anything I want
# [01:01] <fantasai> szilles: There's another mechanism that allows you to do that.
# [01:01] * jdaggett goes back to reading case folding algorithms
# [01:01] <fantasai> szilles: This is only for one simple thing, therefore well-defiend in simple case.
# [01:01] * sylvaing hey, we could just add a pseudo-element for horizontal bits of text!
# [01:02] * sylvaing ok, that wasn't funny
# [01:02] <fantasai> fantasai: Setting writing-mode: horizontal-tb; would get you an inline block that does whatever you want
# [01:02] <fantasai> szilles: This also compresses whatever you put in there to fit within an em
# [01:02] <SimonSapin> nobody asked for vertical digits in horizontal text?
# [01:02] <fantasai> Glenn: Does it allow overlap of advancement?
# [01:02] <sylvaing> SimonSapin, use-case?
# [01:02] <fantasai> szilles: Believe that's UA-defined
# [01:03] <fantasai> Rossen: Going back to first issue, reintroducing 'digits' value. Does anyone have an objection to that?
# [01:03] <SimonSapin> sylvaing, messing with spec writers
# [01:03] <fantasai> Bert: Why not use a 'display' value?
# [01:03] <fantasai> fantasai: Wouldn't be able to do the automatic processing, which is important.
# [01:04] * sylvaing SimonSapin, that's not a use-case, it's a *goal*. RESOLVED.
# [01:04] <fantasai> http://www.w3.org/TR/2012/WD-css3-writing-modes-20120501/#text-combine-horizontal
# [01:04] <fantasai> szilles: Seems like nobody's opposed to adding those values back in, just change the name so that ascii is implied
# [01:04] <fantasai> s/those values/that value/
# [01:04] <fantasai> RESOLVED: Add 'ascii-digits' back in as 'digits' to text-combine-horizontal
# [01:05] <jdaggett> good
# [01:05] <fantasai> Rossen explains what this value does
# [01:05] <fantasai> to Bert
# [01:05] <fantasai> Glenn: Why limit to ASCII digits?
# [01:06] <jdaggett> because that's the use case
# [01:06] <fantasai> Rossen: This is the 90% use case, and it's simple
# [01:06] <jdaggett> arabic digits == no use case!!!!!!!!!!!!!!
# [01:06] <jdaggett> ditto for any other sort of digit you want to find in Unicode
# [01:06] * fantasai thinks roman numeral digits would have a use case in japanese
# [01:06] <jdaggett> actually it's the 99.999999999999999999999999% use case
# [01:07] <fantasai> Glenn wants all Nd characters from Unicode
# [01:07] <jdaggett> ^ bikeshedding
# [01:07] <fantasai> szilles: Don't want all digits b/c definitely don't want fullwidth digits to combine
# [01:07] <jdaggett> Nd characters == no matching use case
# [01:08] <jdaggett> the only real use case outside of digits is
# [01:08] <fantasai> Glenn wants naming the other way around, with 'digits' being generic and a more specific name for the ASCII digits thing.
# [01:08] <jdaggett> 1.3
# [01:08] <jdaggett> but authors can use 'all' for that
# [01:08] <jdaggett> ascii-digits == silly name
# [01:09] <fantasai> szilles: I'm neutral on the name. In the end I don't think it matters.
# [01:09] <fantasai> Glenn: Do we elsewhere use the term digits when we specify that it refers to Unicode definition of digits?
# [01:09] * sylvaing oh yeah, let's argue ASCII/non-ASCII: it's proven to be the best way to resolve things
# [01:09] <jdaggett> the value name is contextual
# [01:09] <jdaggett> in this case digits means ascii digits
# [01:10] <jdaggett> keep it simple please...
# [01:10] <fantasai> fantasai: I think the closest thing we have is font-variant-numeric, which uses -numeric and -nums
# [01:10] <fantasai> koji: CSS Speech has speak-as: digits
# [01:11] <fantasai> szilles: Is digits a technical term in the Unicode spec?
# [01:11] <fantasai> The Nd category is called " Number, Decimal Digit"
# [01:11] * fantasai actually wonders why we use -nums instead of -digits
# [01:12] * jdaggett oh please stop...
# [01:12] * fantasai isn't sure which is correct
# [01:12] * sylvaing Because Unicode and/or OpenType call them numerals, among other things?
# [01:12] * jdaggett is looking for his suicide pills...
# [01:13] * sylvaing John, if you want LC you got to accept some renaming....
# [01:13] * jdaggett yes, that's right, i forgot the rule
# [01:13] * jdaggett when near LC, must debate silly minor name changes...
# [01:13] * sylvaing we enforce all the unwritten rules
# [01:14] <jdaggett> btw, -nums was used partly because we had -caps already
# [01:15] <jdaggett> and this has been debated on www-style before
# [01:15] <fantasai> Glenn concedes on digits
# [01:15] * sylvaing did the scribe just give up and go home?
# [01:15] <fantasai> Bert: Why 'all'?
# [01:16] <fantasai> Rossen: 'digits' implies auto-discovery
# [01:16] <fantasai> Rosen: 'all' implies you've found your content, and you transform it
# [01:16] <jdaggett> because you want to deal with cases like '1.3'
# [01:16] <jdaggett> which there are examples of in existing content
# [01:18] <fantasai> Rossen: So, text-horizontal?
# [01:18] <fantasai> TabAtkins: Kinda like having the 'combine' in the name
# [01:19] <fantasai> fantasai: One problem I have with 'text-combine-horizontal' is that we have 'glyph-orientation-horizontal'
# [01:19] <fantasai> fantasai: The first takes effect only in vertical text, the second takes effect only in horizontal text
# [01:19] <fantasai> also it's long....
# [01:19] <fantasai> Rossen: We can leave this open
# [01:19] <fantasai> Rossen: Call it 'horizontal-in-vertical'
# [01:20] <jdaggett> ewwww
# [01:20] <SimonSapin> yay for 'text-combine'! works for vertical stacks of digits in horizontal text
# [01:20] <fantasai> plinss suggests using the ideographic characters
# [01:20] <fantasai> TabAtkins protests this violates earlier decision not to add non-ASCII property names
# [01:20] <fantasai> fantasai points out it is not bicameral
# [01:21] * jdaggett oh dear, the wg members are hitting the bottle early...
# [01:21] <fantasai> [the jokes get worse and worse]
# [01:21] * sylvaing jdaggett, so it's not just me...
# [01:21] * jdaggett i have my jack at the ready, good for washing down suicide pills...
# [01:22] * sylvaing jdaggett, you're in AZ. I believe they'll provide the gun for free.
# [01:22] <jdaggett> text-縦中横はどう？
# [01:23] <TabAtkins_> jdaggett: +1
# [01:23] * jdaggett ah true, don't they sell those in liquor stores here
# [01:23] <TabAtkins_> jdaggett: Though the question mark shouldn't be part of the proeprty name.
# [01:23] <TabAtkins_> As written, it'll be included in the ident.
# [01:23] * sylvaing probably comes with a 6-pack
# [01:23] <fantasai> fantasai: So we have some open naming issues. Suggest we don't solve any of them right now.
# [01:24] <fantasai> szilles: 'force-horizontal'
# [01:24] * Joins: franremy (~franremy@public.cloak)
# [01:24] <jdaggett> that works too
# [01:24] <fantasai> plinss: Next?
# [01:24] <dbaron> plinss: could also do text-force-horizontal
# [01:24] <dbaron> (but a bunch of people did like force-horizontal)
# [01:25] <jdaggett> or text-inline...
# [01:25] * Quits: tantek (~tantek@public.cloak) (tantek)
# [01:25] <dbaron> Topic: before/after logical directions
# [01:26] <jdaggett> hmmm, logical direction discussions for a spec we want to go to LC?
# [01:26] * Joins: tantek (~tantek@public.cloak)
# [01:26] <fantasai> [above/below is an available pair]
# [01:26] * jdaggett oh, this discussion...
# [01:26] <fantasai> [someone mentions they're kindof oriented up/down, but so are over/under]
# [01:27] <dbaron> There was also a brief joke about using 上/下.
# [01:27] <fantasai> fantasai: at least people are more likely to guess correctly which of above/below start/end is in which direction
# [01:28] <fantasai> szilles: I think it's better to stay with before/after until we come up with clearly better terms, but I admit to being biased.
# [01:29] <fantasai> fantasai: above/below do clearly map to those ideographic characters :)
# [01:29] <fantasai> Topic: CSS2.1
# [01:30] <fantasai> fantasai: Status of errata? Are they in sync with resolutions?
# [01:30] <fantasai> fantasai: How do we get an up-to-date draft somewhere public?
# [01:30] <fantasai> Bert: Make a WD. Or PER?
# [01:31] <fantasai> dbaron: PER is like LC and PR at the same time
# [01:31] <fantasai> dbaron: Get LC comments, and a simultaneous AC vote
# [01:31] <fantasai> Bert: Probably want WD then
# [01:32] <fantasai> fantasai: We're just going to confuse everyone by publishing it as WD
# [01:33] <fantasai> dbaron: Think we should do an Editor's Draft, and at some point go to PER
# [01:33] <fantasai> Bert: That's confusing, having a non-official WD and still want comments on it.
# [01:33] <fantasai> dbaron: It may be that most of the rest of the world doesn't know that PER is like LC
# [01:34] * Quits: liam (liam@public.cloak) (Client closed connection)
# [01:34] * sylvaing wait, there is a stage that is like LC but nothing gets renamed? Can we use that all the time?
# [01:34] <fantasai> Discussing process of updating the 2.1 REC
# [01:35] <fantasai> dbaron: I think we should have a public editor's draft before PER
# [01:35] <fantasai> dbaron: Would rather not go through rest of the process
# [01:35] <fantasai> dbaron: Don't want LC/CR again for example
# [01:35] <fantasai> dbaron: Publishing WD would be a confusing signal
# [01:36] * Joins: franremy2 (~franremy@public.cloak)
# [01:37] * Quits: franremy (~franremy@public.cloak) (Ping timeout: 60 seconds)
# [01:40] <fantasai> [not minuting this]
# [01:40] <fantasai> szilles: Prior draft to PER would be the REC itself
# [01:40] <fantasai> szilles: Only if the PER is rejected would it have to go back to WD.
# [01:41] <fantasai> szilles: Requirements are you describe in the PER what has changed since REC, but errata already do that.
# [01:41] <fantasai> szilles: Fact that we work in public is just a side benefit
# [01:41] <fantasai> szilles: Best I can determine, it's not inventing new process.
# [01:41] <fantasai> Bert: The reason we're publishing an editor's draft is to help people o that they don't have to look at the errata.
# [01:42] <fantasai> Bert: But the editor's draft is not WG-approved. How are we helping?
# [01:42] <fantasai> tantek: transparency
# [01:42] <fantasai> fantasai: You can double check the editor by double-checking the errata
# [01:44] <fantasai> [more process discussion]
# [01:45] <fantasai> szilles: Best plan I've heard so far is that we begin to develop the text for the PER as an open editor's draft, and that when we get it to point where we think we're happy with it, and we have implementation report, we request a PER.
# [01:45] <fantasai> szilles: That means having some way of writing an implementation report.
# [01:46] * Quits: franremy2 (~franremy@public.cloak) (Ping timeout: 60 seconds)
# [01:46] <fantasai> fantasai: That makes sense. /TR is up-to-date because it has errata, editor's draft is up-to-date b/c editor's draft. As long as we keep the errata and the editor's draft in sync, everything's in sync
# [01:47] <fantasai> fantasai: As long as Bert checks things into both places, it's good
# [01:47] <fantasai> RESOLVED: Follow szilles' plan. Bert takes responsibility for keeping things in sync.
# [01:48] <fantasai> Bert: Where do we put the editor's draft?
# [01:48] <fantasai> Bert: Annoyance with Mercurial is that making edits to any module requires merging/updating all others.
# [01:49] <fantasai> [Bert describes annoyances of working with mercurial vs. cvs]
# [01:50] * tantek is relieved he's not the only one who suffers with a lot of friction with our editing / source control tools.
# [01:50] <fantasai> dbaron: You can commit just a directory, rather than all changes to the repo
# [01:50] * tantek observes that he was having a ton of mercurial problems a year ago - as minuted at the Paris meeting.
# [01:51] * jdaggett btw, just pushed a new draft of the css3 fonts spec, with caseless family name matching spelled out:
# [01:51] * jdaggett http://dev.w3.org/csswg/css3-fonts/#font-family-casing
# [01:51] * tantek wonders if all these magic incantation suggestions for using mercurial are documented on the wiki.
# [01:51] * sylvaing tantek, weren't they setup problems on the mac?
# [01:51] <tantek> sylvaing - sure, plenty
# [01:51] <fantasai> Bert: I can't do a push unless everything has been committed
# [01:51] * sylvaing fwiw i couldn't make it work on my mac.
# [01:51] <fantasai> plinss offers to help Bert offline
# [01:52] <fantasai> fantasai: So goal is that it shows up on dev.w3.org and how that happens it TBD
# [01:53] <fantasai> ACTION Bert: publish editor's draft of CSS2.1
# [01:53] * trackbot is creating a new ACTION.
# [01:53] <trackbot> Created ACTION-531 - Publish editor's draft of CSS2.1 [on Bert Bos - due 2013-02-12].
# [01:55] <fantasai> SimonSapin: Changes to syntax, should we backport?
# [01:56] <fantasai> fantasai: If there are changes in behavior, we should keep the two specs in sync
# [01:56] <fantasai> Topic: CSS3 Syntax changes from 2.1
# [01:56] <SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-tokenizer
# [01:56] <SimonSapin> thttp://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
# [01:56] <SimonSapin> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
# [01:57] <fantasai> dbaron: I disagree with the change to DASHMATCH and INCLUDES
# [01:57] * Joins: SteveZ (~chatzilla@public.cloak)
# [01:58] <fantasai> dbaron: I want to see ... because that's hard.
# [01:58] <fantasai> SimonSapin: DASHMATCH is important for disambiguation with namespace
# [01:58] <fantasai> dbaron: You need DASHMATCH to avoid two-token lookahead
# [01:58] <fantasai> SimonSapin: I had 3 in my implementation
# [01:58] <fantasai> dbaron: With DASHMATCH, I believe nothing in CSS needs more than 1 token of lookahead
# [01:58] <fantasai> in the parser
# [01:59] <fantasai> dbaron: If you implement attribute matching without DASHMATCH and namespaces, you'll need 2-token lookahead
# [01:59] <fantasai> dbaron: If you're parsing attribute selector and you see |, you can't tell whether namespace or |= without 2-token lookahead
# [02:00] <fantasai> TabAtkins: What are your opinions on other match tokens. Should we just have DASHMATCH?
# [02:00] <fantasai> SimonSapin: Selectors 3 added a few attribute selector operators
# [02:00] <fantasai> SimonSapin: Tokenizer only had tokenizer for a few
# [02:00] <fantasai> dbaron: Thought change was implicit in 3
# [02:00] <fantasai> dbaron: Gecko adds tokens for all the match types in Selectors
# [02:00] <fantasai> TabAtkins: Ok, that seems fine
# [02:01] <fantasai> SimonSapin: The core grammar is written that it has a promise not to change
# [02:01] <fantasai> SimonSapin: But if we're fine with changing sometimes, then ok
# [02:01] <fantasai> TabAtkins: We added scinot, so that's a change
# [02:01] <fantasai> TabAtkins: Agreed to pull plus/minus signs into NUMBER token
# [02:01] <fantasai> dbaron: Wouldn't want to backport plus/minus thing to 2.1...
# [02:02] <fantasai> TabAtkins: OK, revert #1 and add additional tokens for Selectors
# [02:02] <fantasai> TabAtkins: I need to do testing for #2. There's a thread about it
# [02:02] <fantasai> TabAtkins: Only matches WebKit's parsing, which is stupid.
# [02:02] <fantasai> TabAtkins: I made a lot of decisions based on WebKit and only realized afterward that we do stupid things.
# [02:02] <fantasai> dbaron: All other browsers are more internally consistent, and also more consistent with spec
# [02:03] <fantasai> dbaron: We've only changed this 3-4 times in the past 3-4 years :) Trying to find out what our code does this week.
# [02:03] <fantasai> TabAtkins: Afaict, we haven't gotten any compat bugs on it.
# [02:04] <fantasai> TabAtkins: May not be important that we do something different than everyone else
# [02:04] <fantasai> TabAtkins: 3 and 5 were decided by WG
# [02:04] <fantasai> TabAtkins: #4 is irrelevant for CSS, just lets you use the same parser for SVG.
# [02:04] <fantasai> fantasai: The NUMBER thing looks inconsistent across our specs.
# [02:05] <fantasai> TabAtkins: I'll go through all our specs and check that they're consistent once we're ready to publish this.
# [02:05] <fantasai> TabAtkins: On the parser side, changes are more minor.
# [02:06] <fantasai> TabAtkins: Grammar didn't allow certain things before, now show up
# [02:06] <fantasai> [] blocks, () blocks and functions can now contain {} blocks, at-keywords or semicolons
# [02:06] <fantasai> http://dev.w3.org/csswg/css3-syntax/#changes-from-css-2.1-core-grammar
# [02:10] <dbaron> RESOLUTION: add tokens for all the multi-character attribute selector operators to css3-syntax
# [02:11] <fantasai> Discussion of @page parsing
# [02:13] <dbaron> dbaron: the " Selectors can now contain semicolons " should say it's talking about only selectors for style rules and not @page selectors
# [02:14] <dbaron> TabAtkins: no, because Selectors in the terms of the syntax spec is only selectors in style rules; @page selectors in the terms of the syntax spec are an @-rule prelude
# [02:14] <dbaron> dbaron: ah, that's what I don't like about the multi-level stuff in the syntax spec
# [02:14] <dbaron> TabAtkins: you don't have to implement it as multi-level
# [02:14] <dbaron> dbaron: ... until you make a mistake
# [02:15] <dbaron> dbaron: Maybe the term for the thing thing that the parser parses to go where a selector goes shouldn't be "selector"?
# [02:15] <dbaron> TabAtkins: maybe "style rule prelude"?
# [02:18] <dbaron> [discussion about parsing and how to write and specify parsers]
# [02:19] * Quits: glazou (~glazou@public.cloak) ("Page closed")
# [02:19] <dbaron> Bert: now that selectors can contain semicolons and @-keywords... the whole of an @-page rule ... ...
# [02:20] <dbaron> Tab: @-rules are either rule-filled or declaration-filled. Either of them can have @-rules in them, but nothing can contain both declarations and style rules.
# [02:22] <dbaron> I'd like to have some sort of a conclusion about the terminology in css3-syntax.
# [02:22] <dbaron> but it seems like we're gradually closing the meeting
# [02:22] * Quits: smfr (~smfr@public.cloak) (smfr)
# [02:23] * Quits: SimonSapin (~SimonSapin@public.cloak) ("Page closed")
# [02:24] <fantasai> Meeting closed.
# [02:24] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [02:24] * Quits: Kazutaka (~Kazutaka@public.cloak) ("Page closed")
# [02:24] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [02:25] * Quits: tantek (~tantek@public.cloak) (tantek)
# [02:25] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [02:27] * plinss is now known as plinss_away
# [02:27] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [02:28] * Quits: plinss_ (~plinss@public.cloak) (Ping timeout: 60 seconds)
# [02:29] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 60 seconds)
# [02:36] * Quits: koji (~koji@public.cloak) (Ping timeout: 60 seconds)
# [02:36] * Quits: SteveZ (~chatzilla@public.cloak) (Ping timeout: 60 seconds)
# [02:38] * heycam is now known as heycam|away
# [03:11] * sylvaing is now known as sylvaing_away
# [03:16] * Joins: tantek (~tantek@public.cloak)
# [03:18] * Joins: tantek_ (~tantek@public.cloak)
# [03:21] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 60 seconds)
# [03:21] * tantek_ is now known as tantek
# [03:21] * sylvaing_away is now known as sylvaing
# [03:36] * heycam|away is now known as heycam
# [03:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [03:46] * Joins: cabanier (~cabanier@public.cloak)
# [04:36] * sylvaing is now known as sylvaing_away
# [05:01] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [05:08] * plinss_away is now known as plinss
# [05:10] * Joins: dbaron (~dbaron@public.cloak)
# [05:11] <dbaron> so, did the pizza dinner group get back before us or after us?
# [05:28] <dbaron> I'm guessing not, but a bunch of us are in the lobby
# [05:35] * Quits: tantek (~tantek@public.cloak) (tantek)
# [05:46] * Joins: lmclister (~lmclister@public.cloak)
# [06:10] * plinss is now known as plinss_away
# [06:19] * Quits: sylvaing_away (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [06:20] * Quits: lmclister (~lmclister@public.cloak) (Client closed connection)
# [06:20] * Quits: paul___irish (~paul___irish@public.cloak) (Ping timeout: 60 seconds)
# [06:20] * Joins: sylvaing_away (~sylvaing@public.cloak)
# [06:20] * Quits: alexmog (~alexmog@public.cloak) (Ping timeout: 60 seconds)
# [06:20] * Joins: lmclister (~lmclister@public.cloak)
# [06:20] * Joins: paul___irish (~paul___irish@public.cloak)
# [06:20] * Joins: alexmog_away (~alexmog@public.cloak)
# [06:20] * sylvaing_away is now known as sylvaing
# [06:21] * alexmog_away is now known as alexmog
# [06:21] * Joins: stearns_ (~anonymous@public.cloak)
# [06:21] * Joins: hober2 (~ted@public.cloak)
# [06:21] * Quits: sawrubh (~uid6719@public.cloak) (Ping timeout: 60 seconds)
# [06:22] * Quits: stearns (~anonymous@public.cloak) (Ping timeout: 60 seconds)
# [06:22] * Quits: slightlyoff (~uid1768@public.cloak) (Ping timeout: 60 seconds)
# [06:22] * stearns_ is now known as stearns
# [06:22] * Quits: hober (~ted@public.cloak) (Ping timeout: 60 seconds)
# [06:49] * Quits: lmclister (~lmclister@public.cloak) ("")
# [06:57] * Joins: lmclister (~lmclister@public.cloak)
# [07:07] * Joins: isherman-book (~Adium@public.cloak)
# [07:20] * Quits: shepazu (schepers@public.cloak)
# [07:20] * Quits: stearns (~anonymous@public.cloak) (Client closed connection)
# [07:20] * Joins: shepazu (schepers@public.cloak)
# [07:21] * Joins: stearns (~anonymous@public.cloak)
# [07:29] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 60 seconds)
# [07:29] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [07:30] * Joins: arronei (~arronei@public.cloak)
# [07:33] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [07:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 60 seconds)
# [07:36] * heycam is now known as heycam|away
# [07:52] * Joins: jdaggett (~jdaggett@public.cloak)
# [07:53] * Joins: isherman-book (~Adium@public.cloak)
# [08:14] <fantasai> http://www.w3.org/mid/CAAWBYDACr4H9w2LMY4ys8PAqvyiOL3m5oHO_ytrdPk6=0R+M2g@mail.gmail.com
# [08:14] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [08:14] <fantasai> http://www.w3.org/mid/CAAWBYDACr4H9w2LMY4ys8PAqvyiOL3m5oHO_ytrdPk6=0R+M2g@mail.gmail.com
# [08:15] * Quits: hober2 (~ted@public.cloak) (Client closed connection)
# [08:15] * Joins: hober2 (~ted@public.cloak)
# [08:17] * Joins: sawrubh (~uid6719@public.cloak)
# [08:18] * Joins: slightlyoff (~uid1768@public.cloak)
# [08:20] * Joins: SimonSapin (~simon@public.cloak)
# [08:24] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [08:30] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [08:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [08:53] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [09:00] * Quits: TabAtkins_ (~TabAtkins@public.cloak) (Ping timeout: 60 seconds)
# [09:01] * Joins: teoli (~teoli@public.cloak)
# [09:16] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:48] * Quits: lmclister (~lmclister@public.cloak) ("")
# [09:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:53] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:53] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:54] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:54] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:54] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:55] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:55] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:56] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:56] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [09:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [09:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:00] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:00] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [10:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [10:04] * Joins: franremy (~franremy@public.cloak)
# [10:26] * Quits: arronei (~arronei@public.cloak) (Client closed connection)
# [10:26] * Joins: arronei (~arronei@public.cloak)
# [10:32] * Quits: franremy (~franremy@public.cloak) ("Nettalk6 - www.ntalk.de")
# [10:37] * Joins: jdaggett (~jdaggett@public.cloak)
# [10:39] * sylvaing is now known as sylvaing_away
# [10:58] * Joins: franremy (~franremy@public.cloak)
# [10:59] * Quits: franremy (~franremy@public.cloak) ("Nettalk6 - www.ntalk.de")
# [11:08] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
# [11:08] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [11:11] * Quits: slightlyoff (~uid1768@public.cloak) (Ping timeout: 60 seconds)
# [11:13] * Quits: sawrubh (~uid6719@public.cloak) (Ping timeout: 60 seconds)
# [11:29] * Joins: slightlyoff (~uid1768@public.cloak)
# [12:07] * Joins: cabanier (~cabanier@public.cloak)
# [12:30] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
# [12:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:30] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:34] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:34] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:37] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:37] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:38] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:39] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:39] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:44] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:44] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:47] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:50] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [12:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:59] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [12:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:02] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:04] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:04] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:05] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:05] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:06] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:07] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:08] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:09] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:11] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:13] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:13] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:14] * Joins: sawrubh (~uid6719@public.cloak)
# [13:14] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:14] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:15] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:15] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:16] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:18] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:18] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:19] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:19] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:20] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:20] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:24] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:24] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:25] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:25] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:26] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:26] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:29] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:29] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:29] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:29] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:30] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:30] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:31] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:31] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:34] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:34] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:35] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:37] * Joins: nvdbleek1 (~nvdbleek@public.cloak)
# [13:37] * Quits: nvdbleek (~nvdbleek@public.cloak) (Client closed connection)
# [13:40] * Joins: florian (~florian@public.cloak)
# [13:43] * Joins: tmpsantos (~tmpsantos@public.cloak)
# [13:43] * Quits: tmpsantos (~tmpsantos@public.cloak) ("Leaving")
# [13:49] * Quits: nvdbleek1 (~nvdbleek@public.cloak) ("Leaving.")
# [13:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [13:50] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [13:50] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [14:00] * Quits: florian (~florian@public.cloak) (Client closed connection)
# [14:00] * Joins: florian (~florian@public.cloak)
# [14:04] * Quits: florian (~florian@public.cloak) (Ping timeout: 60 seconds)
# [14:38] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [15:05] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [15:11] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [15:17] * Joins: teoli (~teoli@public.cloak)
# [15:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:56] * Joins: jdaggett (~jdaggett@public.cloak)
# [15:57] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [15:57] * Quits: jdaggett (~jdaggett@public.cloak) (Client closed connection)
# [15:57] * jdaggett_ is now known as jdaggett
# [16:00] * Joins: SimonSapin (~simon@public.cloak)
# [16:05] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [16:07] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [16:16] * sylvaing_away is now known as sylvaing
# [16:38] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:38] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:40] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:40] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:41] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:41] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:42] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:42] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:43] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:43] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:45] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:45] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:47] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:47] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:48] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:48] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:49] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:49] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:57] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:57] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:58] * Joins: glenn (~gadams@public.cloak)
# [16:58] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [16:58] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:01] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:01] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:02] * plinss_away is now known as plinss
# [17:03] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:03] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:07] * Joins: Molly (~Molly@public.cloak)
# [17:08] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:09] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:09] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:09] * Joins: SimonSapin (~simon@public.cloak)
# [17:10] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [17:10] * Joins: SimonSapin1 (~simon@public.cloak)
# [17:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:10] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:10] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:12] * Joins: jdaggett (~jdaggett@public.cloak)
# [17:12] * jdaggett good morning
# [17:14] * Joins: smfr (~smfr@public.cloak)
# [17:14] <smfr> test
# [17:14] * Joins: dbaron (~dbaron@public.cloak)
# [17:16] * Joins: rhauck (~Adium@public.cloak)
# [17:16] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:18] * Joins: glazou (~glazou@public.cloak)
# [17:18] * Joins: mollyholzschlag (~mholzsch@public.cloak)
# [17:22] <glazou> test
# [17:23] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [17:23] <Ms2ger> test?
# [17:24] <fantasai> They're checking the connection.
# [17:24] * Quits: Molly (~Molly@public.cloak) ("Page closed")
# [17:24] * Joins: koji (~koji@public.cloak)
# [17:24] <glazou> Ms2ger, for display
# [17:28] <fantasai> Topic: Paged Media 4
# [17:28] <glazou> http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com
# [17:28] <fantasai> glazou: One of my activities right now is my EPUB editor
# [17:28] <fantasai> glazou: We have a few issues between IDPF and ourselves, W3C
# [17:28] <fantasai> glazou: They are taking things from us that are unstable drafts
# [17:29] <fantasai> glazou: They rely exclusively on XML serialization of HTML5
# [17:29] <fantasai> glazou: One thing ppl do with electronic books is convert Word documents
# [17:29] <fantasai> glazou: Word allows very powerful headers, footers, footnotes, bookmarks, etc.
# [17:29] <fantasai> glazou: GCPM has very weak headers/footers, and all data you can put there comes from generated content
# [17:29] * Joins: rhauck1 (~Adium@public.cloak)
# [17:29] <fantasai> glazou: These are not elements. They're just text.
# [17:30] <fantasai> glazou: Not enough to import document coming from word processor
# [17:30] <fantasai> glazou: We are far behind
# [17:30] <fantasai> glazou: What we do, allow, is not enough to allow ebooks
# [17:30] <fantasai> glazou: And not enough to allow importing Word documents into Web formats, Ebook formats
# [17:30] <fantasai> glazou: The way Håkon designed headers/footers in css3-page
# [17:30] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 60 seconds)
# [17:30] <fantasai> glazou: He divides the page margin into 16 boxes
# [17:31] <fantasai> glazou: We have new specs on the radar for csswg, grid, flexbox, regions, etc
# [17:31] <fantasai> glazou: That allow precise layouts
# [17:31] <fantasai> glazou: we don't need so many boxes now
# [17:31] <fantasai> glazou: The idea is to take the parts of GCPM/css3-page that make sense
# [17:31] <fantasai> glazou: And for the rest, deprecate almost what's in Paged Media
# [17:32] <fantasai> glazou: And move towards much more powerful page definitions
# [17:32] * Joins: Kazutaka (~Kazutaka@public.cloak)
# [17:32] <fantasai> glazou: Get flows of content, like what's in the Regions spec, to allow powerful complex headers/footers, which we don't have right now
# [17:32] <fantasai> glazou: If I take first word document from my hard disk, e.g. invoice
# [17:32] <fantasai> glazou: It has header with quote number invoice number, customer number, etc.
# [17:32] <fantasai> glazou: All of that is lost when you import to HTML+CSS
# [17:32] <fantasai> glazou: ebook industry is big enough that we should address this problem
# [17:33] <fantasai> glazou: The current GCPM and css3-page are only implemented by batch processors
# [17:33] <fantasai> glazou: There's not a single browser implementing bits from these specs
# [17:33] <fantasai> glazou: Very basic properties, page size, maybe
# [17:33] <fantasai> glazou: I'd like to hear reasons why they were not implemented
# [17:33] <fantasai> glazou: Not a priority? Only for batch processors? Not implementable? Bad perf?
# [17:33] <fantasai> glazou: My idea is to start Paged Media Level 4
# [17:34] <fantasai> glazou: If you're absolutely not interested, though, it's not worth the time
# [17:34] <fantasai> glazou: Would reuse bits of L3
# [17:35] <fantasai> tantek: Even if no one is interested, if you have ideas on a simpler proposal, it's worth writing up
# [17:35] <fantasai> tantek: Seeing your ideas may spur other ideas
# [17:35] <stearns> would this be only for printed output, or would it also include paginated views?
# [17:35] <fantasai> glazou: It's not just simplification, but also a harmonization with other proposals in the CSSWG
# [17:35] <fantasai> glazou: In HTML5 we have <header> and <footer> elements. We are not able to deal with them on a per-page basis
# [17:35] <fantasai> dbaron: Wrt priorities, I think the current draft has not been as high priority as other things
# [17:36] <fantasai> dbaron: I think there are many features that look like a lot of work but don't get you much contributes to that, but not the only thing.
# [17:36] <fantasai> glazou: Not asking for commitment to implement or even review, but can I start a draft?
# [17:37] <fantasai> [people seem supportive of this idea]
# [17:38] <fantasai> tantek: One big change that has occurred since GCPM was first developed and framed is,w e shifted from a desktop/print-centric web to a mobile web
# [17:38] <fantasai> tantek: GCPM feels heavyweight large screen
# [17:38] <fantasai> tantek: That's not the focus to day. The focus is mobile
# [17:39] <fantasai> tantek: The only advice I give is any simplification should first, foremost, solve mobile use cases that paged media has rather than books, print, all these edge cases
# [17:39] <fantasai> glazou: Books are an edge case?
# [17:39] <fantasai> szilles: 5% that everybody uses is still pretty important
# [17:39] <fantasai> szilles: displaying info is key role of Web
# [17:39] <stearns> mobile (particularly tablets) should raise the priority of paginated views, imo
# [17:39] <fantasai> szilles: At least one issue with small screens is being able to hvae reasonable pagination
# [17:40] <fantasai> tantek: Do reasonable pagination, but also need to solve the scrolling problem.
# [17:40] <fantasai> glazou: Wrt mobile, one major application is ebook reading
# [17:40] <fantasai> tantek: Yes, mobile ebook reading, but rather than massive complex texts everyone brings as examples
# [17:40] <fantasai> mollyholzschlag: Isn't it included
# [17:40] <fantasai> mollyholzschlag: Our primary role is to have interop across these devcies
# [17:41] <fantasai> mollyholzschlag: I disagree, having many years in publishing industry
# [17:41] <fantasai> mollyholzschlag: Was talking about GCPM to Tim O'Reilly, he said "We are desperate. EPUB does not fulfill the needs we have. We need solution that incorporates the open standards."
# [17:41] <fantasai> Rossen: I wanted to mention, the GCPM spec, the way it is currently standing
# [17:41] <fantasai> Rossen: We've been looking at it quite a bit
# [17:42] <fantasai> Rossen: it's not something which is easy to develop on top of
# [17:42] <fantasai> Rossen: Are we building a platform that other ppl will build on top of?
# [17:42] <fantasai> Rossen: Or are we building the platform which is the reader?
# [17:42] <fantasai> Rossen: GCPM defines a nice reader app, in s
# [17:42] <fantasai> Rossen: If you're building a platform, then implementing GCPM itself does not allow enough programmability for ppl to build on top fo
# [17:42] <fantasai> s/fo/of/
# [17:43] <fantasai> glazou: You are thinking in terms of implementation. I'm thinking in terms of readers and books [?]
# [17:43] <fantasai> glazou: Ebook publishers need to do a lot more with footers and headers
# [17:43] <fantasai> glazou: Not a question of platform, question of usage.
# [17:43] * stearns agrees rabidly with Rossen
# [17:43] <fantasai> Rossen: My point is, e.g. debate of "what is a page". Author should define what is a page.
# [17:44] <fantasai> Rossen: Whatever we do should also be printable
# [17:44] <fantasai> Rossen: All efforst currently putting forward in Fragmentation, regions, etc, are all moving in that direciton of exposing enough primitives on platform so ppl building apps on top can have sufficient resources to do that.
# [17:44] * Joins: lmclister (~lmclister@public.cloak)
# [17:44] <fantasai> glazou: Again, what I have in mind is more harmonization with other specs on WG's radar, than something entirely new
# [17:45] <fantasai> glazou: We have plenty of things, and we don't use them for page definition. We could. It will be much better tailored and much more maintainable and manipulable
# [17:45] * dbaron wants to ask Rossen what he meant by defining what a page is
# [17:45] * Joins: kawabata (~kawabata@public.cloak)
# [17:45] <fantasai> glazou: for Web authors
# [17:45] * fantasai suggests taking that offline
# [17:45] <fantasai> glazou: More controversial... footnotes
# [17:45] <fantasai> glazou: Way theyr'e done in GCPM is way complicated. Should do them with flows.
# [17:45] <fantasai> glazou: Same thing with bookmarks
# [17:46] <fantasai> glazou: A footnote would be an element with some flow
# [17:46] <fantasai> glazou: Has to be tailored, but should be doable.
# [17:46] <fantasai> glazou: Mention the ebook case bcause i'm working on it, but it's not the only one
# [17:46] <fantasai> glazou: When you want to display datay, you want to paginate, to scroll between pages.
# [17:46] <fantasai> glazou: We don't address that.
# [17:46] * Joins: Rossen (~Rossen@public.cloak)
# [17:46] <fantasai> glazou: We are too weak in terms of CSS rendering
# [17:46] <fantasai> glazou: So goal is to try to do that
# [17:46] <fantasai> glazou: My assumption is not that you will agree immediately, but submit ideas to WG and start discussion on that
# [17:47] <fantasai> glazou: Would give very good signal to IDPF if we do that.
# [17:47] <fantasai> RESOLVED: glazou to start css4-page based on ideas outlined above
# [17:47] * Rossen dbaron, my point is that I don't want to define "what a page is", I want to give authors the ability to define it themselves
# [17:47] <fantasai> SimonSapin: I agree with most of what you said, except for the part of deprecating css3-page
# [17:47] * dbaron Rossen, are you talking about allowing authors to do paginated overflow like in Håkon's overflow:paged proposal, or something else?
# [17:48] * SimonSapin1 is now known as SimonSapin
# [17:49] * Rossen dbaron, this is a good start but not sufficient if you want to allow variable page sizes
# [17:49] <SimonSapin> SimonSapin: … because it’s been implemented and used for many years, even though not on the web
# [17:49] * Joins: tantek (~tantek@public.cloak)
# [17:49] <fantasai> Topic: Flexbox
# [17:49] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012
# [17:49] * dbaron Rossen, that sounds like regions or overflow:fragments
# [17:49] * Joins: TabAtkins_ (~TabAtkins@public.cloak)
# [17:50] <fantasai> First issue is handling of zero-length boxes at end of line
# [17:50] <TabAtkins_> http://dev.w3.org/csswg/css3-flexbox/#algo-line-break
# [17:50] * Rossen dbaron, yes, these proposals are really good start in this direction
# [17:51] * Joins: SteveZ (~chatzilla@public.cloak)
# [17:51] <fantasai> fantasai: Question is what happens if first item is really wide, then add zero-length item
# [17:51] <fantasai> fantasai: Should it stay on first line or go to next line?
# [17:52] <fantasai> [discussion of flex line breaking]
# [17:53] <fantasai> fantasai: We put items until you overflow
# [17:53] <fantasai> TabAtkins: Then back up by one
# [17:53] <fantasai> (unless it's the first item, then don't back up, just break)
# [17:54] <fantasai> TabAtkins: It's possible that you have a negative-length item that will make an overflowing item fit, but we don't look ahead.
# [17:54] <fantasai> szilles: Overflows lefthand side of flexbox?
# [17:54] <fantasai> szilles: What are user expectations?
# [17:55] <fantasai> TabAtkins: Don't use negative margins that big?
# [17:55] <dbaron> sounds like it's worth being clear about what happens with negative margins, and not looking further forward
# [17:55] <fantasai> fantasai: Not a big user expectation issue. Edge cases, we want to make sure implementers are happy with it
# [17:55] * Joins: teoli_ (~teoli@public.cloak)
# [17:56] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [17:56] <fantasai> TabAtkins: Suppose flexbox is 300px wide. First 2 items 200px wide, third is -100px
# [17:56] <fantasai> TabAtkins: Theoretically, can fit all three in box
# [17:56] <fantasai> TabAtkins: But since you overflow after adding the second, you break after the first item.
# [17:57] <fantasai> TabAtkins: If ordering was different, had third before second, then all three would fit on first line
# [17:57] <dbaron> dbaron: I'd support defining the negative margins case clearly; it's not defined clearly for inline layout.
# [17:57] <fantasai> fantasai: In the same example, if we had a first item of 400px, and second item is 0px or -100px
# [17:57] <fantasai> fantasai: In both cases, the second item would wrap, even though it doesn't increase the length of the flex line
# [17:58] <fantasai> fantasai: This last example is what this issue is about.
# [17:58] <fantasai> fantasai: Any further comments? People happy with this interpretation of line-breaking?
# [17:59] <fantasai> szilles: Record what Tab said, that use of negative box sizes is discouraged, but it's defined, and in a way that doesn't require excessive lookahead
# [18:00] <fantasai> Issue 2
# [18:00] * trackbot doesn't understand that ISSUE command.
# [18:00] <fantasai> Handling of negative-size flex lines
# [18:00] <dbaron> fantasai: If all items in a flex line have negative cross-size, does the flex line have negative or zero height?
# [18:00] <fantasai> TabAtkins: Decided to clamp the flex line's cross-size at zero
# [18:01] <fantasai> TabAtkins: Could let them be negative, but don't see any reason to do so.
# [18:01] <fantasai> Rossen: wrt regular block flow, where you can do that...
# [18:01] <fantasai> TabAtkins: If you have a wrapper div in block flow, and fill with negative size things, div is still at least zero height
# [18:01] <fantasai> Rossen: [...]
# [18:02] <fantasai> TabAtkins: You can't have negative-height lines, because only way to get negative sizes is negative margins
# [18:02] <fantasai> TabAtkins: In main dimension, can have items overlap each other
# [18:02] <fantasai> TabAtkins: and have them be negative
# [18:03] <fantasai> TabAtkins: In cross direction, can overlap, but not have negative cross-size for lines
# [18:03] <fantasai> szilles: Note that some of these issues are relevant to inline layout
# [18:03] <fantasai> fantasai: This one doesn't apply, because of root inline's line-height.
# [18:05] <fantasai> RESOLVED: Zero-length boxes stay at end of earlier line unless line is already overflowing, in which case they wrap
# [18:05] <fantasai> RESOLVED: flex lines are floored at zero
# [18:05] <fantasai> cross-size
# [18:05] <fantasai> Issue 3
# [18:05] * trackbot doesn't understand that ISSUE command.
# [18:06] <fantasai> fantasai: Wanted to fill flex items, e.g. each item having content with height :100%;
# [18:06] <fantasai> TabAtkins explains Rudolph's case
# [18:06] * Joins: leif (~lstorset@public.cloak)
# [18:06] <fantasai> TabAtkins: No way to fill it without invoking more flexbox
# [18:06] <fantasai> TabAtkins: Believe our proposal is do nothing, it's currently workaroundable
# [18:07] <fantasai> fantasai: But no way to do, e.g. 50% fill
# [18:08] <fantasai> fantasai: Btw, what are percentage margins relative to on a flex item?
# [18:08] <fantasai> TabAtkins: Think it's same as block
# [18:09] <fantasai> fantasai: So relative to containing block's width for both horizontal and vertical margins?
# [18:09] <fantasai> Bert: Should it be relative to writing mode or flex direction?
# [18:09] <fantasai> TabAtkins: If you think of flex as better block, then should be consistent.
# [18:10] <fantasai> Rossen: If your cross size changes, you have margins in percent, that resolves from the main size, by increasing your cross size, main size will increase.
# [18:11] <fantasai> fantasai: Guess this a separate issue, should probably double-check that things work sensibly.
# [18:11] <fantasai> ACTION fantasai: investigate handling of percentage margins on flex items
# [18:11] * trackbot is creating a new ACTION.
# [18:11] <trackbot> Created ACTION-532 - Investigate handling of percentage margins on flex items [on Elika Etemad - due 2013-02-12].
# [18:11] <fantasai> [discussion between Rossen and Tab wrt margins]
# [18:12] <fantasai> Tab, Rossen, and fantasai to investigate during the break
# [18:12] <fantasai> fantasai: So back to the issue, a related concept is that if you have 'stretch' item, it does not propagate definiteness from the flex container to the flex item, so you can't resolve percentages against it.
# [18:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012
# [18:13] <fantasai> fantasai: In Rudolph's case, it's trying to reference an auto size, so percentages definitely wouldn't work.
# [18:14] <fantasai> fantasai: But suppose flex container is definite size, 'stretch' doesn't allow to resolve against that height right now
# [18:14] <fantasai> Rossen: Should do so, because stretch is equivalent to height 100%
# [18:14] <fantasai> Rossen: We did the same thing for Grid as well
# [18:14] <fantasai> ACTION TabAtkins: Make stretch definite when flexbox is single-line
# [18:14] * trackbot is creating a new ACTION.
# [18:14] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [18:14] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [18:15] <fantasai> 4th issue, Constant spacing around items
# [18:15] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0249.html
# [18:15] <fantasai> TabAtkins: Basically requesting more spacing controls
# [18:16] <fantasai> TabAtkins: Have had similar requests from yehuda Katz
# [18:16] <fantasai> TabAtkins: Wanting to put fixed spacing among items
# [18:16] <fantasai> TabAtkins: This one wants specific spacing between flex lines, perferably same as spacing between flex items on same line
# [18:16] <fantasai> TabAtkins: Think to defer to Level 2. Want more spacing controls, but do a proper treatment of it later.
# [18:17] <fantasai> RESOLVED: Defer additional spacing controls to Level 2
# [18:17] <fantasai> 5th issue: http://lists.w3.org/Archives/Public/www-style/2012Oct/0220.html
# [18:18] <fantasai> fantasai: If you have percentage that can't be resolved, CSS2.1 says it's treated as auto. Currently spec says it computs to auto, but we decided it's actually the used value that's auto
# [18:18] <fantasai> fantasai: We need that to be clear for this issue to be clear in Flexbox
# [18:18] <fantasai> TabAtkins: Stretch checks against computed value of 'auto'
# [18:19] <fantasai> fantasai: So question is, when does 2.1 erratum get published?
# [18:20] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0437.html
# [18:21] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0466.html
# [18:21] <fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
# [18:22] <fantasai> Bert: Did we want to keep the computed value as a percentage so you can back-resolve the parent's width?
# [18:22] <fantasai> fantasai: No idea. Just know that the current text is wrong.
# [18:23] <fantasai> fantasai: Bert, do you need anything from the WG on this issue?
# [18:25] <fantasai> ACTION Bert: Update errata, CSS2.1 spec for bug 15392
# [18:25] * trackbot is creating a new ACTION.
# [18:25] <trackbot> Created ACTION-533 - Update errata, CSS2.1 spec for bug 15392 [on Bert Bos - due 2013-02-12].
# [18:25] <fantasai> Issue 6 was editorial
# [18:25] * trackbot doesn't understand that ISSUE command.
# [18:26] <fantasai> 7th issue was straigthforward, fixing conflicting wording in spec
# [18:26] <fantasai> 8th issue we discussed in December, was waiting on Rossen to confirm
# [18:26] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
# [18:26] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0040.html
# [18:26] <fantasai> Rossen: We ignore aspect ratio once main size is determined
# [18:26] <fantasai> Rossen: Have overlapping content?
# [18:27] <fantasai> TabAtkins: No, no overlapping. Just ignore aspect ratio
# [18:28] <fantasai> Rossen draws example
# [18:29] <fantasai> <div flex><img/><img flex:1/></div>
# [18:29] <fantasai> div is 300px, images 100px each, square
# [18:30] <fantasai> div is 200px tall
# [18:30] <fantasai> TabAtkins: If it's single line, they both stretch to 200px, and main size increases to 200px accordingly
# [18:31] <fantasai> TabAtkins: Then second one is flex: 1, so it negative-flexes to fit, becoming 100px wide. Stays 200px tall.
# [18:35] <fantasai> RESOLVED: Proposed handling of stretched items with intrinsic aspect ratio is accepted.
# [18:36] <fantasai> 9th issue
# [18:37] <fantasai> RESOLVED: http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
# [18:37] <fantasai> 10th issue
# [18:38] <fantasai> Do flex items with negative margins increas available space?
# [18:38] <fantasai> fantasai: Flex items can have negative sizes, we don't clamp the outer size to zero
# [18:39] <fantasai> RESOLVED: Flex items can have negative outer size; no clamping to zero
# [18:40] * dbaron notes the midm
# [18:40] * dbaron notes the midmorning croissant arrival
# [18:41] <fantasai> 12th issue: Orthogonal Flex Layouts Sub-optimally Defined
# [18:41] <fantasai> fantasai: We haven't figured out how to solve this yet, so still open
# [18:42] <fantasai> 13th issue: Should ::first-line/::first-letter apply to a flex container?
# [18:42] <fantasai> fantasai: Mailing list seemed to think, why bother at this point, nobody seems to be demanding it and it's additional complexity
# [18:42] <fantasai> TabAtkins: It wouldn't be too tricky, since you'd be propagating into the first flex item.
# [18:42] * Joins: rhauck (~Adium@public.cloak)
# [18:43] <fantasai> RESOLVED: ::first-line/::first-letter don't apply to flex containers. Could revisit later if this is in high demand.
# [18:44] <fantasai> 14th issue was closed as invalid
# [18:44] <fantasai> 15th issue: Should 'overflow' apply to flex containers?
# [18:44] <fantasai> TabAtkins: We answered yes
# [18:45] <fantasai> dbaron: It's a lot of work
# [18:45] <fantasai> TabAtkins: Two of us already do it
# [18:45] <fantasai> dbaron: Is the idea that you run the entire flex layout algorithm as if the container is that size
# [18:45] <fantasai> TabAtkins: And if you overflow, you add scrollbars and do it again
# [18:46] <fantasai> dbaron: If you have horizontal overflow, you make a scrollbar that can go out to there, but then you do the layout as though the width is still the original width minus the scrollbar.
# [18:46] <fantasai> dbaron: Is that clear?
# [18:46] <fantasai> fantasai: I think that's implied in the way overflow is defined
# [18:47] <fantasai> RESOLVED: overflow applies to flex containers
# [18:47] <fantasai> <br type="tea">
# [18:49] * Quits: leif (~lstorset@public.cloak) ("Leaving.")
# [18:55] * plinss is now known as plinss_away
# [18:58] * plinss_away is now known as plinss
# [18:58] * sylvaing is now known as sylvaing_away
# [19:05] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [19:13] <fantasai> Topic: Transitions
# [19:13] <fantasai> dbaron: Follow-up from yesterday
# [19:13] <fantasai> dbaron: We agreed on a whole bunch of edits
# [19:13] <fantasai> dbaron: Want to publish a WD with those edits, most of which but not all of which are done,
# [19:13] * Joins: SimonSapin (~simon@public.cloak)
# [19:13] <fantasai> RESOLVED: Publish updated WD of Transitions with those edits
# [19:14] * hober2 is now known as hober
# [19:14] <fantasai> ACTION dbaron: edit publish Transitions
# [19:14] * trackbot is creating a new ACTION.
# [19:14] <trackbot> Created ACTION-534 - Edit publish Transitions [on David Baron - due 2013-02-12].
# [19:14] <fantasai> dbaron: Things are done, except bits wrt moving to other specs
# [19:15] <fantasai> dbaron: In general, should I write them and check them in, or send mail to editors with patches
# [19:15] <fantasai> jdaggett: I want a patch
# [19:15] <fantasai> TabAtkins, fantasai: Just check them in
# [19:15] <fantasai> fantasai: Any editor's other than jdaggett want a patch?
# [19:15] <fantasai> szilles: Which specs affected?
# [19:16] <fantasai> dbaron: High priority are fonts, ui, backgrounds, ...
# [19:16] <fantasai> dbaron: Other thing is, I've made some slight editorial changes
# [19:16] <fantasai> dbaron: table that describes how properties are animatable now looks the way I want animatable lines work
# [19:17] <fantasai> TabAtkins: Can't do just "Animatable: yes" for simple things?
# [19:17] <fantasai> dbaron: Right
# [19:17] <fantasai> TabAtkins: :(
# [19:19] <fantasai> Topic: Cascade of Animations and Transitions
# [19:20] <fantasai> smfr: In august F2F there was a resolution that Transitions happen last in the Cascade
# [19:20] <fantasai> smfr: This related to !important rules overriding animations
# [19:20] <fantasai> dbaron: We did want !important rules to override animations, which meant animations not at the top
# [19:21] <fantasai> dbaron: Also how transitions start as a function of computed style changes, requires them to be on top of everything else that affects computed style
# [19:21] <fantasai> dino: In my mind I agree that !important rules should override animations
# [19:21] <smfr> link to previous discussion: (see 16:42): http://logs.csswg.org/irc.w3.org/css/?date=2012-08-15
# [19:22] <fantasai> dino: [something about stopping animations]
# [19:22] <fantasai> dbaron: But that would stop all animations.
# [19:22] <smfr> dino suggesting that the way to stop animations is animation-name: none !important;
# [19:22] <fantasai> dbaron: If a user needs high contrast colors, but motion is fine, if they try to enforce high contrast they lose animations
# [19:22] <fantasai> dino: Right.
# [19:22] <fantasai> dino: Inconsistency that we discussed a few months ago
# [19:23] <fantasai> dino: Would be nice to set it up so that force color overriding animation
# [19:23] <fantasai> dino: Seems like we need some new special rule for cascade so you can do both what you want and in general case override transitions
# [19:23] <fantasai> dino: red to blue animation infinitely
# [19:24] <fantasai> dino: some other rule applies temporarily trigger a transition that overrides the animation
# [19:24] <fantasai> dino: So supose you have red to blue animation
# [19:24] <fantasai> dino: Have a transition rule on color, color transitions over 1s
# [19:24] <fantasai> dino: :hover rule changes color to green, but it's not !important
# [19:24] <fantasai> dino: It would change the color to green
# [19:24] <fantasai> dino: which interrupts the anmation
# [19:25] <fantasai> dbaron: It would only interrupt if the color to green is a change that overrides the animation
# [19:25] <fantasai> dino: Transitions apply last
# [19:25] <fantasai> dino: Yes, but transition only happens if there's a computed value change to trigger it
# [19:25] <fantasai> dbaron: So, in our model, when we're deciding when to start transitions
# [19:25] <fantasai> dbaron: We're looking at a computed style that already has animation results
# [19:26] <fantasai> dino: So technically would start a transition very often
# [19:26] <fantasai> dbaron getting confused now
# [19:26] <fantasai> dbaron: I know we don't start transitions as a result of changes from animations
# [19:26] <fantasai> dbaron: We have a concept of style with/without animations
# [19:27] <fantasai> smfr: You would only show a transition when there would be a visible change that isn't caused by the animation
# [19:27] <fantasai> smfr: So if !important rule makes it yellow, you start a transition
# [19:27] <fantasai> smfr: What's your starting color?
# [19:28] <fantasai> dbaron: Think it's the currently animating color
# [19:28] <fantasai> fantasai: Think that's what it should be
# [19:28] <fantasai> smfr: More pragmatic point is, WebKit we don't do that. Animations are applied last, overriding !important rules
# [19:28] <fantasai> smfr: So for next year or two we'll have different implementations
# [19:28] <fantasai> smfr: How do we deal with that?
# [19:28] <fantasai> dbaron: From security perspective, bunch of !important rules in our UA style sheet, and they must take effect.
# [19:29] <dbaron> fantasai: I think honoring the !important rules is the right thing for the user.
# [19:31] * hober can no longer hear; tab, are you doing something near the mic?
# [19:31] <fantasai> [lots of discussion that wasn't minuted]
# [19:31] * dino - meeting room has cut out since sylvaing joined skype
# [19:32] <fantasai> szilles: Seems like 2 issues here: whether !important should win, and whether transitions or animations win
# [19:32] <fantasai> fantasai^: [...stuff...]
# [19:33] <fantasai> [mostly about how there seems to be no new info, and we're just repeating the discussion we had last time]
# [19:33] <hober> Present+ hober (remote)
# [19:33] * Joins: sylvaing (~sylvaing@public.cloak)
# [19:33] <fantasai> [which fantasai does not want to minute again, personally\
# [19:34] <fantasai> mollyholzschlag: Wrt a11y and user, animations and transitions are 2 aspects of CSS where a11y does come into play, and having !important, don't have an opinion on transitions vs. animations, but should not interrupt pattern of allowing users !important over that stuff
# [19:34] <fantasai> szilles: If I'm doing an animation, what does it mean for the !important rule to take effect but not stop the animations
# [19:35] <fantasai> fantasai: It means the animation continues, but that value does not change.
# [19:35] <fantasai> plinss: Wrt transitions, it's a red herring. If !important rule overrides, and there's a transition to that state, shoudln't affect whether or not !important overrides the statement.
# [19:35] <fantasai> smfr: In WebKit in theory we would like !important to override, but it's an implementation
# [19:35] <fantasai> plinss: Nobody's disagreeing
# [19:35] <fantasai> dino: Maybe explain the point again from last time
# [19:36] <fantasai> dino: Completely agree that !important style rule should oerride an animation
# [19:36] <fantasai> dino: But don't think transitions should apply after animations, think it causes inconsistency in the model
# [19:36] <fantasai> dbaron: Could imagine a model where cascade for animations sort of operates instead of on the actual value on a dummy value that says "the value of this comes from this animation"
# [19:36] <fantasai> dbaron: And then if that wins in the cascade, then you use the animation
# [19:36] <fantasai> dbaron: In that sort of model, can see animation overriding the transitions
# [19:37] <fantasai> dbaron: I know how to do it in our implementation, don't know how to specify it in CSS specs
# [19:37] <fantasai> TabAtkins doesn't understnad what was just said; fantasai either
# [19:37] <fantasai> fantasai: Isn't that what transitions is already doing?
# [19:37] <fantasai> fantasai: I don't understand this assertion that transitions should lose to animations.
# [19:38] <fantasai> dbaron: If you've specified an animation, that should win over transition between static value
# [19:38] <fantasai> fantasai: Suppose you have two states, State A and State B.
# [19:38] <fantasai> fantasai: In State A, you are running animation Q
# [19:39] <fantasai> fantasai: And in State B, animation Q does not run
# [19:39] <fantasai> fantasai: Why would you not want a smooth transition from State A to whatever State B wants
# [19:39] <fantasai> ?
# [19:40] <fantasai> dbaron: Do you want a transition from the animated state of A, or the non-animated state of A.
# [19:40] <fantasai> fantasai: whatever I'm seeing at that moment
# [19:41] <TabAtkins_> .foo { color: yellow; animation: go-from-red-to-blue 1s infinite; }
# [19:41] <dino> now change color to green
# [19:41] <TabAtkins_> .foo:hover { color: green; }
# [19:41] * Quits: shepazu (schepers@public.cloak) (Client closed connection)
# [19:41] <dino> in both cases you see animation
# [19:41] * Joins: shepazu (schepers@public.cloak)
# [19:41] <TabAtkins_> .foo { transition: color 1s; }
# [19:41] <fantasai> plinss: Nothing triggers a transition, because nothing changes
# [19:42] <fantasai> plinss: The animation is still overriding the color
# [19:42] <fantasai> plinss: The color of the element has not change.
# [19:42] <fantasai> dino: If there was a transition on color, why would we see the yellow-to-green transition?
# [19:42] <fantasai> s/see/expect/
# [19:42] <fantasai> plinss, fantasai: Nobody expects that
# [19:43] <fantasai> dbaron: I think we're going around in circles, yet I don't think there is any disagreement over the desired results
# [19:44] <fantasai> fantasai: So, suppose in the :hover state, we say animation: none; so that it is in fact green
# [19:44] <dbaron> I think we agree that (a) we want !important rules to override animations and (b) we want animations to override transitions
# [19:44] <fantasai> fantasai: Dean is asserting that you won't see the transition, it just snaps to green
# [19:44] <fantasai> fantasai: And peter and I are saying it should transition to green from whatever color it was starting at.
# [19:45] <fantasai> dbaron: I don't care what happens in that case, should be whatever's easiest that gets us a nad b
# [19:46] <fantasai> discussion of where to start
# [19:46] <fantasai> dbaron: Are you starting from base state of the animation state, the current state of the animation, or the dynamic state of the animation
# [19:46] <fantasai> plinss and fantasai are sayng the 2nd option
# [19:47] <fantasai> plinss: When you trigger :hover, the animation has ended
# [19:47] <fantasai> plinss: you take the state of the animation at that point, and then take that s the starting point and go from there to the :hover state
# [19:49] <fantasai> dbaron: I think use cases for these features are mostly orthogonal, and interaction should be what makes sense
# [19:49] <fantasai> dbaron: Four options
# [19:49] <sylvaing> +1 to david's orthogonality point. the demand to solve this is 100% spec completeness afaik.
# [19:50] <TabAtkins_> Which is half of why we do anything in this group anyway.
# [19:51] <sylvaing> ...and it's the half we bikeshed the most on....
# [19:51] <fantasai> dbaron: Suppose you have p { margin-top: 50px; animation: bounce; }
# [19:51] <fantasai> @keyframes bounce { from: 100px; to: 150px; }
# [19:51] <sylvaing> to the risk of being outrageous i'd even propose to keep this undefined in this level.
# [19:52] <fantasai> s/bounce/bounce alternate/
# [19:52] <glazou> sylvaing, I'll say it for you
# [19:52] <fantasai> p { transition: margin-top 2s; }
# [19:52] <fantasai> p:hover { margin-top: 0; }
# [19:53] <fantasai> s/bounce/bounce 1s infinite/
# [19:53] <sylvaing> glazou, thanks. definitely no objection to giving this a shot.
# [19:53] <fantasai> dbaron draws a graph
# [19:53] <fantasai> 150px 100px 50px 0px along y axis
# [19:53] <fantasai> x axis represents time
# [19:54] <fantasai> hover is halfway along time
# [19:54] <fantasai> dbaron draws the base-state of the margin at 50px straight through to :hover
# [19:55] <fantasai> dbaron draws the animated state as a zig zzag from 1000px to 150px sloping up, down, up, then halfway down before hitting hover
# [19:55] <fantasai> s/1000/100
# [19:55] <fantasai> :hover { animation: none; }
# [19:55] <fantasai> plinss: Does anyone disagree that without the animation: none rule, it would just continue to animate?
# [19:56] <fantasai> Everyone agrees that continuing to animate is what we want
# [19:56] <fantasai> dbaron draws a dotted line representing this continuation
# [19:57] <fantasai> dbaron draws 4 options
# [19:57] <fantasai> 1. If from or to value comes from animation, there's no transition. Just instant change.
# [19:57] <fantasai> (draws line dropping at hover to zero
# [19:57] <fantasai> )
# [19:58] <fantasai> 2. The transition ignores the animation completely. You transition from base state (50px) to zero.
# [19:58] * sylvaing can't wait to see that pic; cam is a bit fuzzy at that distance
# [19:58] <fantasai> (draws line dropping from 50px at hover to zero after 2s)
# [19:59] <glazou> http://lockerz.com/s/281620122
# [19:59] <fantasai> 3. Take from where the animation left off to where the :hover state is
# [19:59] <fantasai> (draws line from partway through the zag at :hover down to zero at 2s
# [19:59] <fantasai> )
# [20:00] <fantasai> 4. Transition, interpolating between the dynamic state of the animation and zero
# [20:00] <fantasai> (draws line that zigzags sligtly from the :hover point on the animation to zero)
# [20:01] <dino> I would be quite scared if we couldn't come to agreement on this situation. It's the !important one that's tricky.
# [20:01] <fantasai> plinss: 4 should never happen, because the animation is no longer running
# [20:01] <fantasai> dino: Alternate end state, p:hover { margin-top: 0 !important; }
# [20:02] <fantasai> s/dino/dbaron/
# [20:02] <fantasai> dbaron: We have zero models that explains all the other stuff we want, so let's figure out a model that gets us everythign else we want and then see what falls out of that
# [20:02] <fantasai> plinss: Just before you hovered, there was no animation, but a transition running from some previous state
# [20:02] <fantasai> suppose
# [20:03] <fantasai> plinss: Suppose there was no animation, base state is margin-top 50, but just before that you were in some other state, and there's a transition running from that state to the 50px
# [20:03] <fantasai> plinss: Now you start the :hover.
# [20:03] <fantasai> plinss: Where are you transitioning from?
# [20:03] <fantasai> dbaron: That's the open issue Tab has an action item to write a JS simulation for
# [20:03] * sylvaing must say this is a pretty awesome graph
# [20:04] <fantasai> plinss: Think the answer to that should inform the answer to this
# [20:04] * fantasai pokes tantek, can you help sylvaing
# [20:04] <fantasai> ...
# [20:04] <fantasai> dbaron: A change caused by an animation does not trigger a transition
# [20:05] <fantasai> dbaron: Not difficult to go from there to, if your before/after state is an animation, you don't transition
# [20:05] * sylvaing fantasai, what?
# [20:05] <fantasai> plinss: It's *an* answer
# [20:05] <fantasai> plinss: 2 and 3 both make sense
# [20:05] <dino> I like what I think dbaron is suggesting. (obviously assumes I think what I'm thinking!)
# [20:05] <fantasai> fantasai: I don't like 2, it jumps
# [20:06] <fantasai> smfr: 3 is problematic, because, imagine flip this around
# [20:06] <tantek> fantasai - I think sylvaing has already seen http://pics.lockerz.com/s/281620122
# [20:06] <sylvaing> what happens with #3 when you un-hover?
# [20:06] <fantasai> smfr: You're trying to hit a moving target
# [20:07] <fantasai> plinss: If your :hover is applying a different animation, you're trying to hit two moving targets
# [20:08] <sylvaing> suspects answers that mitigate jarring visual discontinuities are better for authors but you end up managing 2 or more states for the same computed value which is....weird.
# [20:08] <fantasai> fantasai: I think in the case smfr outlines, you'd look 2s into the animation, where am I supposed to be, then transition into that.
# [20:08] <fantasai> fantasai: That's what's going to get you the smooth transition, which is what you want. Otherwise it's jumpy
# [20:08] <fantasai> dbaron: If you go from big animation to small animation, you can't pick the time that will look right
# [20:09] <fantasai> dbaron: Because the correct time will depend on the speed you want, which can vary depending on the distance you're trying to hit
# [20:09] <fantasai> smfr: We don't have paced animations
# [20:09] <fantasai> [discussion of velocity]
# [20:10] <sylvaing> if an author wants something this sophisticated, i'm not sure the current level of Transitions/Animations cuts it.
# [20:10] <fantasai> dbaron: Then you need distance functions for all your properties.
# [20:10] <fantasai> plinss: That's a level 4 Transitions feature
# [20:10] <fantasai> dbaron: Level 5
# [20:10] <sylvaing> Web Animations Level 6!
# [20:10] <fantasai> plinss: Yeah. But I think it's an important use case that we should get to
# [20:10] <fantasai> ...
# [20:11] <fantasai> plinss: The only way you'd get behavior of 4 is if the animation continues during the transition period even though you've turned it off. It could be rational, but you turned it off
# [20:11] <fantasai> s/you turned it off/a lot of work/
# [20:11] <sylvaing> agree #4 isn't an option in this case.
# [20:12] <dbaron> The example markup ended up being:
# [20:12] <fantasai> smfr: Have a few high-level comments.
# [20:12] <dbaron> p { margin-top: 50px; transition: margin-top 2s linear; animation: bounce 1s infinite alternate }
# [20:12] <fantasai> smfr: Think looking at use cases and desired behavior is good, for coming up with correct model
# [20:12] <sylvaing> +1 to smfr
# [20:12] <dbaron> @keyframes bounce { from { margin-top: 100px } to { margin-top: 150px } }
# [20:12] <fantasai> smfr: Also for current level of spec, not sure we'll come to agreement.
# [20:12] <fantasai> smfr: Agree with sylvaing, maybe we should leave this undefined.
# [20:12] <dbaron> [option 1] p:hover { margin-top: 0; animation: none }
# [20:12] <dbaron> [option 2] p:hover { margin-top: 0 ! important }
# [20:13] <fantasai> szilles: Problem with that is you can't fix it if there's wide deployment of something
# [20:13] <sylvaing> szilles, I think that's a feature...
# [20:13] <fantasai> fantasai: What exactly are we proposing to undefine?
# [20:13] <fantasai> dbaron: I think we need to work on a model that answers the rest of the stuff
# [20:13] <fantasai> dbaron: How we describe how transitions/animations interat with cascade, even ignoring this issue.
# [20:14] <fantasai> dbaron: How do transitions interact with cascade, how do animations interact with cascade, ignoring how they interact with each other
# [20:14] <fantasai> dbaron: Maybe including how they interact with each other in the non-boundary case.
# [20:14] <fantasai> fantasai: You mean, if we remove 'animation: none' from that example
# [20:15] <dbaron> (i.e., with [option 3] p:hover { margin-top: 0 })
# [20:15] <fantasai> fantasai: Since we agree the animation should just keep going
# [20:15] <fantasai> szilles: If an animation is running and therefore defining the value of a property, then using some other mechanism to change the value of that property has no effect (regardless of whether a transition period was defined)
# [20:15] <fantasai> szilles: The animation is overriding the value of the property anyway
# [20:16] <fantasai> szilles: question is interesting, if the animation stops, completes, then what's the value of the property?
# [20:16] <dbaron> we all agree that p { margin-top: 50px; transition: margin-top 2s; animation: bounce 1s infinite alternate } @keyframes bounce { from { margin-top: 100px } to { margin-top: 150px } } p:hover { margin-top: 0 } should produce no visible transition (the animation should just keep going)
# [20:16] <fantasai> szilles: :hover is still there, animation completes
# [20:16] <fantasai> plinss: When the animation completes, return to the base value of the property
# [20:16] * Joins: cabanier (~cabanier@public.cloak)
# [20:16] <sylvaing> once animation completes i'd expect the :hover rule to apply
# [20:16] <fantasai> right
# [20:17] <fantasai> szilles: If you're in :hover, and animation terminates while you're in :hover, whatever cascade says value will be will be the value
# [20:17] * fantasai thinks sylvaing just said that more clearly
# [20:17] <fantasai> szilles: Question then is, is a transition triggered when the animation stops?
# [20:18] <fantasai> smfr: Think dean, me, dbaron, anyone else might meet to go through use cases
# [20:18] <fantasai> plinss: Think open issue Tab was going to write JS for is important here
# [20:18] <fantasai> dbaron: I don't think so
# [20:18] <fantasai> dbaron: That's internal to the transitions model, the reversing behavior
# [20:19] <fantasai> dbaron: No cascading behavior, not two different models interacting with each other
# [20:19] <fantasai> szilles: Why is interrupting a transition with a transition different from interrupting an animation with a transition?
# [20:20] <fantasai> dbaron: [something about different models]
# [20:20] <fantasai> szilles: As a user, how is it different?
# [20:20] <fantasai> dbaron: It's a much more important use case
# [20:20] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [20:20] <fantasai> dbaron: It's very common to interupt a :hover partway through a transition
# [20:21] <fantasai> plinss brings up case of animation ending, do you snap to base state
# [20:21] <fantasai> smfr: Yes. Never transition due to animation
# [20:21] <fantasai> plinss: So in that case, we shouldn't transition from any other animated state
# [20:21] <sylvaing> we do have a clause saying animating values do not cause transitions to start
# [20:21] <fantasai> plinss: See the logic of it. Not sure users would be happy with that.
# [20:22] <fantasai> szilles: Agree. Think users would like to be able to avoid flashing.
# [20:22] <fantasai> szilles: question is, is that some new L5 feature we add to handle that case?
# [20:22] <sylvaing> if people apply both an animation and a transition to something I think it's rational to believe they don't expect unanimated transitions between the two
# [20:23] <fantasai> ...
# [20:23] <sylvaing> or other visually janky switching
# [20:23] <fantasai> fantasai: You could have an animation-transition property :)
# [20:23] <fantasai> szilles: pick a simple solution for this, add something to patch it later
# [20:24] * sylvaing elika, no renaming until LC
# [20:24] <SteveZ> sylvain: rename "last call" to "renaming call"
# [20:25] * fantasai wasn't proposing to rename anything
# [20:25] * SimonSapin just renamed stuff in css3-page … but we had LCs in 2003 and 2006 so it’s fine.
# [20:25] * fantasai was proposing to add a aproperty, how is this a renaming discussion
# [20:25] <sylvaing> SteveZ, yes. Let us bikeshed on process step names!
# [20:25] * fantasai that's a terminology change, it doesn't count
# [20:25] * fantasai ^SimonSapin
# [20:26] <fantasai> ACTION dbaron: assign actions
# [20:26] * trackbot is creating a new ACTION.
# [20:26] <trackbot> Created ACTION-535 - Assign actions [on David Baron - due 2013-02-12].
# [20:26] * sylvaing right. if you add a property at LC its name is by definition correct. we should just wait for LC to define these things :)
# [20:26] <dbaron> ACTION dbaron meet with smfr and dino to come up with a proposed model for transitions/animations cascading and interaction
# [20:26] * trackbot is creating a new ACTION.
# [20:26] <trackbot> Created ACTION-536 - Meet with smfr and dino to come up with a proposed model for transitions/animations cascading and interaction [on David Baron - due 2013-02-12].
# [20:27] <dbaron> trackbot, mark ACTION-535 complete
# [20:27] <trackbot> Sorry, dbaron, I don't understand 'trackbot, mark ACTION-535 complete'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
# [20:27] <fantasai> Topic: F2F Tokyo
# [20:27] <jdaggett> http://wiki.csswg.org/planning/tokyo-2013
# [20:27] <dbaron> trackbot, close ACTION-535
# [20:27] * trackbot is closing ACTION-535.
# [20:27] <trackbot> Closed ACTION-535 Assign actions.
# [20:27] <fantasai> June 2013
# [20:27] <fantasai> Su Mo Tu We Th Fr Sa
# [20:27] <fantasai> 1
# [20:27] <fantasai> 2 3 4 5 6 7 8
# [20:27] <fantasai> 9 10 11 12 13 14 15
# [20:28] <fantasai> jdaggett: One complication, SVG wants to co-locate
# [20:28] <fantasai> jdaggett: Mozilla will sponsor both meetings
# [20:28] <fantasai> jdaggett: Multiple offers of ppl to host one or the other, but I think easier to keep on one site
# [20:28] <fantasai> jdaggett: Looks like Mozilla Japan will have a new office with room
# [20:28] <fantasai> jdaggett: So would like to pick dates
# [20:28] <dbaron> June 5-7 are the proposed dates
# [20:29] <dbaron> AC meeting is 9-11
# [20:29] * shepazu warns jdaggett that dates are sticky, and he should wash his hands after picking them
# [20:31] <dino> when is the SVG meeting?
# [20:31] <fantasai> RESOLVED: June 5-7 at Mozilla Japan in Tokyo
# [20:31] <jdaggett> dino: svg is discussing that this week
# [20:31] <jdaggett> dino: on friday i think
# [20:31] * fantasai notes that not many people responded to the doodle
# [20:31] <glazou> <br type="lunch" />
# [20:32] * dbaron fantasai, what doodle?
# [20:32] * fantasai http://doodle.com/z99cyshc5fy96kbr
# [20:32] <Bert> ACTION-535?
# [20:32] * trackbot is looking up ACTION-535.
# [20:32] <trackbot> ACTION-535 -- David Baron to assign actions -- due 2013-02-12 -- CLOSED
# [20:32] <trackbot> http://www.w3.org/Style/CSS/Tracker/actions/535
# [20:33] <dino> i agree it should give the link when creating. Maybe a shortlink? w3.org/q/2duoi4
# [20:34] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 60 seconds)
# [20:36] * Bert counts 23 PERs
# [20:37] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:40] * mollyholzschlag test
# [20:43] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 60 seconds)
# [20:55] * Joins: smfr (~smfr@public.cloak)
# [21:00] * Quits: tantek (~tantek@public.cloak) (tantek)
# [21:05] * plinss is now known as plinss_away
# [21:08] * plinss_away is now known as plinss
# [21:14] <dbaron> what happened to dvcs.w3.org?
# [21:14] <dbaron> It's giving my HTTP Error 500 Internal Server Error
# [21:14] <dbaron> s/my/me/
# [21:14] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [21:14] * Joins: dbaron (~dbaron@public.cloak)
# [21:16] * Joins: jarek (~jarek@public.cloak)
# [21:23] * Quits: smfr (~smfr@public.cloak) (smfr)
# [21:29] * Joins: SimonSapin (~simon@public.cloak)
# [21:38] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 60 seconds)
# [21:42] * Joins: antonp (~Thunderbird@public.cloak)
# [21:50] * Joins: sylvaing (~sylvaing@public.cloak)
# [21:51] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:55] * Joins: smfr (~smfr@public.cloak)
# [21:58] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [21:58] * Quits: koji (~koji@public.cloak) ("Page closed")
# [21:58] * Joins: koji (~koji@public.cloak)
# [22:01] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:06] * Joins: isherman-book (~Adium@public.cloak)
# [22:06] * Joins: tantek (~tantek@public.cloak)
# [22:08] <mollyholzschlag> Heya - if you're speaking tonight take a moment and ping me your name or any details you want mentioned in your introduction
# [22:11] <fantasai> SimonSapin: Issue discussed at TPAC wrt multi-col
# [22:11] <fantasai> SimonSapin: Algorithm there has an idea of an unknown available width, and I think it doesn't make sense
# [22:11] <fantasai> SimonSapin: I tried to talk with Håkon and Bert, via email, F2F
# [22:11] <fantasai> SimonSapin: but seems we don't understand each other
# [22:11] <fantasai> glazou: Seems like adding to agenda is a good idea
# [22:11] <fantasai> szilles: Would also like to add exclusions update to agenda
# [22:11] <fantasai> SimonSapin: Related issue is that we have two different definitions for min-content and max-content
# [22:11] <fantasai> SimonSapin: One is sizing, and one in box module, and they are not compatible
# [22:11] <fantasai> SimonSapin: Discussed at TPAC... but still have two.
# [22:11] * Parts: glazou (~glazou@public.cloak) (glazou)
# [22:11] * Joins: glazou (~glazou@public.cloak)
# [22:12] * Joins: Rossen (~Rossen@public.cloak)
# [22:12] <fantasai> Topic: Fonts
# [22:12] <fantasai> jdaggett: First topic is case-sensitivity of font family names
# [22:12] <fantasai> jdaggett: Talked about this yesterday
# [22:12] <fantasai> jdaggett: I put last night wording into spec to define the exact algorithm to be used
# [22:13] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-family-casing
# [22:13] <fantasai> jdaggett: Would like to take a second to resolve on this
# [22:13] <fantasai> jdaggett: Points at default caseless matching algorithm in Unicode spec
# [22:13] <fantasai> jdaggett: You case-fold each string
# [22:13] <fantasai> jdaggett: Use case mappings defined by C/F statuses in CaseFoldingtxt
# [22:14] <fantasai> jdaggett: Noted there is no normalization, no locale-specific behavior
# [22:14] <fantasai> jdaggett: Another paragraph explains to authors where they should be careful
# [22:14] <fantasai> jdaggett: Most people won't be affected
# [22:15] <fantasai> smfr: Maybe 2nd paragraph should be a note
# [22:16] * Joins: mollyholzschlag_ (~mholzsch@public.cloak)
# [22:16] <fantasai> fantasai: Think the last sentence of 1st paragraph should be a note
# [22:16] <fantasai> jdaggett: Want to make sure implementers don't use the wrong pre-written methods
# [22:17] <fantasai> TabAtkins: Pulling it out into a note would actually make it more obvious
# [22:18] <fantasai> jdaggett: Implementations MUST NOT use platform routines that they don't understand.
# [22:18] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [22:18] * Quits: mollyholzschlag (~mholzsch@public.cloak) (Ping timeout: 60 seconds)
# [22:18] <fantasai> fantasai^: The normative requirements are already expressed in the paragraph, above. You're just pointing out that it's easy to screw up; this isn't a normative requirement, it's informative helpful advice
# [22:18] * mollyholzschlag_ is now known as mollyholzschlag
# [22:19] <fantasai> [discussion of normative, informative, notes, etc]
# [22:20] * glazou " this specification requires a minimal neuronal mass from the reader, please check your eligibility first " ?-)
# [22:21] <fantasai> jdaggett: Another issue is wrt default [?]
# [22:21] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#language-specific-support
# [22:22] <fantasai> jdaggett: This deals with language-specific features
# [22:22] * Quits: nvdbleek (~nvdbleek@public.cloak) ("Leaving.")
# [22:22] <fantasai> jdaggett: Question is, whether UAs should by default always use the default system, or huse heuristics to guess language
# [22:23] <fantasai> fantasai: You defer to the "document language"
# [22:23] <fantasai> fantasai: If it's unknown, use default. Don't guess
# [22:23] * TabAtkins_ plinss: I'll be back in a sec, but when jdaggett is done, I'd like to go through the remaining Counter Style issues and request LC.
# [22:24] <fantasai> jdaggett: HTML5 explicitly says that if it's not sepcified, it's unknown
# [22:24] <fantasai> [...]
# [22:25] <fantasai> jdaggett: So if it's not known, what do we do?
# [22:25] <fantasai> fantasai: Is the language a required param to the API calls?
# [22:25] <fantasai> jdaggett: No.
# [22:25] <fantasai> fantasai: Then don't pass a language.
# [22:25] <fantasai> fantasai: If the author wanted lang-specific features, should have put a lang tag
# [22:26] <fantasai> ...
# [22:26] <fantasai> [discussion of mapping ISO lang codes to OpenType lang systems]
# [22:26] <fantasai> jdaggett: For most things, you can map. If you want to override, you can also override
# [22:26] <fantasai> Glenn: ... script ...
# [22:26] <fantasai> jdaggett: This is given by character code
# [22:27] <SimonSapin> HTML "language of a node" http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#language
# [22:27] <fantasai> glenn: Opentype indic have two scripts defined, one for older tables and one for newer tables
# [22:27] <fantasai> glenn: Since we don't have a way for authors to define script specifically, we have a gray box here..
# [22:27] <fantasai> glenn: I would suggest treating the whole problem space is
# [22:27] <fantasai> jdaggett: So define default script as well as default language?
# [22:28] <fantasai> glenn: You need three tags to generate the tables that apply
# [22:28] <fantasai> glenn: script, language, ?
# [22:28] <fantasai> s/?/feature
# [22:28] <fantasai> jdaggett: We have a set of properties dictating...
# [22:28] <fantasai> glenn: For a given set of features, leaves script and language as parameters
# [22:28] <fantasai> glenn: If you want to fully hanlde this mapping, then you need to define all three of these
# [22:28] <fantasai> glenn: Do you have language for dealing with script tag?
# [22:29] <fantasai> jdaggett: what's explained to me is that in general, script tag can be inferred from the codepoint
# [22:29] <fantasai> jdaggett: Some issue with different versions of indic, but for given implementation, you're picking one and using that one
# [22:29] <fantasai> jdaggett: Using one or the other
# [22:29] <fantasai> glenn: I'm aware of one implementation, because I did it, in XSL:FO, allow to specify script identifier based on ISO script identification system
# [22:30] <fantasai> glenn: So I happen to implement the ability to allow author to specify variants in order to select between old indic vs. new indic
# [22:30] <fantasai> glenn: If you look for indic fonts, some built for first version, some for second, some to support both
# [22:30] <fantasai> jdaggett: Those tables can be looked up
# [22:30] <fantasai> jdaggett: You're sort of overspecifying by pushing out into author space
# [22:30] <fantasai> glenn: Just want to make sure script tag mapping is discussed
# [22:30] <fantasai> jdaggett: I thought it was just an implementation detail, didn't need to be author-facing
# [22:31] <fantasai> jdaggett: Think I might leave this open, since nobody else is speaking up
# [22:31] <fantasai> glenn: I agree with fantasai that you should defer to document language at first order
# [22:31] <fantasai> glenn: We should make sure there's a well-defined mapping between the tag sets
# [22:31] <fantasai> glenn: Also begs question of lang tags for non-OT fonts, not sure we need to get into that
# [22:32] <fantasai> jdaggett: Think we need to make sure it works for OT, implementers can fill in the dots for other formats.
# [22:32] * Quits: isherman-book (~Adium@public.cloak) ("Leaving.")
# [22:32] <fantasai> fantasai: Would like to point outUsers agents are required to infer the OpenType language system from the value of the ‘lang’ attribute
# [22:33] <fantasai> fantasai: Should just defer to document language, not specify how it's found.
# [22:33] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/70
# [22:33] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Sep/0197.html
# [22:33] <fantasai> jdaggett: I went in to fonts spec and put in prose to handle all the cases, but never cleared out the issue
# [22:34] <fantasai> jdaggett: Has to do with the ay certain combinations of say questin marks, what the semantics of that are
# [22:34] <fantasai> jdaggett: In the spec, a number of statements about this
# [22:34] <fantasai> jdaggett: Was a conflict with the way the syntax spec was worded, but that's ironed out before lunch
# [22:34] <fantasai> jdaggett: So, unless anyone sees anything here, I'd like to close this issue
# [22:34] <fantasai> jdaggett: Can always raise another issue if there's something specific to handle
# [22:34] <Bert> -> http://www.w3.org/TR/selectors/#lang-pseudo Selectors text about what is an element's language
# [22:34] <fantasai> jdaggett: Think we've fixed all the problems in this issue
# [22:35] <fantasai> SimonSapin: Think Syntax solves the parsing-related issues
# [22:35] <fantasai> dbaron: Might be worth sending something to Zack
# [22:35] <fantasai> RESOLVED: Close ISSUE-70, ping Zack about this
# [22:35] <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/71
# [22:36] <fantasai> trackbot, close ISSUE-70
# [22:36] * trackbot is closing ISSUE-70.
# [22:36] <trackbot> Closed ISSUE-70 UNICODE-RANGE definitions.
# [22:36] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2008Nov/0077.html
# [22:36] <fantasai> jdaggett: Spec now has prose to talk about this
# [22:37] <fantasai> jdaggett: Gecko implementation doesn't implement 'unicode-range', so part of reason for difference in behavior [...]
# [22:37] <fantasai> jdaggett: Think most issues have been dealt with in the spec
# [22:37] <fantasai> jdaggett: Can open new bugs if more specific things are found
# [22:38] <glenn> http://lists.w3.org/Archives/Public/www-style/2009Jan/0173.html
# [22:38] <dbaron> that's CSS 2.1 issue 71, not tracker issue 71
# [22:39] <fantasai> fantasai: if dbaron's happy, I'm happy
# [22:39] <fantasai> dbaron: Fine with closing it. May some point look at the text and comment
# [22:40] <fantasai> jdaggett: Font loader issues, but defer that... want WebApps people to comment on some of those things
# [22:40] <fantasai> jdaggett: Other than the language issue, I did make one change...
# [22:43] <fantasai> [some discussion about error handlers]
# [22:43] * Joins: jarek_ (~jarek@public.cloak)
# [22:43] <fantasai> jdaggett: You have to load content, and start laying it out, to assess whether you need to download a font
# [22:43] <fantasai> jdaggett: Could start loading a font via JS, but, then that's your won problem
# [22:43] <fantasai> s/won/own/
# [22:44] <fantasai> jdaggett: Is there a scenario you're concerned about?
# [22:44] <fantasai> glenn: Is there a way to register to handler using onerror attribute?
# [22:44] <fantasai> jdaggett: Yes, there are both event handler attributes plus you can use the event handler name
# [22:44] * Quits: jarek (~jarek@public.cloak) (Ping timeout: 60 seconds)
# [22:44] <fantasai> glenn: So element directly attach tto font loader, woudl that be body?
# [22:44] <fantasai> jdaggett: document
# [22:44] <fantasai> jdaggett: This is all in the spec
# [22:44] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-style-matching
# [22:44] <fantasai> jdaggett: Section I want to look at is cluster matching
# [22:45] <fantasai> jdaggett: I put in some wiggle room for specific scenario that sometimes occurs
# [22:45] <fantasai> jdaggett [quotes spec]
# [22:46] <fantasai> jdaggett: This is a compat issue with the way Arial has implemented Arabic in the past
# [22:46] <fantasai> jdaggett: Where they have Arabic glyphs in the default face, but not the italic face
# [22:46] <fantasai> jdaggett: So if you say italic Arial, you get fallback
# [22:46] <fantasai> in some browsers
# [22:46] <fantasai> jdaggett: This allows creating synthetic italics
# [22:46] <fantasai> jdaggett: Avoid searching all faces
# [22:47] <fantasai> jdaggett: The added wording, "The only exception ..."
# [22:47] <fantasai> Bert: Default face is the roman face?
# [22:47] <fantasai> jdaggett: What you would select if you had all font properties set to initial value
# [22:48] <fantasai> jdaggett: Unless there's other issues to bring up, would propose publishing another WD
# [22:48] <fantasai> jdaggett: Was hoping this woudl be LC, but I'm uncomfortable with the way font loader is right now, and want WebApps people to look it over first
# [22:49] <fantasai> jdaggett: It's an unusual section for a CSS spec b/c defines API with scripting behavior
# [22:49] <fantasai> jdaggett: So would like to have other people review it
# [22:49] <fantasai> jdaggett: But that is my intent, review things, then go to LC
# [22:49] <fantasai> jdaggett: Hopefully within this month
# [22:49] <fantasai> fantasai: There's an issue raised on italics and vertical text that probably warrants some discussion as well
# [22:49] <fantasai> jdaggett: Think we shouldn't deal with that in this level
# [22:49] <fantasai> jdaggett: From your post, Koji, don't see that there's a clear desired behavior
# [22:50] <jdaggett> http://koji.ec/archives/7
# [22:50] <fantasai> jdaggett: In vertical text runs, when you say "italic", most Japanese fonts don't have an italic face, so what is produced is a synthetic oblique face
# [22:51] <fantasai> jdaggett: There were two issues in the mail he wrote
# [22:51] <fantasai> jdaggett: One is, what is the right way to do synthetic italics for Latin in vertical
# [22:51] <fantasai> jdaggett: UAs always oblique to the right. If not right for RTL, could add ways of obliquing to the lft
# [22:51] <fantasai> jdaggett: Tricky one is what to do about vertical text runs, where the obliquing is distinctly different
# [22:52] <fantasai> jdaggett: If you look at the picture
# [22:52] <fantasai> jdaggett: 1 is what you get by default
# [22:52] <fantasai> jdaggett: different processor swill give you different results, depending on what you want to do
# [22:52] <fantasai> jdaggett: I think Koji said IE10 does 6 and Webkit does 8
# [22:53] <fantasai> jdaggett: From my perspective of just defining what italics should map to, I think 8 is correct
# [22:53] <fantasai> jdaggett: However, maybe patterns in Japanese publishing where e.g. 3 or 4 are considered the norm
# [22:53] <fantasai> jdaggett: However, I think they require a different property to solve correctly
# [22:53] <fantasai> jdaggett: Might be a good feature to allow shear transforms on individual glyphs
# [22:53] <fantasai> jdaggett: But don't think we should do this in this level
# [22:54] <fantasai> jdaggett: Fact that there are 8 different renderings
# [22:54] <fantasai> jdaggett: Shows there is a deeper issue, can't be solved by us declaring which one is right
# [22:54] <fantasai> jdaggett: Can take an action to get more opinion on this
# [22:54] <fantasai> jdaggett: Dont' think we'll get a good sampling of opinion on www-style
# [22:54] <fantasai> plinss: Where do these renderings come from?
# [22:54] <fantasai> Koji: I did it by transform
# [22:54] * Joins: mollyholzschlag_ (~mholzsch@public.cloak)
# [22:54] <fantasai> Koji: This picture is generated by transforms
# [22:55] <fantasai> Koji: But tested what actual results are in other implementations
# [22:56] <fantasai> jdaggett: Problem in spec is inconsistency among browsers, not sure we should be looking at other implementations
# [22:56] <fantasai> jdaggett: Koji says we should define what synthetic italic looks like
# [22:56] <fantasai> plinss: Is italic used with japanese glyphs?
# [22:56] <fantasai> jdaggett: Not common, but it happens
# [22:57] <fantasai> jdaggett: For Japanes text, if you have italics, and don't oblique it, people file bugs
# [22:57] * Quits: mollyholzschlag (~mholzsch@public.cloak) (Ping timeout: 60 seconds)
# [22:57] * mollyholzschlag_ is now known as mollyholzschlag
# [22:57] <fantasai> plinss: Is it every correct to oblique the text?
# [22:57] <fantasai> jdaggett: If there's a pattern of text obliqued, should investigate/do somethign about that
# [22:57] <fantasai> jdaggett: but not for this level
# [22:58] * Quits: jarek_ (~jarek@public.cloak) (jarek_)
# [22:58] <dbaron> to my eyes, the difference between 2 and 8 is very subtle
# [22:58] <dbaron> (but I do now see it)
# [22:59] <fantasai> fantasai: I would like more evidence from printed matter that there's one pattern that's always used
# [23:01] <fantasai> s/fantasai/jdaggett/
# [23:01] <fantasai> fantasai: CSS3 Fonts requires synthesizing italics, question here is, if used in vertical text, then what do you synthesize?
# [23:01] <fantasai> jdaggett, szilles: just leave it undefined
# [23:02] <fantasai> jdaggett: Disagree that this blog post is enough to make a decision on the right default
# [23:03] <fantasai> fantasai: Even if we add a property for this, what would be the initial value?
# [23:03] <dbaron> dbaron: Experimentation might lead to a bunch of UAs being willing to switch to another's behavior because it's better.
# [23:04] <fantasai> jdaggett: I'll see if there's more published examples of this being used consistently, but unless that comes back with a solid answer of "you always do this"...
# [23:05] <fantasai> szilles: Also have problem that this is Japanese, what about Chinese
# [23:05] <fantasai> fantasai: The preferred slant is derived from the more cursive forms of Han characters, so would be consistent.
# [23:06] <fantasai> ...
# [23:06] <fantasai> koji: If I specify italic, want consistent behavior across browsers.
# [23:06] <fantasai> jdaggett: If there's variation...
# [23:06] <fantasai> koji: There is variation in typographic world.
# [23:06] <fantasai> koji: Pick an interoperable consistent default behavior.
# [23:07] <fantasai> jdaggett: It's not a commonly used feature. Might be just accident of implementation.
# [23:07] <fantasai> koji: Can add features in future. Want the baseline behavior to be consistent.
# [23:07] <fantasai> koji: My preference is to use 6, because it's what word processors do and people are used to it
# [23:08] <fantasai> jdaggett: Would prefer not to standardize on what a publisher would not do
# [23:08] <fantasai> koji: Publishers want more controls, fine to do in Level 4
# [23:08] <fantasai> jdaggett: Think this needs more research
# [23:09] <fantasai> fantasai: Assume there is a variety of needs. What is the default?
# [23:09] <fantasai> szilles: It's UA-defined.
# [23:10] <fantasai> kawabata-san and koji are not happy with this
# [23:10] <fantasai> kawabata-san: Is there a difference in slanting between LTR or RTL?
# [23:10] <fantasai> j Today there is not. Could argue that this is not ideal behavior.
# [23:10] <fantasai> jd Existing bheavior for syntehtic obliques is consistent.
# [23:10] <fantasai> glenn: italics don't apply to Arabic anyway
# [23:11] <fantasai> jdaggett: It's an artifact of word processors
# [23:11] <fantasai> fantasai: Some precedent for italics in Hebrew though
# [23:12] <fantasai> koji: I'm happy not to make conclusion here, happy to publish WD, as long as this is kept as an open issue.
# [23:12] <fantasai> fantasai^: Following the logic of RTL, where slant is always consistent, why not make writing mode also stay consistent.
# [23:13] <dbaron> the right side of http://www.huji.ac.il/ shows what looks to me like Italic style in Hebrew
# [23:13] <fantasai> RESOLVED: Publish WD
# [23:13] <fantasai> RTL italics discussion: http://typophile.com/node/49385?page=2
# [23:13] <dbaron> (and it's an image, too)
# [23:13] <fantasai> Chinese mixing fonts in Roman/Italics pattern: http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ZhongGuoYin__Xue%202005.4%20001.png
# [23:14] <fantasai> jdaggett: Please review the draft, particularly wrt functionality
# [23:14] <fantasai> szilles: Meaning correct definition of the functionalities there, not what's missing
# [23:14] <fantasai> fantasai: No new features. But if things are unintentionally undefined, should be an issue
# [23:15] * heycam|away is now known as heycam
# [23:15] <fantasai> <br type="tea"/>
# [23:16] * Joins: cabanier (~cabanier@public.cloak)
# [23:19] <jdaggett> fantasai: that's a simple mixing of brush styles
# [23:20] <jdaggett> fantasai: comparing it to roman/italic is an oversimplification
# [23:23] <jdaggett> feedback on faux oblique from nat at adobe:
# [23:23] <jdaggett> In my opinion 斜体 is totally different from italic, or even oblique, in usage and applicability to Latin typographic convention.
# [23:23] <jdaggett> "In InDesign we keep them totally separate."
# [23:24] <jdaggett> "There is no italic in Japanese, no need to faux oblique with Japanese using slant, in fact only slanting is wrong, so just don't do it."
# [23:24] <jdaggett> "Use 斜体 instead which scales, rotates, and shears with precise settings."
# [23:28] <koji> I agree with Nat. The point here is, if publishing industry doesn't need italics at all, and if all word processor vendors/users requires it, why don't we suffice word processor users in level 3, and pursue publishing industry in level 4?>
# [23:32] <jdaggett> if there's consistent behavior that is in common use then we can use that
# [23:34] * Quits: mollyholzschlag (~mholzsch@public.cloak) ("sleeping computer is sleeping")
# [23:36] * plinss is now known as plinss_away
# [23:36] <koji> An example HTML file at http://dl.dropbox.com/u/8812114/italics-vertical.htm
# [23:37] * plinss_away is now known as plinss
# [23:39] <koji> jdaggett: yes, I'll collect actual examples from word processor market to get to you
# [23:40] <jdaggett> we need actual use cases from users
# [23:40] <jdaggett> not just testcases that use the feature
# [23:41] <Bert> ScribeNick: Bert
# [23:41] <Bert> Topic: counter styles
# [23:42] <Bert> TabAtkins_: [looking up the issues]
# [23:42] <TabAtkins_> http://dev.w3.org/csswg/css-counter-styles-3/#alphabetic-system
# [23:42] <Bert> TabAtkins_ : section 5
# [23:42] <Bert> ... example 6
# [23:43] <Bert> ... Fixed with counter style, example
# [23:43] <Bert> ... It's a hack
# [23:43] <Bert> ... Is this important enought to add a fixed width system?
# [23:43] <Bert> fantasai: This is not good practice.
# [23:43] <Bert> ... If we do them, let's do them properly
# [23:44] <Bert> ... Reading from a screen reader, or something, gets the wrong values.
# [23:44] <Bert> glazou: They read 0-0-0-3
# [23:44] <Bert> fantasai: you want the to read "3"
# [23:44] <Bert> TabAtkins_: Just remove it? Or add fixed width system?
# [23:44] <Bert> glazou: The latter
# [23:45] <Bert> TabAtkins_: And waht about negative values and out of range?
# [23:45] <Bert> fantasai: Say fill with how many digits.
# [23:45] <Bert> TabAtkins_: nagative prefix
# [23:45] <Bert> Stevez: another sign position
# [23:45] <Bert> ... Need to say if you have space for sign or not.
# [23:46] <Bert> ... Can ad a value 'sign' to say you want space for sign.
# [23:46] <Bert> ... So that neg values still same width.
# [23:46] <Bert> fantasai: May then prefixx it with spaces.
# [23:46] <Bert> SteveZ: And for overflow, just overflow.
# [23:46] <Bert> TabAtkins_: OK, I'll do that.
# [23:46] <Bert> TabAtkins_: Sect 3.5,
# [23:47] <Bert> ... issue 2
# [23:47] <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/#counter-style-range
# [23:47] <Bert> ... Infinite range obviously not actually supported.
# [23:47] <Bert> ... should we specify a minimum required range?
# [23:48] <Bert> ... Something liek at least 16 bits?
# [23:48] <Bert> TabAtkins_: A nice base-2 number?
# [23:48] <Bert> fantasai: more than 256!
# [23:48] <Bert> TabAtkins_: Yes, 2 bytes or so
# [23:49] <Bert> fantasai: We discussed this elswehere, too.
# [23:49] <Bert> TabAtkins_: Currently between 16 and 32 bits
# [23:49] <Bert> ... 16 bits shoul dmake everyne happy.
# [23:49] <Bert> ... Nobody actually 32, maybe 31 bits
# [23:49] <Bert> Rossen: [missed]
# [23:49] <Bert> TabAtkins_: Easier to test with required range
# [23:50] <Bert> SteveZ: Need ten to change implem that go beyond it.
# [23:50] <Bert> dbaron: We have 32 bit signed int.
# [23:50] <Bert> TabAtkins_: Opera something like 2 billion
# [23:50] <Bert> fantasai: That's more than we need.
# [23:51] <Bert> SteveZ: No, it';s not. Machines generate more than that.
# [23:51] <Bert> dbaron: Yes, I can imagine that
# [23:51] <Bert> plinss: Can also start a count at 20mln and than have only 20 entries.
# [23:51] <Bert> fantasai: 3 bytes, then?
# [23:51] <Bert> plinss: Should we have a minimum range?
# [23:52] <Bert> SteveZ: Yes, we can always raise it.
# [23:52] <Bert> TabAtkins_: Yes
# [23:52] <Bert> SteveZ: Not clamp it.
# [23:52] <Bert> tantek: Unit length: what did we decide?
# [23:52] <Bert> TabAtkins_: Doesn't require a range right now.
# [23:52] <Bert> ... We couldn't get consistent answer in time.
# [23:53] <Bert> tantek: We are going to LC?
# [23:53] <Bert> TabAtkins_: yes
# [23:53] <Bert> ... Length are more complicated
# [23:53] <Bert> fantasai: They can be floats as well.
# [23:53] <Bert> TabAtkins_: And inches and pixels not same range.
# [23:53] <Bert> TabAtkins_: Should I pick 2 bytes?
# [23:53] <Bert> dbaron: Fne as a minimum.
# [23:54] <Bert> SimonSapin: [missed]
# [23:54] <Bert> plinss: Should not wrap.
# [23:54] <Bert> TabAtkins_: yes
# [23:54] <Bert> glenn: [smagic number that scribe didn't catch]
# [23:54] <dbaron> 1114112
# [23:54] <dbaron> (17 * 2^16)
# [23:54] <fantasai> RESOLVED: 2-byte minimum, clamp, no wrap
# [23:55] <fantasai> TabAtkins: Whenever you hit your maximum, clamp to that instead of wrapping into negatives
# [23:55] <Bert> TabAtkins_: When you read the top, don't wrap, just stop there.
# [23:56] <Bert> dbaron: It's about counter-reset with some value
# [23:56] <Bert> SteveZ: Incrementing a clamped value doens't increment it.
# [23:56] <Bert> ... Incrementing maximum value has no effect.
# [23:56] <Bert> dbaron: You can increment with more than 1
# [23:57] <Bert> ... So have to say you become the maximum.
# [23:57] <Bert> plinss: Othe roption is to stay and not incr.
# [23:57] <dbaron> Peter: so if the increment would put you over the maximum, do you increment to the maximum, or stay where you are?
# [23:57] <Bert> SteveZ: Can also say that, increment that would go beyond does nothng.
# [23:57] <SimonSapin> s/[missed]/More important than a minimum range is to define what to do what an implementation-specific range is reached/
# [23:58] <Bert> plinss: Say you're at max-i and incrmeent is 100
# [23:58] <Bert> ... Should not go beyond max
# [23:58] <Bert> dbaron: OK with that
# [23:58] <SimonSapin> s/max-i/max-1/
# [23:58] <SimonSapin> s/go beyond max/go to max/
# [23:58] <Bert> RESOLVED: if current value + increment is outside of the range, then do not increment
# [23:59] <TabAtkins_> test
# [23:59] <Bert> TabAtkins_: issue about fallback style
# [23:59] <Bert> ... For styles with linted range.
# [23:59] <Bert> ... e.g., circled numberd in Unciode.
# [23:59] <Bert> ... You normally drop back to decimal.
# Session Close: Wed Feb 06 00:00:00 2013

The end :)