15:56:02 RRSAgent has joined #css 15:56:02 logging to https://www.w3.org/2018/09/12-css-irc 15:56:04 RRSAgent, make logs public 15:56:04 Zakim has joined #css 15:56:06 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:56:06 Date: 12 September 2018 15:57:42 zheng_xu has joined #css 15:58:34 present+ 15:58:43 present+ 15:58:46 present+ dael 15:58:49 ScribeNick: dael 15:59:13 smfr has joined #css 15:59:26 present+ 16:00:10 Present+ 16:00:30 present+ 16:00:31 present+ 16:00:57 present+ 16:01:14 zcorpan has joined #css 16:01:19 present+ 16:01:42 present+ 16:01:47 present+ 16:02:26 fremy has joined #css 16:02:40 astearns: Let's start and let people straggle in 16:02:55 astearns: Any extra agenda items? I saw the break issue from fantasai. Anything else? 16:03:02 rachelandrew has joined #css 16:03:07 Topic: New co-editor for Filter Effects 16:03:14 present+ 16:03:15 present+ 16:03:23 yay! 16:03:29 astearns: We had a volunteer. I've talked to current editors. They're fine. Chris H. is now a co-editor. 16:03:30 bradk has joined #css 16:03:39 astearns: Hes' been active so hopefully will get things done 16:03:46 Topic: FTF topics needed 16:04:02 https://wiki.csswg.org/planning/tpac-2018 16:04:14 astearns: We need agenda items. It is TPAC so there is less time. Right now agenda in repo and in wiki is light. Please add things 16:04:24 jensimmons has joined #css 16:04:29 present+ 16:04:30 present+ 16:04:36 present+ 16:04:37 present+ 16:04:38 present+ 16:04:38 fremy: I would love to discuss, you know the color filter proposal from Apple, I haven't seen anything but I'd like to discuss. I will add to wiki 16:04:43 sorry 16:04:48 Rossen_ has joined #css 16:04:51 Topic: Review HTML fieldset/legend spec 16:04:55 present+ 16:04:59 github: https://github.com/w3c/csswg-drafts/issues/3094 16:05:17 astearns: Looks like fantasai mats and florian have commented in issue. 16:05:25 astearns: If you were not aware, please take a look at the issue 16:05:35 astearns: If you have anything to contibute please do. 16:05:53 wow long comments are loooooooong 16:06:25 fremy: I didn't write anything on the issue and I haven't seen fantasai comments. It's an amazing document. One concern is in Edge webkit-appearance is cosmetic. We only support none. I'm concerned to see it overriding display and other essential properties to CSS. 16:06:57 fremy: If this is how it works in blink maybe, but I get this impression this is not a thing it does. If this is not how it works in blink I would not make it this way. I have not had a chance to verify 16:07:38 q? 16:07:38 florian: You can I need to be involved in paralel conversaiton. There's a whatwg standardization of the webkit property where they're specing half of it. They're not super happy with out proposal so we should be involved 16:07:51 chris has joined #css 16:07:55 chrishtr: The blink engineers are opposed to adding more functionality to prefix properties. 16:07:57 present+ 16:07:59 florian: Good to know, I agree 16:08:03 tantek: I also agree 16:08:04 +1 16:08:04 s/should be involved/should talk/ 16:08:25 tantek: I don't think should be adding anything to appearance. Adding functionality feels like pointing someone to a giant mess. 16:08:51 florian: Total agreement, but there are 2 groups of people not talking. Our side saying this and another group saying we shoulds tandardize on webkit-appearance 16:09:18 Rossen_: Upcoming F2F event coming up...good thing to talk about there. I propose we keep looking and see if we can reach agreement at TPAC 16:09:21 tantek: sgtm 16:09:26 astearns: Add to wiki agenda? 16:09:36 Rossen_: Def. We'll see if we can pull people from whatwg 16:09:59 astearns: Other thing I noticed is there is a lot being discussed. Threading is hard to follow. If anything can split to its own issue please do 16:10:26 florian: It's tricky. It's a giant spec. Having 25 issues sep is different then one list where everything is bad and maybe we should reconsider. 16:10:39 astearns: Just pointing out as we find separate issues to solve we should split 16:10:49 present+ 16:11:18 dbaron: Another point here: interop is bad and this spec is doing a lot to improve it. SHouldn't ask for it to be thrown out. WE should question what is not needed for interop, but a bunch of this is needed given web compat 16:11:42 present+ 16:11:47 florian: Taking as dependencies as things not defined and assuming they work as they do in chrome. BUt they're not defined to work that way. Until solve dependencies not clear the spec works 16:12:00 agreed with specing backcompat interop 16:12:06 fremy: Let's put this on TPAC agenda where we can work together and once everyone has read the spec. 16:12:17 but disagreed with extending aappearance OR -webkit-appearance 16:12:24 fantasai: I think 2 things to add. This fieldset stuff but also appearance property. 16:12:30 also disagreed with methodology of "just spec what Chrome does" 16:12:49 Rossen_: For appearance property good to summerize the principles as to what we'll take. Also making clear position on prefix properties. Then go from there 16:12:50 can we counterpropose deprecating FIELDSET and LEGEND? 16:13:04 tantek, no 16:13:15 florian: And also people sync internally. Mozilla here and mozilla in compat spec seem to be different to take one example. Talking internally would be nice 16:13:23 florian: Maybe TPAC is the place for that 16:13:27 they are too much trouble for authors to bother trying to use in any compat / interop way 16:13:33 tantek, they're perfectly fine HTML elements, we just need to be able to a) make them not magic b) ideally define the magic so it can be controlled and/or reused 16:13:35 astearns: Good for now? This will all go in the issue. Please continue there before TPAC. 16:13:46 Topic: anything that creates a stacking context should sort in the positioned descendants z-ordering list 16:13:48 lol "perfectly fine HTML elements". ok agree to disagree 16:13:54 github: https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-416803673 16:14:50 florian: I ran into this again while writing tests for Contain. Summary: place in the spec that defines how things stack is in css2.1 THat bit of prose assumes only things that can create stackign context are positioned elements so it's not careful in phrasing. We've introduced other things so we need to clarify if they stack same or not. 16:14:57 astearns: Stacking or painting? 16:15:12 florian: I'm not the expert on stacking and painting. I jsut want this closed. 16:15:39 dbaron: I think most of answer in the issue. Someone needs to propose edits to css2 with a new term, only onething in css2 uses the term, all other specs use that term. 16:15:59 chrisl: Not just css2. Also compositing defines more. I agree we need clarity and changes, but all in css2 is not optimum. 16:16:34 antenna has joined #css 16:16:49 dbaron: Things that should be in compositing, I agree. Term in css2 is 'thing that creates stacking context'. When css 2 refers to that term it says 'positioned elements' and it needs a term so other specs can say this thing creates stacking context so all things css2 says about stacking context applies 16:16:53 chrisl: agree on that 16:17:09 florian: Given css2 has editors can we assign somebody? 16:17:16 tantek: File and issue and take it from there 16:17:20 :) 16:17:43 fantasai: gsnedders is still looking for funding to work on css2 so if you want him to be an effective editor give him some money 16:18:02 astearns: I like idea of separate issue for css2 work o nthis 16:18:09 florian: Is it separate or just the same? 16:18:12 tantek: Yes 16:18:20 dbaron: Edit other specs. Separate issue makes sense 16:18:31 tantek: Fixing css2 is not signing up for all other specs 16:18:44 dbaron: And fixing css2 is complicated because you have to find all the places to change for the new term 16:18:53 astearns: tantek can you create issue? 16:18:55 present+ 16:19:02 tantek: Not failiar. I'd ask current issue creator 16:19:06 dbaron: I'll file and issue 16:19:10 astearns: Anything more? 16:19:17 Topic: containment probably shouldn't apply to most SVG elements 16:19:25 github: https://github.com/w3c/csswg-drafts/issues/2987 16:19:43 florian: Looking to raise attention and get a consentual answer. Last issue on containment. 16:19:56 florian: Seemed dbaron and ameliabr were getting somewhere 16:20:09 chrishtr: Agree with dbaron on outer svg and nothing else 16:20:18 florian: Can we say that or need to be more specific? 16:20:34 dbaron: I think applying to outer SVG is pretty straight forward 16:20:48 tmichel has joined #css 16:20:56 astearns: Don't have ameliabr on the call. Shall we resolve on outer SVG and ask Amelia? 16:21:09 present+ 16:21:24 chris: I think there's agreement on outer SVG. And it's what's outside foreign object. TabAtkins is correct foreign object est containing block but that's all it does. 16:21:30 Rossen_: eq. of iframe basically 16:21:50 astearns: Prop: containment should apply to outer SVG but nothing else in SVG 16:21:52 astearns: Obj? 16:21:56 +1 to proposed resolution 16:22:00 RESOLVED: containment should apply to outer SVG but nothing else in SVG 16:22:08 astearns: I'll tag ameliabr for review 16:22:30 florian: I expect next call to have spec ready for CR. Thanks to Gerard for the test suite 16:22:37 Topic: What is the visual effect of filter() on the document element? 16:22:45 github: https://github.com/w3c/fxtf-drafts/issues/282#issuecomment-418954332 16:23:06 AmeliaBR has joined #css 16:23:42 chrishtr: In previous WG meeting we discussed a couple of issues. One was filter is a containing block for all elements unless filter is on root. Reason for that is that it's important for impl reason and rationality of platform for it to be CB. For root we want fixed to behave correct 16:24:01 chrishtr: Second issue from smfr is that it's unclear what happens when you put a filter and what happens to default white backdrop 16:24:18 chrishtr: Discussed and had somewhat resolution similar to my proposal, but needed use cases 16:24:32 https://docs.google.com/document/d/1iN0LiaKPF3NZ2PCXD9gdWz1WmruhQIER8fJ_EYMm5YE/edit# 16:24:38 zcorpan has joined #css 16:24:40 chrishtr: THere's 3 drawing layers for every doc. UA background layer, canvas layer, root element layer. Blended for final output 16:24:58 chrishtr: Want to make sure final is opaque. That's function of UA background 16:25:08 Rossen_: Always meaning per discression of UA right? 16:25:16 chrishtr: yes but don't think it's good idea 16:25:43 Rossen_: If a UA wants blending enabled for, say, webview with different composition other then opaque they should be allowed. Saying background is always opaque is too strong 16:26:00 chrishtr: Would you agree it's important for dev not to be able to cause blending there? 16:26:26 Rossen_: Agree. Trying to distinguish that UA layer is controlled by UA only. Opque or not is per discretion of UA. Rest is correct 16:27:23 chrishtr: Canvas layer is second. Purpose is a blending backdrop for root element. Root element never has a background, lawyas stolen by canvas layer. THat's as is. Other cases in HTML where body gets its background sotlen, but that's not valid here 16:28:11 chrishtr: I want mixed blend mode and filter to apply to canvas layer as it mixed blend and filter of root element and canvas. Default color of canvas is white. If you don't spec a color on html element canvas will be white 16:28:19 Rossen_: Purpose of root element layer? 16:28:53 chrishtr: Content that's not the background but drawn into stacking context. If you have a non-stacking div that's filtered in 16:28:56 Rossen_: Makes sense 16:28:57 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%20background%3A%20aqua%20%7D%0A%3C%2Fstyle%3E%0A%3Ciframe%20srcdoc%3D%22%3Cdiv%20style%3Dbackground%3Ablue%3Bheight%3A30px%3E%3C%2Fdiv%3E%22%3E 16:29:19 smfr: There was a step to prop. the UA background layer color to the canvas. If you make canvas whit eyou prevent UA from transparency. 16:30:14 chrishtr: Default color of the canvas is white. Step 1 in the algo is paint white into UA. step 2 is put background of root into canvas and if no background put white. Guar. of opaque comes from UA layer, not canvas. UA layer forces the opaque, not canvas. 16:30:25 dbaron: Question on assumption. I put a test case in^ 16:30:50 dbaron: Only tested FF, but iframe is transparent. Canvas does not always have white background 16:31:15 chrishtr: I think the demo is in case of iframe...yeah...white background is root frame but not sub frames. Right. And iframes can be transparent. Right. 16:31:26 astearns: Should that be added to algo? 16:31:46 chrishtr: Yeah. White color is specific to root document. For subframes it's transparent 16:32:03 chrishtr: Tranparent iframe is legitimate 16:32:12 Rossen_: There is no ua background layer in this case 16:32:17 gtalbot has joined #css 16:32:20 chrishtr: THere is eventually if you go up stacking 16:32:30 Rossen_: Yes, for the frame itself 16:32:56 chrishtr: Right. And as dbaron said it doesn't draw white by default. There is no infinite canvas for an iframe. That needs to be thought through 16:33:38 gtalbot has left #css 16:33:44 chrishtr: Another comment on github from earlier today that asked about clipping and masking order relative to filter and blend. Compositing says filter first and then...there's an order 16:33:49 yes, filter should be applied first. 16:34:11 so there are two separate clip stages? 16:34:19 chrishtr: Clipping is clip-path. I think it's important to be after scrolling and overflow clip. Not masking or clip-path. Not sure you can mask or clip-path root. Does anyone know? 16:34:27 chrishtr: It would apply to iframes but not root document 16:34:34 Rossen_: QUestion was? 16:34:42 chrishtr: Masking for css clip to the root 16:34:52 chrishtr: Any way to cause clip on root element 16:35:10 chrishtr: Not sure it makes any sense for root of webpage or if UA impl. Makes sense for an iframe 16:35:23 Rossen_: NOt sure 16:35:41 Rossen_: Assume the use case for iframe I would question why that use case doesn't apply to top level root 16:35:56 chrishtr: Reason wuld be iframes are in a larger drawing serface. 16:36:15 Rossen_: Yes, unless root is inside an iframe. If use case applies to doc in iframe, why when it's not. 16:36:53 fremy: Also if you're drawing on a glass screen I can imagine websites wanting to be transparent and only white background when they want it. I don't think there's a reason to think iframe use case doesn't apply on root 16:36:57 chrishtr: Okay. I see. 16:37:16 Rossen_: Where do we go? Your summary in the explainer is decent. What's next? 16:37:36 chrishtr: Need to go into more detail about iframes and clipping/masking. Then I think it'll be ready to come back 16:37:50 Rossen_: This is great chrishtr . Thank you for putting this together. 16:38:04 Topic: Need to agree on when LinkStyle.sheet gets updated in shadow trees. 16:38:13 github: https://github.com/w3c/csswg-drafts/issues/3096 16:39:25 emilio: cssom spec the first spec when an element has a stylesheet to html. Html doesn't spec. impl did different things. Gecko loads stylesheets in shadow trees. Blink and webkit don't/ Fine spec webkit and tying loading a sheet to connected to a document. Makes shadowroot stylesheets useless unless root is connected 16:39:49 emilio: Overall that makes sense. Example a styleelement.sheet is also used when style is not in doc. 16:39:54 astearns: Any concerns? 16:40:09 astearns: Makes sense to me 16:40:10 s/used/useless/ 16:40:29 emilio: Fine for me if we get a resolution I'll make edits 16:40:45 astearns: Proposal: Spec webkit/blink behavior for disconnected shadown roots 16:41:01 emilio: Disconnected elements don't have stylesheets 16:41:07 astearns: This goes into html? 16:41:24 emilio: May need to. I'll discuss with html editors who should spec. it's right now nowhere 16:41:36 astearns: Prop: Disconnected elements don't have stylesheets 16:41:40 astearns: Objections? 16:42:13 Rossen_: Disconnected elements have no stylesheets. If I make an element through OM and make a style element the contents are dropped? 16:42:21 emilio: Not dropped, but they're not associated. 16:42:28 what about style elements in the disconnected element? or style attributes? 16:42:30 Rossen_: Once I merge into main tree style sheet becomes 16:42:36 emilio: Yes, it's non-null 16:42:56 Rossen_: There's a temp style sheet not accessible through OM, but it's created and retained for lifetime of subtree 16:43:22 Rossen_: My assertion is there is an actual style sheet not accessible through OM until element is merged into main tree 16:43:35 emilio: IN gecko we have no style sheet. We parse when becomes connected 16:43:52 Rossen_: So you're saying if the stylesheet has external reference you won't download until merged into tree 16:44:01 emilio: Right. THat's only thing HTML specs. 16:44:14 Rossen_: Then I'm fine with the proposal. That answers my question 16:44:35 plinss: If you're creating a custom element you cannot manipulate stylesheet through cssom until connected to document. 16:44:38 Rossen_: That's current 16:45:08 emilio: You don't want to trigger loads. Rune said he's in agreement. You can create stylesheet via inner html but can't access via OM 16:45:52 Rossen_: This is also related to our previous discussions abotu sso on disconnected trees. We'd give them stock style answers was our conclusion so you don't trigger style computation. That's why asked if we'd spec so downloads don't occur until merge with main 16:46:04 plinss: If I create web component it cannot be made ready until plug into doc 16:46:07 Rossen_: Correct 16:46:32 plinss: So I plug it in wait for style to download and parse, get a flash of unstyled and then can manipluate. 16:46:41 Rossen_: Not defending, but it is the current 16:46:46 plinss: Do we want this? 16:47:07 emilio: For small components you use inline styles and defer parsing until you insert it. 16:47:31 Rossen_: plinss perhaps is alluding to a separate issue that perhaps we need a trigger that forces download when not connected. 16:47:37 plinss: At least parse and manipulate 16:47:42 Rossen_: Yeah, this is a fair point. 16:47:59 Remember, there is always , which you can add to the main document to trigger a download without applying styles just yet. 16:48:12 emilio: I think there are proposals in Google for document.tree to allow. Wouldn't work like current style sheets. It's a different API. But I think would address that use case 16:48:50 plinss: This is something I ran into in the last week or two. I want to set values of custom prop and I can't do it through clean APIs. We should allow authors to manipulate style sheets before connection 16:49:07 emilio: I thik google proposal address that. I don't think we want current style and link to trigger downloads 16:49:22 plinss: Understood. Not proposing we change legacy. There is a use case here. 16:49:30 emilio: File as a sep. issue? 16:49:34 plinss: Fair enough. 16:49:48 astearns: plinss do you want to investigate current proposals and file an issue if they're not enough? 16:49:50 plinss: Yes 16:50:01 astearns: Proposal: Disconnected elements don't have stylesheets 16:50:04 astearns: Obj? 16:50:06 RESOLVED: Disconnected elements don't have stylesheets 16:50:13 plinss: https://github.com/w3c/webcomponents/issues/468 is what comes to mind 16:50:19 Topic: Pointer Cursor wrangling 16:50:28 github: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-419616109 16:51:18 florian: I think we have strong consensus that we do NOT want to change UA requirements as to what they should do with pointer cursor. But there is a fairly large contingent of authors that think this is an author requirement and if you do pointer on anything other then link it's invalid. 16:51:28 florian: Large part of web does things like pointer on button 16:51:58 florian: Is there room for a note or some wording to say UA do links and links only, but authors can put it in other places 16:52:11 astearns: Last comment in issue TabAtkins suggested the sentence [reads] 16:52:21 this value SHOULD be used on links, and CAN be used on other interactive elements to indicate 'clickability' 16:52:38 astearns: Is that sufficient? Acceptable? 16:52:44 florian: replace can with may but yes 16:53:26 fremy: not thrilled but don't want this thread open for 250000 years and this coming back up all the time. Still wrong because people have been misusing something and people pointed out we're misusing it and now we have to change requirements because we pointed that out 16:53:47 zheng__xu has joined #css 16:53:54 fremy: It doesn't make sense. Either we say it should be used and change UA style sheet. Why say can if we don't do it? I have mixed feelings. I won't object to a may. It's wrong, but I won't object 16:54:44 TabAtkins: That browsers can't change their behavior doesn't have baring on how a lot fo heavy usage leads to the value's usage. Legacy constraint on browsers shouldn't constrain us here. THis is about matching author expections. People expect this to work in a particular way. 16:55:19 astearns: Objections to adding the proposed sentece: this value SHOULD be used on links, and MAY be used on other interactive elements to indicate 'clickability' to UI 4 16:55:36 astearns: the pointer value SHOULD be used on links, and MAY be used on other interactive elements to indicate 'clickability' 16:55:43 +0 sounds ok, still reading 16:55:56 florian: Should this be "authors should use" unstead of "should be used" 16:56:01 TabAtkins: It's on UAs. 16:56:12 florian: Do we want to say UA may apply to others? 16:56:20 TabAtkins: That's why I started with a can 16:56:36 florian: Is sentence meant for author and ua or just author? 16:56:58 TabAtkins: Both author and UA. I don't think it's bad if a browser changes to pointer on clickable things 16:57:10 AmeliaBR: We already agreed to UA must apply pointer on hyperlinks 16:57:29 AmeliaBR: more passive voice this cursor should be used could be included without cancelling the must 16:57:50 florian: I don't object to current. If it's meant as vague I'm okay with vague 16:57:58 ok with CAN or MAY 16:58:05 though slight preference for MAY 16:58:08 dbaron: Good to be clear who requirement is on 16:58:15 astearns: Not vauge, it applies everywhere 16:58:37 also going to note for the record that no one followed up with tests as I requested last year in the issue :P (unless I missed something? searched whole issue for "test") 16:58:42 AmeliaBR: Have an explicit requirement on UAs. Another sentence could be authors should us it on any other element that behaves as a link and may use it to indicate clickability 16:58:51 florian: There's no UAs must not 16:58:56 https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-346420266 16:59:02 AmeliaBR: Exactly. No negative about UAs applying to other elements 16:59:08 florian: Like that better 16:59:18 astearns: Does reduce confusion 16:59:28 astearns: Object to scoping this sentence to jsut authors? 16:59:37 present+ 16:59:47 astearns: Proposal:": Authors should use pointer on links and may use on other interactive elements 16:59:50 no objection 16:59:52 astearns: Obj? 17:00:06 RESOLVED: Add sentence "Authors should use pointer on links and may use on other interactive elements" To UI4 17:00:14 topic: end 17:00:18 astearns: Thanks everyone 17:02:40 trackbot, end meeting 17:02:40 Zakim, list attendees 17:02:40 As of this point the attendees have been astearns, florian, dael, bdc, dbaron, rego, svoisen, zheng_xu, melanierichards, dauwhe, smfr, rachelandrew, xfq_, chrishtr, emilio, 17:02:43 ... jensimmons, tantek, plinss, Rossen_, chris, leaverou, bradk, antenna, tmichel, AmeliaBR 17:02:48 RRSAgent, please draft minutes 17:02:48 I have made the request to generate https://www.w3.org/2018/09/12-css-minutes.html trackbot 17:02:49 RRSAgent, bye 17:02:49 I see no action items