15:58:40 <RRSAgent> RRSAgent has joined #css
15:58:40 <RRSAgent> logging to https://www.w3.org/2021/08/18-css-irc
15:58:42 <Zakim> RRSAgent, make logs Public
15:58:43 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:32 <Morgan> Morgan has joined #css
16:00:31 <astearns> webex is being very slow for me this morning
16:01:14 <cbiesinger> present+
16:01:23 <jfkthame> jfkthame has joined #css
16:02:09 <rachelandrew> present+
16:02:13 <alisonmaher> alisonmaher has joined #css
16:02:19 <alisonmaher> present+
16:02:31 <dandclark> present+
16:02:36 <Morgan> present+
16:02:42 <dbaron[m]> Present+
16:02:42 <miriam> present+
16:03:17 <GameMaker> GameMaker has joined #css
16:03:23 <GameMaker> present+
16:03:25 <plinss> present+
16:03:47 <sanketj> sanketj has joined #css
16:03:54 <sanketj> present+
16:04:02 <jensimmons> jensimmons has joined #css
16:04:23 <bradk> bradk has joined #css
16:04:52 <fantasai> ScribeNick: fantasai
16:05:23 <bradk> present+
16:06:36 <jensimmons> present+
16:07:19 <Rossen_> Rossen_ has joined #Css
16:07:47 <Rossen_> Present+
16:07:47 <fantasai> [skipping sizing-3 issue until fantasai reviews it]
16:08:10 <fantasai> [checking if emilio is on to discuss 6501]
16:08:19 <fantasai> [skipping]
16:08:38 <bradk> Tab, are you sure you clicked the right meeting link?
16:08:39 <emilio> whoops, omw, I was late
16:09:14 <emilio> present+
16:09:24 <fantasai> [ waiting for Tab to get connected for item after that]
16:09:26 <argyle> present+
16:09:32 <TabAtkins> present+
16:09:42 <fantasai> Topic: Throwing on invlaid pseudo-elements in getComputedStyle
16:09:46 <bkardell_> bkardell_ has joined #css
16:09:48 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6501
16:09:57 <bkardell_> present+
16:10:10 <fantasai> emilio: resolved to throw in these cases
16:10:13 <fantasai> emilio: I implemented it
16:10:16 <fantasai> emilio: but people do silly things
16:10:20 <fantasai> emilio: and it's not Web-compatible
16:10:29 <fantasai> emilio: One error is passing property names as pseudo-element names
16:10:32 <fantasai> emilio: and one is ???
16:10:43 <jfkthame> s/???/passing 'false'/
16:10:54 <fantasai> emilio: Question is, should we try to do something smarter? Should we return an empty style? Should we not throw and return the element's own style?
16:11:03 <fantasai> emilio: Blink and WebKit return the element's own style
16:11:18 <fantasai> emilio: Firefox does that, but not if pseudo-element starts with two colons
16:11:30 <fantasai> emilio: which is at least a bit more forwards-compatible
16:11:38 <lea> lea has joined #css
16:11:39 <chris_> chris_ has joined #css
16:11:48 <chris_> present+
16:11:59 <fantasai> astearns: Not returning element style with two-colon strings means we're less likely to have problems when we introduce new pseudo-eements
16:12:00 <lea> present+
16:12:06 <fantasai> emilio: Errors we're seeing seem to be mostly typos
16:12:27 <fantasai> emilio: ...
16:12:33 <fantasai> emilio: We could special-case in the IDL
16:13:03 <fantasai> dbaron[m]: Seems the Web-compat probems are strings without double-colon, so could throw on double-colon strings that are also errors
16:13:06 <fantasai> emilio: I'd be OK with that
16:13:22 <bradk> bradk has joined #css
16:13:26 <fantasai> TabAtkins: Don't have a strong opinion, whatever is both Web- and forwards-compatible
16:13:33 <fantasai> TabAtkins: document legacy weirdness
16:13:52 <smfr> smfr has joined #css
16:13:58 <smfr> present+
16:14:01 <fantasai> astearns: We'd resolved on throwing rather than empty style before, why did we decide that?
16:14:09 <fantasai> emilio: usually better, but optimistic that we could get away with it
16:14:26 <fantasai> emilio: anyone object to returning empty style if string begins with colon, otherwise return element style?
16:14:46 <dbaron[m]> the cases where we need to worry about fowards compat are (we think) the start-with-colon case
16:14:47 <dbaron[m]> s
16:15:04 <fantasai> iank_: Does this paint us into a corner for slot pseudos or anything like that?
16:15:08 <fantasai> emilio: I don't think so
16:15:25 <fantasai> emilio: If you do '::slotted' there's no style to return, multiple elements can match it
16:15:36 <fantasai> astearns: objections?
16:16:18 <fantasai> RESOLVED: Return empty style if string begins with a colon, return element style otherwise
16:16:50 <fantasai> Topic: Shorthand serialization when longhands have variables
16:16:56 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6253
16:17:28 <fantasai> TabAtkins: Variables spec has text about handling situations when shorthand contains variable and you ask for longhands
16:17:37 <fantasai> TabAtkins: at that time, we don't know what they will be, until computed value
16:18:01 <fantasai> TabAtkins: Same problem opposite direction, if variables in longhands, trying to serialize shorthand
16:18:13 <fantasai> TabAtkins: can get two completely invalid longhand that creates a valid shorthand, for example.
16:18:31 <fantasai> TabAtkins: So spec specifies the same thing, if longhand contains variable and you ask for shorthand, considered unserializable shorthand.
16:18:38 <fantasai> TabAtkins: wanted to confirm edits with WG
16:18:50 <fantasai> emilio: This is the only thing that makes sense
16:19:10 <fantasai> TabAtkins: Firefox and Chrome do specified behavior, WebKit does incorrect behavior
16:19:15 <fantasai> TabAtkins: currently
16:19:20 <fantasai> astearns: Any concerns about this?
16:19:35 <fantasai> RESOLVED: accept edits
16:19:53 <fantasai> Topic: overflow-clip-margin + border-radius continuity
16:20:10 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5896#issuecomment-892995385
16:20:14 <TabAtkins> ScribeNick: TabAtkins
16:20:43 <TabAtkins> fantasai: I think dbaron's comments are mostly editorial
16:20:47 <TabAtkins> fantasai: So I'll ask the main question
16:21:24 <TabAtkins> fantasai: Do we want to accept that the overflow-clip-margin follows the same corner-adjustment rules as margin/border/padding edges (so pointy corners stay pointy, round corners stay round)
16:22:00 <TabAtkins> fantasai: When you have a curved border edge, and we calculate the equivalent padding or content-box edges, we subtract the border/padding widths, flooring at zero.
16:22:40 <TabAtkins> fantasai: Similarly when you're going out to the margin edge or box shadows, we *add* the margin/shadow size to the radius, but with a special adjustment that keeps zero radius at zero.
16:22:51 <Rossen_> Rossen_ has joined #css
16:22:56 <TabAtkins> fantasai: Some math keeps it continuous between the two cases without causing noticeable changes in most cases
16:23:15 <TabAtkins> dbaron[m]: Another complexity is that a corner might be an inset on one side and outset on the other. already possible with negativemargins
16:23:26 <TabAtkins> dbaron[m]: This probably makes that case more common, since it's an offset from the padding edge
16:23:41 <fantasai> https://drafts.csswg.org/css-backgrounds-3/#corner-shaping
16:23:45 <TabAtkins> dbaron[m]: I think the spec actually does something reasonble for this right now, but it's by accident. I think it's right, tho
16:24:02 <fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius
16:24:03 <TabAtkins> dbaron[m]: It probably should look more intentional to make sure impls think about that case
16:24:31 <TabAtkins> fantasai: I just posted the testcase we used when we were figuring out the continuity formula
16:24:43 <bradk> bradk has joined #css
16:24:50 <TabAtkins> fantasai: So proposal is to use the same formula for overflow-clip-margin
16:25:21 <TabAtkins> astearns: Any othe ropinions?
16:25:25 <TabAtkins> [no objections]
16:25:31 <a-ja> a-ja has joined #css
16:25:40 <TabAtkins> RESOLVED: overflow-clip-margin uses the same corner-adjustment formula as margin/etc
16:25:52 <TabAtkins> astearns: Should we also resolve about being more clear about the positive-and-negative margin case?
16:25:55 <TabAtkins> fantasai: sure
16:26:10 <TabAtkins> astearns: So proposal is to accept dbaron's feedback, making the "accidental" correctness more explicit.
16:26:32 <TabAtkins> RESOLVED: Accept dbaron's editorial feedback about making the "accidental" case more explicit.
16:26:51 <TabAtkins> dbaron[m]: I don't think there's more to discuss, but I did raise more substantive editorial issues that I think could confused implementors.
16:27:00 <TabAtkins> dbaron[m]: Do think we need to deal with those, but don't think we need group time for them.
16:27:19 <TabAtkins> astearns: So fantasai you'll go thru those and either ipmlement or bring back to the group if necessary?
16:27:27 <fantasai> yes
16:27:38 <fantasai> Topic: aliasing display-legacy at parse-time
16:27:45 <fantasai> ScribeNick: fantasai
16:27:47 <fantasai> github: https://drafts.csswg.org/css-backgrounds-3/spread-radius
16:27:54 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5575#issuecomment-893899115
16:28:15 <fantasai> TabAtkins: Awhile ago, Oriol brought up that we have the short display values like inline-block, inline-table, etc.
16:28:25 <fantasai> TabAtkins: after attempt of splitting display property and then re-unifying
16:28:30 <fantasai> TabAtkins: we have two-keyword values
16:28:46 <fantasai> TabAtkins: question was whether these two ways of writing the same value should be canonicalized at parse time or some other time
16:29:05 <fantasai> TabAtkins: Argument for canonicalizing at parse time is that code written before these values were valid, might be expecting inline-foo pattern
16:29:16 <fantasai> TabAtkins: if author writes 'inline flow-root' for some reason, that code wont correctly respond
16:29:35 <fantasai> TabAtkins: counter-argument is that it can be confusing when we return something different from what author wrote, especially for specified values
16:29:46 <fantasai> TabAtkins: and code written in the past will continue to work, just not with the new syntax
16:29:57 <fantasai> TabAtkins: and that code wouldn't work for new display values in any case
16:30:17 <fantasai> TabAtkins: fantasai and I come down on the side of not canonicalizing at specified-value time
16:30:25 <fantasai> TabAtkins: It doesn't create Web-compat issues
16:30:27 <emilio> q+
16:30:36 <fantasai> TabAtkins: and it lets authors work in the syntax they specified
16:31:13 <fantasai> emilio: is proposal to canonicalize at computed value time?
16:31:25 <fantasai> fantasai: Don't we have a requirement for shortest-serialization for getComputedStyle?
16:31:31 <fantasai> TabAtkins: separate question
16:31:40 <fantasai> emilio: It's very easy to check for one and not the other
16:31:51 <fantasai> emilio: I think it's better to canonicalize at parse time
16:32:17 <fantasai> TabAtkins: It sounds like you're saying that canonicalize to happen at some point, and while prefer at specified value but ok if only at computed value?
16:32:20 <bradk> bradk has joined #css
16:32:24 <fantasai> iank_: Not concerned about Web compat?
16:32:30 <fantasai> emilio: I am, but figure they're accounted for?
16:32:41 <fantasai> iank_: I don't think anyone's done research on this
16:32:55 <fantasai> iank_: If Firefox implements this and it breaks or doesn't break a bunch of sites...
16:33:14 <fantasai> TabAtkins: not canonicalizing can't have Web-compat impact, because legacy code written with inline-block will still return inline-block
16:33:29 <fantasai> TabAtkins: New code written against old libraries would not work maybe, but that's not compat
16:33:37 <fantasai> emilio: Firefox has shipped the new syntax for awhile now
16:33:40 <fantasai> emilio: so could have compat
16:33:47 <fantasai> emilio: I don't think it's super useful not to canonicalize
16:33:54 <fantasai> emilio: useful for authors that write JS code and browsers
16:34:14 <fantasai> astearns: I suspect whether or not we canonicalize at parse time is much less web compat concern than if we do it at computed-value time
16:34:32 <fantasai> astearns: but there's argument of if computed-value is simplified, might be simpler to do it at parse time
16:34:40 <fantasai> iank_: whether we do it at parse time...
16:34:59 <fantasai> TabAtkins: fwiw, I agree that at computed value time they should be canonicalized, because they are in effect the same value, and shortest serialization would require it
16:35:27 <fantasai> iank_: Are we ok with backing out if there's a compat problem?
16:35:48 <fantasai> emilio: this proposed resolution is the behavior of the only existing implementation
16:36:00 <fantasai> TabAtkins: yeah, so this is completely web-compatible if anything can be
16:36:32 <fantasai> fantasai: The existing rule is "shortest most backwards-compatible serialization"
16:36:55 <fantasai> astearns: So want to be clear that they're the same
16:37:21 <fantasai> RESOLVED: these values compute to each other and thus serialize as "shortest most backwards-compatible" which is the older keywrods
16:37:53 <fantasai> TabAtkins: 2 objections to canonicalizing at parse time
16:38:03 <fantasai> TabAtkins: First, specified value should reflect what the author spadi
16:38:12 <fantasai> TabAtkins: if put .style="inline flow-root" should get that back when request it
16:38:44 <fantasai> TabAtkins: Also, canonicalizing back out would make it harder to split back out into two longhands
16:38:49 <fantasai> emilio: I don't see why
16:39:26 <bradk> bradk has joined #css
16:40:18 <fantasai> fantasai: when teaching CSS, Jen and Rachel have found the split keyword syntax useful for explaining the difference between inner and outer display roles
16:40:19 <jensimmons> yup to useful for teaching. Once they are in every single browser everywhere, I expect developers to start using them exclusively. (AKA, 2027?)
16:40:46 <fantasai> fantasai: If they disappear from the OM as soon as they're inputted, that creates a strong bias against using them, they're not so real anymore
16:40:54 <fantasai> [missed exchange]
16:41:03 <fantasai> emilio: I don't feel super-strongly, can compromise at computed-value time
16:41:11 <fantasai> emilio: I think it's weird one way or the other
16:41:21 <fantasai> emilio: computed value of 'display' is more looked-up than specified value
16:41:39 <fantasai> TabAtkins: in general specified values aren't looked at too much anyway, unless looking at value of style attribute
16:41:57 <fantasai> emilio: I don't see this as super useful, but if fantasai disagrees, it's OK I trust her
16:41:59 <astearns> ack emilio
16:42:15 <fantasai> jensimmons: I haven't been completely following, but +1 to what fantasai said
16:42:22 <fantasai> jensimmons: about the syntax of inner and outer is super useful
16:42:35 <fantasai> jensimmons: teaching now, and later once all browser support it, will likely switch to it
16:42:46 <fantasai> emilio: but if we serialize into old syntax, doesn't seem so useful?
16:43:05 <fantasai> emilio: serializing the old value increases time to adoption, while serilizing the new value which is nicer, but...
16:43:25 <fantasai> astearns: I do agree with Tab's first point, that we do try to keep the serialization of specified values as close to what author inputted as possible
16:43:42 <fantasai> astearns: and sounds like Emilio is OK with that, and didn't hear concerns about having specified vs computed being different
16:43:52 <fantasai> astearns: so proposed resolution is that for specified values we serialize as written
16:44:00 <fantasai> astearns: and for ocmputed value, we canonicalize
16:44:19 <fantasai> emilio: not quite as written, if you write "inline flow"... do you want to serialize to "inline"?
16:44:22 <fantasai> emilio: nevermind
16:44:23 <fantasai> emilio: sounds OK
16:44:52 <fantasai> jensimmons: Not sure what issue is, but if this affects what appears in the computed panel in devtools, idea of browsers saying "I took old value for you and put it into the new style" that would be a good thing
16:45:04 <fantasai> emilio: The computed panel, you can put whatever there. Doesn't affect specified.
16:45:16 <fantasai> jensimmons: I think what happens in parsing engine, nobody knows, doesn't matter to authors
16:45:24 <fantasai> astearns: So can we resolve?
16:45:38 <fantasai> RESOLVED: serialize specified value of display using keywords specified
16:45:52 <bradk> +1
16:46:00 <fantasai> Topic: display: contents list-item
16:46:06 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4022
16:46:12 <fantasai> astearns: Proposal is close wontfix?
16:46:27 <fantasai> TabAtkins: brought up that there's nothing theoretically wrong with 'display: contents list-item' which would generate a ::marker
16:46:38 <fantasai> TabAtkins: Currently the grammar doesn't allow combining these two
16:46:48 <fantasai> TabAtkins: My objection to this is just that we don't have any particularly strong reason to do so
16:46:52 <fantasai> TabAtkins: but there's nothing wrong with it
16:46:56 <fantasai> TabAtkins: so suggesting close no change
16:47:10 <fantasai> TabAtkins: but no objection to making it possible if someone thinks this is a useful thing that we should allow
16:47:23 <fantasai> astearns: My case in the comments is completely theoretically
16:47:30 <fantasai> TabAtkins: I can see it, but I think it's one more thing that we don't necessarily need
16:47:37 <fantasai> emilio: seems like one more case that we should avoid, so ok with no change
16:47:49 <fantasai> astearns: Any objections to no change?
16:47:52 <fantasai> RESOLVED: close wontfix
16:47:56 <emilio> s/case that we should/edge case we should
16:48:08 <fantasai> astearns: If Mats feels strongly, he could reopen it
16:48:21 <fantasai> Topic: flow keyword is redundant
16:48:24 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3998
16:48:33 <bradk> bradk has joined #css
16:48:43 <fantasai> TabAtkins: Mats pointed out that the 'flow' keyword doesn't technically do anything
16:48:58 <fantasai> TabAtkins: the display-outside value you pair it with, if don't specify anything else, it's implied
16:49:01 <fantasai> TabAtkins: was wondering why it's there
16:49:04 <fantasai> TabAtkins: there are 2 reasons
16:49:12 <fantasai> TabAtkins: it was a remnant of display-inside/display-outside as sperate properties
16:49:18 <fantasai> TabAtkins: did need a keyword for ordinatry flow
16:49:26 <fantasai> TabAtkins: when we collapsed back to shorthand, combined values
16:49:42 <fantasai> TabAtkins: and then I'm personally not a fan of states which are expressed by a lack of a keyword
16:49:49 <miriam> +1
16:49:59 <fantasai> TabAtkins: so prefer when a particular state allows an explicit keyword, even if getComptutedStyle omits it
16:50:05 <fantasai> TabAtkins: lastly, Firefox already shipped with it
16:50:15 <fantasai> TabAtkins: so my preferred resolution is to close no change, keep the keyword
16:50:38 <fantasai> astearns: any other comments?
16:50:46 <fantasai> RESOLVED: close no change
16:51:06 <fantasai> jensimmons: Sounds to me like this would have a big impact on authors for the reason we discussed earlier, and we want this
16:51:11 <fantasai> jensimmons: so all in favor of the resolution
16:51:19 <fantasai> Topic: Publishing Display
16:51:27 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6516
16:51:46 <fantasai> astearns: proposed resolution is to publish CRD
16:51:50 <fantasai> astearns: we have changes list and doC
16:52:00 <chris_> looks good to me
16:52:14 <fantasai> TabAtkins: the one thing, we will need to do slight modifications to make that resolution about canonicalization clear, but I think that's the only change not reflected in the draft
16:52:35 <TabAtkins> fantasai: We're actually set to publish a new CR Snapshot, which is the one that invokes patent policy
16:52:48 <TabAtkins> fantasai: But we don't have horizontal review when we pulled in 'order' and 'visibility'
16:52:58 <TabAtkins> fantasai: We need review on those bc they're major changes compared to previous CR
16:53:15 <fantasai> https://drafts.csswg.org/css-display-3/#visibility
16:53:27 <TabAtkins> fantasai: Also want the WG to take a look at the 'visibility' section in particular. We didn't just copy from CSS2, we added more text, especially for interactivity (clicking, etc) which wasn't clearly specified in CSS2
16:53:43 <TabAtkins> fantasai: So after we get review on this new CRD, our intention is to request a new CR snapshot
16:53:57 <fantasai> astearns: Objections to publishing CRD after edits from today?
16:54:11 <fantasai> RESOLVED: Publish new CRD of css-display-3 (after today's edits)
16:54:34 <fantasai> Topic: Invalidation of Static Ranges
16:54:38 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4597#issuecomment-892202307
16:54:57 <fantasai> dandclark: Static ranges can get into weird states, like if I remove one boundary from the DOM
16:55:10 <fantasai> dandclark: Sanket came up with criteria for deciding if a range is valid or invalid
16:55:28 <fantasai> dandclark: but the qustion is, if user adds range to a highlight should we use a live range, or use static range internally
16:55:47 <fantasai> dandclark: reason to use live range, don't have to check validity in the same way because they're kept up to date
16:55:59 <fantasai> dandclark: We discussed awhile, and decided not to back static ranges with a live range
16:56:18 <fantasai> dandclark: first, perf reasons -- live ranges, they can slow down DOM mutations because live ranges have to be notified every time there's a DOM mutation
16:56:22 <fantasai> dandclark: static range doesn't have that issue
16:56:30 <fantasai> dandclark: we did some research showing that this perf issue is observable
16:56:39 <fantasai> dandclark: and we also found that with caching, it's possible to cache static range validdity
16:56:49 <fantasai> dandclark: which reduces perf cost during painting
16:56:58 <fantasai> dandclark: but if they were backed by live ranges internally, that wouldn't hold
16:57:07 <fantasai> dandclark: because DOM mutations would have to update, so lose perf benefits
16:57:18 <fantasai> dandclark: Sanket also raised some issues with using live ranges internally
16:57:22 <castastrophe> castastrophe has joined #css
16:57:23 <fantasai> dandclark: Authors don't have direct references to those live ranges
16:57:34 <fantasai> dandclark: so difficult, how would they remove or modify a highlight that they added?
16:57:44 <fantasai> dandclark: even if we added a map, can become out of sync with tree
16:57:59 <fantasai> dandclark: and not clear when safe to drop live range, because author might de-regeister and re-register a static range
16:58:10 <fantasai> dandclark: so confusing developer-confusing scenarios there, tricky answers for spec
16:58:21 <fantasai> dandclark: so proposal is to allow static ranges and live ranges to be added to highlights
16:58:29 <fantasai> dandclark: and there's no live range backing for static ranges
16:58:52 <fantasai> astearns: My first question was, can developer use either
16:58:53 <bradk> bradk has joined #css
16:59:00 <fantasai> astearns: is it clear to devs that live range could have perf implications?
16:59:09 <fantasai> dandclark: It's in line with current use of live ranges
16:59:22 <fantasai> dandclark: Spec issue states that static ranges solve this perf
16:59:34 <fantasai> dandclark: Use of live ranges in genera, here or otherwise, has these perf costs
16:59:46 <fantasai> dandclark: I think it's a documentation and devrel issue
16:59:53 <fantasai> dandclark: of when live ranges vs static ranges are appropriate
17:00:03 <fantasai> sanketj: HTML doc also mentions this (?)
17:00:07 <fantasai> sanketj: It has been documented
17:00:25 <fantasai> sanketj: Static ranges are fairly new concept, previously only had option of live ranges
17:00:37 <fantasai> astearns: OK, out of time
17:00:48 <fantasai> astearns: my understanding is that with this impl experience, you would like to close issue no change?
17:00:54 <fantasai> dandclark: yes
17:01:03 <fantasai> astearns: OK, we'll expect to close no change, and will resolve next week
17:01:07 <castastrophe> present+
17:01:09 <fantasai> Meeting closed.
17:09:48 <astearns> topic: end
17:09:53 <astearns> zakim, end meeting
17:09:53 <Zakim> As of this point the attendees have been cbiesinger, rachelandrew, alisonmaher, dandclark, Morgan, dbaron[m], miriam, GameMaker, plinss, sanketj, bradk, jensimmons, Rossen_,
17:09:56 <Zakim> ... emilio, argyle, TabAtkins, bkardell_, chris_, lea, smfr, castastrophe
17:09:56 <Zakim> RRSAgent, please draft minutes v2
17:09:56 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/18-css-minutes.html Zakim
17:09:58 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:10:03 <Zakim> Zakim has left #css
18:09:06 <dholbert_> dholbert_ has joined #css
18:13:29 <futhark> futhark has joined #css
19:20:31 <dholbert_> dholbert_ has joined #css
19:45:52 <castastrophe> castastrophe has joined #css
20:38:42 <dholbert> dholbert has joined #css
21:45:37 <castastrophe> castastrophe has joined #css