15:56:07 <RRSAgent> RRSAgent has joined #css
15:56:07 <RRSAgent> logging to http://www.w3.org/2013/09/04-css-irc
15:56:15 <Zakim> Zakim has joined #css
15:56:23 <plinss> zakim, this will be style
15:56:23 <Zakim> ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 4 minutes
15:57:15 <Zakim> Style_CSS FP()12:00PM has now started
15:57:20 <Zakim> +plinss
15:57:35 <rhauck> rhauck has joined #css
15:57:39 <krit1> krit1 has joined #css
15:58:02 <glazou> glazou has joined #css
15:58:16 <glazou> hello, finally made it :-)
15:58:30 <Zakim> +??P18
15:58:30 <glazou> Zakim, this will be Style
15:58:31 <Zakim> ok, glazou, I see Style_CSS FP()12:00PM already started
15:58:38 <glazou> Zakim, code?
15:58:38 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
15:59:01 <Zakim> + +1.413.325.aaaa
15:59:16 <krit1> Zakim, who is on the phone?
15:59:16 <Zakim> On the phone I see plinss, ??P18, +1.413.325.aaaa
15:59:19 <Zakim> + +1.408.652.aabb
15:59:35 <glazou> Zakim, aabb is me
15:59:35 <Zakim> +glazou; got it
15:59:56 <Zakim> +??P32
15:59:58 <Zakim> + +1.415.832.aacc
16:00:01 <dcramer> 413.325.1307 is Dave Cramer from Hachette
16:00:02 <glenn> zakim, ??p332 is me
16:00:02 <Zakim> sorry, glenn, I do not recognize a party named '??p332'
16:00:09 <Zakim> +[IPcaller]
16:00:09 <Zakim> +??P40
16:00:11 <glenn> zakim, ??p32 is me
16:00:11 <Zakim> +glenn; got it
16:00:13 <smfr> smfr has joined #css
16:00:19 <krit> Zakim, P18 is me
16:00:19 <Zakim> sorry, krit, I do not recognize a party named 'P18'
16:00:22 <jdaggett> zakim, ipcaller is me
16:00:23 <Zakim> +jdaggett; got it
16:00:27 <SteveZ> SteveZ has joined #css
16:00:30 <oyvind> oyvind has joined #css
16:00:30 <Ms2ger> Zakim, aacc is dcramer
16:00:31 <Zakim> +dcramer; got it
16:00:37 <Zakim> +Lea
16:00:37 <Zakim> +Stearns
16:00:46 <krit> Zakim, ??P18 is me
16:00:46 <Zakim> +krit; got it
16:00:48 <Zakim> + +1.415.615.aadd
16:01:09 <dael> dael has joined #css
16:01:20 <rhauck> Zakim, aadd is me
16:01:20 <Zakim> +rhauck; got it
16:01:21 <Zakim> +smfr
16:01:48 <Zakim> + +1.610.324.aaee
16:01:54 <antonp> antonp has joined #css
16:01:59 <dael> zakim, aaee is me
16:02:00 <Zakim> +dael; got it
16:02:05 <ChrisL> ChrisL has joined #css
16:02:20 <smfr> smfr has changed the topic to: http://lists.w3.org/Archives/Public/www-style/2013Sep/0061.html
16:02:32 <florian> florian has joined #css
16:02:51 <Zakim> +Plh
16:03:03 <Zakim> + +44..aaff
16:03:09 <Zakim> +Bert
16:03:24 <Zakim> +[Apple]
16:03:25 <hober> Zakim, Apple has me
16:03:26 <Zakim> +hober; got it
16:03:42 <Zakim> +fantasai
16:04:00 <SimonSapin> How do I tell Zakim about a room with two people?
16:04:16 <Zakim> +[IPcaller]
16:04:20 <Zakim> + +93192aagg
16:04:24 <antonp> Zakim, aagg is me
16:04:24 <Zakim> +antonp; got it
16:04:44 <florian> Zakim, IPcaller has me
16:04:48 <Zakim> +florian; got it
16:04:49 <ChrisL> zakim, simon has foo
16:04:50 <Zakim> sorry, ChrisL, I do not recognize a party named 'simon'
16:05:11 <SimonSapin> Zakim, aaff is [Mozilla]
16:05:11 <Zakim> +[Mozilla]; got it
16:05:13 <Zakim> + +1.520.280.aahh
16:05:18 <SimonSapin> [Mozilla] has SimonSapin
16:05:24 <SimonSapin> Zakim, [Mozilla] has SimonSapin
16:05:24 <Zakim> +SimonSapin; got it
16:05:29 <SimonSapin> Zakim, [Mozilla] has dbaron
16:05:29 <Zakim> +dbaron; got it
16:05:38 <bkardell> 520.280.3584 is bkardell
16:06:01 <fantasai> ScribeNick: fantasai
16:06:01 <antonp> ScribeNick: antonp
16:06:05 <fantasai> ScribeNick: fantasai
16:06:17 <fantasai> plinss: Any additions to the agenda
16:06:37 <fantasai> Topic: Unicode-Range
16:06:45 <fantasai> SimonSapin: In the Syntax spec, some changes from CSS2.1
16:06:57 <fantasai> SimonSapin: Tried to match Fonts spec, do parsing/normalization of unicode-range in tokenizer
16:07:02 <fantasai> SimonSapin: But fonts spec changed
16:07:13 <fantasai> SimonSapin: So want to revert changes, and do what CSS2.1 does for UNICODE-RANGE
16:07:14 <Zakim> +[Microsoft]
16:07:28 <israelh> israelh has joined #CSS
16:07:53 <fantasai> SimonSapin: Prefer to do parsing in Syntax, have unicode-range return pair of integers rather than string
16:08:14 <Rossen_> Rossen_ has joined #css
16:08:15 <SimonSapin> s/Prefer/Tab prefers/
16:08:27 <Zakim> + +33.9.81.36.aaii
16:08:46 <fantasai> fantasai: Well, I know we have implementations of the 2.1 tokenization
16:08:52 <ChrisL> zakim, aaii is me
16:08:52 <Zakim> +ChrisL; got it
16:09:00 <fantasai> SimonSapin: They're not testable
16:09:13 <fantasai> dbaron: Some cases can be tested via obscure counter-reset/increment declarations
16:09:54 <jerenkrantz> jerenkrantz has joined #css
16:10:12 <fantasai> dbaron: But don't think it's worth worrying about
16:10:20 <Zakim> +[Microsoft.a]
16:10:31 <Rossen_> zakim, microsoft has me
16:10:31 <Zakim> +Rossen_; got it
16:10:31 <fantasai> dbaron: 2 questions - what is the desired behavior, and which spec?
16:10:40 <fantasai> dbaron: So first, what's the desired behavior
16:10:50 <fantasai> jdaggett: Desired behavior in terms of ... ?
16:10:54 <darktears> darktears has joined #css
16:10:59 <fantasai> dbaron: What are the differences in behavior that we're discussing
16:11:10 <fantasai> SimonSapin: Fonts spec changed details of UNICODE-RANGE parsing in last WD
16:11:17 <Zakim> + +1.212.318.aajj
16:11:22 <fantasai> SimonSapin: e.g. ranges beyond Unicode used to be clipped, but are now invalid
16:11:29 <jerenkrantz> zakim, aajj is me
16:11:29 <Zakim> +jerenkrantz; got it
16:11:32 <fantasai> jdaggett: How does that impact Syntax?
16:11:42 <fantasai> SimonSapin: Because Syntax defines tokenization
16:12:01 <SimonSapin> SimonSapin: Syntax used to do clipping in the tokenizer
16:12:03 <fantasai> jdaggett: Only opposition is Tab, and he's not on the call atm
16:12:13 <fantasai> SimonSapin: What came out of ML discussion was Tab, was compromise
16:12:20 <fantasai> SimonSapin: Tokenizer would have pair of integers
16:12:34 <fantasai> SimonSapin: Leave to fonts what to do with integers, depending on whether increasing/decreasing etc.
16:12:38 <fantasai> SimonSapin: Just two integers given back
16:13:04 <fantasai> jdaggett: impact of what we're talking about is whether parser takes something as UNICODE-RANGE or not
16:13:17 <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Sep/0019.html
16:13:18 <Zakim> + +1.832.797.aakk
16:13:18 <fantasai> jdaggett: Cases where author will want to use that syntax somewhere else is almost never
16:13:38 <leif> leif has joined #css
16:14:05 <fantasai> SimonSapin: Proposal is to remove part of syntax that defines unicode-range range restrictions
16:14:52 <fantasai> plinss: Does this impact Fonts, which is going ot CR?
16:14:58 <florian> florian has joined #css
16:15:02 <SimonSapin> SimonSapin: ie. removing this section: https://dvcs.w3.org/hg/csswg/raw-file/aa1b58939f73/css-syntax/Overview.html#set-the-unicode-ranges-range
16:15:26 <fantasai> TabAtkins: Could remove stuff from Fonts spec, because covered by Syntax
16:15:50 <fantasai> fantasai: Don't think we should be removing anything from Fonts spec, Syntax is kindof early stages, would like Fonts to be complete as of now.
16:16:03 <fantasai> jdaggett agrees
16:16:14 <fantasai> ChrisL: Don't want Fonts spec to change
16:16:21 <fantasai> ChrisL: Given it's going to CR
16:16:41 <fantasai> TabAtkins: UNICODE-RANGE in CSS2.1 accepts syntax that will never be needed/used
16:16:42 <Zakim> +??P98
16:16:52 <leif> Zakim, I am ??P98
16:16:52 <Zakim> +leif; got it
16:16:57 <fantasai> TabAtkins: Would like those cases to not parse as UNICODE-RANGE.
16:17:04 <fantasai> TabAtkins: But fine with range-restrictions staying in Fonts spec
16:17:36 <fantasai> ...
16:17:44 <fantasai> TabAtkins: I would like to kill U+1?3
16:17:50 <SimonSapin> examples of bad syntax: U+1?3, U+1?-30
16:17:52 <fantasai> TabAtkins: Want to make that invalid at the tokenization level
16:18:10 <fantasai> SimonSapin, I think the second one is already invalid in 2.1
16:18:24 <SimonSapin> fantasai, it is valid in 2.1
16:18:32 <fantasai> plinss: Any other comments?
16:19:04 <SimonSapin> 2.1’s definition: u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
16:19:10 <fantasai> fantasai: No changes to Fonts spec, right?
16:19:12 <fantasai> right
16:19:35 <fantasai> fantasai: So only question is whether UNICODE-RANGE uses the 2.1 syntax or Syntax syntax
16:20:02 <fantasai> jdaggett: [talks about splitting definitions across specs]
16:20:41 <fantasai> fantasai: If we're changing definition fo UNICODE-RANGE, we need to errata 2.1
16:20:42 <florian> florian has left #css
16:20:43 <{Darktears}> {Darktears} has joined #css
16:20:44 <florian> florian has joined #css
16:20:48 <fantasai> fantasai: Can't have two different definitions depending which spec you read
16:21:12 <fantasai> plinss: Anyone objecting to Tab's change?
16:21:43 <fantasai> TabAtkins: Simon's proposal was to accept 2.1 syntax, and have Font's processing make things invalid
16:21:50 <fantasai> SimonSapin: I'm fine with Tab's proposal as well
16:22:22 <fantasai> fantasai: Only thing that bothers me is that we have implementations on the 2.1 tokenization
16:22:34 <fantasai> fantasai: They'd have to go back and change
16:22:45 <fantasai> TabAtkins: It's (for the most part) author-undetectable
16:22:47 <MaRakow> MaRakow has joined #CSS
16:22:56 <rhauck1> rhauck1 has joined #css
16:23:36 <fantasai> Bert: I'd like to see the regex first, if that's ok
16:23:56 <fantasai> TabAtkins: Ok, I will send to ML
16:25:00 <fantasai> RESOLVED: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more restrictive in what it takes, per Tab's proposal
16:25:05 <fantasai> No changes to Fonts
16:25:34 <jdaggett> http://dev.w3.org/csswg/css-fonts/doc-20130711-LCWD.html
16:25:39 <fantasai> plinss: Fonts to CR?
16:26:04 <fantasai> jdaggett: There was one outstanding issue on 'ordinals', but that got cleared up over ML with examples/pics
16:26:08 <bradk> bradk has joined #css
16:26:18 <fantasai> jdaggett: Question is, do we need another LC or go to CR?
16:26:39 <fantasai> jdaggett: I don't think there's a huge impact on implementations from any of these changes
16:26:40 <ChrisL> q+
16:26:52 <fantasai> jdaggett: Most significant change is removing 'auto' value
16:27:10 <plinss> ack next
16:27:17 <fantasai> fantasai: I don't think we need to go through another LC, changes aren't very major
16:27:50 <fantasai> ChrisL: Spec is currently listing everything as major changes, most are minor
16:28:01 <fantasai> ChrisL: But several are substantial [lists]
16:28:08 <fantasai> ChrisL: Reorder feature precedence, 'auto', etc.
16:28:40 <fantasai> ChrisL: All these need to be addressed, and argue that they are minor
16:29:10 <fantasai> ChrisL: I'd rather not do another LC
16:29:23 <Zakim> +BradK
16:29:39 <fantasai> jdaggett: Auto value was never implemented
16:29:43 <fantasai> jdaggett: Not part of CSS2 spec
16:30:03 <fantasai> jdaggett: Only removing a single value, that was never implemented
16:30:51 <dbaron> I think ChrisL was saying that we need to argue that the changes weren't substantial in order to go from LC to CR.
16:30:56 <dbaron> (for minutes)
16:31:10 <dbaron> s/substantial/substantive/
16:31:20 <fantasai> [process discussion]
16:31:26 <ChrisL> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr
16:31:41 <fantasai> jdaggett: So I should revise Changes section to not list changes as major
16:32:02 <ChrisL> quote "Some reasons for declining a transition request
16:32:02 <ChrisL>     The technical report has been substantively modified since the previous transition. In this case, the document is returned to the Working Group for further work."
16:32:45 <fantasai> jdaggett: Could also add an "impact" statement, to describe what the impact is on implementations
16:32:53 <fantasai> jdaggett: For most of these, no impact, because there aren't implementations
16:33:48 <fantasai> [discussion of how to style DoC]
16:35:12 <fantasai> [more discussion of handling DoC]
16:35:41 <fantasai> ChrisL: I'm trying to be pre-emptively awkward here, to make the transition call go smoothly
16:36:06 <fantasai> plinss: I get your point Chris, and but for this point, i don't think this is worth taking up group time
16:36:20 <fantasai> plinss: I'd rather take up 10 min of transition call time than 10 min of CSSWG telecon time
16:36:25 <fantasai> plinss: Any objections to CR?
16:36:37 <fantasai> SteveZ: Sent email this morning on 'ordinal' issue
16:36:52 <ChrisL> ok. socan we have a minuted decision to request CR followed by a transition request email
16:37:00 <fantasai> SteveZ: I have no text that's there, just want to point out that there's an aspect of ordinals that is in the OT definition, that really no longer applies
16:37:07 <ChrisL> I can help draft the transition request if that would help
16:37:24 <fantasai> SteveZ: The original conception of 'ordinal' feature was that you could mark a paragraph, and it would ordinal everything that was number followed by letters
16:37:37 <fantasai> SteveZ: Problem was that writing rules for all languages was troublessome
16:37:48 <fantasai> SteveZ: So you need to apply  the feature around just the numbers
16:37:54 <fantasai> SteveZ: as the example shows
16:38:03 <fantasai> SteveZ: Might want to say that in the text
16:38:15 <fantasai> jdaggett: Don't think it's necessary
16:38:33 <fantasai> jdaggett: I can add to the sentence within the example, just to indicate that it's not applied to the paragraph
16:38:37 <fantasai> SteveZ: That sounds good to me
16:38:47 <fantasai> SteveZ: Just want a warning to not apply it to the whole paragraph
16:39:17 <fantasai> jdaggett: Any objections to CR?
16:39:22 <fantasai> fantasai: No, let's do it!
16:39:25 <lmclister> lmclister has joined #css
16:39:28 <ChrisL> none at all
16:39:38 <fantasai> RESOLVED: Fonts Level 3 to CR
16:39:54 <fantasai> ACTION ChrisL Send transition request
16:39:54 <trackbot> Created ACTION-576 - Send transition request [on Chris Lilley - due 2013-09-11].
16:39:58 <fantasai> Topic: CSS Cascade
16:40:16 <fantasai> http://dev.w3.org/csswg/css-cascade/issues-lc-2013
16:40:43 <ChrisL> rrsagent, draft minutes
16:40:43 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/04-css-minutes.html ChrisL
16:41:14 <fantasai> fantasai summarizes all the comments
16:41:26 <glazou> go ahead!
16:41:31 <fantasai> RESOLVED: Cascade L3 to CR
16:42:00 <fantasai> Topic: text-combine-horizontal and font features
16:42:23 <Zakim> - +1.832.797.aakk
16:43:01 <bradk> bradk has joined #css
16:43:22 <Zakim> + +1.281.627.aall
16:43:30 <TabAtkins> zakim, aall is me
16:43:30 <Zakim> +TabAtkins; got it
16:43:38 <TabAtkins> zakim, aakk was me
16:43:38 <Zakim> I don't understand 'aakk was me', TabAtkins
16:44:13 <fantasai> fantasai: [summarizes discussion]
16:44:17 <fantasai> jdaggett: I'm fine with that
16:44:23 <fantasai> SteveZ: Can I raise a related issue?
16:44:28 <fantasai> jdaggett: Can you raise it on the list?
16:44:38 <fantasai> plinss: Will it impact this discussion?
16:44:41 <fantasai> SteveZ: Don't know
16:45:01 <fantasai> SteveZ: When I contacted Adobe font people about compression issue, they basically said "don't do that"
16:45:27 <fantasai> SteveZ: So I had a private conversation with Koji, who said 'but we have to do that, because the WebKit based publication guide wants to be able to ensure that all their text fits within an em-square for body text'
16:45:36 <fantasai> SteveZ: Issue I'm concerned about is making the default for text-combine do the compression
16:45:43 <fantasai> SteveZ: Rather than have a property to turn it on
16:45:53 <Zakim> -Bert
16:45:55 <fantasai> SteveZ: Which would remove many of the cases that we seem to be stumbling over
16:46:07 <fantasai> jdaggett: This issue is exactly what we discussed 1.5 years ago.
16:46:14 <fantasai> jdaggett: We had a property to control it
16:46:19 <fantasai> jdaggett: But seemed overkill to me
16:46:25 <fantasai> jdaggett: Maybe post to the list, what you want
16:46:35 <fantasai> jdaggett: We've added this property, and then took it out, and now you're leaning towards bringing it back
16:46:46 <fantasai> SteveZ: What I want is not have the default be compression
16:47:20 <dbaron> fantasai: reason default is compression for CSS and not for indesign is that in indesign author can see and tweak the result and will adjust it; in CSS author doesn't see it and doesn't know exactly where lines will break, etc.
16:47:43 <dbaron> fantasai: important for publishers not to have overlap.  Can't manually check with CSS.  So better to force 1em compression so they can guarantee there's no conflict.
16:47:54 <tantek> tantek has joined #css
16:47:58 <ChrisL> rrsagent, make logs public
16:48:03 <ChrisL> rrsagent, draft minutes
16:48:03 <RRSAgent> I have made the request to generate http://www.w3.org/2013/09/04-css-minutes.html ChrisL
16:48:54 <fantasai> SteveZ: Use in headings usually doesn't result in conflicts
16:49:00 <ChrisL> ChrisL has joined #css
16:49:16 <fantasai> jdaggett: I'd like to capture the resolution that for now we take out the automatic disabling of full-width variants
16:49:37 <fantasai> fantasai: As long as we are ok to reopen if we wind up with fonts that would benefit, I'm ok with that
16:50:20 <fantasai> RESOLVED: TCY doesn't disable font-variant: full-width. Revisit if fonts start to become popular that would benefit from this extra interaction
16:50:44 <fantasai> Topic: CSS3 Images
16:50:50 <fantasai> Swapping order of color stop fixul
16:51:18 <fantasai> TabAtkins: Gradients require color stops to be in order
16:51:33 <fantasai> TabAtkins: If not, push later ones to position of next position
16:51:44 <fantasai> TabAtkins: Rules for fixup right now they work, but result in weird ness for animations
16:51:51 <smfr> http://lists.w3.org/Archives/Public/www-style/2013Aug/0296.html
16:51:53 <fantasai> TabAtkins: Step 2-3 requires layout infos
16:52:06 <fantasai> TabAtkins: Back when doing gradients, Shane suggested changing this
16:52:16 <fantasai> TabAtkins: I think we shot this down because fatigued with gradient changes
16:52:22 <fantasai> TabAtkins: But should revisit
16:52:24 <fantasai> TabAtkins: Small change
16:52:33 <fantasai> TabAtkins: Rendering change is fairly minor
16:52:38 <fantasai> TabAtkins: And not likely to be many cases affected
16:52:54 <fantasai> TabAtkins: So Suggest swapping order of steps, so that can transition gradients without requiring layout
16:53:06 <Zakim> -jdaggett
16:53:08 <fantasai> rhauck: Any specific examples that would change?
16:53:20 <leaverou> s/rhauck/Lea/
16:53:26 <ChrisL> ChrisL has joined #css
16:53:27 <fantasai> sorry :)
16:53:31 <TabAtkins> http://dev.w3.org/csswg/css-images/#color-stop-syntax
16:53:54 <fantasai> florian: If we do this, should go into L3
16:54:06 <TabAtkins> linear-gradient(red 100px, blue 0px, white, yellow 200px)
16:54:13 <TabAtkins> currently, fixup moved the blue one first, then figures out the white positino, so you get
16:54:24 <fantasai> krit: We don't order when we have transitions
16:54:26 <fantasai> ?
16:54:38 <fantasai> krit: Asking, you asked to move the ordering step to the last possible way
16:54:44 <fantasai> krit: When you have transitions, you do not order the color stops
16:54:50 <fantasai> TabAtkins: Correct
16:54:57 <fantasai> TabAtkins: You position first/last stops and interpolate
16:55:03 <fantasai> TabAtkins: Then at layout time do the stop fixup
16:55:07 <TabAtkins> so currently, you end up with red 100px, blue 100px, white 150px, yellow 200px.
16:55:08 <fantasai> krit: Ok, I'm fine with this
16:55:18 <TabAtkins> With my change, you'd end up with red 100px, blue 0px, white 100px, yellow 200px
16:55:30 <TabAtkins> and at layout, it'd be fixed up to red 100px, blue 100px, white 100px, yellow 200px.
16:55:36 <TabAtkins> but you'd do transitions with the prior one
16:55:46 <fantasai> Leif: Given implications of this, I think I'd like some time to review
16:55:52 <fantasai> TabAtkins: Ok
16:56:05 <fantasai> plinss: Come to back to this for F2F/
16:56:21 <fantasai> Topic: CSS3 MQ Errata
16:56:34 <Zakim> -Lea
16:56:36 <fantasai> dbaron: There was a thread, someone pointed out obvious mistake in 2 places
16:56:48 <fantasai> dbaron: Mistake is in REC errata
16:57:02 <fantasai> florian: I've updated MQ4, asked plh to update errata
16:57:15 <fantasai> plh: Haven't processed email yet, but should be done today
16:57:19 <fantasai> florian: Ok, thanks!
16:57:35 <fantasai> florian: As for folding them into MQ and publishing updated REC, we thought to wait awhile to do that.
16:57:44 <fantasai> florian: Maybe we'll run into more issues
16:57:52 <fantasai> florian: Maybe wait until end of year
16:57:58 <fantasai> fantasai: Maybe aim for TPAC
16:58:38 <fantasai> fantasai: Put it on TPAC agenda, assign any relevant action items then
16:58:55 <fantasai> plinss: F2F next week, please add your items to agenda so we can use time productively!
16:58:59 <Zakim> -BradK
16:59:00 <Zakim> -rhauck
16:59:01 <Zakim> -jerenkrantz
16:59:01 <fantasai> plinss: See you all next week
16:59:03 <Zakim> -smfr
16:59:03 <Zakim> -[Apple]
16:59:04 <Zakim> -leif
16:59:05 <Zakim> -ChrisL
16:59:05 <Zakim> -glazou
16:59:05 <Zakim> -dael
16:59:05 <Zakim> -glenn
16:59:05 <Zakim> -antonp
16:59:06 <jerenkrantz> jerenkrantz has left #css
16:59:06 <Zakim> -Stearns
16:59:06 <Zakim> -krit
16:59:07 <Zakim> -plinss
16:59:08 <Zakim> - +1.413.325.aaaa
16:59:09 <Zakim> -fantasai
16:59:09 <Zakim> -Plh
16:59:09 <Zakim> -[Microsoft.a]
16:59:11 <Zakim> -[Mozilla]
16:59:15 <Zakim> - +1.520.280.aahh
16:59:31 <Zakim> -TabAtkins
16:59:38 <cabanier> cabanier has joined #css
16:59:39 <leif> leif has left #css
16:59:40 <dcramer> dcramer has left #css
17:00:07 <Zakim> -dcramer
17:00:11 <Zakim> -[IPcaller]
17:00:28 <Zakim> -??P40
17:05:28 <Zakim> disconnecting the lone participant, [Microsoft], in Style_CSS FP()12:00PM
17:05:31 <Zakim> Style_CSS FP()12:00PM has ended
17:05:31 <Zakim> Attendees were plinss, +1.413.325.aaaa, +1.408.652.aabb, glazou, +1.415.832.aacc, glenn, jdaggett, dcramer, Lea, Stearns, krit, +1.415.615.aadd, rhauck, smfr, +1.610.324.aaee,
17:05:31 <Zakim> ... dael, Plh, +44..aaff, Bert, hober, fantasai, +93192aagg, antonp, florian, +1.520.280.aahh, SimonSapin, dbaron, +33.9.81.36.aaii, ChrisL, Rossen_, +1.212.318.aajj, jerenkrantz,
17:05:32 <Zakim> ... +1.832.797.aakk, leif, BradK, +1.281.627.aall, TabAtkins
17:32:32 <SimonSapin> TabAtkins: Bikeshed gives me "FATAL ERROR: No 'type' refs found for '<unicode-range>'."
17:33:27 <SimonSapin> I’m using <<<unicode-range>>> in the source
17:40:26 <florian> florian has joined #css
17:42:14 <SimonSapin> TabAtkins: oh, got it. I had <<<unicode-range>>, missing one >
18:15:10 <TabAtkins> SimonSapin: Yup, note the error message - it was looking for a "type" def, not a "token" def, which indicates you got the syntax-guesser confused.
18:15:35 <SimonSapin> ah, <<foo>> is a type. Got it
19:07:45 <Zakim> Zakim has left #css
20:05:59 <fantasai> TabAtkins, SimonSapin: Does bikeshed use biblio.ref or what?
20:06:41 <fantasai> TabAtkins, SimonSapin: Because it's got out-of-date references to css3-conditional.
20:42:51 <tantek> tantek has joined #css
20:57:05 <fantasai> Bert: I'm going to set up Grid Layout for publication, if you can help the webmaster set it up tomorrow, that would be great!
20:57:17 <fantasai> Bert: want to get it up before the f2f