IRC log of css on 2021-03-03

Timestamps are in UTC.

23:56:17 [RRSAgent]
RRSAgent has joined #css
23:56:17 [RRSAgent]
logging to
23:56:19 [Zakim]
RRSAgent, make logs Public
23:56:20 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:58:43 [plinss]
23:58:50 [argyle]
argyle has joined #css
23:59:02 [argyle]
23:59:11 [Rossen_]
23:59:44 [aja]
aja has joined #css
23:59:56 [Morgan]
Morgan has joined #css
00:00:00 [jfkthame]
jfkthame has joined #css
00:00:23 [miriam]
00:00:25 [fantasai]
00:00:44 [chris]
chris has joined #css
00:00:46 [heycam]
heycam has joined #css
00:00:53 [fantasai]
ScribeNick: fantasai
00:01:02 [dlibby]
dlibby has joined #css
00:01:07 [smfr]
smfr has joined #css
00:01:11 [Morgan]
00:01:13 [dlibby]
00:01:16 [alisonmaher]
alisonmaher has joined #css
00:01:18 [xiaochengh]
xiaochengh has joined #css
00:01:21 [astearns]
00:01:22 [alisonmaher]
00:01:25 [chris]
00:01:48 [smfr]
00:01:50 [leaverou]
00:01:53 [heycam]
00:02:28 [sanketj]
sanketj has joined #css
00:02:28 [jfkthame]
00:02:35 [sanketj]
00:02:39 [TYLin]
00:02:41 [myles]
myles has joined #css
00:02:44 [myles]
present+ myles
00:03:06 [dholbert]
00:03:45 [fantasai]
Topic: advance-override details
00:03:49 [Rossen_]
00:05:11 [myles]
fantasai: We decided we wanted to add an advance-override descriptor to the @font-face rule, but we didnt' define what it actually does other htan to say it takes a percentage that's resovled agains the advance itself
00:05:34 [chris]
00:05:37 [una]
00:05:41 [myles]
fantasai: A couple of points that would need to be resolved: 1. How are we increasing or decreasing the advance width? The size of the glyph in bohth axes together? Just x axis? Space around each glyph? left side? right side, start end, end end?
00:05:59 [myles]
fantasai: There's been some discussion in the issue about what it should apply to and how it should apply, but no conclusions.
00:06:15 [myles]
fantasai: I think the first thing we'd have to decide is how we increase the size of the glyphs
00:06:19 [myles]
fantasai: to do text layout
00:06:32 [fantasai]
myles: Shouldn't distort the outlines
00:06:44 [Rossen_]
ack chris
00:06:50 [fantasai]
chris: We're changing the advance, not the bounding box of the glyph. Not changing the outline
00:06:59 [fantasai]
chris: just changing the amount you need to move forward
00:07:03 [myles]
chris: We're changing the advance, not the bounding box of the glyphs, n or teh geometry. We're changing the amount you need to move forward before painting the next glyphs. Changing spacing in the text advance direction
00:07:04 [fantasai]
chris: very clearly not changing any glyph geometry
00:07:09 [myles]
chris: There's also a size override, but there's separate
00:07:13 [fantasai]
chris: There is a proposal to have a scale factor, but that's separate
00:08:04 [fantasai]
myles: I think that the exact way that space is added, I think that's not a super important decision, so doing whatever makes sense is easiest. For us that would be applying to the right side always
00:08:24 [fantasai]
Rossen_: Is that affected by directionality?
00:08:27 [fantasai]
myles: No, always on the right side
00:08:30 [fantasai]
chris: Why?
00:08:42 [fantasai]
myles: it's just easier to implement. Base-level API renders text LTR
00:08:59 [fantasai]
chris: So you're saying you do bidi reordering in the backing store and then apply space after that?
00:09:07 [jfkthame]
00:09:09 [fantasai]
Rossen_: So proposal is to keep it uniform on one side
00:09:38 [fantasai]
jfkthame: I would not like to specify that space is only applied on one side
00:09:44 [fantasai]
jfkthame: if that's easiest to apply, maybe allow it
00:09:47 [fantasai]
jfkthame: but I don't think that's the best behavior
00:09:56 [fantasai]
jfkthame: browser should be able to apply equally across both sides of glyph
00:10:01 [fantasai]
jfkthame: which is superior
00:10:08 [Rossen_]
ack jfkthame
00:10:12 [Rossen_]
ack fantasai
00:10:34 [chris]
I'm a bit concerned about margins not lining up, with space at the margins
00:11:49 [Rossen_]
00:12:00 [fantasai]
chris: could add space not at margins
00:12:18 [fantasai]
myles: bleeds into my point. naive implementation is to just multiply the number in the font file
00:12:23 [fantasai]
myles: but that applies before shaping
00:12:31 [fantasai]
myles: when you apply shaping, have to match what's in the font file.
00:12:40 [fantasai]
myles: Correct implementation of this needs to apply this after shaping
00:12:44 [fantasai]
myles: which is a more complicated implementation
00:12:51 [TabAtkins]
00:12:59 [fantasai]
myles: doing something like what chris said is not hard, because you're already at the level of knowing that information
00:13:10 [fantasai]
Rossen_: So sounds like we're aligning on adding space on both sides?
00:13:17 [fantasai]
Rossen_: any other opinions? or resolve?
00:13:40 [fantasai]
myles: If you do it on both sides, then alignment won't look good on either side
00:14:26 [fantasai]
jfkthame: We're putting the space equally makes for a less-bad result than you will get than if it's all on one side
00:14:36 [fantasai]
jfkthame: in practice, I don't think this is a feature that should be used for a large adjustment
00:14:47 [fantasai]
jfkthame: it's for fine-tuning the metrics of a fallback font to match another font
00:14:59 [fantasai]
jfkthame: so the adjustment is going to be a small fraction of a glyph width. Not too bad.
00:15:08 [fantasai]
myles: I suggest leaving it undefined
00:15:11 [chris]
we should put that wording from jfkthame into the spec - fine adjustments, not major ones. fine tuning
00:15:22 [fantasai]
myles: Major point is that it makes text more/less compact
00:15:35 [fantasai]
myles: Might be worth getting impl experience
00:15:50 [fantasai]
jfkthame: Wrt trimming space at line boundaries, I'd be opposed.
00:15:57 [fantasai]
jfkthame: This is effectively about modifying the metrics of the font
00:16:14 [fantasai]
jfkthame: if you modify metrics of a glyph, should be everywhere that glyph occurs, not different based on position in the line
00:16:40 [Rossen_]
ack fantasai
00:18:08 [TabAtkins]
q+ to remind that we're trying to better solve a case where people are *already* doing letter-spacing
00:18:09 [astearns]
AFAIK this feature is NOT about making things look good, it’s merely about reducing layout shift once a font loads
00:18:27 [fantasai]
fantasai: Slight tangent, but
00:18:34 [fantasai]
fantasai: This feature has a lot of badness to it
00:18:43 [fantasai]
fantasai: First, as we've been discussing, it distorts alignment
00:18:53 [fantasai]
fantasai: Second, it breaks complex and cursive writing systems
00:19:23 [fantasai]
fantasai: Third, because it introduces uneven amounts of spacing between pairs of characters, it distorts the rhythm of the text and hence impacts readability in a negative way
00:19:43 [fantasai]
fantasai: None of these problems apply if the font is scaled in both axes instead of adding space between characters
00:19:43 [liam]
liam has joined #css
00:20:12 [fantasai]
fantasai: And I think it would be harmful if we ship this feature without also shipping a scaling-factor descriptor that could be used in any cases where that would be usable in place of advance-override
00:20:21 [fantasai]
jfkthame: Strongly agree with that.
00:20:26 [Rossen_]
00:20:34 [Rossen_]
ack TabAtkins
00:20:34 [Zakim]
TabAtkins, you wanted to remind that we're trying to better solve a case where people are *already* doing letter-spacing
00:20:54 [xiaochengh]
00:22:17 [fantasai]
TabAtkins: Keep in mind, the goal is not to define a new typographic feature for text. It's to replace existing hacks that people use to reduce layout shift when fonts load
00:22:26 [fantasai]
TabAtkins: if we can reduce layout shift, even if it looks bad, still successful
00:22:37 [fantasai]
TabAtkins: Want it to look good and make it work across writing systems
00:22:47 [fantasai]
TabAtkins: but if not ideal, that's fine, because that's not the point
00:23:03 [fantasai]
TabAtkins: should be for fonts that not there for very long, will be replaced by the real font later
00:23:17 [fantasai]
TabAtkins: Want a solution that works across scripts and works OK, better than current hacks
00:23:27 [Rossen_]
ack xiaochengh
00:23:33 [fantasai]
xiaochengh: Regarding scaling / font-size override
00:23:45 [fantasai]
xiaochengh: we have prototyped in Chrome, and found it tricky to nicely specify
00:23:55 [fantasai]
xiaochengh: This might affect ascent-override etc.
00:24:11 [fantasai]
xiaochengh: they have a %, which font-size do these resolve against? resolve against the font-size property value of the element or used font size?
00:24:16 [fantasai]
xiaochengh: Either way going to surprise some users
00:24:35 [fantasai]
xiaochengh: since our main focus is to reduce layout shift, wouldn't want to introduce a blocking issue on top of advance override
00:24:52 [TabAtkins]
fantasai: To reply to TAb, I udnerstand this is for reducing layout shift
00:24:56 [Rossen_]
ack fantasai
00:25:09 [TabAtkins]
fantasai: But there's different way to do that, and I think in many cases scaling outlines without affecting resolution of length units would also have that affect
00:25:22 [TabAtkins]
fantasai: wrt using it as a fallback, what happens if the other font doesn't load
00:25:33 [TabAtkins]
fantasai: This isn't "onlya pplies in a fallback font"
00:25:49 [TabAtkins]
fantasai: People on slow connections, etc are stuck with a font that's not just non-ideal but also has weird spacing
00:26:00 [TabAtkins]
fantasai: And this doesn't work for complex or cursive script as specified today.
00:26:09 [TabAtkins]
fantasai: You can handle those scripts if you scale, not if you intro space.
00:26:32 [fantasai]
TabAtkins: if your fallback font plus scaling advance looks terrible, you chose a bad fallback font
00:26:48 [fantasai]
TabAtkins: we don't need to protect author from that. They should tweak it to be closer.
00:26:55 [fantasai]
TabAtkins: If it is, it's a bad page.
00:26:58 [jfkthame]
instead of `font-size-override`, suggest something like `glyph-scale-factor`, then it's clearer that it doesn't affect anything else
00:27:19 [fantasai]
myles: What is the exist for this discussion? We've talked about several issues here.
00:27:25 [myles]
00:27:25 [fantasai]
TabAtkins: Trying to figure out how to fix this for awhile
00:27:31 [myles]
s/exit/exit criteria/
00:27:35 [fantasai]
TabAtkins: keep getting objections that it's not ideal
00:27:43 [fantasai]
TabAtkins: but nobody is helping making a better solution
00:27:53 [fantasai]
TabAtkins: we did exploration with scaling, it doesn't lookg good
00:28:03 [fantasai]
TabAtkins: maybe we need to scale on some scripts
00:28:10 [fantasai]
TabAtkins: but essentially just letter-spacing works well
00:28:46 [fantasai]
fantasai: letter-spacing applies evenly
00:29:08 [fantasai]
fantasai: and if it's supposed to apply for temporary font, should shut off if you're not loading another font and sticking with this one
00:29:21 [fantasai]
TabAtkins: but then you have a layout shift
00:29:37 [fantasai]
fantasai: If downloading is turned off, then no layout shift
00:29:54 [fantasai]
myles: rogue character with accent in the middle of a paragraph causes ...
00:30:24 [fantasai]
Rossen_: Proposed path forward... not hearing a clear consensus around a) where the adjustment should take place or b) should we even have that
00:30:35 [fantasai]
Rossen_: I think we resolve in backwards order
00:30:45 [TabAtkins]
summary of myles: also useful if you have a fallback used for certain characters, which has an oddly different character size - this lets you adjust the fallback characters to feel better
00:31:21 [fantasai]
Rossen_: First question, should we still pursue this?
00:32:09 [chris]
OK so close this discussin with "needs proposal"?
00:32:44 [fantasai]
fantasai: I can live with having this plus a scaling factor, but not having just this one, because if only have a broken option that's not good enough
00:32:54 [fantasai]
myles: I think we should have both, changing scaling factor makes a lot of sense
00:33:22 [fantasai]
TabAtkins: Not hearing any objections to what we're doing here, other than fantasai's point.
00:33:30 [fantasai]
Rossen_: so no objection to continuing on this
00:33:48 [fantasai]
Rossen_: So specific proposal here, fantasai mentioned adding scaling factor and then we have to decide where space is added
00:33:57 [fantasai]
Rossen_: My proposal is to take back to the issue and iron it out there
00:35:04 [Rossen_]
ack fantasai
00:36:49 [fantasai]
fantasai: suggest to take a resolution on a) adding a scale-factor descriptor that only affects the glyph outline b) add space on both sides, maybe *allow* (MAY) UAs to do one side only if it's an implementation problem c) apply it to all glyphs in all writing systems, d) warn about how that can break things in certain writing systems / if too much space is added
00:37:11 [Rossen_]
Topic: Consider clarifying Highlight system color, and maybe adding a new system color for control background
00:37:19 [Rossen_]
00:37:59 [fantasai]
chris: emilio raised it
00:38:04 [fantasai]
chris: I'm reluctant to add a new system color
00:38:25 [Rossen_]
Topic: Commas in color-mix()
00:38:32 [Rossen_]
00:38:51 [fantasai]
leaverou: Since we have rule that ? reptition should use commas but not other things
00:38:59 [fantasai]
leaverou: we removed commas from color-mix because not a list
00:39:09 [fantasai]
leaverou: but it doesn't read very nicely, and not clear which color the percentage belongs to
00:39:13 [fantasai]
leaverou: so thinking to add the colors back
00:39:14 [Rossen_]
00:39:22 [fantasai]
leaverou: since we can't keep going back and forth about it, UAs are implementing
00:39:27 [fantasai]
leaverou: Wanted to resolve this once and for all
00:39:33 [fantasai]
leaverou: I also agree it's more readable with commas
00:39:38 [TabAtkins]
q+ to agree
00:39:38 [una]
00:39:42 [fantasai]
leaverou: I think it should have a comma to separate metadata from list of colors
00:39:45 [una]
to also agree (we need commas)
00:39:56 [fantasai]
leaverou: clarify whether about the first color or the function as a whole
00:40:01 [fantasai]
leaverou: Seem to have consensus on adding them back
00:40:08 [fantasai]
leaverou: Also, do we still have 'in' for color space?
00:40:19 [fantasai]
leaverou: Seems like only have color space in the beginning
00:40:30 [Rossen_]
ack TabAtkins
00:40:30 [Zakim]
TabAtkins, you wanted to agree
00:40:37 [fantasai]
TabAtkins: Agree with leaverou
00:40:46 [fantasai]
TabAtkins: we're not attached to using commas everywhere like JS is
00:40:51 [fantasai]
TabAtkins: only use it in some places
00:40:55 [fantasai]
TabAtkins: It works reasonably here
00:40:58 [fantasai]
TabAtkins: and helps with readability
00:41:15 [fantasai]
TabAtkins: and we should also have the metadata in a single thought at the beginning, separated by comma
00:41:20 [fantasai]
TabAtkins: consistent with gradients and shapes
00:41:32 [fantasai]
TabAtkins: so +1 to what leaverou suggested
00:41:41 [Rossen_]
ack una
00:41:42 [fantasai]
una: I agree that commas are needed here
00:41:45 [fantasai]
una: much like gradients
00:41:57 [miriam]
+1 need commas
00:42:01 [fantasai]
una: I also want to add, I don't think we need end keyword if we have this syntax
00:42:04 [leaverou]
00:42:10 [fantasai]
una: I think we are reaching consensus in the issue, and +1 to proposal
00:42:14 [chris]
00:42:18 [aja]
fwiw, emilio landed on nightly, used commas, & % applied to 2nd color, "in srgb" at start or end. willing to change
00:42:27 [fantasai]
leaverou: I would argue for 'in' keyword
00:42:36 [Rossen_]
ack leaverou
00:42:45 [fantasai]
leaverou: it reads better, and also lets us expand the syntax later to add more options
00:42:49 [tantek]
tantek has joined #css
00:43:02 [fantasai]
leaverou: So, makes it more readable and makes syntax less ambiguous, so argue to keep it
00:43:11 [fantasai]
Rossen_: Seems like we have consensus around adding commas, any objections?
00:43:23 [chris]
great, emilio already implemented what we are about to resolve <3
00:43:26 [fantasai]
RESOLVED: Add back commas
00:43:48 [una]
00:43:50 [fantasai]
Rossen_: Next one is do we want to have the 'in' keyword
00:43:58 [fantasai]
una: I would like to object to it
00:43:59 [Rossen_]
ack una
00:44:09 [leaverou]
00:44:10 [aja]
chris, except for which color the percentage applies to
00:44:17 [TabAtkins]
Also object, we don't use these sorts of intro keywords except absolutely necessary for disambiguation.
00:44:19 [fantasai]
una: Reasoning, I don't think it's necessary and we don't have a construct of 'in' elsewhere in CSS, so introduces new concept not seen anywhere else and I don't think it adds clarity
00:44:34 [astearns]
we have 'at' elsewhere
00:44:35 [fantasai]
una: Don't want to add new syntax to CSS
00:44:35 [TabAtkins]
Colorspace keywords are plenty clear and won't block our extensibility in the future.
00:44:47 [fantasai]
Rossen_: OK, I suggest we open a separate issue for this
00:44:48 [TabAtkins]
astearns, yeah, that's for disambiguation
00:45:02 [TabAtkins]
because there are two positions
00:45:02 [Rossen_]
ack leaverou
00:45:16 [fantasai]
leaverou: Using prepositions for metadata in functions is common in gradients as well, which is where I got the inspiration. But agree with separate issue.
00:45:32 [tantek]
00:45:39 [fantasai]
TabAtkins: I'm happy to argue that gradients are special
00:45:45 [Rossen_]
Topic: More clarity around the percentage in color-mix()
00:45:56 [Rossen_]
00:46:30 [TabAtkins]
gradients use "to" because it disambiguates whether the gradient comes *from* that direction or goes *to* that direction (and we flipped back and forth during dev, so there's no obvious answer).
00:46:31 [fantasai]
miriam: In the middle space, single percentage value, and spec was conflicted on what that refers to
00:46:40 [fantasai]
miriam: is it percentage color, or distance to second color
00:46:40 [chris]
00:46:44 [fantasai]
miriam: or percentage of second color
00:46:49 [fantasai]
miriam: spec disagreed with itself
00:46:52 [TabAtkins]
gradients use "at" to separate the <position> from the possibly-preceding <length>{1,2}
00:46:57 [fantasai]
miriam: with commas, would be nice to do percentage in either color
00:47:05 [leaverou]
note: the spec has since been fixed and does not disagree with itself anymore :)
00:47:10 [fantasai]
miriam: so if you put in first color refers to weight of that color, second is weight of second color
00:47:14 [Rossen_]
00:47:18 [leaverou]
00:47:20 [fantasai]
miriam: would have to decide what to do if 2 percentages are specified
00:47:31 [fantasai]
miriam: SASS functions confusing as well, never clear to me which the percent refers to
00:47:32 [TabAtkins]
00:47:44 [Rossen_]
ack chris
00:47:49 [fantasai]
chris: My understanding was % is % of that color, and all examples (there were more examples before)
00:48:05 [fantasai]
chris: there was just one sentence that was off, and Adam fixed ti
00:48:20 [fantasai]
chris: Seems clear it's a % of that color, not along a blend between the two colors
00:48:32 [fantasai]
chris: the color that it's next to
00:48:41 [fantasai]
leaverou: mixing paints, makes sense % of first color
00:48:46 [fantasai]
chris: ... that's confusign
00:49:15 [fantasai]
chris: if % don't add up, scale to add to 100%
00:49:18 [fantasai]
chris: does that make sense?
00:49:31 [fantasai]
miriam: So % goes with a color between the commas, that makes sense to me
00:49:43 [fantasai]
miriam: so % can be applied to either color, and can put it in one or both
00:49:57 [fantasai]
leaverou: Should allow for ...
00:50:00 [fantasai]
leaverou: and scale accordingly
00:50:07 [fantasai]
chris: Have that in HWB, if too high scale it back
00:50:13 [Rossen_]
ack leaverou
00:50:33 [fantasai]
TabAtkins: I think whichever syntax we go with, should be consistent between color-mix() and cross-fade()
00:50:37 [fantasai]
00:50:44 [fantasai]
TabAtkins: cross-fade() matches up with what miriam suggests
00:50:50 [fantasai]
TabAtkins: can add % with any of the images
00:51:01 [fantasai]
TabAtkins: whichever one, if omitted, it's just 100% - [sum]
00:51:13 [fantasai]
TabAtkins: if don't add up to 100%, we fill in the remainder with a transparent image
00:51:17 [Rossen_]
ack TabAtkins
00:51:32 [fantasai]
TabAtkins: idk if we want to do with colors
00:51:33 [chris]
prefer a rebalance like HWB
00:51:45 [fantasai]
leaverou: 3-way mixes are confusing, too many ways to do it
00:52:05 [fantasai]
TabAtkins: I agree with reasoning for not doing 3-color mixes, but adding in transparency doesn't suffer from same confusion issues
00:52:13 [fantasai]
TabAtkins: not strong on either, but greater consistency with cross-fade() would be good
00:52:14 [Rossen_]
00:52:42 [TabAtkins]
chris, note that HWB does *not* rebalance for <100% sum
00:52:59 [TabAtkins]
there it takes the remainder from the pure hue
00:53:19 [TabAtkins]
>100% causing rescaling is uncontroversial and common between all the functions, yes
00:53:28 [leaverou]
00:53:43 [fantasai]
Rossen_: Can someone summarize the proposed resolution?
00:54:07 [fantasai]
leaverou: Before we summarize, one last point
00:54:11 [TabAtkins]
Proposed new grammar: color-mix(<metadata>, <color-option>#{2}), where <color-option> = <color> && <percentage>?
00:54:24 [fantasai]
leaverou: if we handle percentages < 100% by mixing with transparent, it has special interpolation handling so [????]
00:54:43 [leaverou]
s/[????]/we don't want to do that/
00:54:50 [chris]
q+ for the negative percentages
00:54:51 [fantasai]
TabAtkins: Ignoring the < 100% sum and take it to the issue, think we can resolve on the rest
00:55:04 [argyle]
`color-mix(in lch red 80%, blue)` also `color-mix(in lch, red, blue 80%)`
00:55:11 [argyle]
`color-mix(in lch, red 80%, blue)` also `color-mix(in lch, red, blue 80%)`
00:55:13 [fantasai]
TabAtkins: proposal above
00:55:18 [fantasai]
TabAtkins: if above 100%, rescale to add to 100%
00:55:32 [TabAtkins]
if below 100%, figure out in issue
00:55:46 [fantasai]
Rossen_: any objections?
00:55:50 [fantasai]
RESOLVED: color-mix(<metadata>, <color-option>#{2}), where <color-option> = <color> && <percentage>?
00:56:06 [fantasai]
Topic: [css-color-5] How should negative percentages behave in color-mix()?
00:56:26 [fantasai]
chris: ? who is implementing pointed out that can't do negative percentages
00:56:34 [fantasai]
chris: una said why don't we flip it 0-100%
00:56:36 [fantasai]
chris: nobody wants this
00:56:38 [fantasai]
chris: I can define it
00:56:47 [fantasai]
00:56:47 [smfr]
s/?/Sam Weinig/
00:56:51 [fantasai]
fantasai: Can you make it invalid?
00:57:00 [fantasai]
TabAtkins: invalid matches behavior in other mixing functions
00:57:07 [fantasai]
TabAtkins: we intend for it to be meaningless, so should be invalid
00:57:17 [fantasai]
RESOLVED: negative percentages are invalid in color-mix()
00:57:25 [argyle]
sounds like calc() would get scary?
00:57:44 [Rossen_]
00:57:47 [Rossen_]
00:57:55 [chris]
ack chris
00:57:55 [Zakim]
chris, you wanted to discuss the negative percentages
00:58:06 [chris]
ack lea
00:58:29 [fantasai]
Topic: end
00:58:44 [fantasai]
Rossen_: OK, end of meeting, we'll take the rest next week
00:58:54 [chris]
present+ zoe
00:59:03 [Rossen_]
00:59:27 [Rossen_]
Zakim, end meeting
00:59:27 [Zakim]
As of this point the attendees have been plinss, argyle, Rossen_, miriam, fantasai, Morgan, dlibby, astearns, alisonmaher, chris, smfr, leaverou, heycam, jfkthame, sanketj, TYLin,
00:59:30 [Zakim]
... myles, dholbert, una, TabAtkins, tantek, zoe
00:59:30 [Zakim]
RRSAgent, please draft minutes v2
00:59:30 [RRSAgent]
I have made the request to generate Zakim
00:59:32 [Zakim]
I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye
00:59:36 [Zakim]
Zakim has left #css
01:40:06 [dauwhe]
dauwhe has joined #css
04:03:09 [liam_]
liam_ has joined #css
05:44:10 [florian]
florian has joined #css
07:32:28 [florian]
florian has joined #css
07:34:51 [florian]
florian has joined #css
07:40:59 [florian]
florian has joined #css