- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Jul 2015 08:11:20 -0400
- To: www-style@w3.org
Paris F2F --------- - Everyone was okay with having some overlap time with the SVG WG during the Paris F2F instead of during TPAC. Using an images/ Folder for Specs --------------------------------- - RESOLVED: keep images and an images/ folder and source files in a source/ folder for each spec Clarification on percent margin/padding --------------------------------------- - This issue was editorial and will be addressed by the editors Logical Values for caption-side ------------------------------- - RESOLVED: add block-start-outside and block-end-outside overflow: clip and BFCs ----------------------- - One of the blockers for the conversation was the use of the word 'clip' when it really was a property to just do overflow: hidden, but not allow scrolling. If the property is re-named a main objection will be removed. - hidden-no-scroll was the new name used on the call. - A larger issue as to if this is solving an important problem was also raised. One side was that this is along the same lines as will-change that allows authors to indicate intentions in order to speed up the browser. However, the same argument that will-change was fixing an implementor issue can also be applied to overflow: clip. - Florian will write an e-mail summary of the conversation and the options moving forward to continue the conversation forward with input from those that weren't on the telecon. Variants of pre-wrap and longhands of the white-space property -------------------------------------------------------------- - The third option in Florian's list of suggestions (available here: https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html) was discovered not to be a potential solution. - It was instead replaced by eliminating the white-space longhands that are causing the problem. - Discussion will continue on the list. bikeshed user-select: element ----------------------------- - This conversation will wait a week so that people can review the history of this property. ===== FULL MINUTES BELOW ====== Present: Rossen Atanassov David Baron Bert Bos Tantek Çelik Dave Cramer Alex Critchfield Simon Fraser Daniel Glazman Koji Ishii Dael Jackson Brad Kemper Chris Lilley Peter Linss Myles Maxfield Anton Prowse Florian Rivoal Simon Sapin Hyojin Song Alan Stearns Lea Verou Johannes Wilm Regrets: Tab Atkins Sanja Bonic Edward O'Connor Greg Whitworth scribe: dael plinss: Anything to add? Florian: Topics 6, 7, and 8 are related and I prefer 7 before 6. Paris F2F --------- plinss: I did have one request from Cameron. Looks like SVG meeting isn't going to meet at TPAC and they're looking at co-locating with us in Paris and were hoping they could spend time with us in Paris. ChrisL: When in Paris? Rossen: We decided to combine SVG and CSS. SVG will start Monday or maybe Sunday and we'll overlap two days with CSS. In that way we can do a FX joint meeting either the first or second day of the CSS meeting. Rossen: If there are issues that require some members we can go back and forth between rooms. Rossen: Basically, they'll overlap for two days. Florian: Depending on agenda, I don't mind doing it during the overlap, but I do mind before. Rossen: I don't believe that was the request. Rossen: The request was for a regular CSS date. plinss: I'm not hearing objections so I'll send a thumbs up. Rossen: We can provision a half day and if more is needed everyone is in the same building so we should be able to facilitate as we go. plinss: Right. We can factor that into the agenda. Rossen: There's a number of topics pushed away for joint discussion. And since there's too many members with TPAC conflicts they decided to cancel that meeting. Using an images/ Folder for Specs --------------------------------- plinss: TabAtkins isn't here, but he sent an e-mail with the proposal. fantasai: Sounds good to me. Florian: It's all images in a sub folder of each spec, not a joint folder, right? plinss: Yes. Florian: That I'm okay with. smfr: I like the idea and did it for transforms. smfr: There was question about where to put files generated by images and I'd prefer them in a separate folder. astearns: Things should be in sub folders, that's what we should go with. Rossen: The way I read the request is he was requesting a single folder for all of them. Florian: It's one per spec. <astearns> and we shouldn't dictate folder structure fantasai: Each spec has a folder for where the files and and the images for the spec would go in there. Rossen: And this is more optimal than one images folder for all the specs and if a spec requires something special... fantasai: We have: <fantasai> css-break/Overview.bs <fantasai> css-break/Overview.html <fantasai> css-break/images/ <fantasai> css-break/images/diagram.png fantasai: And all the stuff goes inside images. Florian: We don't share images across specs. plinss: And a shared folder would create publication problems. ChrisL: And if something changes you need to work out dependencies. Florian: Do the source files for the images go in there or do we use a sub folder? ChrisL: I prefer separate. And for publication it makes it easier to have separate. * fantasai prefers keeping sources in the same folder, easier to see which file you're supposed to edit when working with them images * fantasai is sympathetic to concerns wrt publishing, though smfr: How does publishing choose which files? ChrisL: On the new system you send a manifest file that lists all the directories and files in that. Old way someone made the choice. Florian: My small use case for separate images and source is what I did for CSS 3 there were a bunch of images and not all were used and it makes it a lot easier if the images supposed to be used are in one place, but that's a small thing. RESOLVED: keep images and an images/ folder and source files in a source/ folder for each spec dbaron: But it goes in a sub directory? plinss: bikeshed source file, see where they are. This is just files to generate images if any. <dbaron> I don't think "source/" was a name to be used for image sources... Percentage resolution for abspos vs inflow grid items ----------------------------------------------------- Florian: Didn't we do that? fantasai: And we need TabAtkins Clarification on percent margin/padding --------------------------------------- Rossen: This is editorial. I don't think it requires much group discussion. Rossen: Basically someone reading the spec was confused by the current text that says margins and paddings resolve their percent values from their...what was the current text... from their respective sizes or something like that. It sounds like they would resolve percent from themselves. Rossen: It's editorial to show they resolve from the width or height of the block. plinss: We'll let you take care of that one. Grid issues ----------- Rossen: Who has this one? plinss: There were some from fantasai and gregwhitworth had one. Rossen: For gregwhitworths's he's on vacation. Rossen: I don't have the ability to do those. We can push them to the end of the call and by then I might be in the office. plinss: We'll defer those. Logical Values for caption-side ------------------------------- <dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0004.html fantasai: We have 2 values of caption-side that didn't have logical equivalents. In the spec and those are top-outside and bottom-outside and the proposals are block-start-outside and block-end-outside. Rossen: Let's start with those and if we rename we'll do everything. Being consistent with the current ones sounds good. plinss: Other opinions? <glazou> +1 smfr: What does outside mean in this context; source? stuff for generating images? I would rather leave it up to editor choice. fantasai: The model for table captions in CSS 2 is the table caption is a block whose containing block is the width of the table's containing block. In implementation captions were constrained to the size of the table itself. In CSS 2.1 we changed the definition so that that's how it behaved. fantasai: Because you often want the old behavior we said there would be top and bottom values that would hold the behavior. Mozilla had implemented those as per spec and since they have that and they're implementing logical equivalents they needed logical values for those that don't exist anywhere but note. smfr: So it's in terms of containment, not left page, right page. fantasai: Yes, it's about the table, not paging. Rossen: What module is that in? fantasai: caption-side values are in CSS 2.1 in a note. fantasai: And we have the logical equivalents in writing-mode. Rossen: Thank you. <fantasai> The model for table captions in CSS2.0 was the table caption was a block whose containing block was the table's containing block. <fantasai> However, in implementations, captions were constrained to the size of the table itself. plinss: It sounds like people are okay with it. RESOLVED: add block-start-outside and block-end-outside overflow: clip and BFCs ----------------------- <dael> https://lists.w3.org/Archives/Public/www-style/2015Jul/0013.html Florian: In relation with containment and paint containment, we added a value to overflow that's 'clip'. It's the same as 'hidden', but you can't scroll even programmatically. Very often that's what authors want and if they can say that it allows browsers to be more efficient. Florian: Mozilla has a slightly different thing. Every value of overflow other than visible makes the elements create a BFC. Florian: Mozilla's doesn't do that. Florian: Before we go further I thought we should consider that and if we should align. I think it's odd, but it's what they do. Rossen: This would complicate the float algorithm quite a bit because if I have floats that extend past the bounds of the clipping element, it means they're bound for the purposes of line layout will need to be considered for visual clipping. Rossen: That sounds weird. dbaron: That's not what Mozilla's value does. dbaron: This is how we did overflow: hidden before it was clear what it did. What we do is just visual clipping, it's not layout change. dbaron: It's a lot like clip, but it applies to more than abspos elements. Rossen: So layout would have been taken account like it's visible and the clipping is render time only behavior? dbaron: Yes. Florian: So for historical reasons, I see how you ended up there, but do you want to maintain it? <vollick> Is this related to contain:paint? <vollick> I.e., is overflow:clip similar to overflow:hidden + contain:paint? Rossen: I question the usefulness. dbaron: Its been useful as a lighter weight variant of clipping. Rossen: What makes it heavy weight? dbaron: You need to be able to allow scrolling. In our implementation some of that is heavy. Florian: That's why overflow: clip is supposed to be different. It's the same as hidden, but you don't have the scrolling. Rossen: It's going to be a different behavior because all the floats inside the clipping element, but adding clip all the floats won't affect the layout outside. If you toggle back and forth with the clip you have to re-layout. Florian: That's the same as hidden. Rossen: Yeah, in that respect yes. In the way dbaron described it you wouldn't have to do anything, it's just visual. Florian: In terms of run time costs, switching to my clip is higher cost than Mozilla's. But in terms of implementation you have it already because you have hidden. Rossen: In terms of implementation cost for us, if we pursue one of the other there won't be that much difference, I don't think. It's allowing...um... Florian: I question the usefulness of hidden floats going outside and change the layout. Rossen: That's what I have a problem with. If there's a float to the bottom and I clip it the stuff at the bottom will re- layout and that's weird. dbaron: It's also weird to design things to be more expensive just because of floats which we do a lot. Rossen: But we can't just ignore them, right? fantasai: Keep in mind that we do now have a switch for creating a block formatting context group. A lot of overflow is to make the BFC and you can do that now explicitly. Right now you can't say I just want to clip as easily. Florian: What's the use case for clipping without a BFC? fantasai: Maybe you don't have floats, just margin collapsing, and you don't want to change the margin collapsing behavior. Rossen: It sounds again like we're oversimplifying once we toss the float out of the picture. Rossen: dbaron, in your implementation I'm assuming the only things you're doing is constraining the key region for the rendered sub tree? dbaron: I think so, yes. Florian: One of the goals for this value, just like the other non-visible values you should be able to use it with the stuff that requires overflow to be non-visible. fantasai: That should be fine. Right now we don't have a way of saying I want to clip only in this dimension. fantasai: This would allow you to combine, you could have hidden overflow in the y and visible in the x, we don't have that. Rossen: I would argue we should extend clip and define it so that it applies to everything and not piggyback on overflow. dbaron: I think if we want overflow: visible in one direction and not the other, it makes sense to not make a BFC. I suspect webcompat will let us not extend and we'd need something new. <tantek> agreed with dbaron about clip compat Rossen: Do you know how much of a compat issue this is for you? Because we haven't done this. dbaron: We haven't implemented and I don't think anyone has. Its been out there for years so I think there will be breakage. fantasai: 'clip' could apply to more than abspos if you made the rect value not apply. fantasai: The rect notation is very awkward so the other ways of spec clip paths are better and if we had those they could apply to all. Rossen: So if we're talking about clipping, let's make it part of clipping not overflow. Florian: Stepping back, one of the reasons of introducing this, when you do contain: paint it would do a number of things including something like overflow: clip but it wouldn't go through the overflow property, so you couldn't have resize apply to that. Unless you turn it to hidden or auto, but that causes memory allocation to go up. Having contain: paint do overflow :clip through the overflow property is part of the justification for having this. Florian: If we have the ability to be overflow-x: visible and overflow: clip the resize property doesn't make sense. We used to have a note that this is an oops and we need to fix it, but we removed it because we didn't think it would happen. Rossen: Do you think this would change if we define it on the clip rather than the overflow? Rossen: I have overflow: visible in both directions and have clip: bottom... Florian: There would be a compat issue if resize starts to work when overflow is visible. There may be things that depend on it not applying. Florian: We could define to do something sensible when you have visible only in one direction. That could be an expansion to the spec. Florian: If you say resize in both directions, but only one is visible, the other is clip, then I don't know. Florian: It's not a case that's been possible before. Maybe you can do in both directions if it's something other than visual. It's a bit more complex than saying it's the same as hidden without scrolling. Florian: To do as fantasai said, this would be possible. Rossen: My pushback is I'd prefer it to be part of clipping. The overflow has already happened. If the floats that are overflowing have already affected the contents, it means it happened. Florian: I think it's going to be a problem to go through clip because if you're trying to contain: paint and resize. You do contain: paint because you don't want a large buffer. If you're in overflow: visible you can't have the resize apply. And then you have to flip and you end up with the buffer and possibly scroll bars. fantasai: I think a more common case is wanting to have text overflow apply and the ellipsis set. Florian: Yes. Same problem. Rossen: This is a use case for overflow: hidden Florian: Yes, but it brings in what you didn't want, scrolling. Rossen: You're describing to me having an additional scroll/no scroll keyword to overflow: hidden... Florian: Yes, I'm just calling it clip. I'm happy to call it hidden-no-scroll except that it's long. Rossen: And that comes with all the BFC-ness etc. It basically clips on both sides. Florian: Yes. Florian: So if we rename you find it more acceptable and leaves 'clip' for another property? Rossen: Correct. Florian: I'm okay with that. Rossen: Are you defined those as part of UI4? Florian: Overflow spec. Rossen: Oh, okay, <tantek> yes we decided a while ago to move overflow properties from UI to another spec, except text-overflow. Florian: And in containment when it comes to computed value of both properties. Rossen: Right, right, okay. Florian: I think Rossen and I are on the same page. fantasai: I'm a bit less sure. Rossen: What if you did the changes and we can discuss more on the list or at a call? Florian: I'm okay with that. I'm not editing clip property's spec so the part that is done through the clip property someone else will need to do the edits. I'm happy writing something. For overflow I can spec and discuss again. Rossen: Cool. smfr: Is it accurate that you're suggesting a new hidden-no-scroll because for some UA hidden makes you scroll and allocate resources? smfr: I'd argue that's an implementor issue. If the hidden is never scrolled, the UA doesn't have to allocate resources. Florian: It's the same nature as the will-change. You could get around it, but in practice people don't. So let authors be explicit we have a value. Rossen: I'm fully...I agree with smfr. If we're talking about the heuristic, you would create all the scroll handlers and objects the first time you request to scroll from script for overflow: hidden. Going into the behavior where users explicitly want to prevent scroll, like you're doing layout behind the scenes, for that I can see a better argument. Rossen: What I'm hearing is the motivation is the performance. And a new value for that is overkill Florian: I understand your point, but why is it that having a new value for this isn't good, but will-change is fine? They are the same kind of thing. Rossen: I've never said I was fine with will-change. Florian: For me, I'm not the biggest fan, but if we're going in that direction this makes equal sense. Rossen: But piggybacking on...I'd prefer to follow the good examples. <vollick> I tend to agree with smfr as well. Rossen: Back to your topic, do you...I don't know where we stand. Do we want to discuss more on the ML when TabAtkins can contribute? Florian: I think we have two reasonable ways forward. One is to have hidden-no-scroll and contain: paint can invoke that or it just invokes hidden and you can scroll. I'm okay with both. I'm not okay with contain: paint doing the magic clip and it's not accessible manually <fantasai> +1 to what florian just said Florian: If contain: paint will do something to overflow, I want it to affect overflow. smfr: Can it not select clip-path? Florian: Then you can't use the resize which depends on it not being visible. smfr: It allows resize? Florian: contain: paint does not in itself prevent resize. The thing is if it is just like overflow except not through that property then that it's not through there means you have to set overflow to get the things that depend on that and if that affects speed it's no good. Florian: So I think given the situation we're in it's too early to write a spec, but I can write a new summary that says can we have good enough heuristics and is this important enough. Florian: And if I'm missing something, you can reply to that e-mail. Florian: Does that sounds like a decent path forward? Rossen: Sounds good. smfr: I think so. ACTION Florian write a summary e-mail about the discussion on overflow: clip to move the conversation forward <trackbot> Created ACTION-701 <vollick> Fighting with webex a bit. It feels like the efficiency of overflow:hidden should, as smfr said, be a UA concern. If we want a will-change style hint to say that we won't scroll, could we tie this hint to will-change explicitly? <tantek> ooh good question. is there an existing table we can use and extend? Variants of pre-wrap and longhands of the white-space property -------------------------------------------------------------- <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jun/0099.html <tantek> pre-wrap is one of my favorite CSS features :) Florian: At the F2F we discussed changing pre-wrap and allowing some of the current implementations in through pre-wrap-auto Florian: We also said in level 4 we would add pre-wrap-trim Florian: We're explaining these in terms of white space, but in level 4 of text white-space is a short hand and I'm not sure how to split these between the longhands. Florian: That's what this mail is about. Florian: The longhands are text-space-collapse and text-wrap. One option is to say text-space-collapse is the weird one. Or we can go the other way around and say that text-space- collapse is normal and text-wrap is weird. Florian: I can see a lot of options and I'm not sure how to proceed. If anyone has a feeling on how to split these I'd appreciate input. plinss: Anyone have anything? Florian: I can be more specific, but I'm not sure it's easy to think through by listening. Florian: I have one question. This white space property now that it's a long hand: is text-space-trim a longhand of that? fantasai: I can't because it doesn't inherit. Florian: Okay. That means option 3 in my e-mail is eliminated. Florian: This pre-wrap-auto and trim are difficult because wrapping and collapsing aren't entirely orthogonal. That's why it's hard to say on which side of the longhand. fantasai: We could give up on the longhand? Florian: That's the new option 3. Florian: I can define options 1 and 2, but it feels weird. I'm not sure of how the implementation is actually done, but I think it's multiple stages and when you think of it as stages the property can influence multiple stages. If you don't care about stages, I can describe it and I have a preference. Florian: I think if fantasai can reply to my mail, if we can agree we can ask the group it it's fine. fantasai: It looks like a situation with no good option, but okay. Florian: Okay. You have the URL, we can move forward. Florian: I'm happy to spec both, but I'd like an opinion on which way. plinss: Okay. bikeshed user-select: element ----------------------------- Florian: It had this name, element, for no longer relevant history. The behavior IE and everyone else has in text areas. If you select within the element you can't select outside the element. It's strange. I'd rather a new name. Its compat risk is much smaller than other values so I think we can rename. Florian: I'd like 'contain'. Is that okay? smfr: webkit implements this. The use case we had is we wanted an element to select atomically. Our interest was outside-in selection. Florian: Atomic selection is something we have and it's user-select: all smfr: Okay, maybe I'm mis-remembering. tantek: But you're right, that was the original intent, it's just not needed. Florian: And I think it was originally more complicated, like selecting one and not several elements in a drop down which is a different kind of selection. * fantasai is pretty confused at this point Rossen: I honestly don't remember the history. Rossen: If we're okay to wait for next week so I can discuss this and look back, I'd prefer to do that. Rossen: Is that okay? Florian: Yea. plinss: We'll defer then. That's the top of the hour. <glazou> bye plinss: I'll be gone the next two weeks at F2Fs. Try not to have too much fun without me. Follow-up conversation on IRC about user-select: element ----------------------------- <Florian> user-select (way back when) used to do several things. Selection as we mean it today was one, but deciding whether you can pick only one (like radio buttons) or several (like checkboxes) in form controls was another goal. radio buttons was called "element" and checkboxes was called "elements" <Florian> this was also supposed to apply to dropdowns <tantek> Florian, also list view <select> elements <tantek> where you could either select *one* <option> inside, or multiple <option>s inside <Florian> indeed. <tantek> the point was to be able to rebuild that behavior out of any elements <tantek> rather, to be able to specify that behavior via UA stylesheet <tantek> rather than HTML magic <tantek> on selection/option/input <Florian> The modern incarnation of user-select does none of this, but the "element" name has been repurposed to something else. The something else is a useful thing, but the name "element" is not a good match for it. <Florian> for what the property and value do now, I'd rather call it contain. Element is confusing, as evidenced by smfr, who thought it meant "select the whole element" (which is what the "all" value does). <tantek> no smfr was right <tantek> it's just that you two disagreed on outside-in aspects vs. inside-out aspects <tantek> or had different assumptions thereof <Florian> well, smfr was right that it is one of the things this value used to do, but he was wrong in that the value webkit implemented to do atomic selection is not this one. <tantek> user-select was always intended to affect how selection of stuff *inside* the element worked <tantek> but seems to be have been re-interpreted as how selection of the element itself works in its parent context <tantek> "all" is atomic on the outside. element / elements is atomic on the inside. <tantek> they're both "atomic" selection variants <TabAtkins> ...lolwut (re user-select being used to do radio/checkbox) <TabAtkins> That's nowhere near sufficient to model them. I know, I wrote the spec to do so. <Florian> element in the old spec was that. element as currently shipped by microsoft (and the css-ui-4 spec follows that) is not. <Florian> The new incarnation of element is not about atomicity. It simply says that a selection that starts inside an element may not escape it. but you can still select only part of that element. <Florian> I am not debating whether or not the old version of user-select matches this model, since nobody is implementing (or planing to implement) the old version of user-select.
Received on Thursday, 9 July 2015 12:12:19 UTC