- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 1 Mar 2017 21:31:17 -0500
- 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. ========================================= Percentage [max-]width|height and intrinsic sizes ------------------------------------------------- - dbaron will review and comment on the issue. What are "form controls"? / Define interaction of display:contents and replaced elements ------------------------------------------------------------------ - The topic of "what are form controls?" was deemed too large and undefined to take up telecon time right now, but the smaller issue around display:contents could be addressed. - There were three proposed solutions: 1) Treat all the types as stripping off the one box. 2) Treat all of the types as doing display:none when you do display:contents. 3) Do display:none on form elements and box stripping on others. - RESOLVED: Have display:contents treated as display:none for replaced elements and form controls. Use flex-order first or document-order first item's baseline? ------------------------------------------------------------- - RESOLVED: Take the visually first line when considering baseline alignment in flexboxes. Percentage [max-]width|height and intrinsic sizes ------------------------------------------------- - gregwhitworth was actioned to check web compat on fantasai's proposal (captured here: https://github.com/w3c/csswg-drafts/issues/765) abspos flex/grid item "align-self: auto behaves as start" spec-text is too vague ------------------------------------------------------------------- - RESOLVED: align-self:auto and justify-self:auto still look at parent's align and justify items for abspos when calculating static position only. Renaming stroke-* in paint -------------------------- - smfr indicated Apple's intent to implement fill and stroke, so TabAtkins and fantasai will put a high priority on making the Paint spec ready for a FPWD. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2017Mar/0000.html Present: Rachel Andrew David Baron Bert Bos Bogdan Brinza Tantek Çelik Dave Cramer Alex Critchfield Elika Etemad Simon Fraser Daniel Glazman Tony Graham Dael Jackson Brad Kemper Ian Kilpatrick Chris Lilley Peter Linss Myles Maxfield Michael Miller Anton Prowse Liam Quin Melanie Richards Jen Simmons Geoffrey Sneddon Alan Stearns Lea Verou Greg Whitworth Steve Zilles Regrets: Vladamir Levantovsky Simon Pieters Scribe: dael Use flex-order first or document-order first item's baseline? ------------------------------------------------------------- astearns: Tab you were looking for interop? TabAtkins: I didn't do that yet. astearns: Then let's table. <fantasai> I think more than interop, need to consider logic <fantasai> commented in bug <fantasai> Proposal is in the last comment <fantasai> need WG approval to try something that's not interop but more sane <fantasai> astearns, ask if there's any objection to last comment in first issue? <fantasai> astearns, in which case we can resolve it Percentage [max-]width|height and intrinsic sizes ------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/765 astearns: dbaron, you were volunteered to talk on this. dbaron: I'm not sure how ready this is for telecon. I missed the proposal on the issue. astearns: Can I action you? ACTION dbaron comment on the percentage [max-]width|height and intrinsic sizes thread <trackbot> Created ACTION-833 What are "form controls"? / Define interaction of display:contents and replaced elements ------------------------------------------------------------------ <astearns> https://github.com/w3c/csswg-drafts/issues/1024 TabAtkins: Still the question on if this is the definition or the max-width...which issue? dbaron: The display:contents bit I think was a different github TabAtkins: 540, yes (https://github.com/w3c/csswg-drafts/issues/540) dbaron: Right. dbaron: We have this historic problem that CSS meant to treat form controls as replaced elements but then we applied a bunch of css to form controls so we now have this world where each one is half way between replaced and controlled by css and each is different. * tantek agrees with dbaron's summary dbaron: We need to go through list of form controls and say which one counts as replaced and which doesn't. There might be a good general definition for 80% but I'm skeptical on 100% having a good general definition. TabAtkins: In general I agree with the outline of the problem. Which topic do we want to try and discuss. Sizing in certain circumstances? display:contents? other stuff? dbaron: I think this is complicated enough it should be offline for a bit. dbaron: Unless there's a particular topic. <fantasai> I don't think defining what a "form control" is is something we can resolve atm, but 'display: contents' issue is important <fantasai> max-width issue is the 2nd issue on the agenda, that astearns skipped over. I think it is prepared enough for wg discussion right now TabAtkins: Percentage max-height|width is more relevant. We should be consistent on display:contents soon as browsers are intending to ship. TabAtkins: display:contents might be easier since you posted a detailed comment. You had the 3rd option of run display:contents literally for form controls. Remove the box and treat children as normal boxes. * fantasai I think the 3rd option is totally sensible here dbaron: That avoids the problem and seems like a reasonable behavior. TabAtkins: I don't agree it will be useful as only some form controls have children. Having options as you strip away doesn't seem all that useful, but I guess it's fine. There's a lot of form control behavior that becomes unclear. astearns: Would you get different boxes for same form control in different browsers? TabAtkins: No. You would pretend the form control element wasn't there and it's children as just present. <gregwhitworth> that's not actually true - for example our input will have a clear box - where as Chrome/FF/Safari will not <gregwhitworth> select should be pretty uniform dbaron: Proposal was that display:contents on a form control is that the form control loses it's replaced magic and you display children on normal css rules. TabAtkins: So stripping a select would be a bunch of option inline children. <tantek> kind of like how alt text is displayed as normal inline when an img fails to load. dbaron: However options display not in a select. From CSS it's straight forward. It's not well spec what aspects of form controls are associated with DOM and which with box. <gregwhitworth> 100% what David said TabAtkins: Do the options in select...are they still selectable? TabAtkins: Is there a behavior distinction between select multiple and single? That's the hard part. tantek: As soon as it's replaced by plain text or content it loses it's special behavior. This happens with images when the alt text is rendered. You can't drag and drop, but you can select the alt text. It's a simple answer, if not ideal. TabAtkins: But then you can't walk the DOM and submit a form. You can't walk the DOM and find the select, you have to look at the presentation layer. <gregwhitworth> this sounds messy IMO tantek: Technically that's not the same. We could draw a distinction between user interaction behavior and submit behavior. It's not ideal. TabAtkins: If we strip the select you couldn't click on an option to change select index. tantek: Yeah. It loses it's UI behavior. TabAtkins: Seems not crazy. * fantasai just wants a spec that's 100% defined and not a side-effect of Gecko's nsCSSFrameConstructor tantek: For DOM and form submission it would behave as-is in the DOM. tantek: It's not ideal, but technically you can separate those two. TabAtkins: Okay. I like it better then what I thought you were saying. I think we can define that generically in a reasonable fashion. astearns: Does that mean we define as replaced elements when using display:contents lose their replaced behavior? <fantasai> "Replaced elements no longer replace their content, but instead that content is displayed according to the usual CSS rules" TabAtkins: If we wanted generic over all replaced we have to accept this has consequences with object. Or we can acknowledge that the children are css-y and that's why it works normally. astearns: We'd have to display what form elements are to have an order of this. TabAtkins: Sure, but CSS wouldn't care directly. It would have an extra category that the host link would define. When you display:contents if they have a special rendering normally their children become normal boxes. TabAtkins: We can define that category. THere's still more to answer like how they work in layout, but for this situation we can do it generically without a lot of effort <fantasai> Alternate proposal: replaced elements do what was just suggested, but form controls (defined as anything that could potentially submit in HTML), behave as display: none fantasai: I'm a little skeptical about how we'd define event handling and interaction for form controls. Possibly it's straight forward, but I'm not certain. And what aspects of styling and interaction are inherent to the form element. <gregwhitworth> I'm fine with them behaving as display none fantasai: I think this makes sense for actual replaced elements. Taking away the box and showing contents is fairly straight forward. But for form controls I think we can say they display as display:none. Saying they all disappear entirely is simpler to understand and define. And form control is anything capable of submitting html. TabAtkins: This seems backwards. The elements more similar should be treated odd, but the things further from normal would act normally. fantasai: I see replaced objects like videos as more normal than form controls since the idea was control would define how replaced elements work. fantasai: They don't have elements that are children that themselves have special behavior that only make sense as being part of the outer element. <rachelandrew> the solution fantasai is suggesting makes sense to me, doesn't seem weird. <smfr> what about <input type=“text” style=“display:contents”><div> children</div></input> smfr: Do we expect orphans will want their own children in form controls? Or only content the UA creates will show up? TabAtkins: HTML parser doesn't let you put stuff in form controls, though DOM APIs do. It's not expected people put things there on purpose. It's defining how this error case occurs. dbaron: You're thinking people might use the dom to do things like that. dbaron: I think that might be okay too. * glazou notes editors like CodeMirror are based on that rachelandrew: What fantasai is saying makes sense to me. Authors see form controls as weird anyway so saying they have the display:none behavior makes sense. TabAtkins: They're weird, but they act like they have children. Replaced elements have 0 children and are a black box. That's why it's weird to me that this thing with no children can display children. <dbaron> there might be an advantage to making them less weird, though... fantasai: That's not true. When the image fails to load you display the contents of the container. rachelandrew: It maps to how authors using this stuff think about it. tantek: I disagree with fantasai generalization that replaced elements act in a consistent way. That's false. Image, object, and video behave completely differently in regards to their children. tantek: Trying to lump those together...they behave differently. TabAtkins: Her point is the video element where its children are just info sources vs a select where the options have a behavior. They interact with user interaction. Her point is there's more magic in that options are now normal vs tracks are normal. <fantasai> thanks, TabAtkins :) That was a clearer explanation than I would've managed tantek: Object is between those two. It does do special things based on if browser supports etc. TabAtkins: It does fallback. There's no interaction on the normal behavior. You treat it like it's doing fallback. I think we should be consistent with replaced where they all strip one box or all display:none. tantek: I'd like image and object to be treated the same and strip away one box. <gregwhitworth> And what happens when the children boxes vary browser to browser? That sounds like a testing nightmare. <gregwhitworth> should not be - doesn't mean they won't TabAtkins: I don't think there's use cases for any of these. We're defining least intrusive option. dbaron suggests doing it literally is the least intrusive. TabAtkins: I'm support it on that frame, not on terms of usefulness. People shouldn't display:contents these. tantek: For object the use case is to force the fallback to show. <fantasai> tantek, that is the effect, yes TabAtkins: There is no use case. We're defining based on it needs some behavior and we need the easiest. What sounds easy isn't easy architecturally. Stripping a level is a little easier. TabAtkins: If you bring up use case you're arguing wrong. It's a corner case. fantasai: It has the effect and if it's useful, do that. But we're not going from a use case here. <tantek> I'm ok with treating things simply (architecturally) as a first cut and see what unexpected things happen, and then address those as needed plinss: Every single time in the past where we define a corner case by whatever is easiest it's come back and bitten us years later. astearns: We have 2 proposals. 1 is treat all these as stripping out one box which will cause a bit more spec pain as we'll have to define what that means for all of these things. Other proposal is treat all of these as doing display:none when you do display:contents. It seems simpler to spec and communicate. <gregwhitworth> It also makes it much more obvious to the author that there's a problem astearns: Because it's a corner case we're not looking for utility so the display:none might be easier because we don't know side effects. <dbaron> I think I'm OK with the display:none thing; at the very least it (so far) has a lot fewer problems than the original display:inline solution. fantasai: 3rd was display:none on form and box stripping on others TabAtkins: I believe that's the worse astearns: I'd rather a consistent story on the edge cases of display:contents <tantek> I thought I heard that "stripping off the one box" was the simpler architectural option? <fantasai> tantek, it's tricky to define for form controls I think astearns: And tantek mentions that stripping one box was simpler architecturally. dbaron: It's much simpler then display:inline thing. This started as we wanted to make it display like and then compute to display:inline astearns: And that's off the table. <tantek> ok it sounds like convergence is happening, will wait it out and see what people say <gregwhitworth> We can reference HTML5 for "form controls" right? If you have a new one that is proprietary we don't need to spec that. <fantasai> gregwhitworth, technically "form control" isn't dfn'd but I think we can define it relatively simply or ask HTML to do so <gregwhitworth> fantasai: 👍 astearns: Does anyone disagree we're down to display:none or strip one box? [silence] astearns: Does anyone have a marked preference between them? <tantek> I know we're not arguing usefulness/use-cases, BUT I have a slight preference for strip one box for that reason (e.g. object) TabAtkins: I believe FF dev expressed a preference for stripping a box because display:none is still not trivial. dbaron: Emilio's second comment? TabAtkins: Yeah. dbaron: I'm not entirely sure what he was thinking about but I'm not sure it implies it's easier. TabAtkins: Okay. <dbaron> (emilio's comment being https://github.com/w3c/csswg-drafts/issues/540#issuecomment-281875695 ) astearns: So there's slight preference for strip one box. We could try spec this and go through repercussions of that. astearns: I have a feeling we will run into similar problems as we did for inline. dbaron: I'm fine with going with none. I should ping Emilio. <tantek> I think fantasai provided the two key examples that help make strip one box doable. e.g. img does not display alt, but object does display its contents <tantek> seems like all form controls fall into one of those two categories <tantek> empty or not? <gregwhitworth> I would prefer none - stated it before but I'll say it again :) TabAtkins: Do we tentatively resolve and if there's evidence to the contrary we can re-open? astearns: Objections to display:none for items with display:contents? <dbaron> And I'm fine with "treated as display:none" -- "computes to display:none" would be problematic. fantasai: I'd like to gear from rachelandrew <tantek> do we have objections to strip one box? rachelandrew: It seems okay. It's a corner case and we need something to explain. astearns: Proposal: have display:contents treated as display:none for replaced elements and form controls. astearns: Objections? <tantek> no objection, but seems like we're throwing away an opportunity oh well RESOLVED: Have display:contents treated as display:none for replaced elements and form controls. ACTION dbaron to ping Emilio about the have display:contents treated as display:none for replaced elements and form controls resolution <trackbot> Created ACTION-834 Use flex-order first or document-order first item's baseline? ------------------------------------------------------------- fantasai: I have data that's not compat data, which is about what is the point of the feature. I think we need to choose visually first. fantasai: If you're reverse ordering a column flexbox then you're choosing first baseline on an element that's potentially in the middle. If the goal is visual alignment of text then you need visually first baseline. Regardless of the interop I think we need to go with first visual box for first-baseline and last for last-baseline. astearns: I'm confused about the element in the middle. <gregwhitworth> an int is used on ~1.3% of sites crawled: https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/order/ <gregwhitworth> granted this doesn't determine if they care about baseline alignment in these cases fantasai: Suppose each box has 10 lines of text. We'd be taking the 21st line of text as the "first line" to align to. This makes no sense. TabAtkins: If you do it with order and move things you'd take visually the first line. It's taking flex direction into account as well. astearns: I'm happy going with visually first line. astearns: Proposal: take the visually first line when considering baseline alignment in flexboxes astearns: Objections? RESOLVED: Take the visually first line when considering baseline alignment in flexboxes Percentage [max-]width|height and intrinsic sizes ------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/765 fantasai: There's an interop case where if you have a replaced element with a width or max width in percentage we take the intrinsic size contribution to be 0 or as close to 0 as you can get on form controls. dbaron: Not all form controls, just text area and input-type is text and only the width thing, not max-width. fantasai: To get interop into spec we'd have to say all replaced elements get max-squished if the width is % unless it's a form control where we only look at width. Max-squashed you take whatever the percentage resolves to. fantasai: Issue I find is doing this special case for width, but not max-width for input when doing both for images seems inconsistent. dbaron: This is a thing where we imitated this quirk for web compat. fantasai: I understand we want to be close to what's there, but do we have to not do this for max-width on input and text-area? If that's not a web compat requirement we can do these things but have rules for images and inputs the same. I want to put it to the WG, but I don't expect answers right now. fantasai: Was that clear? astearns: I'm not following, but I wouldn't have the data you're looking for. fantasai: It's summarized with a test case in the last comment. astearns: What do we do next? fantasai: Impl need to review and see if they find it acceptable or if it will result in web compat. astearns: Can I get impl besides dbaron to volunteer? astearns: gregwhitworth? I'd like you to look from Edge. ACTION gregwhitworth to review #765 in github <trackbot> Created ACTION-835 abspos flex/grid item "align-self: auto behaves as start" spec-text is too vague ------------------------------------------------------------------- <astearns> https://github.com/w3c/csswg-drafts/issues/440 <astearns> https://github.com/w3c/csswg-drafts/issues/440#issuecomment-280459999 fantasai: There was a comment here. fantasai: from TabAtkins. fantasai: Issue was Christian raised a concern about the change in behavior from when we worked on align. We realized we don't have align self to take the align item value of the parent because it may have nothing to do with layout. TabAtkins: One step back: the behavior before alignment spec when you have abspos when you set top right bottom left it fills the box. We've now tied that to the stretch behavior of align & justify self. If you don't want that and want to center the abspos you can set top right bottom left to 0. So auto looks at the parent for align or justify items. TabAtkins: If parent is a flexbox, but the abspos containing block is further up the tree and is entirely manually positioned you'll get a weird effect where flexbox's align items changes how the abspos is rendered. It's mysterious and shouldn't have this effect. TabAtkins: We tried to break that but we probably go too aggressive and made it no longer look at parent for static pos. TabAtkins: We can probably make this more subtle so abspos with align-self:auto doesn't pay attention to parent for normal alignment, but will for static pos. fantasai: Did anyone follow? gregwhitworth: You wont be changing static position again? TabAtkins: It wasn't intended to change static position. TabAtkins: Goal of the edit was to remove the weird parent. The change was more aggressive then intended. I can do a carve out that does this properly. gregwhitworth: Sounds good. fantasai: 3 behaviors: align-self had no effect on abspos unless effects static position of an abspos that happened to be a child. So it would have a side effect of setting the static position of the abspos if it happened to be a child. Then we had this super weird thing where it ended up doing unexpected alignment. So then we said abspos don't look at parents, they're always normal. Then Christian said it changes the behavior of the static pos. fantasai: So we can say when it's abspos it's just normal, but we can fix it so that static isn't changed. fantasai: Proposal: Static position of a child abspos of a flex container is calculated with align-self looking at align items even though the abspos normal alignment calculations don't do that. TabAtkins: Align-self:auto & justify-self:auto still look at parent's align and justify items for abspos when calculating static position only. astearns: Objections? RESOLVED: align-self:auto & justify-self:auto still look at parent's align and justify items for abspos when calculating static position only. Renaming stroke-* in paint -------------------------- <smfr> https://drafts.fxtf.org/paint/ <smfr> https://drafts.fxtf.org/paint/#perfect-world smfr: I want to note apple has interest in fill and stroke. smfr: We need Japanese captions which use stroke on a text and we'd like to use these standard properties. We'd like this draft to move forward. We want to talk about if we should accept the rename in 3.7 which is perfect world syntax. We don't want to lock into old names and we want to impl soon. TabAtkins: fantasai and I plan to spend our work week in March finishing this and making it publication ready, now that you have interest smfr: We have implemented paint-order so we need to put it here. There's a stroke-align property where the request is it goes on the outside of the glyph. It's hard in the graphics engine. Easier to pop the fill on top of the stroke. So we've impl paint order. TabAtkins: Only works for opaque text, but that's the common case smfr: Absolutely. smfr: One other things, I'm not sure it specified if you have fill-color and color. TabAtkins: Color becomes like svg where it just sends the current color. It becomes an information channel. smfr: So color: red fill-color: blue TabAtkins: You get blue text. smfr: So fill-color is more specific and wins? TabAtkins: Color...we're filling in a previously unspecified property. It was previous un-specifiable so it was currentColor. Now we can spec. astearns: We're at the hour. Great that we'll get more work on the draft. Let's continue these discussion as topics come up. Thanks all. <fantasai> yeah, finish off this FPWD has been on our to-do list for awhile, just finally getting around to it now that Grid is mostly stabilized :)<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color: #4453ea;">www.avast.com</a> </td> </tr> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>
Received on Thursday, 2 March 2017 02:38:42 UTC