16:59:39 <RRSAgent> RRSAgent has joined #css
16:59:43 <RRSAgent> logging to https://www.w3.org/2025/03/05-css-irc
16:59:43 <Zakim> RRSAgent, make logs Public
16:59:44 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:00:01 <bkardell_> present+
17:00:15 <flackr> flackr has joined #css
17:00:21 <kbabbitt> kbabbitt has joined #css
17:00:31 <flackr> present+
17:00:39 <JoshT> present+
17:00:43 <kizu> kizu has joined #css
17:00:52 <kbabbitt> present+
17:00:56 <kizu> present+
17:01:00 <bramus> present+
17:01:11 <alisonmaher> alisonmaher has joined #css
17:01:17 <alisonmaher> present+
17:01:19 <ydaniv> present+
17:01:56 <dholbert> dholbert has joined #css
17:02:08 <smfr> smfr has joined #css
17:02:39 <gfaujdar> gfaujdar has joined #css
17:02:47 <Di> Di has joined #css
17:02:48 <noamr> noamr has joined #css
17:02:51 <gfaujdar> present+
17:02:53 <noamr> present+
17:03:07 <masonf> masonf has joined #css
17:03:12 <dholbert> present+
17:03:13 <fantasai> scribenick: fantasai
17:03:17 <fantasai> Topic: Administrivia
17:03:25 <fantasai> astearns: Looks like we can skip item 2
17:03:25 <weinig> present+
17:03:42 <fantasai> bramus: US is switching to summer time, but Europe is lagging.
17:04:02 <fantasai> bramus: so next two weeks Europe will have CSSWG meetings at a different time
17:04:03 <vmpstr> present+
17:04:08 <fantasai> bramus: since out of sync with US
17:04:12 <bramus> s/two/three
17:04:23 <fantasai> astearns: Good luck everyone with figuring out international meetings
17:04:29 <emilio> present+
17:05:08 <fantasai> astearns: Another change is Pete Snyder was supposed to make this meeting, but couldn't due to a conflict.
17:05:08 <schenney> schenney has joined #css
17:05:16 <schenney> present+
17:05:22 <smfr> present+
17:05:27 <jfkthame> jfkthame has joined #css
17:05:31 <hober> present+
17:05:40 <ChrisL> q+
17:05:41 <miriam> present+
17:05:51 <kbabbitt> scribe+ kbabbitt
17:05:56 <jfkthame> present+
17:06:02 <kbabbitt> fantasai: nt1m published first draft of css-forms-1, looking for feedback
17:06:05 <fantasai> https://lists.w3.org/Archives/Public/www-style/2025Mar/0004.html
17:06:07 <chrishtr> present+
17:06:09 <kbabbitt> astearns: we have an openui meeting tomorrow
17:06:17 <fantasai> astearns: should put it on the agenda for review
17:06:20 <lea> lea has joined #css
17:06:37 <fantasai> fantasai: hoping to publish FPWD soon, since the draft is fairly complete now (even though lots of issues)
17:06:39 <smfr> https://drafts.csswg.org/css-forms/
17:06:49 <github-bot> Topic: [meta][css-fonts-4] Index of local font issues: fingerprinting, I18n, privacy
17:07:02 <fantasai> hober notes that Metafont is an actual thing
17:07:48 <fantasai> ChrisL: I created this meta-issue ... to organize the discussion
17:08:09 <fantasai> ChrisL: Sometimes we solve certain aspects and close an issue, so this is why closed issues are included
17:08:20 <fantasai> ChrisL: Want to show where we are, what we've solved / not solved, etc.
17:08:22 <SebastianZ> SebastianZ has joined #css
17:08:33 <fantasai> ChrisL: Some recent discussions around treating local fonts like webfonts
17:09:07 <fantasai> ChrisL: But we need to solve this in some way, and we need to not break the Web, and to not disadvantage users who use languages other than English
17:09:13 <fantasai> ChrisL: For example Chinese often relies on local fonts
17:09:37 <fantasai> ChrisL: Another use case was a word processor type application, where users expect the browser to access all the local fonts
17:09:56 <fantasai> ChrisL: Point of agenda item is to ask, who is interested in this topic? Who plans to work on it? If we come up with solutions, who will prototype them?
17:10:31 <fantasai> astearns: Looking for volunteers to look at the possible solutions, try to make progress up to and including prototyping, to see what we can do to make this a better situation across all browsers.
17:10:51 <SebastianZ> present+
17:11:02 <fantasai> noamr: I'm personally interested in it, but don't have the bandwidth atm. I can try to find ppl in Google internally, but that's the most I can commit to.
17:11:07 <fantasai> ChrisL: That's still helpful, thanks!
17:11:28 <fantasai> astearns: As we work on solutions and get closer to something that seems viable, it may be a little easier to convince others to take the time to prototype things.
17:11:45 <emilio> (not with a mic r/n), but I'm interested, and there's people at Moz that also are, but whether but whether we're the right people to prototype depends on what solutions we're talking about :)
17:11:47 <fantasai> astearns: I will say that I got 5 private responses to my query that was meant to prompt public reply-all of ppl interested in this issue.
17:12:11 <fantasai> astearns: People expressed their opinions on what most likely possibilities were on the issue, but just private replies and not sure what ppl are comfortable with me making public.
17:12:41 <fantasai> ChrisL: I sent a private reply. First I had increased time in CSSWG by 10% and plh was ok with it.
17:13:06 <fantasai> ChrisL: I also commented on what I thought were the most practical directions, but as the editor I want to be neutral.
17:13:10 <fantasai> ChrisL: so that's why private reply
17:13:33 <fantasai> astearns: I will commit more time to looking through these issues and replying with problems that I see, or avenues that seem promising.
17:13:42 <jensimmons> jensimmons has joined #css
17:13:43 <fantasai> astearns: I may not be quite the level of ChrisL, might be more 5% increase. :)
17:13:46 <jensimmons> present+
17:13:49 <dgrogan> dgrogan has joined #css
17:13:53 <Zakim> astearns, you wanted to read emilio's comment
17:14:00 <fantasai> astearns: [reads emilio's comment]
17:14:27 <fantasai> jfkthame: I'm in a fairly similar position to noamr, I'm interested, but I have very little bandwidth atm
17:14:48 <fantasai> jfkthame: at the same time, if/when we coalesce around ideas worth prototyping, I'm happy to advocate for them and try to find resources to work on it
17:15:07 <kbabbitt> q+
17:15:25 <fantasai> kbabbitt: Encourage incubating ideas
17:15:34 <astearns> ack kbabbitt
17:15:36 <fantasai> kbabbitt: Since I brought up word processing idea, I can discuss with those stakeholders
17:15:47 <fantasai> kbabbitt: Will try to produce data necessary
17:16:05 <fantasai> astearns: So maybe we take this back to the issues and get some more work done, unless anyone else wants to add to the conversation?
17:16:27 <fantasai> astearns: OK, done for now. Expect these issues to return!
17:17:07 <github-bot> Topic: [css-values] Distinction between `attr(foo type(<string>))` and `attr(foo string)` is too subtle
17:17:25 <fantasai> TabAtkins: attr() has the ability to say how to parse the attribute
17:17:34 <fantasai> TabAtkins: default behavior is to take the value and use it directly as a string
17:17:41 <fantasai> TabAtkins: we also have the ability to parse it as CSS value
17:17:55 <fantasai> TabAtkins: In particular, can parse it as a string. This is weird, because you would need to include the quotes.
17:18:06 <fantasai> TabAtkins: But it would also be weird to exclude that, so we're allowing it.
17:18:25 <fantasai> TabAtkins: But it's confusing because to get the first behavior you write 'string' and for the second behavior you write 'type(<string>)'
17:18:36 <fantasai> TabAtkins: These are super close to each other, and probably confusing for authors.
17:18:47 <fantasai> TabAtkins: Some discussion about other keywords.
17:18:55 <fantasai> TabAtkins: unparsed-string, raw-string ...
17:19:04 <bkardell_> sgtm
17:19:09 <fantasai> TabAtkins: Unless anyone has other ideas, propose to rename to raw-string
17:19:21 <fantasai> TabAtkins: this is one of the keywords that do special behaviors
17:19:23 <TabAtkins> attr(href raw-string)
17:19:38 <fantasai> fantasai: this is equivalent to attr(href)
17:19:57 <fantasai> astearns: If it's equivalent to syntax without keyword, can we just remove the keyword?
17:20:24 <fantasai> TabAtkins: We can't. For one thing, I prefer having explicit keywords. But more importantly, legacy behavior requires us to fall back to an empty string if the attribute is missing
17:20:38 <fantasai> TabAtkins: whereas the new behavior is falling back to Invalid At Computed Time behavior.
17:20:48 <fantasai> TabAtkins: It would be weird if you couldn't do that for the most common case
17:21:18 <fantasai> TabAtkins: so omitting falls back to empty string, including keyword falls back to IACT
17:21:48 <kbabbitt> fantasai: that is a subtle difference that is not going to be obvious at all
17:22:03 <kbabbitt> fantasai: if that's actually a behavioral difference I think it would be good to make it clearer
17:22:16 <kbabbitt> TabAtkins: don't know how to bake IACVT into a keyword
17:22:18 <kbabbitt> fantasai: me either
17:22:27 <kbabbitt> TabAtkins: right now if you specify a type at all you get IACVT as a fallback
17:22:41 <kbabbitt> TabAtkins: not tied to string vs ??, a little more for people to learn
17:22:51 <kbabbitt> TabAtkins: agree it's not great but need to work around legacy behavior
17:23:10 <fantasai> fantasai: Something for us to think about, if we can make it clearer.
17:23:18 <fantasai> astearns: So for now, proposal is to rename to raw-string
17:23:36 <fantasai> TabAtkins: Should do asap, since we're shipping already.
17:23:40 <bkardell_> +Q
17:23:44 <bkardell_> q-
17:23:56 <bkardell_> 1+
17:23:57 <fantasai> astearns: any objections to changing string to raw-string?
17:24:10 <fantasai> RESOLVED: Rename string keyword to raw-string
17:24:30 <github-bot> Topic: [css-overflow-5] Default UA styles for scroll markers and scroll buttons
17:25:05 <fantasai> flackr: We want to have a reasonable default styling for scroll markers and buttons, so they're visible
17:25:21 <fantasai> flackr: Our suggestion is to make scroll buttons to render like buttons, including handling 'appearance'.
17:25:27 <fantasai> flackr: and scroll markers would look like links
17:25:31 <fantasai> flackr: since they're interactive etc.
17:25:44 <TabAtkins> q+
17:25:59 <astearns> ack TabAtkins
17:26:08 <fantasai> TabAtkins: you did bring up question of appearance?
17:26:10 <dholbert> dholbert has joined #css
17:26:12 <fantasai> flackr: I implemented it, think it should
17:26:13 <fantasai> TabAtkins: agree
17:26:25 <astearns> ack fantasai
17:26:40 <kbabbitt> fantasai: the interesting question is whether the scroll markers match the ? pseudo class
17:26:45 <TabAtkins> :visited/:link
17:26:59 <kbabbitt> fantasai: technically they can't because :link by itself selects elements but not pseudos
17:27:11 <kbabbitt> fantasai; wondering what we want to do about that
17:27:21 <fantasai> s/;/:/
17:27:46 <fantasai> TabAtkins: So if page author changes their :link style, wouldn't change scroll markers?
17:27:50 <fantasai> fantasai: right
17:28:08 <chrishtr> q+
17:28:26 <fantasai> flackr: agree that would be nice... open to suggestions?
17:28:45 <JoshT> q+
17:29:08 <chrishtr> q-
17:29:34 <fantasai> astearns: If we don't find a way of having link styling apply to scroll marker, then what we're doing is requiring authors to add the ::scroll-marker selector to their link styling block
17:29:38 <fantasai> fantasai: which they're not going to remember to do
17:29:55 <fantasai> JoshT: Why are they being styled as links rather than buttons?
17:30:11 <fantasai> flackr: They scroll to content, just like regular links do
17:30:27 <chrishtr> it seems unlikely to me that developers won't notice that these Pseudos have the wrong colors, and then go fix it
17:30:43 <fantasai> JoshT: In the past, authors probably would have implemented as buttons; but I see the logic
17:31:00 <fantasai> TabAtkins: it depends what you're doing. Carousel dots, more like buttons; but for ToC, more like a link.
17:31:01 <chrishtr> the colors being wrong will make their scroll markers look invisible or totally wrong in prominent site ui
17:31:28 <fantasai> JoshT: What is the aria role?
17:31:38 <fantasai> flackr: They're tabs, with scroll marker group being the tablist
17:31:59 <kizu2> kizu2 has joined #css
17:32:12 <fantasai> astearns: Should we resolve on this, and then try to figure out link styling? Or is this a fundamental question we need to solve?
17:32:36 <fantasai> fantasai: the goal of default styling is to make it visible... if not visible, not a good thing?
17:32:51 <fantasai> TabAtkins: As chrishtr points out, authors will almost always tweak them anyway
17:32:56 <fantasai> TabAtkins: so they're going to notice if looks bad on the page.
17:33:22 <fantasai> TabAtkins: same as if they put a blue background; will notice links are invisible
17:33:25 <fantasai> TabAtkins: so probably fine
17:33:55 <fantasai> astearns: Whether or not fine, could resolve today on default styling for scroll markers matching link styling, and scroll buttons taking button styling
17:33:55 <chrishtr> +1 to this proposed resolution
17:34:03 <fantasai> astearns: anything about appearance?
17:34:29 <fantasai> TabAtkins: appearance applies to scroll buttons same as regular buttons
17:34:55 <fantasai> PROPOSED: Default styling for scroll markers will match default styling for links. Default styling for scroll buttons will match default styling for buttons (and appearance will apply accordingly).
17:34:59 <fantasai> RESOLVED: Default styling for scroll markers will match default styling for links. Default styling for scroll buttons will match default styling for buttons (and appearance will apply accordingly).
17:35:16 <fantasai> flackr: I'll open a separate issue for the :link-matching
17:35:36 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11208
17:35:36 <github-bot> Topic: [css-display-4] reading-flow and mix of auto-flow and explicit items
17:35:36 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11208.
17:36:22 <kbabbitt> TabAtkins: last time we discussed thre was a question about whether reading order is the one that explicitly sets an element to a particular spot
17:36:26 <kbabbitt> ... rather than relying on visual stuff
17:36:35 <kbabbitt> ... should work without opting into one of the other explicit reading flow values
17:36:41 <kbabbitt> ... whether it should be explicit or implict etc
17:36:45 <kbabbitt> ... authors had opinions in thread
17:37:00 <kizu> kizu has joined #css
17:37:00 <kbabbitt> ... the idea of having a reading-flow value that does no reordering by default but just gives side effects
17:37:03 <hober> fs
17:37:05 <kbabbitt> ... sounds perfectly reasonable
17:37:17 <kbabbitt> ... we didn't do this before because just tab-index was the side effect
17:37:40 <kbabbitt> ... but with reading order in display now it makes sense to have a reading-flow value that does no implicit reordering
17:37:50 <kbabbitt> ... just reordering that author asked for
17:37:58 <kbabbitt> ... we do however feel strongly that it needs to be a new keyword
17:38:09 <kbabbitt> ... rather than a default behavior that can trigger anytime an eleement has reading order
17:38:23 <kbabbitt> ... fantasai was suggesting that if any element has reading order it automatically makes parent into a reading flow container
17:38:28 <kbabbitt> ... emilio disagreed on perf implications
17:38:36 <kbabbitt> ... can't tell if something is a reading-flow container just from element itself
17:38:47 <kbabbitt> ... grid with a whole bunch of autoflow children can be an expenseive operation
17:39:00 <kbabbitt> ... I think becoming a reading flow container has side effects
17:39:35 <kbabbitt> ... having a child with reading order would implicitly apply side effects to siblings
17:39:49 <kbabbitt> ... this would happen if you have the same markup several times on a page or across multiple pages
17:39:58 <kbabbitt> ... only some have a reading order child or have a reading order child that is hideable
17:40:04 <kbabbitt> ... will change whether side effects apply to everything else
17:40:12 <kbabbitt> ... seems not great, just as hard for authors to predict as stated concern
17:40:23 <kbabbitt> ... that authors would not be able to predict whether reading flow works by default
17:40:34 <kbabbitt> ... so we are pretty strongly against reading flow working by default for these reasons
17:40:45 <kbabbitt> ... should instead opt into reading order
17:40:53 <kbabbitt> ... fantasai's third point in response was forward compatibility
17:41:07 <kbabbitt> ... if reading order automatically turns on reading flow containers, that only works if everything can be a reading order container
17:41:19 <kbabbitt> ... or if we fix the set of block types that can ever be reading order containers
17:41:28 <kbabbitt> ... otherwise others could set reading order on a block which would do nothing today
17:41:40 <kbabbitt> ... we could define it in the future and it would turn on suddenly causing side effects that they don't expect
17:41:53 <kbabbitt> ... fantasai suggested we could go ahead and define block-level reading flow right now in trivial case of no reordering
17:41:57 <kbabbitt> ... we're not super comfortable with that
17:42:07 <kbabbitt> ... display:block order is going to be complicated anyway
17:42:16 <kbabbitt> fantasai: I don't think so, we're not proposing to add new visual order
17:42:28 <kbabbitt> ... just saying you can have normal flow order and also apply reading order different from source order
17:42:49 <kbabbitt> ... you ahve an order that's the source order, you don't have a magic order, just saying reading order shoulda pply to source order like in a flexbox
17:43:08 <kbabbitt> ... don't think floats etc. introduce any more complexity
17:43:18 <kbabbitt> ... just as simple as a flexbox that doesn't have any order properties
17:43:21 <kbabbitt> chrishtr: almost a no-op?
17:43:39 <kbabbitt> fantasai: no because if you set reading order on... eg. I have a section with a heading and a couple of paragraphs
17:43:53 <kbabbitt> ... if I set reading order -1 on the heading it would pull up the heading above the paragraphs
17:43:56 <kizu> kizu has joined #css
17:44:04 <kbabbitt> ... no magic about floats, because that would require a new value for reading-flow
17:44:10 <kbabbitt> ... which would be magic block reordering something
17:44:14 <kbabbitt> ... we're not suggesting that
17:44:25 <kizu> present-
17:44:27 <emilio> q+
17:44:44 <kbabbitt> TabAtkins: it does sound like a potentially doable behavior for block but our opinion is still towards not triggering by defau;t
17:44:56 <kbabbitt> ... our ideal conclusion would be to add a no-op value that just makes something a reading flow container
17:44:59 <astearns> ack JoshT
17:45:01 <kbabbitt> ... and doesn't do anything else special
17:45:06 <kbabbitt> ... define that it works for everything
17:45:21 <kbabbitt> ... not everything because we still want tables to be handleable in a different way
17:45:25 <kbabbitt> ... so define it for blocks and call it a day
17:45:36 <kbabbitt> fantasai: this gets into another issue about initial value of reading-flow
17:45:52 <kbabbitt> ... next issue
17:46:00 <kbabbitt> ... having initial value being smarter than sort order
17:46:08 <kbabbitt> ... adding new value that is strict source order
17:46:17 <kbabbitt> ... with those two, the strict source order could be the value we use here
17:46:26 <astearns> q+
17:46:38 <kbabbitt> emilio: agree with TabAtkins
17:46:56 <kbabbitt> ... did we decide whether reading order affects a11y tree as well?
17:46:57 <kbabbitt> fantasai: yes
17:47:10 <kbabbitt> emilio: I don't know exact order of abspos and floats right now
17:47:15 <kbabbitt> ... but presumably that would get more tricky
17:47:21 <iank_> I think this property only applies to in-flow elements?
17:47:29 <kbabbitt> ... e.g. does the float get ordered... in source order?
17:47:42 <kbabbitt> fantasai: if we apply to blocks, when floats come out of flow that's a visual effect
17:47:46 <kbabbitt> ... does not affect reading order
17:47:50 <kbabbitt> ... would be there as if not floated
17:47:53 <kbabbitt> emilio: ok that seems fine
17:48:06 <kbabbitt> ... I would expect containing block to ? the order
17:48:15 <astearns> ack emilio
17:48:16 <astearns> ack astearns
17:48:19 <kbabbitt> fantasai: in the future maybe we want to do something fancy with floats
17:48:50 <kbabbitt> astearns: in the proposal where reading order works without reading flow, is it the case that if you set reading order on an element that will make the nearest block-level parent a reading flow container?
17:48:52 <kbabbitt> TabAtkins: yes
17:48:53 <kbabbitt> fantasai: yes
17:49:08 <kbabbitt> astearns: very limited utility with markup I'm used to working with where things can get wrapper elements
17:49:19 <kbabbitt> ... caption goes above picture until someone decides caption needs a wrapper element
17:49:23 <kbabbitt> ... then it stops working as intended
17:49:34 <kbabbitt> fantasai: don't think you can introduce a ? that hoists things out of the tree
17:49:42 <kbabbitt> astearns: yes. I think this is an argument for TabAtkins' position
17:49:54 <kbabbitt> fantasai: don't think that would change situation in your case
17:50:01 <kbabbitt> ... if reading order ?? it's still not going to move
17:50:10 <kbabbitt> ... you still have to set it on child that you're trying to reorder
17:50:50 <kbabbitt> ... if reading order is not set on the elements you want to reorder that are siblings
17:50:56 <kbabbitt> ... nothing is going to happen
17:50:58 <astearns> s/on child/on the direct child/
17:51:07 <kbabbitt> ... question is whether or not you need something on the container, not going to make a difference here
17:51:18 <kbabbitt> ... reason TabAtkins wants it is to make sure author is opted into the side effects
17:51:28 <fantasai> s/the side/the tabindex side/
17:51:35 <kbabbitt> TabAtkins: that's the big part, also if we go with your suggestion we could never introduce a more complex behavior
17:51:48 <kbabbitt> ... might be something we never need but I feel like if we explore block cases more we might want to do something like that
17:51:56 <kbabbitt> ... uncomfortable with shutting off that possibility
17:52:03 <kbabbitt> fantasai: if you were going to reshuffle the tree...
17:52:07 <kbabbitt> ... order property doesn't work like that
17:52:23 <kbabbitt> TabAtkins: but order property only works with flex and grid which are explicit about container child relationship
17:52:37 <kbabbitt> ... uncomfortable shutting off possibility of better block reordering strategy
17:52:44 <kbabbitt> fantasai: how would that work? extract element outside container?
17:52:47 <kbabbitt> TabAtkins: don't know
17:52:51 <kbabbitt> ...there's some meat on that bone though
17:53:03 <kbabbitt> ... because as astearns said, it's common to have wrapper elements
17:53:29 <kbabbitt> fantasai: if you introduce wrapper elements the reading order property will be on outermost wrapper
17:53:48 <kbabbitt> ... a number of properties that you want to set on outermost wrapper, reading order is one of them
17:54:11 <kbabbitt> TabAtkins: discussion got mixed with next issue
17:54:21 <kbabbitt> fantasai: swap issues or stay on this one?
17:54:28 <kbabbitt> TabAtkins: we can get some resolutions on this one
17:54:43 <kbabbitt> ... can resolve on a no-op container ? value, a source order value or something
17:54:46 <kbabbitt> fantasai: need that for both issues
17:54:52 <kbabbitt> chrishtr: not to choose a name, say there is a value
17:55:01 <kbabbitt> TabAtkins: happy to resolve on that
17:55:22 <kbabbitt> astearns: Proposed resolution is to add a source order value to reading-flow property
17:55:33 <fantasai> PROPOSED: Add a source-order value to reading-flow.
17:55:44 <kbabbitt> RESOLVED: Add a source-order value to reading-flow.
17:56:12 <kbabbitt> fantasai: Proposed: reading-order applies to block-level elements, does not apply to inline-level elements
17:56:33 <kbabbitt> TabAtkins: such that source-order value points to it?
17:56:38 <kbabbitt> fantasai: that's the third question
17:56:46 <kbabbitt> TabAtkins: not yet whether it applies by default or not
17:57:24 <fantasai> PROPOSAL: reading-order applies to block-level boxes, and not to inline-level boxes. (Note this will work under source-order, and not e.g. flex-*/grid-*)
17:58:23 <TabAtkins> reading-flow:source-order works on block containers. reading-order works on block children of those block containers that are opted in to reading-flow
17:58:51 <fantasai> PROPOSAL: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes
17:59:06 <kbabbitt> astearns: objections?
17:59:09 <fantasai> RESOLVED: reading-flow: source-order works on block containers. reading-order applies to block-level boxes, and not to inline-level boxes
17:59:21 <kbabbitt> astearns: anything more we can resolve on?
17:59:27 <kbabbitt> chrishtr: that it has to be explicit?
17:59:31 <kbabbitt> astearns: that is the sticking point
17:59:39 <kbabbitt> TabAtkins: resolution as it stands says implict stuff doesn't work
17:59:45 <kbabbitt> ... right now only explicit works
17:59:50 <kbabbitt> fantasai: we can take that back to the issue
18:00:06 <kbabbitt> chrishtr: come back to this issue next week for 3rd point
18:00:12 <kbabbitt> topic: end
20:51:32 <projecto-> projecto- has joined #css
20:52:02 <leaverou_> leaverou_ has joined #css
20:53:03 <Rossen-> Rossen- has joined #css
20:53:33 <shans_> shans_ has joined #css
20:54:03 <sylvaing_> sylvaing_ has joined #css
21:36:29 <jfkthame> jfkthame has joined #css
22:05:48 <jensimmons> jensimmons has joined #css
22:33:05 <antonp> antonp has joined #css
23:29:01 <jfkthame> jfkthame has joined #css