- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Aug 2016 21:35:08 -0400
- To: 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. ========================================= CSS Pseudo Elements & CSSOM items --------------------------------- - RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom) from the current level 4 draft and move the work to Houdini - Rossen was actioned to open an issue on Box 3 for Houdini Should Device Adaptation include a normative definition of <meta> viewport? --------------------------------------------------------------------- - RESOLVED: Change the <meta> viewport text to normative and add two issues. One to test if the description matches reality. Second is while we spec with the same mechanism there may be differences as we tease out compat. box-suppress name and shorthanding relationship to 'display' ------------------------------------------------------------ - RESOLVED: Make display into a short hand and add an issue on naming for the long hands. Overflow: Consider support for overlay scrollbars ------------------------------------------------- - Florian brought his proposal to create overflow-style: auto|auto-hide|overlay to allow authors more control over scrollbars while balancing out the desires of implementors to control their scrollbars. - There was a feeling that this was still too problematic and auto-hide and overlay should be merged into one value that behaves depending on the platform behavior. - The group was heading in the direction of creating value that reserves the same amount of space whether the scrollbar is shown or not in order to solve the re-layout problem, but ran out of time so conversation will continue on github. ====== FULL MINUTES BELOW ====== Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Bert Bos Dave Cramer Simon Fraser Tony Graham Dael Jackson Brad Kemper Peter Linss Michael Miller Anton Prowse Florian Rivoal Jen Simmons Alan Stearns Liam Quin Ian Vollick Greg Whitworth Steve Zilles Regrets: Tantek Çelik Daniel Glazman Chris Lilley Scribe: dael CSS Pseudo Elements & CSSOM items --------------------------------- <astearns> https://drafts.csswg.org/css-pseudo/#cssom astearns: Let's get started. astearns: Does anyone have anything extra to add to the agenda? astearns: This is a hold over from last week as to if we should drop the CSSOM part. Florian: Should move to next level. astearns: There isn't one. My preference would be if we drop we start a new level so that it has some place to go. We know we need to work on it. fantasai: Given that the whole section is a bunch of issues including design level issues I would prefer to leave it as an open issue on the issues list and link it to whatever proposals we have. This is on the TR page. We can have it as an open issue on github. fantasai: If someone wants to go through it and create a real proposal I'm happy to keep it or have it in 5, but if no one is going to work on it I'm inclined to that. astearns: There's working on the API and working on implementing any portion. fantasai: If the API is close I'm happy to hang on to it, but based on the issues it seems like a random proposal that as the spec author I'm not sure is a good idea. It may lead people wrong or in a specific direction when we don't have one. Florian: If this is so vague how is it under TR? fantasai: It was somewhere else and when I drafted pseudo elements it got scooped in. astearns: I think it was always in pseudo elements and we removed other even more unlikely things before TR, but this was left. fantasai: If someone wants to work on it or has reviewed it and think this is a good general approach I'm fine. Florian: If we move entirely off the spec to an issue in github... it's not one big issues it's a set of things. If we collapse that to one thing it stifles the lower level issues. fantasai: I think to address the lower level we need to do the higher level of is this even what we want. Picking the paint before you decide you want a house instead of a school is a bad idea. Florian: Or you can flesh it out and see if it makes sense. astearns: The issue about not sure on direction I wanted someone besides me to look and see if it's the right direction and that hasn't happened. Is anyone besides me interested in working on this section? * TabAtkins has too much stuff on his plate, tho he's interested. Florian: Theoretically...I haven't reviewed it...but there's another bit of OM stuff which is how pseudo elements and the selections OM work together. Does it have anything about that? fantasai: No. For selections a lot of that is covered in other OM specs. Florian: Currently just it's not possible. But that's a problem. astearns: The current bits of the OM are about accessing the pseudo element. It's a first step. Rossen: I joined a bit late, but did you discuss moving it to Houdini? This is fairly applicable type of functionality we're doing there. Like exposing boxes and stuff not backed by DOM elements? astearns: Perfect timing. I was going to bring that up. Rossen: I'm interested in working on it, but that's my preferred path. fantasai: I'm fine with that. Florian: As to interested, to the extent this allows selections on pseudos I'm interested. astearns: Let's resolve on removing this from the current level 4 draft and moving the work to Houdini. Objections? RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom) from the current level 4 draft and move the work to Houdini <dbaron> Is it going to move to an actual document in houdini? <TabAtkins> Well, I think it'll move into a new WICG repo with the intention of it "maturing" into Houdini. Florian: Does Houdini inherent the context of relationships with other groups from CSSWG? astearns: My assumption is inherit from CSS relationships. Florian: So we can talk to everyone. astearns: Which Houdini doc does this move to, as dbaron asked? Rossen: I would assume this is the Box 3 spec that doesn't have anything actionable. But bringing in something like this would make it actionable. So I think Box 3 spec. astearns: Could I action you to open an issue on the Box 3 spec? ACTION Rossen open an issue on Box 3 spec to include the pseudo information Should Device Adaptation include a normative definition of <meta> viewport? --------------------------------------------------------------------- Florian: Background: There's 2 theories on setting the viewport size. The widely deployed <meta> viewport and CSS's @viewport. <meta> came first, @viewport was a response. Florian: <meta> viewport doesn't have a normative spec. There's an informative section in @viewport with a fairly detailed description. Florian: The first point is I think there should be a normative description for <meta> viewport. Second item is, is this the right place to do it? To say that you have to understand the spec. It describes a concrete CSS syntax for @viewport and a separate section called constraining procedure that says once we have values how does it effect the @viewport. And another section for if you have <meta> viewport how does it translate. Florian: How @viewport was defined it's a bit short of <meta> viewport. Florian: First I'd like to hear if people want a normative description. If yes, should we take the small extension to the abstract and include it in the main. Turn the informative section into a normative section with a disclaimer that if there's discrepancies they should talk to us. Florian: I have other things, but I'll let others express thoughts first. <fantasai> I'm in favor of having a spec for this thing somewhere, and this seems the best place. dbaron: I think...I couldn't quit hear... <meta> viewport has quirks that may or may not be copied to @viewport. We should make explicit decisions on that instead of assuming one thing or the other. Florian: I think this is a fair point. It's possible the description is out of date and there also may be quirks. We should put an issue there. Anyone can dive in and try to ID which parts are good, which is odd, what's universal. There's a fair amount of testing in the wild, but not our format. The knowledge should be out there. Florian: I'm saying we flip from informative to normative and add prominent issues. astearns: This seems like the right place to put this info, so I'm in favor of Florian's proposal. <fremy> Florian: +1 Florian: Two other things. There have been some discussions as to if the @viewport syntax isn't pre-loader friendly. Also maybe that it's needlessly expressive. This isn't in contradiction of what we've said now...this isn't about the mechanism behind it. We may change the @viewport rule syntax later. But since syntax and how it works is spec separately it shouldn't effect our discussion, but it's worth pointing out. bradk: Can the <meta> be normative and deprecated? It's there for compat but we want @viewport to take over for authors. <astearns> probably a bit premature to deprecate anything Florian: Maybe. The concerns about <meta> being preloader friendly and @viewport isn't so I don't think there's universal opinion to phase out <meta> viewport. Eventually, but the time isn't right. bradk: It's odd we're specing HTML. Florian: Yes, but what that thing does is about layout and viewport. bradk: But we don't spec font tags. Florian: No one specs this. There's already a description in the spec for parsing. TabAtkins: We're specing a <meta> tag that's an extension tag. It's reasonable for us to spec a given <meta> tag. bradk: You're saying it's not HTML specific. TabAtkins: The meaning of the <meta> values is mostly defined by other specs that are using it as a generic transfer method. Florian: So we have two ways to deal with the viewport, one of which is CSS specific and one is a micro syntax. Florian: Meta is all over the place in terms of deployment. bradk: I understand the need for compat. I have no objection - it just seems weird and backwards looking. astearns: Other opinions? smfr: I'm okay with making it normative. The spec needs to say what happens if meta and @viewport are present. Florian: It does. smfr: The preload problem is serious so I don't think we at webkit would be interested in dropping <meta> until that's resolved. Florian: That doesn't surprise me. smfr: Definitely there's a lot of compat issues with <meta> viewport tag so we have to be careful. Florian: There is a detailed and careful language, but I'm sure the problem space is thorny enough we're missing things. We need to start testing and find where the implementations disagree. I think you should have a quick look, it's fairly decently detailed. I don't think we can get further without poking. Florian: We do have pokers, though. smfr: The parsing algorithm looks like it was reverse engineered. That should be exposed in webkit now. Florian: Fair enough. I don't know if everyone parses the same way. Florian: By saying it's normative I don't expect the definition to be final. astearns: Proposal: add normative text describing the <meta> tag with... Florian: Not adding. Change the text from informative to normative. astearns: Okay. With two issues. One to test if the description matches reality. Second is while we spec with the same mechanism there may be differences as we tease out compat. Is that correct? Florian: Not exactly what I was thinking for the issue, but a good alternative. Let's go with that. astearns: Objections? RESOLVED: Change the <meta> text to normative and add two issues. One to test if the description matches reality. Second is while we spec with the same mechanism there may be differences as we tease out compat. box-suppress name and shorthanding relationship to 'display' ------------------------------------------------------------ <astearns> https://github.com/w3c/csswg-drafts/issues/343#issuecomment-235961589 fantasai: There has been an open issue on renaming box-suppress property. One discussion that came up was that the reason for having the display-or-not property be independent of display was to put a rule for hidden in the UA stylesheet and this would have an effect despite authors having display property in their stylesheet. fantasai: That's probably not something we can do at this point. Hidden is implemented as display: none and authors have adapted to override hidden using something like opacity. So main reason for separation is no longer valid. fantasai: Proposal is to make display-or-not a sub-property of display. fantasai: Other reason for splitting was to make authors not say display inside and display outside separately. We can solve that by having display-as property. So we'd have display with display-type and display-as and display-box or whatever we call that. fantasai: The advantage is we don't have display:none as its own thing that doesn't interact with display or not. fantasai: The disadvantage is authors currently using display won't be able to auto switch unless their selector for that declaration is more specific. fantasai: I think this would be an appropriate use of !important would be to set something like hidden attribute display-or-not: none fantasai: So 1) redo short handing relationship. 2 & 3) name sub-properties Florian: One place I'm not clear. Why do we want to merge display inside and outside? fantasai: Authors want to set them at the same time. Right now display sets inside and outside together which is what you want. display-or-not is a separate property. If we merge it back then any time you say display: table or whatever it resets none to its initial value. Florian: Got you. Florian: Generally makes sense to me. The cascading with !important makes me a little skeptical, but it might be right fantasai: It fits together better. It's mainly historical thing. We didn't have that independent not-none switch. Florian: Okay. I like it. <fremy> @fantasai @astearns: why not extend visibility:collapse, in case this is closer from what we want? astearns: fantasai, did you see fremy comment? fantasai: Partly that's sometimes what you want. This is effecting all media. display: none takes the box from the box tree. Sometimes we want visibility: flat. There's a proposal for hide that keeps the element in the box tree, but not effect layout in any way. The main advantage is it tells you this will be a dynamic thing. fantasai: Another advantage is it keeps track of animation timers. So if you hide and show you haven't lost your timer. It keeps counters in place as well. fantasai: That's just a proposal right now. It would make sense to have that in the display property. astearns: I think this proposal makes sense. As a way to design all these interaction this is the way to go. astearns: I'm wary because we're talking about legacy with display and display property is used EVERYWHERE. fantasai: Existing style sheets won't be effected. If you decide to start using display-or-not property you have to know that rule is more specific. Which you'd have to do anyway. Florian: Or you need to stop using the shorthand and use the longhands. fantasai: Right. The current solution is the make sure your noneness is specific or you use the longhands and shorthands we're introducing here. <fremy> @fantasai People will use libraries which are not compatible, and this will make it harder than it should Florian: I like it. I don't have a good name. <jensimmons> I assume this is all to get us to a place where we have a CSS property to let everyone write one line of CSS to accomplish what the industry does now with a hack — .element-invisible { position: absolute !important; height: 1px; width: 1px; overflow: hidden; clip: rect(1px 1px 1px 1px); } — yes? <fantasai> jensimmons: yes, exactly :) <jensimmons> visually hidden <jensimmons> element invisible <jensimmons> visual display fantasai: We don't have a great name. display-box was suggested. I think there were some others. Anyone with a suggestion please put it in IRC. astearns: display as a short hand...display-or-not is available ^-^ fantasai: This is true. :) * jensimmons thinks ‘box’ is odd. Most people don’t think of these items as boxes, even if technically they are astearns: Objections or concerns about going in this direction? Florian: One question. Where does display: content go in terms of the long hand? fantasai: I believe it's display-outside. It used to be a property on display-or-not, but it's more of a display type then hiding or showing. It wasn't an intuitive decision, but we thought about it for a bit. Florian: Makes sense. Then we could actually use display-or-not even though it was a joke. fantasai: The values on this property have to be about display this box or not. Anything more complex has to go elsewhere. I think about it as display-or-not for that reason. Florian: Do we have other properties that take a boolean? fantasai: This isn't necessarily a boolean. astearns: Proposal: Make display into a short hand and add an issue on naming for the long hands. astearns: Objections? Florian: Ship it. RESOLVED: Make display into a short hand and add an issue on naming for the long hands. Overflow: Consider support for overlay scrollbars ------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/92 <fantasai> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-236550745 Florian: That's me. We've been discussing overlay scrollbar and having control. Different OSes do it differently. There's when it always takes space, it's when they disappear when they're not used. There's desire from authors to control that and desire from vendors to not allow that because you get bad behavior. Florian: There's a third dimension where the author doesn't care on looks, but when you're in an overflow auto situation don't display the scrollbar if not used, but give it space. Florian: The proposal is linked above. Florian: Recycle the overflow-style property with values auto|auto-hide|overlay. Auto is the initial which is follow the style. Overlay requires the scrollbars to not take up space. Florian: Windows has an overlay scrollbar, just not as the default. Florian: auto-hide if you're overflow auto it's the same as overlay. For overflow scroll it does a few things. The space for the scrollbar must be reserved. You take the space for the scrollbar and if the element isn't scrollable you don't display the scrollbar. Florian: Why it's on overflow-style is that these things should cascade separately. The style you want is different than where you want them. Florian: Yea/nay/questions? <dbaron> the 'auto-hide' value seems weird smfr: I think this is still treading on platform conventions. If you have a mouse with a scroll wheel you get space reserving scrollbars. It's also a setting in preferences. Florian: Yes... smfr: I think we discussed in Sydney and this still allows authors to override users scrollbar choices which I don't agree with. Florian: I've tried to minimize that tension. I'm not sure how to provide the things authors want without completely getting in the way of consistency for vendors. astearns: Authors want to be able to say reserve space for the scrollbars so I don't get re-layout. Is that right? Florian: It's one aspect. astearns: There are authors that want to control the scrollbars. Is there a way to give them control without overriding the users? TabAtkins: I think that's what auto-hide does. And I agree with your characterizations. That's what our impl want too, to never have to worry about scrollbars. Rossen: With auto you still have that problem. We had that in older IE where we had the area for the scrollbar reserved for the top scroller. It's weird but I can see why people want it. * jensimmons uses a wacom tablet — in Safari, the scrollbars are the same as when I don’t have it plugged in. In Firefox, it switches to oldschool scrollbars that reserve space all the time & show the scrollbar all the time. Just FYI. (We tripped over this when making a tool for Grid in Firefox, unexpected scrollbars.) Florian: I'm hearing that the way out is to merge overlay and auto-hide and that depends on platform. So it'll either overlay or be space consuming and not appear when not needed. But either way it won't consume the layout TabAtkins: It seems odd. I'd like to pursue getting the width of the scrollbars which is something else people want. But if you can't predict having it you can't control spacing. Having a plain auto-hide that reserves space and we have the other that always shows. So we can guarantee no re-layout and when possible takes no space but we have the always takes space value. Florian: I could see that. <liam> +1 to TabAtkins Florian: smfr would that work? smfr: Let me reword...If the scrollbar is a normal scrollbar, always visible, do nothing. If overlay allows the author to reserve the width of the scrollbar space. TabAtkins: Slightly different. auto-hide value from Florian where you always reserve space for the scrollbar even if it's not drawn. Rossen: So this is like overflow: scroll but up to the platform if you show the scrollbar Florian: It has two differences. On OSs that have overlay scrollbars, they don't consume space. This requires they do. Rossen: No. The size of the overlay scrollbar in layout is 0. You can consume 0. TabAtkins: We're saying you consume the normal width for a non-overlay scrollbar. <bradk> It would require reserved space even when no scrolling is necessary? Rossen: Okay. Now I agree it's weird. TabAtkins: We want to give authors a predictable width that doesn't change due to content or user preference. They have a predictable and usable geometry to work with without something shrinking outside their control * liam wonders whether overlay scrollbars and "traditional" ones are always the same width, and how you know which side they'll be on <bradk> Sounds horrible <dbaron> trying to make something that doesn't change based on user preference is silly when it changes as a function of OS and OS version <fantasai> Why don't we just make this the default behavior of `overflow: scroll`: Don't paint the scrollbar unless it's active. Florian: This could work when the space is 0 and you could reserve that on both sides. Even when it's 0 it visually takes space. Rossen: They only get rendered...in layout they only have render size while you're manipulating the content...while you're scrolling. So it's visible when you have a pointer down. The rest of the time they're not visible. Rossen: But why would you mess up layout for the rest of the time? <fantasai> + MAY make it invisible or semitransparent at other times Florian: You don't mess up the layout, you always reserve. Rossen: I get your point. You want to reserve the space on both sides so when the scrollbar is visible it's not overlaying any of the content. My pushback is for overlay scrollbars they're only visible when you're scrolling and when you're scrolling your not reading TabAtkins: That's why I said a second value is to merge with overlay where it can go to 0 if your platform uses overlay. So that way you have one that's always consistent and one that takes up as much space as it can, but it's predictable so that when scrollbars show up it won't jiggle. Rossen: I got your point. For layout...for scrollbars that do take up layout space this feature makes sense. * fantasai thinks this needs to be written up TabAtkins: I think the first is important; I know a requested use case is for authors to turn on overlay and then reserve the space so that no content is ever covered. So making that easy seems worthwhile. TabAtkins: We can bikeshed over the names to make sure it's clear and they point you in the right direction. But I feel strongly from the use cases I've seen we want both. Rossen: I suggest that instead of a unit we look into something like gutters that we can do by box. Because people will start depending on this. astearns: There's lots of details. We're over time. People want to work on this to allow control of layout, but not scrollbar. Florian: There's two points against the proposal. Overlay needs to change definition which I can do. Second is what we were just talking about. astearns: I think we should continue discussion in the issue. You can propose changes there. We're a bit overtime now. astearns: Thanks everyone. We're done. <liam> padding-left: max(1em, --ui-scrollbar-width) <TabAtkins> liam: My plan is to push for either a `scrollbar` keyword, or better, a `scrollbar` <length> unit. <liam> sounds good * Bert thinks liam may have an interesting way out <jensimmons> yes, let’s not get into giving people the ability to ‘style’ the scrollbars. People want that. People used Flash just to get that. It was a usability nightmare. <TabAtkins> liam: Assuming we get a max(), yeah, like `max(1em, 1scrollbar)` or something. <astearns> liam - please add a comment to the issue <liam> of course, there's likely a user preference or locale setting for whether scrollbars are on left right, top or bottom <liam> ok
Received on Thursday, 11 August 2016 01:36:08 UTC