15:58:29 <RRSAgent> RRSAgent has joined #css
15:58:29 <RRSAgent> logging to https://www.w3.org/2022/07/13-css-irc
15:58:32 <Zakim> RRSAgent, make logs Public
15:58:33 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:01 <jfkthame> jfkthame has joined #css
15:59:44 <flackr> present+
15:59:50 <bramus> present+
16:00:56 <emilio> present+
16:01:04 <dholbert> dholbert has joined #css
16:01:11 <dholbert> present+
16:01:18 <rachelandrew> present+
16:01:52 <argyle> present+
16:01:59 <smfr> smfr has joined #css
16:02:03 <emilio> Scribenick: emilio
16:02:21 <alisonmaher> alisonmaher has joined #css
16:02:24 <dbaron> Present+
16:02:27 <alisonmaher> present+
16:02:28 <TabAtkins> present+
16:02:42 <plinss> present+
16:02:43 <jfkthame> present+
16:02:48 <bkardell_> bkardell_ has joined #css
16:02:54 <chrishtr> present+
16:03:10 <oriol> oriol has joined #css
16:03:13 <GameMaker> GameMaker has joined #css
16:03:17 <jensimmons> present+
16:03:20 <GameMaker> present+
16:03:28 <oriol> present+
16:03:37 <faceless> present+
16:03:42 <fantasai> present+
16:04:01 <fantasai> Topic: Upcoming Meetings
16:04:12 <chris> chris has joined #css
16:04:16 <fantasai> scribe+
16:04:16 <emilio> topic: [css-2022] Add CSS Color 4 to "Official definition"
16:04:20 <bkardell_> present+
16:04:37 <fantasai> +1 to adding to snapshot
16:04:37 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7455
16:04:41 <TabAtkins> +1
16:04:43 <dandclark> present+
16:05:02 <emilio> RESOLVED: Add Color 4 to snapshot
16:05:12 <chris> great!
16:05:19 <lea> lea has joined #css
16:05:28 <bradk> bradk has joined #css
16:05:30 <emilio> topic: [css-highlight-api] Incubating custom highlight pointer event handling in CSSWG
16:05:34 <lea> present+
16:05:39 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7447
16:06:02 <emilio> dandclark: Highlight API had some progress these last couple years
16:06:06 <bradk> present+
16:06:15 <emilio> ... but no progress to be able to interact w/ highlights
16:06:27 <emilio> ... common use case is spellcheck
16:06:40 <emilio> ... there's no way to interact with highlighted ranges
16:06:56 <emilio> ... so a super useful addition would be to add pointer events to highlighted ranges
16:07:10 <florian> q+
16:07:11 <emilio> ... there's various ways to determine how they'd be routed etc
16:07:29 <emilio> ... but I wanted to check whether this is the right place for this, since this is a bit more DOM-y
16:07:47 <emilio> ... some first steps would be moving some issues from the MSEdgeExplainers repo to CSSWG
16:08:04 <emilio> ... we can do some spec PRs and prototyping
16:08:16 <astearns> ack florian
16:08:31 <emilio> florian: I think the use cases are numerous and compelling, and proposed API looks pretty good at first sight
16:09:00 <tantek> present+
16:09:03 <emilio> ... there are a number of interesting questions: things like dealing with overlapping ranges, and how to dispatch to the DOM in general
16:09:09 <TabAtkins> Agree the use-cases for the feature are good and worth developing. Fine with this group taking on the work; we do DOM-ish stuff sometimes, and it feels reasonable to handle this in the same group as the rest of the CSS feature.
16:09:39 <emilio> florian: the other similar thing that comes up is other pseudo-elements
16:09:51 <emilio> ... is this a missed opportunity to fix that too?
16:10:13 <emilio> ... anyways I think the best thing to do is bringing it in-group
16:10:31 <emilio> astearns: is csswg the only place you have considered bringing in?
16:10:33 <emilio> q+
16:10:54 <emilio> dandclark: for now csswg, but we possibly also want to raise a tag review and other groups like whatwg
16:11:21 <fantasai> emilio: My first question is whether, there's a Selection and Editing API WG, which already has a buch of interop problems to solve
16:11:37 <fantasai> emilio: Other question is, do we really need to dispatch new events on these, or can we re-use the existing machinery?
16:11:44 <fantasai> emilio: [missed]
16:11:50 <fantasai> emilio: I don't know whether StaticRange has it as well
16:11:57 <fantasai> emilio: there are ways to check interaction of pointer events
16:12:10 <fantasai> emilio: It seems to me there's some other areas where this could benefit from, other groups that could also help here
16:12:16 <fantasai> emilio: especially editingWG
16:12:24 <fantasai> emilio: lots of interaction with ShadowDOM and stuff
16:12:25 <hober> present+
16:13:00 <emilio> s/missed/add a convenient way to check whether an event intersects with a highlight
16:13:10 <fantasai> dandclark: [missed]
16:13:19 <fantasai> dandclark: But would think it's good to start here in CSSWG
16:13:33 <fantasai> astearns: Emilio, any objection to starting here?
16:13:36 <fantasai> emilio: no objection
16:13:39 <fantasai> astearns: Any other comments
16:13:52 <gtalbot> gtalbot has joined #css
16:14:01 <fantasai> astearns: I suggest we take this as an incubation in the CSSWG, noting that it's merely an incubation
16:14:16 <emilio> astearns: objections?
16:14:30 <emilio> RESOLVED: Incubate this in CSSWG
16:15:08 <emilio> dandclark: there's a section in the existing draft about this, which is just a missing section
16:15:15 <emilio> ... do we want to put it there?
16:15:21 <vmpstr> vmpstr has joined #css
16:15:29 <emilio> astearns: seems like a reasonable place to start?
16:15:46 <emilio> fantasai: do we want to put it into a L2 spec instead? Seems like highlight API is relatively stable
16:15:52 <emilio> florian: was about to suggest the same
16:15:55 <chris> A level 2 diff spec seems a better way, agreed
16:16:07 <emilio> dandclark: that works for me, might have some follow-up questions about process
16:16:27 <hober> present-
16:16:28 <emilio> astearns: who's the current editor?
16:16:45 <emilio> florian: I'm one of them
16:16:52 <GameMaker> I'm the third editor
16:17:19 <emilio> fantasai: there's 5 open issues on L1, we should consider trying to fix them and move to CR
16:17:30 <emilio> astearns: dandclark, would you want to be an editor of L2?
16:17:33 <emilio> dandclark: sure
16:17:54 <emilio> RESOLVED: Create a highlight L2 spec, dandclark is an editor
16:17:59 <TabAtkins> ol' D&D Clark, as I always read it
16:18:24 <emilio> topic: [selectors-4] Issue 11: Introduce pseudo-class matching when user changed the value of an input
16:18:43 <emilio> github: https://github.com/w3c/csswg-drafts/issues/1533
16:19:10 <fantasai> emilio: I think this would mostly be an alias to a simple :is(:user-valid, :user-invalid)
16:19:22 <fantasai> emilio: but maybe best to have this conversation with Sebastien
16:19:58 <fantasai> fantasai: Comment pointing out a few cases where it's not exactly the same
16:20:03 <emilio> fantasai: It's not exactly what emilio is suggesting, see last comments in the issue
16:20:37 <emilio> bramus: so this is to target inputs, proposed aliases :dirty / :changed / :user-edited
16:20:54 <emilio> ... concept is when a user interacts with the input then it would become dirty
16:21:45 <emilio> fantasai: the other thing to note is that `:user-valid` / `:user-invalid` is that they trigger on submission, but this presumably won't
16:21:58 <tantek> I feel like this has come up in the past but I can't recall what we called it.
16:22:02 <argyle> https://angular.io/guide/form-validation#control-status-css-classes
16:22:12 <emilio> astearns: should we resolve to work on this?
16:22:33 <emilio> bramus: there seems to be a minor difference between :dirty and whether the user touched it
16:22:45 <tantek> q+
16:22:50 <emilio> ... e.g., focusing the input would be touched, changing the value would be dirty
16:22:52 <emilio> q-
16:23:00 <astearns> ack tantek
16:23:06 <emilio> tantek: in general looks like a good area to explore
16:23:09 <fantasai> tantek: This in general sounds like a good area to explore
16:23:23 <emilio> ... I think we have talked about in the past about this but I can't recall where
16:23:39 <emilio> ... one question is what happens with autofill and similar interactions
16:23:52 <argyle> i found these very helpful in the past: https://www.irccloud.com/pastebin/mBDWfxFT/
16:24:04 <emilio> ... does autofilling + clearing it out get special treatment?
16:24:17 <emilio> ... there's a bunch of questions about what other states do we need to design for
16:24:29 <emilio> ... we might want to do some more research on that
16:24:33 <bramus> Good suggestion
16:24:41 <emilio> +1, it seems there's a variety of different use cases that don't quite always match
16:24:42 <flackr> q+
16:24:53 <astearns> ack flackr
16:25:06 <emilio> flackr: I thought the autofilled text isn't exposed till the user interacts with the field
16:25:16 <tantek> I would also advise coordinating this exploration with #openui
16:25:25 <emilio> flackr: which would suggest that naively that before you interact with the page it wouldn't be dirty
16:25:47 <fantasai> emilio: You're right we dont' expose it
16:25:53 <fantasai> emilio: but we do match ?? pseudo-class
16:25:56 <dbaron> some of this may differ between password management autofill and more general autofill, too
16:25:59 <emilio> s/??/:autofill
16:26:18 <tantek> +1 dbaron
16:26:32 <emilio> astearns: I'll raise an issue with openui so that they're aware
16:26:42 <emilio> ... but it seems we have more questions than decissions at this point
16:26:50 <emilio> ... so I wonder if we should take it to the issue again for now
16:26:57 <emilio> ... does that sound ok?
16:27:00 <emilio> [silence]
16:27:16 <emilio> topic: [css-text-decor] Feature request - add a property text-decoration-length that modifies the length of the underline
16:27:31 <emilio> github: https://github.com/w3c/csswg-drafts/issues/4557
16:27:43 <emilio> fantasai: there's been a variety of requests for controlling the length of underlines
16:28:07 <fantasai> https://github.com/w3c/csswg-drafts/issues/4517
16:28:11 <emilio> ... we have some spec text to ensure that underlines break between words
16:28:21 <emilio> ... but we've been asked to provide more control
16:28:35 <emilio> ... suggestion is to define a new `text-decoration-trim` property
16:28:37 <fantasai> https://github.com/w3c/csswg-drafts/issues/4557#issuecomment-1117735704
16:28:41 <emilio> ... which would take a `<length-percentage>`
16:28:49 <emilio> ... and shortens the underline by the given amount
16:29:02 <emilio> ... there's the question of what's the percentage relative to
16:29:08 <emilio> ... so we could start with `<length>`
16:29:21 <emilio> ... on block containers we could apply it to both sides of the block
16:29:35 <emilio> ... on inlines it should follow the behavior of box-decoration-break
16:29:57 <emilio> ... negative values are allowed and would extend the text-decoration
16:30:06 <emilio> ... percentages were suggested to be relative to the containing-block
16:30:18 <emilio> ... there's some effect animating where that'd be useful for
16:30:39 <fantasai> https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property
16:30:48 <emilio> ... if we want to discuss percentages we can do that now but I'd like to add this to the spec and remove `text-decoration-skip-inset`
16:31:28 <emilio> ... as described above wrt inlines / blocks
16:31:40 <emilio> astearns: is text-decoration-skip-inset implemented anywhere?
16:31:43 <emilio> fantasai: I don't think so
16:31:58 <emilio> astearns: is trim the best word when negative lengths can be an extension?
16:32:16 <tantek> just like indent negative means outdent?
16:32:22 <fantasai> yep
16:32:24 <emilio> fantasai: I think so since negative trim is to extend the same way as negative extend is trim, I think use case is mostly trimming
16:33:01 <emilio> florian: the property that would be dropped had an auto value
16:33:07 <emilio> ... should this have the same value?
16:33:21 <emilio> ... if you want the browser to trim by the right amount
16:33:33 <emilio> ... so we'd be losing this but we could reintroduce this if wanted
16:33:36 <emilio> fantasai: yes
16:33:47 <emilio> astearns: fantasai, would this go into your initial write-up? or should we decide later?
16:34:07 <emilio> fantasai: I don't think an auto value is particularly useful if you can specify lengths
16:34:20 <tantek> +1 fantasai, worth documenting an actual use-case of for 'auto', like what problem is it solving?
16:34:35 <fantasai> it's solving the problem documented in https://www.w3.org/TR/css-text-decor-4/#text-decoration-skip-inset-property
16:35:01 <emilio> florian: in CJK when you have a piece of content and they might be next to each other, and without skipping you might not notice that they're different words
16:35:12 <emilio> ... you might want to say "browser, just do something"
16:35:15 <faceless> Easy enough to define "auto" as "the width of the underline" perhaps?
16:35:32 <emilio> ... you could do "3px" or something, but then why that?
16:35:43 <emilio> fantasai: I think the width of the underline was my initial thought
16:36:06 <emilio> ... though might not be useful if the underline is very big? So might be more like `min(0.1em, underline-width)` or something
16:36:14 <emilio> florian: do we want browser guidance here?
16:36:33 <emilio> fantasai: I think we want to do that so people know what to implement
16:36:42 <emilio> florian: [missed]
16:37:09 <emilio> fantasai: one of the problems we have with percents is that we have percentages for word-spacing etc to reference the font-size of the element? Maybe we can do that
16:37:14 <astearns> s/[missed]/I have wanted this without having an opinion on a specific value/
16:37:24 <florian> s/[missed]/As one data point, I have authored CJK content where I've wanted this, without having a view as to how big it should be./
16:37:38 <emilio> fantasai: happy to start with `<length>` / `<length>|auto` / then add percentages
16:37:46 <emilio> ... probably worth starting with length and add things afterwards
16:38:17 <emilio> plinss: question, removing lengths from the end of the decoration, or also from the skipping between descenders and so
16:38:23 <emilio> fantasai: just end
16:38:47 <emilio> astearns: we discussed that and run into implementation difficulties
16:38:58 <emilio> plinss: ok, just wanted clarification, would be weird if it trimmed from both
16:39:08 <florian> s/do we want browser guidance here?/can we leave it as browser defined, or do browsers want guidance here?/
16:39:23 <jensimmons> `text-decoration-trim: <length>` for the resolution
16:39:33 <emilio> jfkthame: one thing I wondered is whether we want two values, one for start, one for end
16:39:42 <emilio> fantasai: makes sense
16:39:54 <emilio> jensimmons: separate for start/end could be declared all at once
16:40:07 <tantek> q+ to ask about interactions with text-overflow
16:40:09 <emilio> ... could see authors creating some kind of drop-shadow-like effects
16:40:16 <fantasai> -> illustration https://github.com/w3c/csswg-drafts/issues/4517
16:40:21 <emilio> ... specially when combined with underline offset/thickness
16:40:40 <dbaron> maybe also when combined with italic/oblique
16:40:43 <emilio> ... there's the question of what happens with inline-box breaking
16:41:04 <emilio> astearns: that's the part where it'd follow box-decoration-break
16:41:10 <astearns> ack tantek
16:41:10 <Zakim> tantek, you wanted to ask about interactions with text-overflow
16:41:31 <emilio> tantek: just wanted to add with potential interactions with text-overflow: ellipsis
16:42:05 <emilio> ... do you want this always, only when there's no text overflow, do you want to trim from the ellipsis start...?
16:42:18 <emilio> fantasai: can't even remember whether the ellipsis gets underlined or not atm
16:43:04 <emilio> astearns: if you're not using trimming at all, it seems this is a higher level question, you should get control for whether the underline applies to the end overflow
16:43:31 <emilio> plinss: my intuition would be that the end would be that the end would be where it'd be without text overflow
16:43:49 <emilio> fantasai: [missed], something about box-decoration-break
16:44:01 <emilio> plinss: I like separate start/end, provides more interesting animation possibilities
16:44:09 <fantasai> box-decoration-break defaults to slice, which would get the behavior plinss describes
16:45:49 <emilio> RESOLVED: Remove text-decoration-skip-inset, add `text-decoration-trim: <length> <length>?`, follow-up for improvements and issues
16:46:16 <emilio> florian: could I ask people familiar with in-design and similar software if they have auto values and how it works if so?
16:46:18 <emilio> astearns: don't recall
16:46:44 <emilio> astearns: will ask about in-design underlines
16:47:01 <emilio> fantasai: should I add the definitions with auto / percentages in the first draft?
16:47:07 <emilio> astearns: I think it'd be good to add at least a note
16:47:36 <emilio> florian: either that or put the value in with an issue on how to define it
16:48:01 <emilio> fantasai: if people are fine with me adding it in I'd just do that since it makes it easier to discuss
16:48:14 <emilio> topic: [css-ui] revert-layer rolling back to author origin should disable native appearance
16:48:23 <emilio> github: https://github.com/w3c/csswg-drafts/issues/7239
16:48:57 <emilio> oriol: there are some properties than when set on autor/animation origin disable native appearance unless `revert` / `revert-layer` is specified
16:49:02 <emilio> ... for revert it makes sense
16:49:10 <emilio> ... since it always reverts to user/ua origin
16:49:20 <emilio> ... but revert-layer can revert to author origin
16:49:26 <florian> q+
16:49:29 <emilio> ... and in this case it should disable native appearance
16:49:35 <emilio> ... all implementations already behave like this
16:49:44 <emilio> ... so proposal is to align with implementations
16:49:44 <astearns> ack florian
16:50:01 <emilio> florian: I think it's over-correction, original spec forgot revert-layer but forgot taking this into account
16:50:22 <emilio> ... if you have multiple revert-layers, how does this behave? Is it feasible to check all of them?
16:50:41 <emilio> oriol: I didn't test this more complex case
16:51:10 <emilio> florian: could we spec that however many layers you revert you account for that, and revisit if it's problematic?
16:51:11 <emilio> q+
16:51:17 <astearns> ack emilio
16:51:26 <fantasai> emilio: I just wanted to say, you do need to revert all the layers
16:51:31 <fantasai> emilio: you need to get to the original value
16:51:41 <fantasai> emilio: so I think it makes sense to spec this, it's the sensible thing to do
16:51:47 <emilio> so, +1
16:52:53 <emilio> RESOLVED: For properties that disable native appearance, do all the reverting, take into account the origin of the final cascaded value
16:53:38 <fantasai> Topic: [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?
16:53:44 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7213
16:54:04 <fantasai> emilio: I did check with the security folks at MOzilla, and they weren't concerned about making this apply even more generally to iframes
16:54:26 <fantasai> emilio: Only attack is if a page is in an iframe and a top-level frame, can determine ???
16:54:31 <fantasai> emilio: But no problem for SVG images
16:54:37 <fantasai> emilio: I think it'd be nice to do it for iframes as well
16:54:48 <fantasai> emilio: My discussion with them was that it's not a big concern, idk if other folks have an opinion
16:55:03 <fantasai> smfr: On the WebKit side would be much more reluctant to do on iframes, but OK for SVG images
16:55:17 <fantasai> smfr: Was having trouble finding text in HTML spec that SVG couldn't run script or load external images
16:55:28 <fantasai> smfr: so part of this issue needs to clarify when SVG can load external resources or run script
16:55:38 <chris> q+
16:55:40 <fantasai> emilio: Why reluctant to make it work on iframes?
16:55:47 <fantasai> emilio: We already communicate info about backgrounds
16:55:56 <fantasai> smfr: I'd have to go back and ask the security ppl
16:55:58 <CSSWG_LogBot> CSSWG_LogBot has joined #css
16:56:07 <astearns> ack chris
16:56:10 <fantasai> chris: SVG images in <img> tag don't run scripts or fetch resources
16:56:11 <dholbert> smfr: RE where it's defined that SVG Images don't run scripts, that's defined in https://svgwg.org/specs/integration/
16:56:18 <fantasai> chris: if they are in <object> they can fetch and run script
16:56:33 <fantasai> chris: It's not a function of SVG, but function of SVG's integration in external environment and what it allows them to do
16:56:36 <dholbert> see https://svgwg.org/specs/integration/#secure-animated-mode
16:56:38 <fantasai> astearns: When in <object> ...
16:56:41 <dholbert> "Secure animated mode"
16:56:41 <fantasai> chris: They can do everything
16:56:46 <fantasai> astearns: Are they SVG images?
16:56:51 <fantasai> chris: Yes, just not using an <img> tags
16:56:53 <smfr> dholbert: but HTML doesn’t reference that everywhere it needs to
16:56:59 <fantasai> emilio: From implementation point of view, they are iframes
16:57:06 <TabAtkins> (as far as I recall) Chrome is fine with passing into any SVG that can't fetch or run script (aka <img> tags), and same-origin iframes.
16:57:07 <fantasai> chris: Also if displayed standalone, same thing
16:57:14 <fantasai> chris: they can run scripts, fetch resources, etc.
16:57:19 <TabAtkins> We just don't want to open up new cross-origin communication bits.
16:57:32 <fantasai> emilio: Seems there would be no objection to doing on SVG images
16:57:37 <fantasai> emilio: and maybe file an issue about iframes
16:57:44 <fantasai> smfr: Sounds good
16:58:10 <astearns> ack TabAtkins
16:58:27 <fantasai> TabAtkins: from what I recall, Chrome is fine with this so long as it doesn't open up new cross-origin communication bits
16:58:35 <fantasai> TabAtkins: So SVG as img should be fine
16:58:40 <fantasai> TabAtkins: and same-origin iframe should be fine
16:58:44 <fantasai> smfr: That matches WebKit's preference, too
16:58:54 <fantasai> emilio: OK, then we can discuss iframes separately
16:59:05 <fantasai> emilio: I'm more interested in this SVG case
16:59:12 <fantasai> emilio: It's not easy for the iframe to tell where the preference comes from
16:59:16 <fantasai> emilio: we can discuss another time
16:59:18 <astearns> ack fantasai
16:59:18 <Zakim> fantasai, you wanted to propose resolution
16:59:44 <fantasai> fantasai: Seems we have consensus on SVG as <img> and also same-origin iframe
17:00:02 <fantasai> ???: what about SVG's that are rendered through CSS?
17:00:13 <fantasai> fantasai: There's an embedding mode for SVG that does this, so anything in that embedding mode
17:00:31 <fantasai> astearns: Maybe let's take a resolution on SVG first
17:00:43 <fantasai> emilio: draw background in iframes, that doesn't care about same vs cross-origin, so unsure how to do that
17:00:56 <fantasai> astearns: proposed that prefers-color-scheme in SVG-images is context-dependent
17:01:18 <fantasai> smfr: "SVG rendered in secure animated mode"
17:01:28 <smfr> https://svgwg.org/specs/integration/#secure-animated-mode
17:01:34 <fantasai> astearns: objections?
17:01:52 <fantasai> RESOLVED: prefers-color-scheme in SVG rendered in secure animated mode is context-dependent
17:01:58 <fantasai> Meeting closed.
17:02:08 <astearns> zakim, end meeting
17:02:08 <Zakim> As of this point the attendees have been flackr, bramus, emilio, dholbert, rachelandrew, argyle, dbaron, alisonmaher, TabAtkins, plinss, jfkthame, chrishtr, jensimmons, GameMaker,
17:02:12 <Zakim> ... oriol, faceless, fantasai, bkardell_, dandclark, lea, bradk, tantek, hober
17:02:12 <Zakim> RRSAgent, please draft minutes v2
17:02:12 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/13-css-minutes.html Zakim
17:02:14 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:02:19 <Zakim> Zakim has left #css
17:02:20 <fantasai> Topic: Meeting Registration (missed, goes first in the minutes)
17:02:35 <fantasai> astearns: If you think you might come to the F2F, please register into the wiki
17:02:41 <fantasai> https://wiki.csswg.org/planning/nyc-2022
17:03:10 <fantasai> astearns: Also, TPAC 2022 registration just opened. There is registration both for in-person and remote attendance, so please register appropriately
17:03:25 <fantasai> [note there's a cut-off date for early registration pricing]
17:03:32 <fantasai> https://www.w3.org/2022/09/TPAC/
17:03:37 <RRSAgent> I have made the request to generate https://www.w3.org/2022/07/13-css-minutes.html fantasai
17:04:48 <gtalbot> gtalbot has left #css
17:06:54 <Linux_Kerio> Linux_Kerio has joined #css
18:05:41 <bradk> bradk has joined #css