16:31:39 <RRSAgent> RRSAgent has joined #css
16:31:39 <RRSAgent> logging to http://www.w3.org/2011/11/30-css-irc
16:31:44 <glazou> Zakim, this will be Style
16:31:44 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 29 minutes
16:31:49 <glazou> RRSAgent, make logs public
16:36:59 <arno> arno has joined #css
16:37:18 <jdaggett> jdaggett has joined #css
16:45:10 <sylvaing> sylvaing has joined #css
16:47:13 <ericm> ericm has joined #css
16:50:51 <dbaron> dbaron has joined #css
16:51:24 <dstorey> dstorey has joined #css
16:55:32 <danielweck> danielweck has joined #css
16:57:11 <Zakim> Style_CSS FP()12:00PM has now started
16:57:18 <Zakim> +??P37
16:57:27 <divya> divya has joined #css
16:57:33 <jdaggett> zakim, ++P37 is me
16:57:33 <Zakim> sorry, jdaggett, I do not recognize a party named '++P37'
16:57:35 <divya> are we on?
16:57:51 <jdaggett> zakim, +??P37 is me
16:57:52 <Zakim> sorry, jdaggett, I do not recognize a party named '+??P37'
16:57:54 <Zakim> +??P39
16:57:59 <glazou> Zakim, ??P39 is me
16:57:59 <Zakim> +glazou; got it
16:58:10 <jdaggett> zakim, ??p37 is me
16:58:10 <Zakim> +jdaggett; got it
16:58:35 <Zakim> +??P43
16:58:44 <Zakim> +plinss
16:58:45 <florianr> Zakim, I am ??P43
16:58:45 <Zakim> +florianr; got it
16:59:14 <antonp> antonp has joined #css
16:59:29 <Zakim> +[Microsoft]
16:59:37 <Zakim> +divya
16:59:41 <sylvaing> Zakim, [Microsoft] has sylvaing
16:59:41 <Zakim> +sylvaing; got it
17:00:04 <glazou> Zakim, who is noisy?
17:00:14 <Zakim> glazou, listening for 10 seconds I heard sound from the following: 6 (58%), divya (14%)
17:00:16 <Zakim> +antonp
17:00:31 <lhnz> lhnz has joined #css
17:00:41 <Zakim> +stearns
17:00:43 <Zakim> +[Microsoft.a]
17:00:49 <TabAtkins_> TabAtkins_ has joined #css
17:00:55 <Zakim> +kimberly
17:00:56 <JohnJan> JohnJan has joined #CSS
17:01:06 <smfr> smfr has joined #css
17:01:13 <Zakim> + +1.510.364.aaaa
17:01:18 <JohnJan> zakim, microsoft has johnjan
17:01:18 <Zakim> +johnjan; got it
17:01:20 <fantasai> zakim, kimberly has fantasai
17:01:20 <Zakim> +fantasai; got it
17:01:25 <Zakim> +tabatkins_
17:01:28 <Zakim> +Bert
17:01:29 <kimberly> kimberly has joined #css
17:01:38 <Zakim> +dbaron
17:01:51 <Zakim> +smfr
17:02:10 <Zakim> +??P70
17:02:18 <danielweck> Zakim, ??P70 is me
17:02:18 <Zakim> +danielweck; got it
17:02:20 <glazou> Bert: welcome back :-D
17:02:58 <oyvind> oyvind has joined #css
17:03:13 <Zakim> +howcome
17:03:16 <vhardy> vhardy has joined #css
17:03:24 <howcome> howcome has joined #css
17:03:38 <Zakim> +Oliver_Goldman
17:03:45 <plinss> zakim, who is noisy?
17:03:46 <glazou> Zakim, who is noisy?
17:03:55 <Zakim> plinss, listening for 10 seconds I heard sound from the following: 18 (8%)
17:04:09 <Zakim> glazou, listening for 10 seconds I heard sound from the following: 18 (47%), glazou (18%), plinss (5%), tabatkins_ (90%)
17:04:52 <divya> hahahah
17:05:02 <Zakim> +[IPcaller]
17:05:04 <Zakim> +??P22
17:05:11 <kojiishi> zakim, ??p22 is me
17:05:11 <Zakim> +kojiishi; got it
17:05:14 <tantek> Zakim, IPcaller is tantek
17:05:14 <Zakim> +tantek; got it
17:05:30 <glazou> wow, this becomes impossible to listen too :-D
17:05:33 <tantek> Zakim, mute tantek
17:05:33 <Zakim> tantek should now be muted
17:06:00 <danielweck> WTF ?
17:06:24 <danielweck> :)
17:06:32 <divya> :D
17:06:36 <TabAtkins_> ScribeNick: TabAtkins_ 
17:06:49 <TabAtkins_> Topic: Unicode TR50 update
17:07:01 <TabAtkins_> jdaggett: There was an item on Ed and Sylvain to report back.
17:07:24 <TabAtkins_> smfr: Ted can't make it today.
17:07:31 <TabAtkins_> jdaggett: But he said he would have an update by next week.
17:07:41 <TabAtkins_> sylvaing: And I'm a bit busy with the next preview, but I'm hoping to have it soon.
17:07:56 <TabAtkins_> plinss: Okay, defer to next week.
17:08:06 <TabAtkins_> Topic: Remaining CSS3 Speech issues
17:08:14 <danielweck> http://wiki.csswg.org/spec/css3-speech#issue-1
17:08:30 <TabAtkins_> danielweck: This issue is contentious.
17:08:37 <TabAtkins_> danielweck: Last I heard form the commenter was 29 Sep.
17:08:45 <TabAtkins_> danielweck: I've sent two heads-up.
17:08:55 <danielweck> http://www.w3.org/TR/css3-speech/#cue-props
17:08:58 <Zakim> +SteveZ
17:09:15 <TabAtkins_> danielweck: As far as I understand, the normative text regarding the use of decibels - I agreed we have an issue with normative vs informative text here.
17:09:35 <TabAtkins_> danielweck: However, because of the lack of further discussion from the commenter, I'm not entirely sure what the correct position is regarding which statements are normative.
17:09:45 <SteveZ> SteveZ has joined #css
17:09:55 <TabAtkins_> danielweck: There are some problems with the informative statements we're making about the decibel levels from the output of speech synthesizers, so we need to remove that.
17:09:58 <TabAtkins_> danielweck: So two question.
17:10:04 <TabAtkins_> danielweck: One, what do we do if we don't get feedback?
17:10:26 <TabAtkins_> danielweck: Two, in terms of the process, what happens if we decide to mark this particular issue part of the syntax at-risk?  Not the entire property, just the decibel part.
17:10:37 <TabAtkins_> danielweck: Does that require going back to WD, or what?  How fixable are we?
17:11:07 <TabAtkins_> fantasai: I'd say to do your best to address the person's feedback.  Then record in the disposition of comments the comments and the changes you've made, and record that you haven't gotten a response from them.
17:11:30 <TabAtkins_> fantasai: You've given them plenty of time and reminders.  If they don't respond by the time we take the DoC to the director, he can still review their comments and check that you've addressed them.
17:11:38 <danielweck> http://wiki.csswg.org/spec/css3-speech#issue-18
17:11:41 <TabAtkins_> fantasai: Regarding marking something as at-risk, you can do that now.  It doesn't require going back to WD.
17:11:53 <TabAtkins_> danielweck: Second issue, issue 18.  Not a blocking issue, just waiting for confirmation.
17:12:15 <TabAtkins_> danielweck: I don't think they'd raise an objection if we completed without a confirmation.
17:12:41 <TabAtkins_> danielweck: So in terms of timeframe, what's a reasonable or typical timeframe when writing the call for implementation?
17:13:26 <TabAtkins_> fantasai: The timeframe for CR is generally taken as a minimum.  Usually a six-month minimum, but usually it takes longer than that to get the testsuite and the impl reports, etc.
17:13:53 <TabAtkins_> fantasai: With regards to the transition, the comment period has closed.  If you don't get a response at all in a week or two, I think it's fair to say that's long enough to either respond or request additional time for investigation.
17:14:02 <TabAtkins_> danielweck: Okay.
17:14:44 <TabAtkins_> danielweck: My status as a contributor to the spec in the coming year - we want to work with the spec through CR, including making the testsuite, etc.
17:15:02 <TabAtkins_> danielweck: But I'm not entirely sure who'll be handling the impl reports, liaising with browsers, etc.
17:15:15 <TabAtkins_> fantasai: I think that's fine.  We should probably ask the epub folks to look for somebody to own the testsuite.
17:15:23 <TabAtkins_> danielweck: I'm in the epub and that's our plan too.
17:15:54 <plinss> http://lists.w3.org/Archives/Public/www-style/2011Nov/0735.html
17:15:55 <TabAtkins_> Topic: New draft of Japanese Text Layout spec
17:16:16 <TabAtkins_> plinss: If you have any interest, please look at it and give feedback.  They're looking for comments by the end of the year.
17:16:22 <TabAtkins_> jdaggett: Is there a list of changes?
17:16:33 <TabAtkins_> florianr: Agreed, it's a long document.
17:16:47 <TabAtkins_> [several]: No clue what the changes are.
17:16:55 <TabAtkins_> jdaggett: I sent a message to Richard asking for that.
17:17:03 <TabAtkins_> kojiishi: I talked to Richard and not sure how that went.
17:17:18 <TabAtkins_> plinss: Perhaps reply online?
17:17:19 <glazou> Zakim, who is noisy?
17:17:31 <TabAtkins_> szilles: Even a diff against the old one, since it's structured the same.
17:17:33 <Zakim> glazou, listening for 12 seconds I could not identify any sounds
17:17:39 <fantasai> !?
17:17:58 <glazou> thank you Zakim to let me know my ears get older
17:18:00 <fantasai> http://wiki.csswg.org/ideas/radial-gradient-readability
17:18:08 <TabAtkins_> Topic: Radial Gradient Readability
17:18:29 <TabAtkins_> fantasai: At TPAC Tab and I decided to investigate the issue of making radial gradient syntax more readable, and more extnesible as a side-effect.
17:18:42 <TabAtkins_> fantasai: We worked with other WG members to come up with a syntax which we posted to the blog, per our action item.
17:18:48 <TabAtkins_> fantasai: We got some feedback, it was somewhat mixed.
17:19:12 <TabAtkins_> fantasai: One of the things we noted was that the proposed syntax used the "to" keyword to distinguish the size from the position, but that seemed confusing/awkward to people.
17:19:24 <TabAtkins_> fantasai: So we tweaked the proposed syntax a bit to remove that.  The new version is up on the wiki.
17:19:30 <TabAtkins_> fantasai: It's simpler than before.
17:19:49 <TabAtkins_> fantasai: The only thing needed is to distinguish the size from the position, but only one of them needs a special marker to resolve the parsing/reading ambiguity.
17:20:15 <TabAtkins_> fantasai: So the proposal is "radial-gradient( [<shape> || <size> ] [at <position>]?, <color-stops> )"
17:20:48 <TabAtkins_> fantasai: In the old syntax, you couldn't specify *just* an explicit size, because of the parsing ambiguity.  That's gone now.  It's also clearer that the number after "at" are a position.
17:21:01 <TabAtkins_> fantasai: An example would be "radial-gradient(5em circle at top left, ...)"
17:21:43 <TabAtkins_> jdaggett: You just put this proposal on the wiki today?
17:22:01 <TabAtkins_> fantasai: I put the latest version up yesterday, and rearranged the text today.
17:23:12 <TabAtkins_> florianr: The polls were inconclusive.  I support the readability initiative, but if it's not a big change, I'm not sure it's worthwhile, given the cost of syntax changing.
17:24:05 <TabAtkins_> howcome: I have a comment in general on replacing commas with keywords, such as "as" in attr().  I don't think it's worthwhile if we already ahve something working.  But I don't have a comment on gradients specifically.
17:25:02 <TabAtkins_> kimberly: I think the old syntax is only really useful with generating tools; it's too hard to write by hand.  The newer syntax can actually be remembered.
17:25:22 <TabAtkins_> florianr: I agree that it's more readable, but I'm not convinced it's particular more rememberable to be more writeable.
17:25:52 <TabAtkins_> sylvaing: Readability isn't just reading a stylesheet, it's also "does it make sense?".  If you see the gradient and some possible forms for it, can you pick the right one?
17:26:23 <dbaron> q+
17:26:37 <TabAtkins_> glazou: We already have four syntaxes in the wild.  This will be a fifth one.  Will impls drop the old ones rapidly?
17:26:57 <TabAtkins_> glazou: For editting tools, this will be hell.
17:27:06 <TabAtkins_> smfr: Webkit won't change its prefixed syntax.
17:27:31 <Bert> q+ to to ask [but feel free to ignore]: Would it help to pull the <shape> out of the parentheses and put it in the function name? radial-gradient(...) vs circle-gradient(...).
17:28:00 <Bert> q- to
17:28:03 <TabAtkins_> sylvaing: And MS might even keep its prefixed one around for a while, since it's compatible with existing content.
17:28:07 <Bert> q+ to ask [but feel free to ignore]: Would it help to pull the <shape> out of the parentheses and put it in the function name? radial-gradient(...) vs circle-gradient(...).
17:28:19 <TabAtkins_> divya: [didn't capture it well]
17:28:25 <glazou> Zakim, ack dbaron 
17:28:25 <Zakim> I see Bert on the speaker queue
17:28:37 <TabAtkins_> dbaron: I heard people comparing it to "the old syntax", but there's not one single old syntax.
17:29:16 <TabAtkins_> dbaron: I think the stuff that led to this change was several feature additions, and if we keep the "old syntax", we should reverse those feature changes as well.
17:29:28 <dbaron> Tab: that's the explicit sizing
17:29:37 <fantasai> q+
17:29:59 <Zakim> -tantek
17:30:20 <florianr> q+
17:30:44 <TabAtkins_> plinss: There's been discussion of prefixes around.  The *entire reason* we have prefixes is so we don't have to worry about legacy content here.  So I'm not going to accept any arguments about not changing something because there is prefixed content.
17:31:03 <TabAtkins_> sylvaing: There is a *lot* of content out there already in a particular syntax.
17:31:41 <Zakim> -danielweck
17:31:41 <arno> arno has joined #css
17:31:56 <Zakim> +??P12
17:32:01 <danielweck> Zakim, P12 is me
17:32:01 <Zakim> sorry, danielweck, I do not recognize a party named 'P12'
17:32:06 <danielweck> Zakim, ??P12 is me
17:32:06 <Zakim> +danielweck; got it
17:32:15 <dbaron> dbaron: I don't think relevant topics should be ruled out-of-order.
17:32:30 <glazou> SOUNDS LIKE A PLAN :-)
17:32:45 <dbaron> ack Bert
17:32:45 <Zakim> Bert, you wanted to ask [but feel free to ignore]: Would it help to pull the <shape> out of the parentheses and put it in the function name? radial-gradient(...) vs
17:32:49 <Zakim> ... circle-gradient(...).
17:33:18 <plinss> q?
17:33:36 <TabAtkins_> TabAtkins_: The shape is the *least* confusing part of the syntax.  Pulling it out wouldn't actually help.
17:33:46 <antonp> @sylaing: :-D
17:34:17 <TabAtkins_> fantasai: This isn't just about radial gradients, or just about *today's* radial gradients.  This "more readable" or "more CSS-y" syntax also lets us expand this more easily in the future, such as adding in the features present in the original webkit gradients.
17:35:00 <TabAtkins_> fantasai: This also applies for more than radial gradients.  The attr() function is an example.  It originally took only one argument.  Now it takes 3.  Perhaps it will take 4 in future (a selector for which children to take the attr from?).  As more args get added, it becomes more confusing.
17:35:26 <glazou> q+
17:35:27 <TabAtkins_> fantasai: What we're trying to do here is to take the CSS value syntax and the fundamental properties we use to develop that, and move that into functions as well, since we seem to have a good handle on extensibility in normal properties.
17:35:35 <glazou> Zakim, ack fantasai 
17:35:35 <Zakim> I see florianr, glazou on the speaker queue
17:36:09 <TabAtkins_> fantasai: If we stick with comma-separated, this limits our ability to extend not only radial gradients, but also other functions in the future.
17:36:18 <TabAtkins_> howcome: The current syntax still uses commas, though, right?
17:36:51 <TabAtkins_> fantasai: Yes, but in the traditional CSS meaning, separating a list of similar values.
17:37:08 <TabAtkins_> florianr: I'm receptive to fantasai's argument regarding extensibility.  I have nothing against it.
17:37:22 <TabAtkins_> florianr: So for the sake of extensibility, I'm rather in favor of this wiki proposal.
17:37:30 <plinss> ack florianr
17:37:31 <TabAtkins_> florianr: For readability, I'm less convinced in this particular case.
17:37:53 <TabAtkins_> florianr: Regarding prefixing, I agree we shouldn't consider it forbidden to change prefixed things.  But we also shouldn't pretend the cost is zero.
17:38:10 <jdaggett> ack glazou
17:38:10 <plinss> ack glazou
17:38:28 <TabAtkins_> glazou: Agree, and clarify what I said earlier.  I said it's hell for editors, but [something I missed].
17:38:46 <TabAtkins_> glazou: smfr said that webkit won't drop its prefix, so what will you do, use a second prefix?
17:39:14 <Zakim> +[IPcaller]
17:39:28 <TabAtkins_> glazou: Unfortunately, because this is so successful, it has left the field of "experimental feature".
17:39:28 <tantek> Zakim, IPcaller is tantek
17:39:28 <Zakim> +tantek; got it
17:39:48 <TabAtkins_> fantasai: No, webkit is not going to use a second prefix.  They'll switch to the new syntax when the drop prefixes.
17:39:57 <sylvaing> if I'm hearing this right, it sounds like prefixes are meant to enable us to fix success
17:40:01 <TabAtkins_> fantasai: So there will be no new prefixed versions.  They'll just implement the new syntax, unprefixed.
17:40:16 <TabAtkins_> glazou: Is that the case for everyone?
17:40:27 <TabAtkins_> fantasai: For Moz, yes.
17:40:32 <TabAtkins_> sylvaing: For MS, yes.
17:40:54 <TabAtkins_> florianr: Opera hasn't made a decision, but will likely do the same.
17:41:33 <TabAtkins_> plinss: Prefixes become more painful the longer we keep them around.  So the best solution to the entire prefix mess is for us to do our job and move things quickly.
17:41:48 <TabAtkins_> fantasai: So in that vein, Tab and I propose to resolve on this syntax and publish a WD.
17:42:43 <TabAtkins_> jdaggett: I want to reiterate that this syntax was just put up on the wiki yesterday?
17:43:10 <TabAtkins_> TabAtkins_: Yes, but it's identical to the old syntax except for the removal of "to", because the blog post comments pretty consistently found it confusing.
17:43:14 <divya> agreed with fantasai for new syntax
17:43:22 <divya> agreed
17:43:27 <TabAtkins_> plinss: There are some general objections, but nothing specific to this.  I hear general consensus.
17:43:39 <TabAtkins_> RESOLVED: Accept the new gradient syntax on the wiki.
17:43:50 <TabAtkins_> RESOLVED: Publish a new WD of Image Values.
17:44:16 <fantasai> ScribeNick: fantasai
17:44:33 <fantasai> TabAtkins: I've been resolving issues or logging them on CSS3 Lists
17:44:48 <fantasai> TabAtkins_: If ppl who have issues want to bring them up, bring them up. I'll respond; not leading right now.
17:45:14 <fantasai> howcome: I reviewed this over several months now, and I do think it has basically the toolkit it's offering authors is good.
17:45:25 <fantasai> howcome: They can create their own counter styles, and use them as if they were native to CSS.
17:45:38 <fantasai> howcome: I think Tab's done a great job of expressing commonly expressed list types
17:45:47 <fantasai> howcome: The draft has 2 parts I don't think fit in there.
17:45:52 <fantasai> howcome: First is pre-defined counter styles
17:45:58 <fantasai> howcome: They may or may not be correct
17:46:02 <fantasai> howcome: They may or not be used.
17:46:08 <fantasai> howcome: I believe most will not be used
17:46:18 <fantasai> howcome: And there may or may not be thousands of other list styles we should have in there.
17:46:25 <fantasai> howcome: I propose for now that we don't do pre-defined counter styles
17:46:29 <fantasai> howcome: So that's for Chapter 10
17:46:46 <fantasai> howcome: We can keep it in an informative appendix, or have W3C host a stylesheet authors could @import
17:46:55 <fantasai> jdaggett: I think that's a really good idea.
17:47:07 <fantasai> jdaggett: I like that idea because it allows for shared usage, allows ... implementations
17:47:17 <fantasai> jdaggett: Also makes it so the definitions are malleable
17:47:21 <glazou> q+
17:47:22 <fantasai> jdaggett: There's a lot less burden to adding things.
17:47:39 <fantasai> jdaggett: ... haven't totally verified the correctness of
17:47:58 <fantasai> florianr: I think there was a clear benefit to coming up with all these styles initially, to ensure the generic mechanism can represent them alll
17:48:08 <fantasai> florianr: But I agree that it's overhead to verify that they're right, to implement, to test, etc.
17:48:16 <fantasai> florianr: For not much benefit, since they can be written in a stylesheet
17:48:35 <fantasai> florianr: I would keep them as an example of how to do it
17:48:46 <fantasai> glazou: Hosting the stylesheet at W3C will generate a lot of traffic, and W3C pays for that.
17:48:56 <fantasai> glazou: Validator for instance already generates a lot of traffic.
17:49:10 <fantasai> glazou: it's very expensive
17:49:21 <fantasai> howcome: We host the Core Stylesheets, and bandwidth was more expensive then.
17:49:39 <fantasai> jdaggett: Requiring it means we have to verify that it's right.
17:50:06 <glazou> let's move the whole WG under chapter 11 :-p
17:50:07 <fantasai> TabAtkins_: Proposal: we take Chapter 10, maybe 11 etc, put them into a separate spec
17:50:20 <Zakim> -tantek
17:50:31 <fantasai> TabAtkins_: They could remain informative, or be normative. Either way the status of the predefined styles won't hinder or affect the status of the overall Lists spec
17:50:37 <fantasai> jdaggett: I would be fine moving these out to a different spec
17:50:48 <fantasai> jdaggett: I think the proposal we were talking about would be better here [...
17:50:56 <fantasai> jdaggett: This is where we're defining the counter styles
17:51:22 <Bert> q+ to suggest making the chapter 10 into a Note.
17:51:22 <fantasai> TabAtkins: The problem with keeping them here is that it's harder to rev the entire Lists spec than to rev a separate Lists document.
17:51:32 <fantasai> glazou: I have compromise. There's a tool we never use: W3C Note
17:51:39 <fantasai> glazou: They are much simpler than specs, almost informative.
17:51:47 <fantasai> glazou: We could release somethng there, it's visible and usable
17:51:54 <dbaron> Today that would be called a "Working Group Note", I think.
17:52:10 <Zakim> +[IPcaller]
17:52:14 <fantasai> glazou: Maybe not 100% correct, but if you find a mistake, please help us.
17:52:19 <fantasai> q+
17:52:21 <tantek> Zakim, IPcaller is tantek
17:52:21 <Zakim> +tantek; got it
17:52:28 <glazou> Zakim, ack glazou 
17:52:28 <Zakim> I see Bert, fantasai on the speaker queue
17:52:33 <dbaron> Also, we should keep the CSS2 styles in the spec.
17:52:35 <Bert> q-
17:52:38 <fantasai> florianr: But it would be just informative for authors, not asking UA styles to implement them.
17:52:49 <Zakim> -tantek
17:52:50 <fantasai> howcome: I think we could make rapid progress on Lists if this issue goes away
17:52:58 <fantasai> dbaron: Which parts of Chapter 11 are you removing?
17:53:03 <tantek> CSS2.1
17:53:06 <fantasai> TabAtkins_: Everything except the CSS2.1 styles
17:53:23 <fantasai> TabAtkins_: But parts about the longhand chinese styles would go with Chapter 10, and Chapter 12 as well
17:53:35 <fantasai> dbaron: 2.1 had one of the CJK styles, and I think we should keep the stuff that was in 2.1 in CSS3 Lists
17:53:56 <fantasai> howcome: I agree, but Tab can express it up to 1000 with @counter-style
17:54:11 <fantasai> florianr: I'm not convinced the predefined styles need to go with the new things.
17:54:26 <fantasai> jdaggett: Why don't we resolve to take them out, and then figure out how to parcel them out at a later point
17:54:33 <fantasai> dbaron: I'd still like to know what we're taking out and what we're keeping
17:54:44 <fantasai> TabAtkins_: I would keep the ones defined in 2.1, defining them in @counter-style is possible and easy
17:54:47 <glazou> glazou has joined #css
17:54:55 <fantasai> TabAtkins lists styles in 2.1
17:54:58 <tantek> when trying to rejoin the call
17:55:09 <fantasai> TabAtkins notes they're very badly specified in 2.1
17:55:20 <jdaggett> we're talking about moving out section 10, 11, 12 but keeping things from 2.1
17:55:23 <fantasai> TabAtkins: In 2.0 we had ideographic, not in 2.1
17:55:33 <fantasai> dbaron: The stuff in 2.0 is widely implemented, we should keep it.
17:55:46 <fantasai> fantasai: It's also required for EPUB
17:56:05 <fantasai> q+
17:56:21 <fantasai> howcome: I don't think we should do that, we took them out of 2.1
17:56:30 <fantasai> howcome: We found a better way for ppl to create these types themselves.
17:56:36 <fantasai> dbaron: *Can* they create them themselves?
17:56:39 <Zakim> +[IPcaller]
17:56:56 <tantek> hence keep stuff that was in 2.1 rather than 2.0
17:56:56 <tantek> Zakim, IPcaller is tantek
17:56:56 <Zakim> +tantek; got it
17:57:02 <fantasai> TabAtkins: The chinese-informal styles can be expressed using hacks around fallback. I put an example of how to do it
17:57:14 <fantasai> TabAtkins_: I can do it up to 999 by creating 11 counter styles
17:57:20 <fantasai> TabAtkins_: Might be able to drop it to 3 styles
17:57:32 <fantasai> TabAtkins_: I could copy-paste it, wouldn't expect an average author to do. 
17:58:13 <fantasai> florianr: Can we say we remove everything except what was in 2.1 and maybe in addition to that what was in 2.0 and is also interoperably implemented?
17:58:32 <plinss> q?
17:58:37 <fantasai> :( :( :(
17:58:51 <glazou> howcome: http://weasyprint.org/
17:59:43 <tantek> plinss, remaining agenda items getting pushed to next week presumably?
18:00:10 <Zakim> -danielweck
18:00:17 <danielweck_> danielweck_ has joined #css
18:00:35 <Zakim> -stearns
18:00:46 <tantek> millions of authors? are there that many that want/need the extra features?
18:01:28 <fantasai> fantasai say something and nobody minutes it
18:01:38 <fantasai> other people say stuff and fantasai didn't minute it either
18:01:48 <divya> :)
18:01:52 <divya> sorry fantasai 
18:02:06 <smfr> gtg
18:02:09 <jdaggett> the problem with predefined lists is that 
18:02:10 <glazou> tantek: I disagree, numbering is part of culture, it should just work
18:02:13 <Zakim> -smfr
18:02:17 <fantasai> howcome: The problem we'll have is we're surely going to find errors in that list, and if we hard-code it into the UA we're going to be stuck with those errors.
18:02:19 <jdaggett> 1) we have to assure the list is correct
18:02:27 <tantek> glazou - that's a reasonable distinction.
18:02:33 <jdaggett> 2) we need to decide the priority
18:02:34 <Zakim> - +1.510.364.aaaa
18:02:45 <fantasai> florianr: People will rely on it being wrong
18:02:54 <jdaggett> and that's hard because stylistic variations occur
18:03:00 <fantasai> fantasai: Won't rely on it being wrong, will rely on it being correct and occasionally be disappointed
18:03:04 <jdaggett> which is more important?
18:03:07 <fantasai> TabAtkins: I can take either way.
18:03:16 <fantasai> FWIW, I have no objection to pulling them into a separate spec
18:03:34 <dbaron> I thought this was the main thing in the lists spec.
18:03:37 <fantasai> just to foisting the entire responsibility onto the authors 
18:04:05 <fantasai> howcome: If we put it in a new spec, it shouldn't be necessarily predefined
18:04:10 <vhardy> sorry, need to drop off.
18:04:15 <Zakim> -Oliver_Goldman
18:04:21 <tantek> I'm in favor of whatever helps the editor move more quickly.
18:04:22 <dbaron> I tend towards agreeing with fantasai; I also need to leave.
18:04:52 <fantasai> plinss: I'm hearing no objection to splitting out the predefined counter styles into a separate spec
18:05:08 <fantasai> howcome: this resolves a bunch of my objections
18:05:23 <Zakim> -dbaron
18:05:41 <Zakim> -glazou
18:05:42 <Zakim> -kimberly
18:05:43 <fantasai> RESOLVED: split predefined counter styles into a separate spec
18:05:44 <Zakim> -howcome
18:05:44 <Zakim> -jdaggett
18:05:44 <Zakim> -antonp
18:05:45 <Zakim> -divya
18:05:45 <Zakim> -[Microsoft]
18:05:47 <Zakim> -SteveZ
18:05:48 <Zakim> -[Microsoft.a]
18:05:54 <Zakim> -florianr
18:05:56 <Zakim> -kojiishi
18:05:58 <Zakim> -Bert
18:06:00 <Zakim> -plinss
18:06:03 <Zakim> -tabatkins_
18:06:05 <Zakim> -tantek
18:06:06 <Zakim> Style_CSS FP()12:00PM has ended
18:06:09 <Zakim> Attendees were glazou, jdaggett, plinss, florianr, divya, sylvaing, antonp, stearns, [Microsoft], +1.510.364.aaaa, johnjan, fantasai, tabatkins_, Bert, dbaron, smfr, danielweck,
18:06:11 <Zakim> ... howcome, Oliver_Goldman, kojiishi, tantek, SteveZ
18:06:56 <fantasai> Meeting closed.
18:13:48 <oyvind> oyvind has left #css
18:21:08 <SteveZ_> SteveZ_ has joined #css
18:59:03 <brianman> brianman has joined #css
19:13:23 <danielfilho> danielfilho has joined #css
19:14:51 <arno> arno has joined #css
19:17:26 <danielfilho> danielfilho has joined #css
19:20:59 <danielfilho> danielfilho has joined #css
19:23:43 <sylvaing> sylvaing has joined #css
19:24:31 <danielfilho> danielfilho has joined #css
19:27:50 <danielfilho> danielfilho has joined #css
19:30:39 <stearns> stearns has joined #css
19:31:31 <danielfilho> danielfilho has joined #css
19:35:02 <danielfilho> danielfilho has joined #css
19:45:40 <drublic> drublic has joined #css
19:49:58 <sylvaing> sylvaing has joined #css
19:53:48 <danielfilho_> danielfilho_ has joined #css
20:14:24 <arno> arno has joined #css
20:33:19 <Zakim> Zakim has left #css
21:39:08 <dbaron> dbaron has joined #css
21:46:24 <TabAtkins> TabAtkins has joined #css
22:03:48 <sylvaing> sylvaing has joined #css
22:13:05 <TabAtkins> fantasai: Just hit an interesting use-case where using :matches() and the subject indicator is much more difficult than using :has().
22:13:23 <TabAtkins> You want to select the preceding tr to the scope, even if it's in a preceding tbody.
22:13:28 <TabAtkins> With has, this is:
22:13:57 <TabAtkins> :matches(tr:has(+tr:scope), tbody:has(+tbody>tr:first-child:scope) > tr:last-child)
22:14:04 <TabAtkins> With matches+subject indicator, this is:
22:14:40 <TabAtkins> :matches( tr! + tr:scope, :matches(tbody! + tbody > tr:first-child:scope) > tr:last-child )
22:14:59 <TabAtkins> I think the use of :matches() solely to scope the subject indicator is confusing there.
22:15:07 <TabAtkins> It took me a little bit of thinking to come up with it, at least.
22:21:16 <drublic> drublic has joined #css
23:01:23 <howcome> howcome has left #css
23:59:33 <tantek> tantek has joined #css