IRC log of css on 2009-03-06

Timestamps are in UTC.

00:29:36 [RRSAgent]
RRSAgent has joined #css
00:29:36 [RRSAgent]
logging to
00:29:38 [trackbot]
RRSAgent, make logs member
00:29:38 [Zakim]
Zakim has joined #css
00:29:40 [trackbot]
Zakim, this will be Style_CSS FP
00:29:40 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
00:29:41 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:29:41 [trackbot]
Date: 05 March 2009
00:29:49 [ChrisL]
rrsagent, make logs public
00:29:56 [ChrisL]
Meeting; CSS f2f Tokyo
00:30:00 [ChrisL]
Chair: Chris
00:30:20 [ChrisL]
zakim, remind me in 8 hours to go home
00:30:20 [Zakim]
ok, ChrisL
00:31:01 [sylvaing]
sylvaing has joined #css
00:31:36 [jdaggett]
00:36:16 [dbaron]
RRSAgent, make logs public
00:37:28 [anne]
RRSAgent, spans midnight
00:37:28 [RRSAgent]
I'm logging. I don't understand 'spans midnight', anne. Try /msg RRSAgent help
00:37:40 [anne]
scribe: anne
00:37:47 [anne]
Topic: font-weight
00:38:59 [sylvaing]
sylvaing has joined #css
00:39:04 [anne]
JD: In Cambridge we discussed bolder and lighter
00:39:06 [jdaggett]
00:39:42 [anne]
JD: It's a frustrating discussion, because of platform restrictions and lack of [cool] fonts
00:40:33 [anne]
JD: m+ (Japanese Open Source font) supports seven weights
00:40:45 [anne]
JD: 300 is equal to 200, 700 is equal to 600
00:45:56 [anne]
JD: the issue in Cambridge was, given a line of text, given font fallback, multiple fonts can be used, then with nested elements with bolder, bolder, bolder, what should happen?
00:46:52 [sylvaing]
sylvaing has joined #css
00:46:57 [anne]
CL: if you have a value already from an inherited context [... scribe missed ...]
00:47:03 [anne]
JD: where do you make the determination?
00:47:33 [anne]
JD: am I simply doing incremental steps of boldness or am I picking a font somehow and resolving the calculation at that point
00:47:50 [anne]
JD: of course the computed value comes in because it becomes funny
00:48:39 [anne]
DB: computed value can be 1) just a weight, 2) a pair of a weight and a number (number indicates times bolder written), 3) a weight plus a sequence of bolder/lighter steps
00:49:31 [anne]
SZ: when I say bolder and there are at least two weights in the font, I'm at the lighter of the two, I'm in a span that has a bolder, what should I expect?
00:49:36 [anne]
JD: euh, the bolder one
00:49:52 [anne]
SZ: it changes the number
00:50:11 [anne]
JD: BB proposed that you calculate a number based on the first font
00:50:35 [anne]
JD: the reason I brought up m+ is that there a number of gotchas with that
00:50:41 [anne]
JD: [missed]
00:50:42 [ChrisL]
(Chris demonstrates some tests with ZalamanderCaps, a font with six weights)
00:50:49 [anne]
JD: if I say my body is 400 and I go to bolder
00:51:34 [anne]
JD: then you get 500, but then if you have a fallback font that has 400 and 700 you end up with 400 again
00:52:20 [anne]
JD: in this world, most fonts are 400/700
00:52:43 [anne]
JD: I suggest we simply iterate through 100/400/700/900 for bolder/lighter
00:53:51 [anne]
HL: you can still use the absolute values if you really know things
00:53:57 [anne]
HL: this is just for the relatives
00:54:01 [anne]
CL: good point
00:54:15 [anne]
SZ: there are some 400/600
00:54:26 [anne]
JD: I don't know of those, Japan has some 300/600
00:54:29 [ChrisL]
not so worried if its just the relatives. As long as higher quality results are not excluded
00:54:30 [anne]
JD: will still do the right thing
00:54:57 [anne]
HL: is the rounding defined?
00:54:59 [anne]
JD: yes
00:55:06 [anne]
HL: sounds reasonable
00:55:11 [anne]
JD: you get a consistent computed value
00:55:17 [ChrisL]
wights in zalamander:
00:55:18 [ChrisL]
ultrabold 800
00:55:18 [ChrisL]
bold 700
00:55:18 [ChrisL]
semibold 600
00:55:18 [ChrisL]
regular 400
00:55:18 [ChrisL]
light 300
00:55:20 [ChrisL]
extralight 250
00:55:39 [anne]
SZ: IH's distinction goes away, right?
00:55:41 [anne]
DB: yes
00:55:59 [anne]
DB: this probably addresses the use case for bolder/lighter better and is much simpler
00:56:03 [anne]
00:56:27 [ChrisL]
critical difference is that you can do bolder/lighter without knowing the current font family
00:56:39 [anne]
JD: I will write this out
00:56:54 [anne]
DB: I think you might want to ping DH directly
00:57:02 [anne]
DB: I think Opera might do that as well
00:57:20 [anne]
DB: they basically maintain a sequence of +ses and -ses
00:57:34 [anne]
[discussion about IH's test and the complexity of the model]
00:58:13 [anne]
CL: might be useful to make duplicate test with different fonts
00:58:40 [anne]
JD: In some of the edits made by the other editors they wanted to allow non-multiples of a 100
00:59:11 [ChrisL]
agree that weights cannot be compared over families
00:59:11 [anne]
JD: 600 in one font vs 650 in another font is not noticable
00:59:29 [ChrisL]
01:00:14 [anne]
SZ: the relatives are not for people who care about typography
01:00:23 [anne]
[scribe notes they are also for default style of elements]
01:00:51 [anne]
DB: I don't think authors know the difference between bold and bolder or think bolder is more bold than bold
01:00:55 [anne]
[joke about adding boldest]
01:01:19 [anne]
JD: I made a post to www-style
01:01:31 [anne]
JD: in response to "CSS font selection is broken" (not exact subject)
01:01:44 [anne]
JD: the way things work on Linux/Windows is unfortunate
01:01:50 [dbaron]
01:02:28 [anne]
[people are quoting from the e-mail]
01:02:48 [ChrisL]
Thomas Phinney's arguments are good but his conclusion does not follow from his arguments
01:02:56 [anne]
[JD is performing a recap of the e-mail on the whiteboard]
01:04:41 [ChrisL]
jd: in opentype, font family can have platform-specific variations - localisations, and windows/mac variations so the semantics are platform dependent
01:05:16 [ChrisL]
... hence Arial and Arial Black, two families on windows and one family on mac
01:06:09 [ChrisL]
... thus MS have a "preferred family" but CSS only allows selecting by slope, width and weight
01:06:42 [ChrisL]
01:07:02 [ChrisL]
... opentype 1.5 has wwsfamily
01:09:43 [ChrisL]
wpf has a hash table classification of *known* fonts (only)
01:10:25 [anne]
DB: If I and JD disagree JD is right
01:11:23 [anne]
JD: there is a possibility in the future that Microsoft might ship fonts with broader families
01:12:01 [anne]
CL: everyone with a photoshop will have a certain set of fonts and communities around photoshop will start using them, etc.
01:13:36 [anne]
SZ: [missed]
01:13:47 [anne]
JD: the first point is that we don't define what a given name maps to on a given platform
01:13:58 [anne]
JD: on any given platform there will be plethora of different font formats
01:14:03 [anne]
JD: but we can give guidelines
01:14:10 [anne]
JD: for OT/TT we suggest that you do certain things
01:14:23 [anne]
SZ: the important part for me was that it's an abstraction, not a direct
01:14:32 [anne]
JD: we can suggest a path to goodness
01:14:38 [anne]
JD: I disagree with your second point
01:15:09 [anne]
JD: with the exception of optical size I don't see a lot of variations even within Adobe families that somehow would be helped with this
01:15:21 [anne]
JD: I'm a little sceptical even with optical size
01:15:30 [anne]
SZ: I understand... in some magical way...
01:15:48 [anne]
JD: the flipside of this, after the break I want to talk about the specifics of the @font-face mechanism and local faces
01:16:10 [anne]
JD: via that mechanism you can separate things out...
01:16:31 [anne]
... it's going to be so rare; there will be font foundries that define fonts with their own set of axis
01:16:57 [anne]
... ... the only thing that we can do is that we put in some kind of string that we can somehow match against the style name
01:17:03 [anne]
... which is suicide
01:17:14 [anne]
... localization issues, semantics could change, accidental matching
01:17:28 [anne]
... using local with the default name is a much more robust mechanism
01:17:42 [anne]
... let's take a break and then talk about @font-face
01:18:07 [anne]
HL: comments from MS?
01:18:35 [anne]
SG: no, I don't work with the Windows team on fonts, but with IE
01:18:49 [anne]
SG: and there's a huge back compat
01:50:57 [anne]
Topic: @font-face
01:51:13 [dbaron]
JD: in css3-fonts, descriptors now have default values
01:51:14 [anne]
JD: two @font-face rules defined; normal and bold
01:51:46 [anne]
JD: I'm not implying this [see whiteboard photo if someone makes one] is a use case
01:51:49 [anne]
CL: I think it is
01:52:20 [anne]
JD: there is no way to have a magic attribute that sucks in a bunch of fonts
01:52:58 [anne]
JD: MD wants font aliasing
01:53:26 [anne]
JD: what I'm saying is that essentially having a variable that equals a bunch of fonts
01:53:36 [anne]
JD: is not a good way to do things
01:53:59 [anne]
JD: if you want Arial to be just like Helvetica you'd have to enumerate the four faces
01:54:02 [ChrisL]
01:54:56 [anne]
[discussiong about MD's proposal]
01:56:14 [ChrisL]
JD proposes @font-alias to group font families
01:56:18 [ChrisL]
01:58:06 [ChrisL]
JD asserts that mixing complete families and individual faces gives ambiguity
01:59:01 [ChrisL]
cl: to point into a zip file with multiple faces you would want a fragment identifier to index into the zipfile
02:01:30 [ChrisL]
cl: @font-face is designed to point to a face (and give info about it) not to a family
02:02:35 [anne]
HL: just to try to connect here, can we put @font-alias into a draft
02:02:44 [anne]
JD: there is a variable proposal, which would do exactly that
02:03:18 [anne]
HL: not clear whether that will make it and it's far more complex
02:03:55 [anne]
HL: I think @font-alias is just for browser style sheets
02:04:09 [anne]
[scribe things the CSSWG should not add features just for browser style sheets]
02:04:12 [anne]
02:04:26 [anne]
JD: I think it is useful for author style sheets too
02:04:37 [anne]
JD: so you don't have to write everything out
02:05:36 [anne]
HL: if we see font families expand @font-alias might be useful, but I don't want authors to have to use this
02:05:36 [ChrisL]
hl: we are seeing font families expand so we need to be able to do this
02:06:09 [ChrisL]
jd: so @font-alias gives a convenient shorthand
02:06:10 [anne]
JD: with large corperations that use lots of fonts and if they are doing things cross platform you need to use a lot of fonts
02:06:29 [anne]
AvK: is font-family the only property it takes?
02:08:02 [anne]
[simplifying syntax]
02:08:31 [anne]
@font-alias "my font" "test", "test", "test";
02:09:35 [sylvaing]
sylvaing has joined #css
02:11:28 [anne]
[discussion about parsing rules for font-family]
02:12:07 [ChrisL]
trackbot, status?
02:12:39 [anne]
Topic: local() syntax issue
02:12:42 [ChrisL]
action John to specity @font-alias per 6 March 2009 minutes
02:12:42 [trackbot]
Created ACTION-129 - Specity @font-alias per 6 March 2009 minutes [on John Daggett - due 2009-03-13].
02:12:50 [anne]
JD: should local require quotes or not?
02:12:55 [anne]
JD: I put in that quotes are optional
02:13:00 [anne]
02:13:08 [anne]
JD: with format() they are required
02:13:14 [anne]
CL: why?
02:13:29 [anne]
AvK: why do we have format?
02:13:50 [anne]
JD: it's for future safety
02:13:56 [ChrisL]
to avoid downloading something you know you don't support
02:14:52 [anne]
JD: we also need it for platform sensitivity
02:15:08 [anne]
JD: for certain fonts you need to identify what information the font has
02:15:58 [anne]
JD: so e.g. truetype-aat is skipped over on Windows
02:16:18 [ChrisL]
02:17:48 [myakura]
myakura has joined #css
02:19:43 [dbaron]
Anne: Spec should say that if the UA doesn't support the format() annotation, the user agent must not download the font.
02:19:53 [dbaron]
02:20:01 [dbaron]
s/must not download/must not use/
02:21:09 [anne]
RESOLVED: format() is authorative
02:21:37 [anne]
i.e. if the user agent does not support the format listed it will not use the font (and should probably not waste bandwidth either)
02:21:57 [ChrisL]
jd: src defines load fallback, not character fallback. order is the first font to load succesfully
02:22:51 [ChrisL]
02:23:15 [anne]
JD: in case of multiple listed src() in a single @font-face that are both supported only the first is used
02:23:47 [sylvaing]
sylvaing has joined #css
02:23:47 [anne]
02:24:01 [anne]
RESOLVED: in case of multiple listed src() in a single @font-face that are both supported only the first is used
02:24:15 [anne]
Topic: unicode-range
02:24:42 [anne]
JD: the way I have unicode-range is defined right now is that unicode-range has the implicit value of the full Unicode range
02:27:21 [ChrisL]
unicode-range initial value should be 0-U+10FFFF
02:27:40 [anne]
JD: In WebKit unicode-range intersects with the supported values of the font
02:27:47 [ChrisL]
02:28:00 [anne]
JD: within the bounderies of unicode-range
02:29:33 [ChrisL]
" C077 [S] Specifications MUST NOT allow code points above U+10FFFF.
02:31:10 [anne]
AvK: e.g. if you have a font with 2,3,5 and unicode-range 1-4 the intersection would be 2,3
02:33:11 [ChrisL]
CSS 2.1 is correct: "If the number is outside the range allowed by Unicode (e.g., "\110000" is above the maximum 10FFFF allowed in current Unicode), the UA may replace the escape with the "replacement character" (U+FFFD)."
02:34:36 [anne]
SZ: for big fonts being specific about what is in the font is useful to avoid wasting bandwidth
02:37:49 [anne]
RESOLVED: unicode-range uses the intersection of the font and unicode-range within the bounderies of unicode-range
02:38:20 [ChrisL]
s/font/font cmap/
02:39:45 [ChrisL]
s/unicode-range uses/the effective unicode range is/
02:39:45 [anne]
Topic: type of local() name
02:40:00 [anne]
JD: there's no ideal name that works on all platforms
02:40:22 [anne]
JD: on the Mac you'd use the postscript name
02:40:52 [ChrisL]
... all fonts on a mac have a postscropt name, either real or synthesized
02:41:11 [anne]
JD: what I have now is that all platforms allow lookup via the full name
02:41:26 [anne]
HL: you want to support having style in the name of the family
02:41:41 [anne]
JD: the name you have here uniquely describes the font within a family
02:41:55 [anne]
[shouting, minute taker gets lost]
02:42:48 [anne]
[excited shouting, for those wondering]
02:42:58 [ChrisL]
fullname is family plus style except for the regular, where style is omitted
02:45:38 [anne]
JD: postscript name doesn't necessarily match the name in the style
02:45:56 [ChrisL]
so, you would need to specify it twice, fullname and postscript name?
02:46:03 [ChrisL]
(cl hears both yes and no)
02:47:06 [anne]
JD: there are OTF fonts where the full name under Windows is the postscript name
02:47:12 [anne]
JD: but on the Mac it is the normal full name
02:47:20 [ChrisL]
so the postscriptname should go first, followed by the fullname (if different to postscript name)
02:50:53 [ChrisL]
02:50:55 [anne]
JD: authors would use local() because they can control individual faces and you cannot do that with font-family
02:51:18 [anne]
SG: font-family only allows the generic family, not a specific face
02:52:50 [anne]
JD: with this nomenclature you have the hope of matching cross platform, with file names it fails
02:53:58 [anne]
SZ: the API is that you give the system a name and use the first it returns
02:54:08 [anne]
HL: I'm afraid different systems will react differently
02:55:30 [anne]
JD: with unicode-range and local() you can create interesting combinations that will work across platforms
02:55:51 [anne]
HL: my experience is different
02:56:01 [anne]
JD: that is because fonts are not cross platform
02:56:10 [anne]
JD: this is inherently platform specific
02:56:30 [anne]
HL: I think that's why we shouldn't do it
02:56:37 [anne]
AvK: font-family is also platform specific
02:56:44 [anne]
HL: we should not expand on that
02:59:40 [anne]
[rehashing of unicode-range and other arguments]
03:00:42 [anne]
HL: does local() and font-family work the same?
03:00:51 [anne]
JD: no, but in some cases it will
03:01:01 [ChrisL]
sz: anything which varies on one of the descriptorts, must be specified by @font face not font-family
03:01:03 [anne]
CL: we don't want that
03:02:05 [ChrisL]
s/tthat/people to use font-family: "Helvetica Bold Italic"
03:02:42 [anne]
s/that/people to use font-family: "Helvetica Bold Italic"
03:07:35 [anne]
HL: I'm ok with this as long as it is interoperable
03:07:52 [ChrisL]
I wonder if a font-size descriptor plus src would let us get at optical variants
03:08:01 [anne]
AvK: the spec can give advice
03:08:03 [anne]
JD: of course
03:08:27 [anne]
SZ: I would not like APIs of systems
03:08:39 [anne]
AvK: if that's the reality it seems better to specify reality
03:09:17 [anne]
AvK: e.g. ARIA does that too
03:09:26 [anne]
SZ: as long as it is clear that it is one way of doing it
03:10:21 [anne]
JD: for the roadmap of this spec I'd like to get what's in the spec now solid
03:10:34 [anne]
JD: and by the end of this month hopefully get a WD out
03:10:50 [anne]
JD: and then work on exposing opentype features and some of the other issues regarding better typography
03:10:57 [anne]
JD: with hopefully a draft for the June F2F
03:12:36 [szilles_]
SZ: I did say that I would prefer that the REC not have API based descriptions in the informative note.
03:13:44 [szilles_]
SZ: What I really meant was that the mapping of the local name to the font name tables ought to be specified in terms of the font format specifications (without having to invoke that APIs)
03:14:28 [szilles_]
SZ: And that the API information should suggest a way to implement that mapping but that not being the only way to implement the mapping
03:21:20 [sylvaing]
sylvaing has joined #css
04:29:26 [jdaggett]
scribenick: jdaggett
04:29:41 [jdaggett]
zakim: hello
04:30:00 [jdaggett]
zakim, how's the weather?
04:30:00 [Zakim]
I don't understand your question, jdaggett.
04:30:24 [jdaggett]
topic: namespaces
04:30:41 [jdaggett]
anne: one clarification
04:30:42 [fantasai]
Anne: There's just one clarification we want to make to the spec before proceeding
04:31:00 [jdaggett]
anne: duplicate clarifications are not conformant
04:31:32 [jdaggett]
anne: after that change and we have two implementations
04:31:43 [jdaggett]
anne: we can go to pr
04:31:59 [jdaggett]
discussion of pr criteria
04:32:27 [jdaggett]
anne: we have a full test suite
04:32:35 [jdaggett]
chrisl: level of coverage?
04:33:01 [jdaggett]
discussion of test failurs
04:33:13 [jdaggett]
04:33:43 [jdaggett]
anne: bugzilla bug exists
04:33:59 [jdaggett]
discussion of exit criteria
04:35:05 [jdaggett]
and whether can remove tests
04:35:41 [jdaggett]
chrisl: no recs got published since i left the group
04:36:34 [jdaggett]
discussion of specific bug mozilla is currently failing
04:37:11 [jdaggett]
dbaron: test is wrong
04:38:25 [jdaggett]
dbaron: has to due with url parsing bug
04:39:00 [jdaggett]
dbaron: hmmm, maybe the bug does exist
04:39:12 [jdaggett]
chrisl browbeats dbaron
04:39:48 [jdaggett]
dbaron resists valiantly
04:40:35 [jdaggett]
anne: waiting for implementations to pass
04:41:37 [dbaron]
04:41:44 [dbaron]
is the test that fails in Gecko
04:45:48 [jdaggett]
correction: anne states duplication declarations are not conformant
04:46:11 [jdaggett]
chrisl: agreement?
04:46:32 [ChrisL]
resolution: duplicate namespace declarations make content nonconforming
04:47:10 [jdaggett]
topic: june f2f agenda
04:47:38 [jdaggett]
howcome: multi-col should be into LC
04:47:45 [jdaggett]
stevel: gcpm?
04:48:10 [jdaggett]
howcome: yes
04:48:22 [jdaggett]
stevel: how to reflect font features in css
04:48:31 [jdaggett]
stevel: test suites?
04:48:58 [jdaggett]
ee: working on draft of paged media
04:49:18 [jdaggett]
anne: what's issue with ms test suite?
04:49:29 [jdaggett]
ee: getting them reviewed is the key
04:50:21 [jdaggett]
howcome: can we get a demo of the test suite?
04:50:58 [fantasai]
04:51:08 [jdaggett]
ee showing tests suite
04:51:12 [fantasai]
04:51:55 [jdaggett]
fantasai: managing test checks via mailing list
04:52:26 [fantasai]
04:52:46 [fantasai]
04:53:13 [fantasai]
send mail to public-css-testsuite
04:53:46 [jdaggett]
ee: build system will hopefully index metadata for tests
04:53:59 [jdaggett]
ee: this should give us
04:54:11 [jdaggett]
ee: a better understanding which tests fail
04:54:54 [jdaggett]
howcome: who's server is this?
04:54:57 [jdaggett]
ee: hp
04:55:11 [jdaggett]
howcome asking about tests
04:56:00 [howcome]
howcome has joined #css
04:56:57 [jdaggett]
ee: svn view to figure out changes
04:57:18 [jdaggett]
ee: build script to turn xhtml to html versions
04:57:35 [jdaggett]
ee: after that i'll be tidying up, cron job to build
04:57:48 [jdaggett]
sylvain: manpower issue
04:58:18 [jdaggett]
discussion of format guidelines
04:59:42 [szilles_]
EE: Arron has a set of scripts written in C# that do a lot of checks; the CSS group does not have these.
05:00:03 [ChrisL] not well formed
05:00:03 [howcome]
05:02:05 [jdaggett]
ee: lots of work to do
05:02:10 [ChrisL]
it would be easy to pass all files through an xml parser and see which ones are nwf so they can be fixed
05:02:13 [jdaggett]
ee: some tests not well-formed
05:02:52 [jdaggett]
howcome: so what's the process here?
05:03:19 [jdaggett]
anne: not clear when a test is approved
05:03:58 [jdaggett]
ee: someone needs to review each test and confirm to mailing list
05:04:06 [ChrisL]
05:04:30 [jdaggett]
howcome notes an error in markup
05:05:09 [jdaggett]
howcome: we follow standards... ;)
05:05:34 [jdaggett]
anne: reparsing a security issue
05:05:47 [ChrisL]
05:06:46 [jdaggett]
sylvain: not sure when this is going to get completed
05:07:16 [jdaggett]
ee: so, um..
05:07:34 [jdaggett]
ee: can make a wiki page with links to tests
05:07:52 [jdaggett]
ee: categorized by reviewed, not reviewed
05:08:02 [jdaggett]
discussion of review process
05:09:53 [jdaggett]
dbaron proposing a process
05:11:22 [jdaggett]
chrisl: check out test, confirm, twiddle tasty bits in test file, check back in
05:11:39 [jdaggett]
ee: need mailing list post
05:13:43 [jdaggett]
ee, dbaron discussing whether to check-in vs. posting to mailing list
05:14:20 [jdaggett]
ee: either way (patches or posting mail) is fine
05:14:43 [melinda]
melinda has joined #CSS
05:14:52 [fantasai]
hey Melinda, just in time. We're discussing tests
05:15:54 [jdaggett]
ee: web interface for checking who has done what
05:16:09 [melinda]
heh heh, I was just going to capture the log as I toddled off to bed, but I can hang out for a bit.
05:16:22 [jdaggett]
ee: aaron wants to know when things change
05:17:07 [jdaggett]
stevel: automatic checkin notification?
05:17:38 [jdaggett]
dbaron: can we just do this via email?
05:17:51 [jdaggett]
stevel: but for others outside the wg
05:18:03 [jdaggett]
anne: for html5, several lists track changes
05:18:32 [jdaggett]
dbaron: uh, not just tools, actually doing the work...
05:20:09 [jdaggett]
ee: need meta element to note review
05:20:16 [jdaggett]
discussion of meta format
05:20:21 [jdaggett]
for review comment
05:21:14 [jdaggett]
stevel making a point
05:21:32 [jdaggett]
anne commenting
05:21:52 [jdaggett]
chrisl: i'm taking fonts chapter
05:22:28 [jdaggett]
more process discussion
05:22:41 [jdaggett]
ee about to speak
05:23:01 [jdaggett]
everyone quiet in anticipation
05:23:24 [jdaggett]
ee fiddling with keyboard
05:24:18 [jdaggett]
chrisl assigning homework
05:25:56 [jdaggett]
anne: chapter 4 syntax
05:26:02 [jdaggett]
dbaron: 5, selectors
05:26:11 [dbaron]
chris: 15, fonts
05:26:37 [jdaggett]
howcome: dbaron, 12
05:26:45 [jdaggett]
stevel: 14
05:27:01 [melinda]
Uh, what homework is being assigned...?
05:27:06 [jdaggett]
howcome: 13
05:27:24 [jdaggett]
MikeSmith getting suckered into more work...
05:27:46 [jdaggett]
MikeSmith: appendix d
05:28:15 [jdaggett]
MikeSmith: media types 7
05:28:39 [jdaggett]
ee: i'm doing bidi tests
05:28:56 [jdaggett]
anne: hixie, 8-11
05:28:57 [jdaggett]
05:29:13 [jdaggett]
howcome: bert, box model?
05:30:03 [jdaggett]
me: fonts, 15
05:30:10 [jdaggett]
howcome gives me a hard time
05:31:07 [jdaggett]
ee: i updated review process
05:31:24 [jdaggett]
with metatag format
05:32:07 [fantasai]
05:32:13 [fantasai]
05:33:02 [jdaggett]
ee demoing svn details
05:33:28 [jdaggett]
howcome: melinda should do?
05:33:40 [fantasai]
svn co myfavdirectoryname to check out everything
05:33:42 [howcome]
Melinda: we're signing up for CSS 2.1 tests to review
05:33:53 [melinda]
05:33:58 [howcome]
Melinda: each person in the room has picked a chapter
05:34:17 [jdaggett]
melinda is working on print, 13
05:34:27 [jdaggett]
ee: ^
05:34:39 [melinda]
But I need a reviewer (thanks, Hakon!)
05:35:35 [fantasai]
05:35:38 [fantasai]
Recommended reading ^
05:35:51 [fantasai]
05:37:05 [jdaggett]
i'll do chap. 6
05:37:49 [howcome]
Melinda: is it possible to put the tests on the same server as where the MS tests are? Or, should I look somewhere else?
05:38:23 [fantasai]
05:38:26 [melinda]
I've been moving some to the csswg site, and I'll try to get the rest moved over next week.
05:38:55 [fantasai]
melinda: Are you putting them in ?
05:39:04 [melinda]
05:39:35 [jdaggett]
stevel: asks for pointers on the wiki page
05:40:47 [jdaggett]
chrisl: agenda item, go over tests in june f2f
05:41:14 [jdaggett]
chrisl: complete tests by start of april?
05:41:49 [jdaggett]
chrisl: review test suite at beginning of april
05:43:12 [sylvaing]
the msft test suite site also allows you to navigate your tests by properties/rules if that helps :
05:46:39 [anne]
rel="reviewer" is now provisionally registered:
05:49:50 [sylvaing]
sylvaing has joined #css
06:04:19 [sylvaing]
sylvaing has joined #css
06:05:07 [dbaron]
ScribeNick: dbaron
06:06:32 [dbaron]
Elika: Do we want to publish a new CR of namespaces with the one change?
06:06:35 [dbaron]
Chris: No point holding it back.
06:06:58 [fantasai]
ACTION: fantasai publish namespaces CR and Selectors LC
06:06:58 [trackbot]
Created ACTION-130 - Publish namespaces CR and Selectors LC [on Elika Etemad - due 2009-03-13].
06:07:33 [dbaron]
Topic: CSS 2.1 issues
06:09:16 [dbaron]
Elika: SVG WG wants us to publish transforms on the same day as ???, so we have a combined news item.
06:09:29 [dbaron]
Håkon: what was the compromise?
06:09:33 [dbaron]
Steve: Dean and I agreed on a paragraph.
06:10:40 [dbaron]
Steve: [reads paragraph]
06:11:03 [fantasai]
06:12:05 [dbaron]
Håkon: I think the second role (layout-affecting transforms) should be in a separate spec, since it's so different.
06:12:10 [dbaron]
Steve: It's all the same properties.
06:12:15 [dbaron]
Anne: No need to discuss this now.
06:12:26 [dbaron]
Anne: Just agree on the text and whether to publish Wednesday.
06:12:33 [dbaron]
Elika: The text you read isn't in the draft.
06:14:38 [dbaron]
Steve: Hmm, he said he'd put this in in mail to me on 23 Feb.
06:14:50 [dbaron]
Chris: Last modification of that draft is 18 Feb.
06:16:27 [dbaron]
06:17:15 [dbaron]
ACTION: Bert to put text from into css3-2d-transforms and request publication.
06:17:15 [trackbot]
Created ACTION-131 - Put text from into css3-2d-transforms and request publication. [on Bert Bos - due 2009-03-13].
06:18:17 [howcome]
howcome has joined #css
06:18:31 [howcome]
06:18:51 [dbaron]
Topic: CSS 2.1 issues, really this time
06:19:31 [fantasai]
06:21:26 [ChrisL]
06:21:26 [ChrisL]
Add The position of the list-item marker in the presence of floats is undefined in CSS2.1. Ask web-designers about text-align.
06:22:06 [dbaron]
David: I don't remember why we couldn't come to an agreement about this, but not sure whether it's worth reopening.
06:24:30 [dbaron]
David: I think we were converging on behavior, though...
06:24:45 [dbaron]
Elika: I think we should leave undefined for 2.1.
06:26:01 [dbaron]
ACTION: David to test how interoperable we are on for both floats and text-align
06:26:01 [trackbot]
Sorry, amibiguous username (more than one match) - David
06:26:01 [trackbot]
Try using a different identifier, such as family name or username (eg. dbaron, dsinger2, hyatt)
06:26:09 [dbaron]
ACTION: dbaron to test how interoperable we are on for both floats and text-align
06:26:09 [trackbot]
Created ACTION-132 - Test how interoperable we are on for both floats and text-align [on David Baron - due 2009-03-13].
06:26:48 [anne]!DOCTYPE%20html%3E%3Cul%20style%3Dtext-align%3Acenter%3E%3Cli%3Ex
06:26:55 [fantasai]
06:29:02 [fantasai]
06:29:11 [fantasai]
I actually prefer option 3
06:29:13 [fantasai]
rather than 2
06:29:28 [fantasai]
(which doesn't conflict with that example either)
06:29:46 [fantasai]
dbaron: I think option 2 was the original intent
06:30:58 [fantasai]
dbaron: The problem is we have a shorthand property that accepts values of its subproperties in any order, and two of the three subproperties take the value none, and only the initial value of one of them is none
06:32:04 [fantasai]
actually I meant to say i prefer 1 :)
06:33:46 [fantasai]
dbaron: We have convergence on 2, since I fixed Gecko to match Opera
06:34:01 [fantasai]
dbaron: since Gecko was pretty wacky
06:34:09 [fantasai]
dbaron: Opera matched 2, and Webkit only sort-of matched 1
06:34:14 [dbaron]
06:36:50 [dbaron]
Chris: Thoughts on the proposed text.
06:36:53 [dbaron]
David: I'm for it, of course.
06:36:58 [fantasai]
RESOLVED: dbaron's proposal accepted
06:37:01 [dbaron]
Håkon, Sylvain: ok with me
06:37:03 [dbaron]
Steve: abstain
06:37:45 [fantasai]
for issue 94
06:38:09 [fantasai]
06:40:15 [dbaron]
David: I think we broke this recently... in the 2004 CR it mentions propagating 'background'
06:41:05 [dbaron]
Elika: are people happy with the css3 text?
06:41:13 [dbaron]
Anne: In theory we should use lower case element names.
06:41:48 [dbaron]
David: I agree with the proposal.
06:42:19 [dbaron]
RESOLVED: accept proposal for issue 100
06:43:02 [fantasai]
06:43:14 [fantasai]
dbaron: I recently rewrote some float code in Mozilla
06:43:30 [fantasai]
dbaron: The old code was so incomprehensible that I tried to understand it by writing test cases
06:43:55 [fantasai]
dbaron: I made a change to follow the spec, and that broke web pages
06:44:34 [fantasai]
dbaron: We have this long list or rules for positioning floats
06:44:43 [fantasai]
dbaron: There are 3 rules for horizontal positioning... 3 5 and 7?
06:45:03 [fantasai]
dbaron: Here's a left float
06:45:16 [fantasai]
dbaron draws a big box with a rectangle on the lefthand side
06:45:54 [fantasai]
and draws arrows pointing left to show that it is a left float
06:46:07 [fantasai]
dbaron draws another smaller box halfway down the empty space on the right
06:46:21 [fantasai]
dbaron: This box is a normal flow descendant of the big box
06:46:34 [fantasai]
dbaron: It has margins big enough that it doesn't touch the float
06:47:20 [fantasai]
06:47:52 [fantasai]
dbaron: The rules that deal with horizontal positioning are 3, 5, 7
06:48:14 [fantasai]
dbaron: So sometime circa 2003 or so, hixie wrote a testcase for rule 5
06:48:24 [fantasai]
dbaron: In the intervening years browsers fixed their bugs to follow rule 5
06:48:29 [fantasai]
dbaron: but not rules 3 and 7
06:49:14 [fantasai]
dbaron: So now we're in the situation where browsers do 3 with added "and its horizontal coordinates intersect the horizontal coordinates of its containing block".
06:49:30 [fantasai]
dbaron: don't ask me whether it's border box or content box
06:49:49 [ChrisL]
06:50:18 [fantasai]
06:51:09 [fantasai]
dbaron: So the question is do we want to change the spec or get the implementations to change?
06:51:26 [fantasai]
dbaron says something about really complicated
06:52:35 [fantasai]
it's not about testing combinations of the rules
06:52:47 [fantasai]
it's about the case where the float doesn't ....
06:52:57 [fantasai]
dbaron: I'm not really happy with any of the options
06:53:30 [fantasai]
dbaron: The spec is simpler. But I did get a bug report one day after changing this in a nightly build
06:53:47 [fantasai]
sylvain: IE8 matches FF3.1 beta
06:54:00 [fantasai]
dbaron: here's the fun part
06:54:34 [fantasai]
dbaron: the bug is not the rule 3 case and not the rule 7 case
06:54:56 [fantasai]
dbaron: It's actually the replaced elements getting pushed around floats case
06:55:12 [fantasai]
dbaron: because the rule 3 case and the rule 5 and rule 7 cases were suppose I put a float inside this big box
06:55:28 [fantasai]
dbaron: But the ? is about putting a wide repalced element inside the big box
06:55:52 [fantasai]
dbaron: e.g. put a box with overflow auto next to the float that "doesn't fit"
06:56:03 [fantasai]
dbaron: even if the fact that it doesn't fit doesn't have anythign to do with the float
06:56:11 [fantasai]
dbaron: Maybe that's web compat and the others aren't
06:56:16 [fantasai]
dbaron: I don't really know
06:56:35 [fantasai]
anne: There are 4 impl matching each other, right?
06:56:42 [fantasai]
dbaron: We need better tests to tell if they're really matching each other
06:57:06 [fantasai]
dbaron: e.g. I wasn't testing border-box vs padding-box vs content-box
06:57:15 [fantasai]
anne: I note that nobody volunteered reviewing those tests either :)
06:57:53 [fantasai]
dbaron: I suppose I could take an action to write more tests and propose changes to the spec
06:58:08 [fantasai]
fantasai: I have no opinion
06:58:14 [fantasai]
dbaron: My guess is Bert would have an opinion
06:58:42 [fantasai]
fantasai: Does anyone have an opinion?
06:58:44 [fantasai]
06:58:52 [fantasai]
s/anyone/anyone here/
06:59:06 [fantasai]
howcome: You're never going to be able to test all cases
06:59:14 [fantasai]
dbaron: For the past 3 years we'd thought we'd gotten this down
06:59:40 [fantasai]
Chris: ...
06:59:50 [fantasai]
dbaron: what rule 7 is saying, if you're next to a float..
06:59:58 [fantasai]
dbaron: so if you have a left float that's wider than its container
07:00:07 [fantasai]
dbaron: it's a left float that's sticking out of its container
07:00:11 [fantasai]
dbaron: it's next to a float
07:00:14 [fantasai]
dbaron: we should push it down
07:00:28 [fantasai]
dbaron: so in some sense you could see these new rules as an improvement
07:00:50 [fantasai]
dbaron: but we do push it down for the 5 case, since someone wrote a test case
07:01:22 [fantasai]
dbaron: of course the real-world testcase was someone using width 100% on a float that had a 2px border
07:02:28 [fantasai]
dbaron: when I found this issue it was one of those realizations where I thought we were done with issues like this
07:02:55 [fantasai]
dbaron: I guess I have an action for this
07:03:00 [fantasai]
ACTION: write testcases for issue 101
07:03:00 [trackbot]
Sorry, couldn't find user - write
07:06:13 [fantasai]
07:07:03 [dbaron]
ACTION: dbaron to write testcases for issue 101 (e.g., see if we're interoperable on content-box vs. border-box) and come up with a proposal
07:07:03 [trackbot]
Created ACTION-133 - Write testcases for issue 101 (e.g., see if we're interoperable on content-box vs. border-box) and come up with a proposal [on David Baron - due 2009-03-13].
07:07:14 [fantasai]
Sylvain: 1a { too: early; } @import "foo.css";
07:07:23 [fantasai]
Sylvain: We discussed this on the telecon
07:08:09 [fantasai]
Sylvain: On one hand the parser is supposed to ignore it. On the other hand we're supposed to throw out the @import
07:08:21 [fantasai]
Sylvain reads from the spec
07:08:45 [fantasai]
Sylvain: THere were 2 things in teh discussions
07:09:18 [fantasai]
Anne: my issue was that "valid statement" is ambiguous
07:09:25 [fantasai]
Sylvain: In this case we wanted the @import to fail
07:09:42 [fantasai]
Sylvain: But we also wanted new @rules to be allowed before @import
07:11:12 [fantasai]
fantasai: So we wanted to totally ignore invalid @rules
07:11:35 [fantasai]
fantasai: but for other junk to recognize that there's junk there (which coudl be future selectors) and not process the @import after the junk
07:11:59 [fantasai]
dbaron: So is it really our goal to prevent authors from doing hacks like that?
07:12:12 [fantasai]
dbaron: Would that prevent us from introducing new syntax in the future?
07:13:08 [fantasai]
dbaron: I don't think that's the most important issue
07:13:37 [fantasai]
dbaron: I think the important issue is whether us introducing an @import in the future will cause the @import to be ignored
07:14:33 [fantasai]
anne: valid statement is ambiguous
07:14:42 [fantasai]
dbaron: I think the intent is "stuff that you can process"
07:14:48 [fantasai]
dbaron: THat's how I interpret it
07:15:02 [fantasai]
anne: Opera interpreted is as syntactically valid per the core grammar
07:15:13 [fantasai]
anne: I do know that we ignore the @import if there's bogus things before it
07:15:51 [fantasai]
dbaron and anne and sylvain test Opera
07:18:02 [fantasai]
anne: I propose replacing "valid statement" with "stuff that is not ignored"
07:18:14 [dbaron]
It sounds like anne is actually ok with the Firefox behavior, he just thinks the spec is ambiguous and Opera developers interpreted it differently.
07:18:46 [fantasai]
dbaron: If we change 'valid' to 'non-ignored' would that work?
07:19:25 [fantasai]
dbaron: It sounds like we want that testcase to be a correct test case
07:19:41 [sylvaing]
in 4.1.5 At Rules
07:19:46 [sylvaing]
instead of
07:19:47 [sylvaing]
CSS2.1 user agents must ignore any '@import' rule that occurs inside a block or after any valid statement other than an @charset or an @import rule.
07:19:52 [sylvaing]
07:20:02 [sylvaing]
CSS2.1 user agents must ignore any '@import' rule that occurs inside a block or after any non-ignored statement other than an @charset or an @import rule.
07:20:05 [fantasai]
anne: In Section 4.1.5 replace 'valid statement' with 'non-ignored statement'
07:20:35 [sylvaing]
Any @import rules must precede all other rules (except the @charset rule, if present).
07:20:51 [sylvaing]
(from 6.3)
07:20:54 [dbaron]
that should say "all other non-ignored rules"
07:21:39 [dbaron]
er, probably shouldn't change since it's authoring conformance, not implementation conformance
07:24:52 [fantasai]
discussion of the difference between authoring conformance reqs and impl conformance reqs
07:25:21 [fantasai]
RESOLVED: anne's proposal accepted for issue 102
07:25:32 [dbaron]
(which is to change 4.1.5 only)
07:26:13 [fantasai]
07:26:35 [fantasai]
dbaron: I was writing a test for this section and realized that it was incorrect despite having read this section at least 50 times before
07:26:40 [fantasai]
dbaron: 10.3.1 is a really short section
07:26:51 [fantasai]
dbaron reads 10.3.1
07:27:42 [fantasai]
dbaron: This section is incorrect for relatively positioned elements
07:28:14 [fantasai]
dbaron: My rpoposal is to remove left and right from 10.3.1
07:28:34 [fantasai]
dbaron: Earlier in 10.3 there's a reference to 9.4.3
07:28:45 [fantasai]
dbaron: we should clarify that that applies to 9.4.3
07:28:55 [fantasai]
s/9.4.3/relatively positioned elements
07:29:06 [fantasai]
dbaron: and that whent he position is static the values are zero
07:32:13 [fantasai]
RESOLVED: Accept to fix error, exact edits determined by Bert
07:34:41 [fantasai]
07:34:57 [fantasai]
RESOLVED: accept that widows and orphans can only accept integers >=1
07:38:20 [fantasai]
07:42:04 [anne]
07:43:11 [fantasai]
RESOLVED: accept proposal for issue 68
07:43:27 [fantasai]
Anne: You should update the reference to BCP47
07:44:51 [fantasai]
Steve argues against referencing the latest version
07:45:22 [fantasai]
everybody else disagrees
07:46:45 [fantasai]
ACTION fantasai: update Selectors with BCP47
07:46:45 [trackbot]
Created ACTION-134 - Update Selectors with BCP47 [on Elika Etemad - due 2009-03-13].
07:51:10 [fantasai]
07:52:37 [fantasai]
07:54:29 [anne] raises the actual issue
07:58:19 [fantasai]
fantasai explains that the sentence in conflicts with the tokenization
07:58:31 [fantasai]
that sentence allows \ followed by newline as an escape
07:58:34 [fantasai]
whereas the tokenization doesn't
08:00:42 [fantasai]
Also, I don't think newlines and spaces should be treated differently here
08:00:56 [fantasai]
So my preference is to keep the prose and fix the tokenization
08:01:16 [dbaron]
I think we should just change the prose: change "except a hexadecimal digit" to "except a hexadecimal digit or a newline (\n, \r, or \f)"
08:06:04 [fantasai]
Three options:
08:06:22 [fantasai]
1. Follow the prose and fix the grammar, so \ followed by newline is treated as a literal newline
08:06:32 [fantasai]
2. Make it invalid, triggering a parse error
08:06:50 [fantasai]
3. \ followed by newline is treated as if neither are present
08:08:58 [anne]
08:09:44 [myakura]
myakura has joined #css
08:10:14 [fantasai]\%0At%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22test%22%3Etest1%3C%2Fdiv%3E%0A%3Cdiv%3Etest2%3C%2Fdiv%3E
08:10:45 [fantasai]\%0At%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22test%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
08:12:26 [fantasai]
Firefox drops the sequence
08:12:30 [fantasai]
Safari treats it as invalid
08:12:44 [fantasai]
IE8 treats it as valid but doesn't drop the sequence
08:12:49 [fantasai]
Opera treats it as invalid
08:13:56 [anne]\%0Ast%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%3Cdiv%20test%3D%22te%26%2310%3Bst%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
08:15:43 [anne][test%3Dte\%0Ast]%20{%20background%3Alime%20}%3C%2Fstyle%3E%0A%3Cdiv%20test%3D%22te%26%2310%3Bst%22%3Etest1%3C%2Fdiv%3E%0A%3Cp%3Etest2%3C%2Fp%3E
08:21:00 [fantasai]
General preference for Firefox behavior
08:21:20 [fantasai]
Needs a change to prose to except newlines and then specify that such escapes are dropped
08:21:35 [fantasai]
dbaron lists changes to tokenizer: removing nl production and merging it into escape
08:24:05 [fantasai]
dbaron: Ok, I retract my position, I want to go the other way
08:24:35 [fantasai]
dbaron: An escaped newline in the middle of a number is a pain
08:25:25 [fantasai]
dbaron: I want to make it invalid
08:26:04 [fantasai]
RESOLVED: make it invalid, add "except newlines" to sentence about Any characters
08:26:09 [anne]
change "except a hexadecimal digit" to "except a hexadecimal digit or a newline (\n, \r, or \f)"
08:28:26 [fantasai]
Topic: Backgrounds and Borders
08:28:37 [fantasai]
summary of issue:
08:28:53 [fantasai]
dbaron: Brad Kemper vehemently believes that box-shadow should be ignored when border-image is on
08:29:22 [dbaron]
...because he thinks they're useful in combination only as fallback
08:30:20 [Zakim]
ChrisL, you asked to be reminded at this time to go home
08:30:30 [dbaron]
fantasai: [draws on whiteboard about issue of what to shadow]
08:31:04 [sylvaing]
fantasai explains how box-shadow draws a shadow around the box itself without considering the content of the border box regardless of the transparency of the latter
08:32:52 [sylvaing]
fantasai explains alternative proposal and its inconsistencies
08:37:36 [ChrisL]
so we have three options
08:38:00 [ChrisL]
a) never allow drop shadow and border image together (no what authors want)
08:38:36 [ChrisL]
b) use the existing drop-shadow with border-image and have the resulting ugliness (not whats wanted either)
08:39:22 [ChrisL]
c) state that, then border-image is specified, drop-shadow works by forming an offset mask from the alpha channel (what authors probably expect)
08:39:54 [ChrisL]
s/then border/when border/
08:40:11 [dbaron]
Steve: One other option to get rid of box-shadow.
08:40:21 [dbaron]
Chris: But it does the job it's designed to do for basic rectangular borders.
08:40:49 [dbaron]
Chris: It should be clear I'm proposing the third option.
08:41:32 [dbaron]
Elika: if (c), then (1) do you clip inside the padding box, and (2) for inset shadows, do you clip inside the padding box?
08:41:48 [dbaron]
Chris: (1) yes, (2) no
08:42:16 [dbaron]
David: dashed, dotted, double, border-radius?
08:42:23 [dbaron]
Elika: You do follow border-radius (as you do for backgrounds).
08:42:31 [dbaron]
Elika: But you don't mask for dashed/dotted.
08:43:21 [dbaron]
Elika: We're just taking the concept of the CSS border box and making it opaque.
08:44:25 [dbaron]
David: I wonder whether box-shadow is actually useful given how many ways there are of doing shadows and how many box-shadow covers.
08:45:09 [dbaron]
ACTION Chris to propose text for how box-shadow should work with border-image
08:45:09 [trackbot]
Sorry, amibiguous username (more than one match) - Chris
08:45:09 [trackbot]
Try using a different identifier, such as family name or username (eg. ChrisWilson, clilley)
08:45:14 [dbaron]
ACTION clilley to propose text for how box-shadow should work with border-image
08:45:14 [trackbot]
Created ACTION-135 - Propose text for how box-shadow should work with border-image [on Chris Lilley - due 2009-03-13].
08:48:51 [fantasai]
fantasai explains the difference between spread and making hte shadow bigger
08:48:53 [fantasai]
Meeting closed
08:51:26 [anne]
08:52:05 [anne]
(example spec that references BCP47)
08:58:27 [Zakim]
Zakim has left #css
10:56:28 [myakura]
myakura has joined #css
11:11:40 [Lachy]
Lachy has joined #css
11:40:51 [szilles_]
szilles_ has joined #css
12:04:40 [anne]
anne has joined #css
13:41:57 [myakura]
13:42:34 [myakura]
yes, we need fallback color for background :)
14:05:31 [dbaron]
dbaron has joined #css
15:17:56 [annevk]
annevk has joined #css
15:27:45 [melinda]
melinda has joined #CSS
15:36:54 [glazou]
glazou has joined #css
16:31:06 [Lachy]
Lachy has joined #css