- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 16:00:17 -0400
- To: "www-style@w3.org" <www-style@w3.org>
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= FX specs location ----------------- - When there are FXTF issues that need WG review, editors will flag as Needs Review. Chairs will make sure Needs Review issues are added to telecon agenda (in an appendix as things that need review or input, but won't be discussed on the call). - FXTF editors may send email summarizing spec or issue statuses to the CSSWG mailing list to bring attention to them as needed. Publications and Editors ------------------------ - RESOLVED: New WD for Filter Effects. - krit will create a DoC for Masking so that it can be republished. - RESOLVED: Add ChrisL and smfr as editors to Compositing and Blending - RESOLVED: Editors for Geometry are krit and TabAtkins CSS Grid 2 ---------- - RESOLVED: Remove the dual-axis proposal in favor of per-axis. (Issue #2280) - RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis proposal. CSS Display ----------- - RESOLVED: ::marker exists on all elements, on ::before and on ::after but no box unless it's display: list-item. (Issue #1793) - RESOLVED: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree. (Issue #1477) - RESOLVED: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree. (Issue #1477) ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule Scribe: dael FX specs location ================= krit: There's a lack of response from CSS WG right now since these specs are in the FXTF repo. Especially when they're mentioned. krit: Is there anything we can do to make this more visible to CSSWG members? krit: Many of our issues don't need WG or a proposal can be made before WG review. If there's anything editors can do to let CSSWG members know their attention is needed. Elsewise please keep and eye on that repo. Rossen: astearns and I scrub issues with Agenda+ on telecons astearns: But krit said some might not need telecon if it gets attention in github fremy: Should we add a tag that's agenda+ for review so it's sent with the agenda but for review? Rossen: Agenda+ items get attention because astearns and I are getting those regularly. Request is for 'hey FXTF is between CSS & SVG can we get more people to actively work on issues so they can make it to agenda+' florian: There's 2 levels. One is everyone remembering. Then there's a review+ tag that you scrub with the agenda+ but you just list those in the call agenda. Rossen: We have a tag for Needs Review. astearns: We only look for agenda+ and needs csswg review. If you use the Needs Review for non agenda+ items individuals could look at the repo and then Rossen and I can look and mention in telecon. florian: Just list them in the agenda of things we won't talk about but please look. And do that across all repos. <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Feb/0009.html <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Mar/0039.html fantasai: I'll often post a summary status like ^ and I'll say here's the status, here's what needs feedback. I don't know how useful, but I try and do that to bring attention to issues that need it. Maybe this is a useful thing to try. krit: FXTF has its own ML, is it okay if I send it to CSSWG as well? fantasai: Yeah. krit: I don't want to annoy anyone. fantasai: Right now it's low traffic because we use github. krit: Yes, those suggestions are good. Publications and Editors ======================== New WD for Filter Effects and CSS Masking ----------------------------------------- astearns: What's changed? krit: A lot. krit: Last publication was 2014 for both. astearns: Yes, let's republish. ChrisL: Is there an up to date changes section? krit: Yes for both. ChrisL: Okay. <ChrisL> https://drafts.fxtf.org/filter-effects/#changes RESOLVED: New WD for Filter Effects Rossen: What's the status for Masking? krit: Both specs have 12-14 issues, about half can be solved by SVG. ChrisL: So Filters isn't a transition. Masking needs a DoC since it's in CR as well as a changes section. ChrisL: So let's not resolve to publish if we're not there. krit: What is needed before I can ask for publication? ChrisL: A DoC ready fantasai: And we get to review it as well. Rossen: So we need to do this before we call for resolution? fantasai: Yes. krit: There are open issue for masking. ChrisL: That's fine. And we don't have to go back to WD. astearns: The opens are called out in DoC. ACTION krit compile DoC for Masking and bring it back for CR publication resolution <trackbot> Created ACTION-873 Assigning Editors ----------------- Rossen: Compositing and Blending ChrisL: I volunteer as tribute. eae: I haven't quite managed to convinced people to do it yet. Rossen: You can lead by example. :) Rossen: We have smfr and ChrisL to edit. RESOLVED: Add ChrisL and smfr as editors to Compositing and Blending krit: Geometry - it would be nice to have someone familiar with JS in general. Rossen: Who possesses those powers? astearns: It's in CR. Impl status? krit: Most UA shipping already. So impl status is pretty good. Have to check in detail. astearns: People with impl experience would be best editors for spec. Rossen: I agree. Rossen: For people who are impl this...? krit: I said to astearns I'd volunteer but if I do it alone it would take longer. It would be preferable if someone with more experience. TabAtkins: I have the skills but not the time. Rossen: Can you teach someone? TabAtkins: I can help. astearns: Anyone at Google you can delegate? TabAtkins: Possibly? Rossen: Mozilla? Anyone good with webIDL? Rossen: So we have krit. emilio: Cameron has the right experience. Rossen: TabAtkins should we put you there for now and you transfer? Rossen: Editors for Geometry are krit and TabAtkins krit: In general editors are always welcome. ameliaBR would be willing but needs funding. RESOLVED: Editors for Geometry are krit and TabAtkins CSS Grid 2 ========== Dual-axis vs. Per-axis Subgrids ------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2280 <tantek> Note also that Mozilla (mats) now has a public intent to implement on subgrid (on dev-platform) Rossen: We took time to review and there's impl feedback from Mats that per-axis makes sense and is implementable. So we either can discuss more or resolve. Rossen: Anything remaining to discuss in this issue before we move to adopt this? Rossen: Objections to publishing Grid L2 with the per-axis subgrid model? ChrisL: Is that fpwd? Rossen: It is. Rossen: Is it? Rossen: Did we not publish the original fork? fantasai: We did. <dbaron> https://www.w3.org/TR/css-grid-2/ Rossen: So it's an updated WD. Rossen: Are there objections to adopt the per-axis model and publish a WD? rego: There are clear use cases and mats has a working sample. He is asking to remove a section and add that the dual axis is included. Rossen: I'd like to publish as is and then open individual issues against it. Rossen: Other comments? tantek: You don't want to make Mats' changes before publishing? Rossen: We open them as separate issues. fantasai: Mats is asking to loosen restrictions a bit; and for some of it I don't actually understand what he's asking yet. fantasai: We need a resolution to remove the dual-axis proposal. Rossen: Objections to removing the dual-axis proposal? RESOLVED: Remove the dual-axis proposal Rossen: The second issues, removing g,h, and i from subgrid should that be a separate issue? fantasai: I'm happy to remove i. Removing g and h I don't understand. Rossen: That's why I suggested a separate issue. fantasai: I don't have a problem discussing and republishing in 2 weeks. Rossen: Objections to publishing a new WD of Grid L2 with the removed dual-axis proposal? RESOLVED: Publish a new WD of Grid L2 with the removed dual-axis proposal Rossen: Please someone open the g and h as a new issue. CSS Display =========== Is ::marker created by display:list-item or does it always exist? ----------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1793 TabAtkins: We all agree on overall behavior. More a question what model we want. ::marker pseudo element. Original question is decided. It was what things in theory can have ::marker pseudo elements. It's only created by thing with display:list-item. Theoretical model of the element tree, which things have 'display: list-item'. TabAtkins: We wanted approval that ::marker elements always existing the box tree on elements before or after and they're auto suppressed. TabAtkins: Other options are if they exist in the tree depends on style or say they always exist but not on elements but not on pseudo elements ::before or ::after which breaks the current behavior for FF and Chrome. TabAtkins: Final option is ::marker elements always exist and can be on any tree abiding elements. This could mean that ::marker pseudos contain ::marker pseudos. Because you can't set display on them, though, you'll never see them. TabAtkins: Depends on the theoretical model you want. emilio: Is that required? Except for ::slotted I think most browsers reject multiple pseudo elements at parsing time. TabAtkins: Does not require that. TabAtkins: That would be good if you actual style nested ::marker. emilio: It would mean you can set content before. TabAtkins: Ideally you should be able to, but right now you have an unstylable marker. dbaron: Auto-suppressed? TabAtkins: Like how ::before doesn't create a box unless it's non-none. ::marker wouldn't have a box unless it's contents had display. dbaron: Is there a distinction between exists and suppressed and not existing? TabAtkins: One is a layer violation. It requires us to not completely build on the tree until we resolve the styles. Right now we can build the element tree fully. This is theoretical design and has no practical considerations. TabAtkins: We suggest they always exist on elements, ::before and ::after fremy: Is that all browsers do? TabAtkins: Those are all that browsers have always there. If we add more we can categorize properly. TabAtkins: Objections to my preferred option that ::marker exists on all elements, on ::before and on ::after but no box unless it's display: list-item. florian: If you display: list-item...the initial value of content is normal then you get it but if you don't display list item is it like a ::before? TabAtkins: It does not show up. Rossen: Objections? <dbaron> sounds good to me RESOLVED: ::marker exists on all elements, on ::before and on ::after, but no box unless it's display: list-item <fantasai> Possible practical implication might be getComputedStyle on ::marker? How does block inside inline affect the box tree, exactly? ---------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/1477 TabAtkins: I recommend looking at the first comment because Loirooriol has a great markup example. TabAtkins: Basic idea, in the box tree there's a span and a div list inside it is it an inline box with a block box inside and during fragmentation we split that or does the splitting happen at box tree time? florian: Observable? TabAtkins: Affects how other properties are defined so yes in theory. I don't think any property could be used as a probe of it. No one uses exact box tree for spec. Loirooriol: Saying splitting happens in the box tree is more consistent because operations happen in the order. If splitting is in box tree we need some kind of exception. CSS 2.1 doesn't distinguish between when it happens so it's like it happens between boxes. TabAtkins: Impl information in FF eq they split and special case text-decoration so it propagates down. koji: We split spans, wrap it in anonymous box, and for the box we split. That last part is same as Gecko. <fantasai> https://www.w3.org/TR/css-break-3/#break-decoration might need an update TabAtkins: Our layout structure doesn't distinguish boxes and fragments either. Hard to argue we have one behavior or the other. fremy: Not sure why we need to know. TabAtkins: Affects how we write specs. iank: Anything we do with block behavior should stay. TabAtkins: Impl details don't matter, it's the theoretical model. Being closer to impl matters. We can live with either model. We just need to decide. florian: Which makes spec writing easier? TabAtkins: Split not until fragment time is easier I believe. Makes text-decoration easy. Other cases that treat them as a single thing work fine in that model. dbaron: I worry a bit about making something trivial to define if it's actually more complex then implemented. I think it's better if the things easy in implementation are easy in spec and hard in implementation are hard in spec. TabAtkins: Agree. florian: That's say split boxes not fragments. fantasai: Shows up for box-decoration-break. Loirooriol: If splitting happens in box tree, inline assumes if you general boxes in that case it uses the box. If one of the two inline boxes are chosen it's strange. TabAtkins: And both are the principal box because both get all properties. fantasai: I'd prefer at fragment tree time, and if we want to change the parentage maybe that's sensible. I don't think spliting in the box tree makes as much sense. I think of this as fragmentation so it makes sense to say that that's what's happening. fantasai: Also, box-decoration-break should be controlling behavior at these breaks. We're slicing by default but may want to switch to clone. This is how we define how the sides of a box that has been split are drawn and if we define them as separate boxes we have to define that they behave as fragments for this case. If it is a fragment it's not a special case. florian: Split at fragment level makes a lot more sense. Seems to be a difference with impl that don't distinguish, but dbaron point earlier that this makes it easier to define hard to impl... fantasai: Does it? There's a reason why we try to discuss and get review and it's to point out where model doesn't make sense. I see some reasons for define as fragments and only theoretical worries for the other. Rossen: The model in fragmentation spec makes a lot of sense to me. Early stages of writing draft there was back and forth for what is a fragment and what's a principal box. As an impl it was a time somewhat odd to map and refer to things not in our impl. There's not a principal box in the impl nor do we call anything a fragment, but the model matched well. Rossen: If the model in the fragmentation spec doesn't make sense what do you propose to change? fantasai: Didn't say it doesn't make sense? Issue is about block in inline splits. Is inline fragmented or of many boxes? A lot of impl has a structure that's not one or the other. We need the theoretical set up here. iank: Eventually we want to move to a model where we use fragment so I'm fine that way. iank: We don't want to do inline splitting at the box tree level eventually. florian: I think so long as we have a conceptual model where boxes and fragments are different this should be at the box level. If we only want to talk about boxes because matches impl that's a different conversation. dbaron: I think there's another view to it then not having both concepts which is that you can keep boxes and fragments as terms but view the fragments as what you get when you split boxes rather then a later process stage. florian: It's a processed box? fantasai: Isn't that what fragments are? dbaron: That's what I thought until a few weeks ago. However people have said things that have made me think differently, including this issue. florian: I don't think fragments are boxes that have been processed in a particular way. TabAtkins: As per spec you are right. Fragment tree is the result of layout on boxes. You get a different tree out of that. florian: Fragments is not a short term to mean a box piece. It's not a whole bunch of boxes some of which are fragments. fantasai: A box is composed of one or more fragments. florian: But later in the process we don't have boxes and fragments. dbaron: You have a box tree and you go to a fragment tree by splitting things up. dbaron: A box corresponds to one or more fragments. If the box has children those are in one or more of the children. fantasai: This is the case where it's not clear that's happening. TabAtkins: In multicol even children might fragment. Putting some children in one fragment and one in the next is fair. dbaron: If box A is parent of box B then any fragment of box B will have a parent of fragment A. fantasai: How we lay this out, they don't act like their the child of the parent. Layout wise it behaves like a sibling and lays out that way. Same is true of block. It lays out as if it's a sibling of the anonymous block before and after. florian: It changes the variant but it doesn't change that you can consider the fragment tree as a processed version of the box tree. There's a little re-parenting but not a lot. Rossen: I'm trying to get to a model that makes sense. What's the model we define in the fragmentation spec in your mind? dbaron: I didn't see the fragmentation spec as contradicting my model. fantasai: It doesn't because it doesn't talk about block-in-inline splits and column spanners. TabAtkins: It's fragmenting easy cases. Rossen: Is it easy? If you have a whole bunch of open inline elements, open spans, and text inside that generates some line effects and then a block element that breaks this line flow. At that moment what do you have? dbaron: In my mental model? One of the things about the blocks inside is that some ways they act like not a child like backgrounds but for relpos they act like they are. Rossen: If an inline element was an anchor open before and close after the block. dbaron: I think it's not related to DOM event propagation. Rossen: But it's type of hit test. florian: When you say some aspects siblings and some not, it's that the same as in box tree descendants and in fragments its siblings? dbaron: If you have it as though there's a thing there is some ways and not others it's easier to have the object there and disable features then not have it there and re-conjure it when you need it. fremy: If you have regions it's in 2 elements and your model can't have regions. They're in different places of the tree and they'll have fragments that aren't related. dbaron: It was a model describing how fragmentations worked and I didn't mean you have to follow it always. Still feels weird to me and I didn't know the spec was different until recently florian: For Gecko these are siblings or one child? The block that interrupts inlines. dbaron: Child of the inline but it is a child of the block fragment of the inline and those are kind of special. florian: But that's not a conflict. You have a single data structure that represents both box and fragment tree. In that single data structure there's a thing that keeps the parenting relationship. In box tree they're parented in fragment node. The object is present in one of the two trees. You're just overlapping the two so it's difficult to talk about one concept without the other. Rossen: Is there a model we can agree on? dbaron: I'm fine resolving on it. I just want to recognize it's pretty substantive decision. Rossen: With that warning. What do people think? Ready to resolve? TabAtkins: If people agree, yeah? Rossen: Objections? TabAtkins: Prop: A block inside an inline is a descendant in the box tree and a sibling in the fragment tree. fantasai: And the inline is a single box that has been fragmented. Rossen: You're agreeing fantasai: They're two things, both need to be considered. astearns: It's not just the box that the block is a sibling. florian: You're agreeing, there's wordsmithing. fantasai: I want it clear that there's a single inline that has been fragmented. It's saying the block is a sibling that's a fragment which is a fragment and there's a following fragment doesn't say it's the same box. Rossen: Prop: Blocks inside of... Rossen: Objections to what fremy is typing? <TabAtkins> <inline>foo<block>bar</block>baz</inline> <== 'block' is a child of 'inline' in the box tree; 'block' is a sibling of two fragments of 'inline' in the fragment tree. <fantasai> proposed resolution: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree <fremy> Proposal: There is one inline box containing one block box (in the box tree). In the fragment tree, there are two inline fragments, sibling on each side of the block fragment. Rossen: What fantasai said is the same. Objections to: "In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree" RESOLVED: In a block-in-inline split, the block is inside the inline in the box tree, and is a sibling of the two fragments of the inline in the fragment tree. fantasai: One more. Same applies to column spanners splitting a box. Same logic applies. florian: Same problem but column spanner may break multi levels of parents. Rossen: They can already have multiple, for inlines. Rossen: Agreed? Rossen: Proposal: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree RESOLVED: A multicolumn spanner that splits and inline is inside of the inline box tree and a sibling to the fragment in the fragment tree. fantasai: We forgot anonymous boxes. <br type="lunch"> <fantasai> The block in a block-in-inline split is actually a sibling of the anonymous block boxes on either side, not of the inline box fragments. <fantasai> And in the column case, the spanner is siblings with the column boxes
Received on Tuesday, 29 May 2018 20:00:45 UTC