15:55:06 RRSAgent has joined #css 15:55:06 logging to http://www.w3.org/2015/04/15-css-irc 15:55:08 RRSAgent, make logs member 15:55:08 Zakim has joined #css 15:55:10 Zakim, this will be Style_CSS FP 15:55:10 I do not see a conference matching that name scheduled within the next hour, trackbot 15:55:11 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:55:11 Date: 15 April 2015 15:55:20 Zakim, this will be style 15:55:20 I do not see a conference matching that name scheduled within the next hour, dbaron 15:55:28 RRSAgent, make logs public 15:55:38 Zakim, this will be CSS 15:55:38 I do not see a conference matching that name scheduled within the next hour, dbaron 15:56:51 alex_antennahouse has joined #css 15:57:19 ScribeNick: dael 15:58:00 sanja has joined #css 15:58:45 Zakim, this will be Style 15:58:45 I do not see a conference matching that name scheduled within the next hour, Florian 15:59:02 murakami has joined #css 15:59:30 Zakim, bye 15:59:30 Zakim has left #css 15:59:32 Zakim has joined #css 15:59:37 Zakim, this is style 15:59:37 sorry, dbaron, I do not see a conference named 'style' in progress or scheduled at this time 15:59:45 Zakim, this will be style 15:59:45 I do not see a conference matching that name scheduled within the next hour, dbaron 16:00:01 I can't connect 16:00:03 obviously 16:00:14 adenilson has joined #css 16:00:28 bcampbell has joined #css 16:00:42 [the bridge is having trouble; the code should work for dial-in but zakim bot is not available] 16:00:42 I can dial in just fine 16:01:01 I can dial in just fine, but Zakim won't announce me (or anyone it seems) 16:01:08 interesting, I'll try again 16:01:10 Florian, right 16:01:12 Florian, well, it won't associate the call with the IRC channel 16:01:20 the bot is not functioning 16:01:22 andrey-bloomberg has joined #css 16:01:43 it has been taken over by an alien life form and is no longer responding to human control. 16:02:20 plinss, can we have everyone that's here type it into IRC so I can get some kind of attendance? I always rely on Zakim. 16:02:28 sure 16:02:39 +1 16:02:41 tantek has joined #css 16:02:46 Thank you! 16:02:49 smfr has joined #css 16:03:32 +dbaron 16:03:41 Zakim not working? 16:03:59 +smfr 16:03:59 Zakim the IRC bot is not working; the phone bridge is working, though. 16:04:01 no, zakim is out to lunch 16:04:17 well, it is lunchtime in zakim's timezone 16:04:25 +Florian 16:05:14 +tantek 16:05:20 plinss: Let's start. 16:05:22 FWIW, I have some somewhat noisy construction (dissassembly of scaffolding) outside my window; I'll try to be muted when I'm not talking 16:05:28 adenilson: +adenilson. 16:05:33 here 16:05:34 here 16:05:36 present 16:05:37 here 16:05:42 is here 16:05:42 present 16:05:42 on phone 16:05:44 vollick has joined #css 16:05:45 presents! 16:05:47 +hober 16:05:48 plinss: Since Zaki isn't keeping track, if everyone could type into IRC something, present, or so that we can get attendance. 16:05:52 present 16:05:54 Tav: I'm not on IRC, but on the phone. 16:05:58 plinss: Anything to add? 16:06:05 Rossen: I have one about next CSS F2F. 16:06:09 plinss: Let's do that. 16:06:25 s/CSS/CSS houdini/ 16:06:43 Rossen: So there's a mail thread about org. before or after the Paris F2F for Houdini. This is something we agreed on for the Feb F2F 16:06:50 http://lists.w3.org/Archives/Public/public-houdini/2015Apr/0018.html 16:06:57 SteveZ_ has joined #css 16:07:06 bradk has joined #css 16:07:27 Rossen: This is an FYI if you can go and do your +1 or don't care. If we have critical mass we'll try and get together. Most like after the F2F in Paris which is currently Tues-Thurs 25-27 Aug. So most likely we'll spill into Fri and Sat. That's an FYI 16:07:41 Rossen: We'll do details on the ML and hopefully MOzilla can host us for a day or two. 16:07:51 I am present 16:07:53 Topic: Profile Bikeshed 16:07:54 +0 for after. (0 only because I'm not critical for this) 16:07:54 ChrisL has joined #css 16:08:08 +1 16:08:11 TabAtkins: Everyone seems fine with dynamic and static and I'm happy with the rename. 16:08:20 +1 to static/dynamic 16:08:24 plinss: proposal is to rename fast and slow to static and dynamic. Any problems with that? 16:08:33 ??: That sounds like an improvement. 16:08:45 RESOLVED: Rename to static and dynamic 16:09:03 s/??/tantek/ 16:09:04 plinss: We heard from MS that they're still working on item two. 16:09:05 s/Profile Bikeshed/Selectors Profile Bikeshed/ 16:09:28 Florian: A quick note, I sent a pull request to change what we've already agreed to. It would be nice to hear back. 16:09:32 tantek: Okay, thank you. 16:09:38 Rossen: Once we have news we'll discuss. 16:09:46 Topic: Selector4 matching algo 16:09:59 https://lists.w3.org/Archives/Public/www-style/2015Mar/0432.html 16:10:17 zakim, who is here? 16:10:17 sorry, ChrisL, I don't know what conference this is 16:10:19 On IRC I see ChrisL, bradk, SteveZ_, vollick, smfr, tantek, andrey-bloomberg, bcampbell, adenilson, Zakim, murakami, sanja, alex_antennahouse, RRSAgent, antenna, dael, 16:10:19 ... gregwhitworth, tgraham, estellevw, plh, dbaron, Ms2ger, jdaggett, Florian, paul___irish, lajava, svillar, logbot, hgl, hober, trackbot, shepazu, Bert, rego, fantasai, 16:10:23 ... achicu_____, plinss, krijnhoetmer, decadance, timeless, robertknight_clo, iank, ojan, cabanier, shane, ppk___, gsnedders, astearns, birtles, mvujovic______, JonathanNeal_, 16:10:23 ... dstockwell, dwim, dholbert 16:10:24 zakim, this is css 16:10:25 sorry, ChrisL, I do not see a conference named 'css' in progress or scheduled at this time 16:10:47 I don't even understand why we have this algorithm in the spec 16:10:48 RELEASE THE KRAKEN 16:10:54 dbaron: So, selectors, there's new prose in selectors 4 that tries to define a matching algo. I wasn't that happy because it essentially defines in left to right matching which isn't how selectors are impl. There might be things easy one way and hard the other in both directions, so I think it's better to have the spec match the impl. There's also risk of introducing subtile mistakes. 16:11:10 dbaron: If there's an algo, and I think why TabAtkins wrote it is to make it clearer how it works... 16:11:17 TabAtkins: That was the inspiration 16:12:38 TabAtkins: It was written to clear up and tighten up prose around matching when I was writting scope. As soon as you have tree crossing you have to do something interesting witht he selector. The reason why left to right is that's seems to match better what authors thought. Also it makes the tree crossing easier b/c the left edge is what matches. The right edge might be a different tree. It seemed to be written left to right 16:13:32 TabAtkins: but once we tree cross it gets a lot more complex. I can chop it up or I can write it more universally and have a check at the end, but those don't match impl. I think impl, ours finds a lowere tree and moves it in and then does a tree trick at the end. I don't know if that's the right way. 16:13:46 TabAtkins: I would appriciate guidance about what is reasonable, that was just simplist. 16:14:05 fantasai: I think if you eval a selector against a single element in a tree because that's kinda the way the rest of the spec talks about selectors. 16:14:37 TabAtkins: That's the problem, though. Which element. You have a selector in some high context matching a nested context. If you're going left to right you have to match against the right side that's in a higher context. 16:14:53 dbaron: I don't understand what the tree crossing thing is given the difference you desc. 16:14:58 TabAtkins: What I'm referring to? 16:15:14 dbaron: No, the behavior you're trying to define. I don't know how productive this will be on the telecon. 16:15:35 TabAtkins: I responded on the thread, so we can hash out there. I said it in an e-mail and there wasn't a responce, but we can continue there. 16:15:39 plinss: So back to e-mail 16:15:48 Topic: copying text-transform'd test 16:15:51 s/test/text 16:16:30 fantasai: We have mostly interop on not copying the transformation. There's some stylistic changes where it doesn't make sense to keep if you copy plain text. So I was going to clarify that in the spec text. 16:16:35 I think most authors will consider that a bug. 16:16:40 fantasai: The one that doesn't do this is Safari Chrome. 16:16:44 certainly users 16:17:07 Florian: I generally agree what we should copy/paste is the original, but we might want to be careful saying if you copy in rich text you should preserve. 16:17:29 fantasai: Do you preserve as a style by changing the character codes, or is it if it happenes to be a CSS style you keep it. 16:18:08 Florian: I'm agreeing with plain text, but I think that if the rich text you're pasting into can preserve it we should, but if it can't you don't. I don't think we can define how rich text works so say there you can do it if you can, but plain text don't do it. 16:18:22 fantasai: I think that the data store, whatever is the org format it shoulds tay in that. 16:18:35 dbaron: I think users will tend to consider not copying what you see as a bug. 16:18:37 Rossen: I agree. 16:18:56 fantasai: If authors intend those things to be cap letters or whatever it should be in the data store. 16:19:31 fantasai: If I have something that I want to have as a heading and have text-transforms to do fancy things, copying it out should give you the same thing as was there originally. 16:19:49 BradK: Has anyone done user testing? 16:19:55 Copying out a heading with text-transform vs. heading with small-caps should give the same result 16:20:05 s/BradK/Tantek/ 16:20:23 Florian: I think this also depends on what text-transform you're using. We have a tranform for Ruby where if you don't preserve it you get the wrong chracter. 16:20:47 plinss: I think we have a few cases where it makes sense to preserve org text on the DOM and a few cases where it makes sense to preserve the transformed style. 16:21:02 Florian: And as fantasai said if they want something to stay, they should put it in the DOM 16:21:22 plinss: So say the text must be available in plain formatting but they may preserve for rich text. 16:21:47 agree that copy/paste is wildly underspecified 16:21:55 tantek: And this is one case of a broader set of problems. If you copy a list do you get the bullets and if you do do you get whatever characters are specified. 16:22:43 fantasai: This is a formatting thing, not generated content. We should be able to get both results. If we make this behave as if you change the DOM you can't get both behaviors. The second things is it's a decision between small caps and all caps, it should be a stylistic choice, not to worry if it will copy/paste 16:22:53 tantek: I don't htink authors worry about if it will copy/paste. 16:23:07 fantasai: I don't think they'll think about it, but it shouldn't have an unexpected side effect. 16:23:15 Florian: I think either could be considered unexpected. 16:23:24 tantek: It's b/c we don't have a copy/paste spec. 16:24:05 Florian: I agree with you, but that generated content is different then the DOM and if you take her suggestion authors can get the behavior, that seems to mean we're getting an answer. I think it is a problem not to have the spec, but we should try to solve this case if we have a solution 16:24:33 tantek: As we solve these individual cases and we're dealing with tradeoffs here, I think we should use should wording rather than must. That's my suggestion for this general area. 16:24:53 ??: Another thing that comes to mind to me is selection, coying and editing move together code-wise. 16:25:18 s/??/hober 16:25:28 hober: The people that hack on webkit are the people to talk to about this and aren't typically on CSS meetings. Maybe we should talk to the editing task force to see if they would chime in 16:25:36 tantek: That's an excellent idea. 16:25:45 fantasai: If someone would give me the email I can do that. 16:25:56 tantek: Would someone be willing to start a copy/paste taskforce? 16:26:06 plinss: I don't think we need a taskforce, but poss a spec. 16:26:12 tantek: No, not a taskforce, a spec. 16:26:39 plinss: Let's ping the editing task force and maybe we need us a spec that defines this based on what we hear back. Does anyone have contact info. 16:26:45 Florian: It should be on the editing spec. 16:26:57 hober: Which WG is it part of? 16:27:02 tantek: webapps 16:27:10 s/hober/tantek 16:27:12 My general position is that copy/paste of plaintext shouldn't be affected by any CSS formatting except 'display' and 'content'. 16:27:13 s/tantek/hober 16:27:14 action fantasai to ping the editing taskforce 16:27:14 Created ACTION-680 - Ping the editing taskforce [on Elika Etemad - due 2015-04-22]. 16:27:26 Topic: user-select 16:27:31 aside: e.g. in CSS3-UI text-overflow we say *should* http://dev.w3.org/csswg/css-ui-3/#text-overflow 16:27:36 "Selecting the ellipsis should select the ellipsed text." 16:27:52 Florian: This was intoduced in the precursor to CSS UI. It was dropped and it wasn't speced, but browsers impl differently and people use it. 16:28:06 tantek, yeah but that's a "what is selected when I click here" question, not a "what is the content when I paste it out". 16:28:21 Florian: I put together a draft spec, I'm not trying to invent a new value, but trying to get some conversion and have them do reasonable things when they agree and converge where they don't. 16:28:23 fantasai - sure, hence aside. 16:28:26 tantek, Would you consider the implementation correc tif it copied out the ellipsis itself? 16:28:35 tantek, that's the level of questioning here 16:28:37 no, because I believe the "should" 16:28:43 Florian: There is a spec, I'd like feedback, this doesn't match any particular impl, but it is based on the current impl. 16:28:59 Florian: There's nothing particular for the call, but I'm asking for review, unless someone has feedback now. 16:29:32 tantek: When I initially wrote user-select, the goal was to capture a bunch of the UI behaviors that native HTML provides and to be able to create a basis to create things like checkbox. 16:33:23 prefer to see that in css ui 4, to not slow down 3 16:33:25 User select is about style when you create a purely decorative pseudo element that shouldn't be interfering with what can be clicked. 16:34:29 bradk, it doesn't control pointer events, just selection 16:37:54 You're right. I was thinking off pointer events 16:38:37 bradk has joined #css 16:38:47 dael has joined #css 16:39:04 q+ 16:39:45 Florian: A side use case is that while it's true that not all values are useful, some of them are. So, rather than trying to have a list of every thing, I have an auto value that makes the control look like what's it looks like. And for now just one value letting you get the bottom. 16:40:07 Florian: We can expand the list, but I think we shouldn't try to get everything. WE need to limit to what authors want and what we can define. 16:40:11 ack Rossen 16:40:19 q+ to comment about 'auto' value 16:40:42 Rossen: I wanted to ask you, having dealt with appearence lately, the main thing we see on the web is speaking to why this came about. We have a closed and not perfect controls model in all native controls. 16:41:53 Rossen: The way people could tap into the controls and try to restyle a button or something. I don't now if you're prop to tone it down or to take it to the next step which is formaize it further. If we're deigning a controls model, there's enough from a component model, we should try to align with those in the future. 16:42:03 Florian: Should I reply, or let dbaron go? 16:42:51 Florian: My intent is not to try and provide everything that could be used to style anything. There are quite a few values on the webkit side that corrispond to pseudo elements where the appearence isn't standard but people might try and get the search icon to appear in places where you can't search. 16:43:51 Florian: IN general I'm trying to tone down the property. However, there are a handful of values for simple control, but are very useful to have. Bottom is a good expamle of that. I don't think we hould try and add form control or complex control where you want to get the behavior. The way I've spec'ed it, you don't change the behavior 16:44:22 florian++ 16:44:28 q+ to say we shouldn't even do 'button' 16:44:33 Florian: It doesn't have the pseudo classes. As soon as you get to complex controls, that is a different story. For that if you're using web comonents or something else. I'm trying to make this exclusively about appearance. 16:44:36 ack dbaron 16:44:36 dbaron, you wanted to comment about 'auto' value 16:44:55 dbaron: I'm not a big fan of auto being a complex list of things you expect UAs to impl, especially when those can be a list of CSS values. 16:45:06 http://dev.w3.org/csswg/css-ui-4/#appearance-switching 16:45:16 appearance: auto | none | button 16:45:23 Florian: I think they cannot be. The actualy long list is different. There are a few base values, but most are not the same and will only be useful in a UA style sheet. 16:45:47 I think 'appearance' should be relegated to a UA-only property. Not for authors nor users. 16:45:48 dbaron: I guess I need to look at the conformance requirements for auto closely. I'm concerened about doing a lot of work that doesn't address use cases. 16:45:52 auto UAs may render form controls using native controls of the host operating system or with a look and feel not otherwise expressible in CSS. 16:45:57 16:46:04 Florian: That wasn't the intent. It was do the right think based on what the host language says. 16:46:17 tantek: You use auto because you need to be able to override none. 16:46:23 s/tantek/hober 16:46:47 dbaron: One other point about things like buttons, appearence imples state changes in resolnce to things like hover. If you say appearence button you get different styles. 16:47:20 q? 16:47:27 Florian: I think that's okay. But if you have something like a checkbox and apply it to a div, the div shouldn't be able to be checked. Active and hover it's fine if they propigate, but things don't aquire new states if you style them with a different appearance. 16:47:44 ack tantek 16:47:44 tantek, you wanted to say we shouldn't even do 'button' 16:48:20 tantek: Given the expereince with appearance, the same comment about user-select doesn't apply. The effects we were trying to do are complex enough that there wasn't a simple declarative solution. I don't think this prop at this point should be rec for authors. I know there is some legacy that in worth investigating. 16:48:30 Toggling is useful. 16:49:06 tantek: I don't think we should put button. I don't think we should have something there that you can use this for. I think they're complex enough where if someone wants to turn a div or even a link into a button, I don't think a single declaritive prop is the way to do it. WE should guide people to web componenets. 16:49:22 tantek: This is a legacy prop. Yes there's some usage on the web, but we shouldn't direct authors there. 16:50:20 Florian: I think auto vs none isn't a legacy problem. I think it's reasonable that your markup would use HTML form elements and youd on't want them to look like form. As for button and similar values, I'm a bit more on the fence. I don't want the whole list like the earlier. I think if it's possible to have a sensible model, I think it's poss to work out. 16:50:29 tantek: I used to believe that, but not any more based on experience. 16:50:52 fantasai: I think you're going to have to run some searches for webcompat becuase there are values out there. We may need to put something in and depricate it. 16:51:10 Florian: That's quite poss. MS has impl -webkit-appearance in IE and it supports button. 16:51:26 plinss: I think tantek point is valid. Maybe we need to put it in and depicate. 16:51:36 Florian: We can define and recommend away. 16:52:24 Rossen: If you define it you encourage use of this. And I'm siding with tantek where we should move away from this and give ways to better construct web components that would allow people to do what they do. Talking from impl experience, very resently, I'm not a huge fan of the appearance stuff. 16:52:31 Rossen: We can con't on the ML 16:53:02 Florian: As to the web component point, I think it's a much better answer to complex controls, but I don't see how it would make it look like a native button. 16:53:17 Rossen: Use a button if you want a button 16:53:29 dbaron: What you do with web comp is you put a button in the componenet. 16:53:41 Florian: If what you has has the semantic of the link, why not use a link? 16:54:22 Florian: I strongly think auto and none are nec. I can see the concerns about other values and hear that we might want to remove button. If people would read mye xact lang I'd appriciate it. 16:54:39 plinss: I don't hear obj to auto and none so let's move forward with that. We need reserach on button. 16:54:50 Florian: I understand the concern. Please read the spec. 16:55:17 fantasai: Let's resolve on having auto and none and poss adding a few other values and someone should take an action to do web compat research b/c we might not have a choice. 16:55:30 RESOLVED: Accept auto and none, do research on the rest 16:55:48 Florian: It would be interesting to hear from MS since they've impl witht he webkit prefix. 16:55:55 Rossen: I think I gave you our feedback. 16:56:20 Florian: In terms of if it's poss. I heard as to if you think it's a good idea, but I'm not sure if I heard if it breaks the web to have the button value. 16:56:27 Rossen: Anything impl is done so the web works. 16:56:37 Florian: And you have impl more values then there is in the spec. 16:56:46 plinss: So who will take an action to do th research. 16:56:53 s/th/the 16:57:15 Florian: I don't have the resources to do the type of research. I cannot go further than what I've done. 16:57:22 :) 16:57:25 plinss: Anyone else willing to take the research. 16:57:48 tantek: Why don't we leave it out pending someone coming forward with the research. Then we leave it open for someone to say we need it. 16:58:00 fantasai: Then we should have the impl say they'll drop it. 16:58:04 Rossen: I'd be happy with that. 16:58:32 Florian: I put button in there so that I designed the prop to see if we needed it we had a way to do it. I would like people to review my sepc language. 16:58:41 plinss: I think the way you did it is reasonable. 16:59:26 Rossen: Is your expectation with this that we'll impl a non-prefix appearance prop? The only reason we added it so the web can work. I don't see what you're gaining. I'd be surprised if I saw other impl rush to impl. 16:59:51 dbaron: I think if we're not going to impl it we have to impl the webkit prefix. I think it's better to do none and auto. 16:59:52 dbaron +1 - only un-prefixed just none and auto 17:00:01 dbaron: If we can get people into a not prefixed it would be better. 17:00:05 Rossen: I agree with that. 17:00:19 +1 to dbaron 17:00:29 even one other value 'button' implies a direction we do not want to take 17:00:33 Florian: I want to make none work and have other values we're comfortable with. None means we need auto. I have button to make sure it worked. 17:00:43 even if that means dropping the mechanism for other values 17:01:05 plinss: We have resolution for auto and none. We don't have anyone to do research that we need the rest, so I agree with tantek to leave them out until someone says we need them. 17:01:06 Call dropped. My position is that if values are necessary for Web compat, then they should be in the spec for the unprefixed property 17:01:28 They can be deprecated, but they should be there. 17:01:33 Florian: I'm okay with taking out button, but I think that people should review how I wrote button because I don't want to lose it and find we need it. 17:01:44 I'm unwilling to drop 'button' from the spec at the moment 17:01:55 I would agree to do it if all the browsers came and said they would drop support 17:01:58 dbaron: Can you take the button text and make it a note as to we might need to add other things and here's an ex of how we'd do it. 17:02:09 Florian: There's some spec text assuming you have three values. 17:02:46 plinss: In general I like your approach and agree if there's more prop this is how they should behave and maybe that can turn into a this prop doesn't effect XYZ and I think you're on the right track. 17:03:08 Florian: I can certainly look into seeing if I can cleanly turn it into a note, but I'd rather not drop entirely. 17:03:23 plinss: Put a big issue in it for now and we have a path to move forward. 17:03:38 +1 to leaving in spec, adding issue 17:03:47 plinss: What brings us past the end of the hour. Thank you everyone and I'll see you next week except I won't be here, I'm at a TAG F2F. 17:04:06 +1 to moving everything 'button' related to an informative note section (including mechanism for it) as a transition to dropping it 17:06:24 Tantek, fantasai: I'll put in a issue now, and look into whether I can separate things more cleanly so that we can turn the related prose into a note or possibly drop it, without causing forward compat problems. 17:07:00 tommyjtl has joined #css 17:08:26 I have clearly heard everyone's feedback that button is not warmly welcome, but I would still appreciate feedback to the question "If research shows we have to have it, would this be a reasonable way to spec how it should work?". 17:09:31 jcraig has joined #css 17:10:25 Florian - I don't think people want to bother with that level of conditional analysis - that's the problem. 17:10:35 would rather just punt on it until someone brings it up later 17:11:17 smfr has left #css 17:14:55 tantek: I don't want to spec a property that cannot be sanely extended in a way we may later find necessary. My research shows that there is demand and usage of this value, and I wanted to make sure we could have it if we had to. The only way I know how to do that is by adding it and seeing if the spec makes sense. To me, it does. 17:15:21 The other way is to punt on it and worry about extending it later. 17:15:25 We do that in CSS all the time 17:15:33 CSS is fundamentally designed to "extend it later" 17:15:46 tommyjtl has joined #css 17:15:48 no need to pre-worry about "sanely extended later" 17:20:15 adenilson has joined #css 17:22:59 Anyway. Issue about button added. Designing it in has helped me understand how this should work, so this was not wasted time for me. The bits of the final prose that are tied to button are quite limited, so the surgery shouldn't be that hard if we want to remove it, but I think the design is better for having considered it. 17:23:15 (added = committed. Will push in 1 minute) 17:27:57 (pushed) 17:37:48 Florian has joined #css 17:47:54 myles has joined #css 17:51:49 adenilson has joined #css 17:58:46 jcraig has left #css 18:11:48 zcorpan has joined #css 18:50:32 dael has joined #css 18:56:58 svillar has joined #css 19:01:13 Florian has joined #css 19:07:43 Zakim has left #css 19:14:48 Ms2ger has joined #css 19:21:43 dbaron has joined #css 19:46:30 zcorpan has joined #css 21:05:32 dbaron has joined #css 21:20:47 Florian has joined #css 21:57:20 dbaron has joined #css 22:04:16 adenilson has joined #css 23:12:38 dbaron has joined #css