Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

[CSSWG] Minutes Telecon 2016-08-31 [css-align][css-tables][css-flex][css-values][cssom-view][mediaqueries]

1 message.

[CSSWG] Minutes Telecon 2016-08-31 [css-align][css-tables][css-flex][css-values][cssom-view][mediaqueries]
Dael Jackson   Wed, 31 Aug 2016 20:38:34 -0400

www-style > September 2016 > 0000.html

Received on Thursday, 1 September 2016 00:39:35 UTC

Show in list: by dateby threadby subjectby author

Link to this message in this page.

Sent 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. ========================================= TPAC ---- - A reminder that the registration closes and registration fees go up soon. - gregwhitworth will likely be the one to speak at the dev meet-up and he'll cover topics around Grid. Synthesized baselines seems like a breaking change -------------------------------------------------- - The behavior of what we do when there isn't a natural baseline is inconsistent both between specs and between implementations. - The proposals of what to standardize around were: A. Make boxes without a natural baseline and boxes establishing an orthogonal flow synthesize a baseline. A.1 Base this synthesized baseline on the margin box edges A.2 Base this synthesized baseline on some other box edge B. Make boxes without a natural baseline and boxes establishing an orthogonal flow use start alignment instead of trying to synthesize a baseline. C. Something else. - RESOLVED: Accept option A2 with the modification that we're talking about the border box. Add <number-optional-number> type --------------------------------- - Several people had reservations on adding a new syntax (+#) to make it easier to read a legacy behavior that could still be written as [ <foo>+ ]# - RESOLVED: Don't add any new syntax, just add a note explaining it. Algorithm of `Element.offsetParent` ----------------------------------- - RESOLVED: Adopt the Gecko/Edge behavior and specify that .offsetParent is based on the nearest abspos containing block or table cell Media Queries ------------- - RESOLVED: Accept the proposal (Proposal: Make the device-width/etc MQs use the same concepts as CSSOM is using for returning device dimensions.) - The group began discussing adding device-pixel-ratio but didn't have time to reach a decision - One opinion was that it shouldn't be added in order to encourage people to use 'resolution' - The other opinion was because '-webkit-device-pixel-ratio' didn't obviously translate to 'resolution' 'device-pixel- ratio' should be added to aid authors. - Right as conversation was wrapping up, smfr asked a question about 'window.devicePixelRatio' which he was asked to post on github to allow further conversation. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0086.html Present: Rossen Atanassov Tab Atkins David Baron Bert Bos Tantek Çelik Dave Cramer Simon Fraser Daniel Glazman Dael Jackson Brian Kardell Brad Kemper Peter Linss Myles Maxfield Thierry Michel Michael Miller Edward O'Connor Simon Pieters Anton Prowse Matt Rakow François Remy Florian Rivoal Andrey Rybka Geoffrey Sneddon Alan Stearns Greg Whitworth Steve Zilles Regrets: Rachel Andrew Jen Simmons scribe: dael TPAC ==== Rossen: Let's get started. Rossen: Hello everyone. Rossen: Any additional agenda items to bring forward? fantasai: Is the grid baseline issue on there? Rossen: It is. Rossen: It's the first one on the agenda. glazou: A reminder about TPAC. Registration fee is about to increase and registration will soon close. glazou: If you haven't it's good to do ASAP. Rossen: Good point. Also please continue to add agenda topics. Bert: Is the dev meetup on? Rossen: I might have missed it. Let's start there. Bert: Can we propose someone to speak at the dev meeting on the Monday evening of TPAC? Rossen: Does it need to be 1 person? Bert: It's 15-20 minutes. It could be more. We can all go, it's just the talk is short. Bert: Do we have an interesting topic and someone to deliver? Rossen: There were proposals on the private list. One from astearns about the talk on the CSSWG and call for help. I proposed grid and volunteered gregwhitworth who can do a shortened version of the Sydney talk. Rossen: One is more process/PR and the other more technical. Rossen: I'm happy with either. Bert: I think grid would be interesting if gregwhitworth is available. gregwhitworth: Sure. gregwhitworth: I'll need to update it, but I can try to shrink it down. Bert: I'll connect you with Gerome who is in charge of the talks. Rossen: Anything else on this? Bert: Nope. Reminder charter review ends soon and we need more AC reps and companies to review. If yours hasn't, please do so. We have 2 days. Rossen: Great reminder. Please update your AC rep and have them respond. Synthesized baselines seems like a breaking change ================================================== fantasai: I'm having connectivity issues, but the summary is in the link. fantasai: The basic issue was that for writing modes...right now the behavior of what we do when there isn't a natural baseline is inconsistent. Implementations don't agree, specs don't agree. There were several options presented. I'd like a resolution. Rossen: One comment...I've edited your comment to say Edge matches Chrome so there's a bit of interop between Edge and Blink. fantasai: Okay fantasai: Just want comments. Does anyone need more explanation? What's helpful here? <Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4416 Rossen: I think a good way to move forward, I'll paste the example and people can look. Rossen: I think it's concise and to the point. Rossen: Are people reviewing? Or are we waiting for someone to talk? Rossen: I think fantasai could elaborate on concerns and proposals. fantasai: Is jensimmons, rachelandrew, or leaverou on the call for an opinion? [they aren't] fantasai: We have a couple of options. 1 is make boxes without a natural baseline synthesize one. 2) If there's no natural we use a fallback. If you use a fallback the author could have gotten that from defining it on the item instead of synthesize. fantasai: If we synthesize we have to decide if we do it on margin box edge or another box edge. Rossen: Reading your comments and looking through this I agree we want consistency. If we synthesize it better be the same. fantasai: I agree. Rossen: If we make the...align with the inline model so based on the margin box...that is the more interesting topic we should decide on. I'm not sure margin makes the most sense for grid. Border may make more sense as it gives you visual. fantasai: I have no opinion on this. Florian: Sounds reasonable on the face of it. Rossen: What do people think? Other opinions? Rossen: Do we pick one of fantasai options? Rossen: I prefer A2 which is they're synthesized based on the border box edge. frremy: I agree. Rossen: So we have some votes for A2. <tantek> I have been trying to read and understand this issue. <tantek> A2 with border-box seems reasonable. Florian: Weak agreement. <Florian> (as in: I agree, but I haven't thought about it for very long) <SteveZ> I agree that visually border box makes more sense, but in inline the alignment is on margin edge so the result would differ inline and across grid areas Rossen: What I'll do because I want to move the conversation forward and it's holding Grid spec up I'll list the options. Rossen: I'm hoping we can get resolution on one. <Rossen> A. Make boxes without a natural baseline and boxes establishing an orthogonal flow synthesize a baseline. <Rossen> A.1 Base this synthesized baseline on the margin box edges <Rossen> A.2 Base this synthesized baseline on some other box edge <Rossen> B. Make boxes without a natural baseline and boxes establishing an orthogonal flow use start alignment instead of trying to synthesize a baseline. <Rossen> C. Something else. fantasai: bradk just joined. Do you have an opinion? bradk: I just joined. Rossen: We're talking about if we should synthesize baseline for grid or flex with orthogonal flow and ones with no inline content. If we do synthesize do we use margin box, border box or something else Rossen: I posted the options and we're trying to narrow down. Currently there's synergy around A2. <fantasai> bradk: https://github.com/w3c/csswg-drafts/issues/373#issuecomment-242863486 SteveZ: Two comments. 1) inlines align on margin box and so you get some interesting things from alignment inline vs row or flexbox. I'm not sure that's important. 2) if you use margin edge you can use big margins to adjust alignment and get centering with a bit of playing Rossen: That's a great point. I would argue the opposite. I wouldn't try and align grid and flex with inline in that respect since alignment and role distribution and sizing are all dependent on the sizing of the items and it doesn't matter for inline. Rossen: So for both complexity and interdependences I would argue the opposite. <tantek> steve makes a good point about potential utility of negative margins <fantasai> tantek: yes, it was mentioned in my writeup. Along with some problems with it <fantasai> tantek, One problem is that negative margins will cause overlapping with subsequent content -- this is less of a problem with inline layout because of the struts <tantek> fantasai, ok. I don't have strong feelings about it. <fantasai> tantek, Another consideration is that the 'alignment-baseline' property can give control over the alignment point of synthesized baselines <fantasai> tantek, and a future property is on the radar for even more control bradk: Would you want to align with table cells? How they align? Rossen: I think they use border box or content box. Rossen: I think gregwhitworth and frremy were looking into table cells bradk: I don't have a strong opinion. Rossen: So bradk if you don't have strong opinions fantasai: table cells align content box Rossen: They're wierd. <tantek> fantasai - does A2 with border-box seem reasonable to you? <fantasai> tantek, yeah. Assuming the baseline controls, it's likely the best solution. <tantek> ok <fantasai> without those controls, it's less clear... dbaron: A bunch depends on what there are use cases for and what can happen in another way. There's a bunch that can be accomplished by using a non-baseline alignment. There's a bunch that can happen from making it a inline block inside a grid cell. Part of what's not clear to me is what are the use cases that you can't do in another way and what are people trying to do Rossen: There's already a bunch of alignment options to center. People use - margins in the inline is because they don't have other ways to center align. I'm with dbaron to allow all the other alignment options work itself and the baseline is a baseline. Rossen: The other comment on the table cell alignment model, that's weird because usually borders are on the table grid level and shared between table cells. That's why there it makes sense to align on content box fantasai: Table cells do content alignment instead of here we do self alignment. Conceptually it's do you move the contents or the box. So they will necessarily be different cases. fantasai: I'll throw in my hat for align on the border box. There are cases you might want items to align to each other. Border box is the visible part of the box and the margin doesn't provide that visible piece. Reason for margin is you can adjust the alignment point, but we have controls like alignment-baseline that let you determine that alignment point. fantasai: Those controls effect how the baseline is synthesized. Also SteveZ pointed out for inline we'd need more fine controls and that's something that we could apply here as well. <Rossen> +1 to everything fantasai said <gregwhitworth> sounds like it's border box then fantasai: So I'm leaning toward border box option because that's more in the spirit. fantasai: Also in flex and grid using a negative margin to adjust the alignment point can cause overlapping content. fantasai: Anyways, that's what I'm thinking. Rossen: I agree with fantasai. frremy: Are we sure we do content box on table rows? frremy: I'm not sure what's what we do. fantasai: We're sure <fantasai> *of course* they align on the content box; if they didn't the borders wouldn't align across the row! <fantasai> if you put inline-level content *inside* the table cell, then that will align on its margin box Rossen: Are you asking what implementors do now? frremy: Yeah. Rossen: Currently there is Edge and Chrome align on synthesize baseline based on margin box. Firefox seems to align on border box. Rossen: Or maybe margin box. Rossen: There's no interop at the moment. Given there's no perfect interop and we have a model that makes sense and is easy to explain and seems obvious we should try and resolve and clean up the spec and allow implementors to follow up. Rossen: To move forward, proposal is: resolve on option A2 with the modification that we're talking about the border box. Rossen: Objections to specifying that [reads option a2] RESOLVED: Accept option A2 with the modification that we're talking about the border box. Add <number-optional-number> type ================================= Rossen: Who wants this one? Rossen: TabAtkins? TabAtkins: We skipped this last week, right? TabAtkins: Basic option is to make the grammar clearer on how to handle weird SVG behavior, particularly where there are optional commas. For single we're fine, but for arbitrary lists you can't quite mark it. You could use +# as a stacked combinator, but that's not technically possible. Proposal is to add it to the grammar and link to SVG but mark it as shouldn't be used and it's legacy Florian: Any drawback to that? TabAtkins: Not that I know of. dbaron: Draw back is another symbol for people to learn and read about. TabAtkins: Yeah. A combo of two symbols. Hopefully with the linking to a definition no one is using it. Bert: I'd prefer not to add a new symbol, but I'm not strongly against. TabAtkins: It's combining two existing combinators in a way that's technically not possible right now. <TabAtkins> <foo>+# Rossen: So any other opinions? * fantasai doesn't have a strong opinion on this myles: I weakly prefer that if we can do this with existing grammar something new doesn't need to happen. <TabAtkins> <foo> [ ,? <foo> ]* TabAtkins: I just put in how to write it without this. TabAtkins: It's that odd doubled grammar thing that we tried to do away with by introducing #. It looks pretty hefty. <fantasai> [ <foo>+ ]# * Bert prefers with the [] as fantasai did myles: Looks fine to me. I don't think we need something new. Florian: It parses right but implies a different tree? TabAtkins: No. Only difference is collapsing it so + and # are next to. It's only because we say combinators are only for non-terminals. fantasai: I think you mean we can't stack multipliers. TabAtkins: Yes. TabAtkins: Or rather we can't do it directly. We can do it with the indirection of a square bracket. fantasai: I don't care either way. <bradk> [ <foo>+ ]# seems clear enough to me <astearns> I think [ <foo>+ ]# is fine <frremy> should we vote, then? yay, nay, don't care? Rossen: There were at least a couple of people preferring not to have it and a couple of people who don't quite care but wouldn't mind adding it. Florian: And since it's legacy only thing maybe adding new isn't that important. TabAtkins: Then I'll probably still want to add a non-normative bit about the [] pattern thing. I'll want some indicator that this pattern has a particular meaning that's slightly different than what it seems to indicate. <astearns> +1 to clarifying note fantasai: I have no problem with a note. I might have comments on the wording, but a note is a good idea. <Florian> +1 <zcorpan> [ 1+ ]# <TabAtkins> (The specific meaning is that [ <foo>+ ]# seems to mean "a comma-separated list of space-separated things", but in SVG it just means "a list that can be separated by spaces or commas". fantasai: Proposal is add a note explaining the syntax, but don't add anything. Rossen: Sounds fine. Can we resolve on this? TabAtkins do you have a problem with that? TabAtkins: Not enough to object. Rossen: Any objections? RESOLVED: Don't add any new syntax, just add a note explaining it. <Rossen> https://github.com/w3c/csswg-drafts/issues/332 Rossen: We covered #3 as a part of #1 fantasai: I don't think there's anything else there Algorithm of `Element.offsetParent` =================================== <Rossen> https://github.com/w3c/csswg-drafts/issues/409 Rossen: Anything new on this we need to talk about? Rossen: I think that was Florian? Rossen: Or maybe smfr. zcorpan: It was me. zcorpan: There were interop problems and it would be good to decide what we want the API to do. Most people prefer Gecko from the comments: matching containing block for abspos descendents. That's not what the spec says. If you have a non-none transform that has a containing block it doesn't affect .offsetParent dbaron: In some or all implementations? zcorpan: Some. It does affect in Gecko. Not in Blink or Webkit. frremy: It does in Edge. We're like Firefox. zcorpan: I suggest we align with Edge and Gecko. smfr: My comment is I agree it's good to standardize, but the guarantee for authors is you can walk up the chain, pop an . offsetLeft and compute. I think it's essential that you can compute a position. zcorpan: .offsetParent also picks up things like table cells which is a quirk in the API. dbaron: Presumably what smfr said will hold if .offsetTop and .offsetLeft are relative to the .offsetParent. zcorpan: They are in the spec. smfr: I don't think they take transforms into account. zcorpan: Spec says transforms are ignored for .offsetTop and .offsetLeft <bkardell> that is my recollection as well from some recent use smfr: Do any implementor have feedback on compat issues? Rossen: We haven't made changes since IE8. I would expect that those are used a lot. Rossen: So changing them will potentially have compat risks. smfr: Right. And I think Blink has changed since webkit fork. So I'd like feedback from blink if they saw compat issues. TabAtkins: I'm not sure. We'll have to investigate. smfr: Actually I'm not sure they've changed. Rossen: So TabAtkins can you verify if you've changed? TabAtkins: Yeah. <smfr> looks like blink added checks for tables and table cells Rossen: So I think there will be some compat risk for whomever changes. So we'll have to evaluate that and minimize the damage by spec whatever we need to spec. Rossen: At the same time if there are differences, especially between Blink and Webkit, that would be a good indicator people don't rely on this. <smfr> oh, no, they just moved code around Rossen: I don't believe we're ready to resolve. zcorpan: What do we need to resolve. Do we need to talk to a browser shipping something else? More opinions? Rossen: We'll have to have a clear spec as to what is expected, as to what the exact rules are for .offsetParent so everyone can compute the same. And then ID the compat issues. Rossen: There will have to be changes for someone. Last week I started writing a quick list of rules that we use for Edge. Once I'm done I'll add it to the issue and we can go from there. And it would be great if you can outline something similar from other impl. zcorpan posted a link to source code which not everyone can look at. smfr: Webkit would be willing to change behavior if we have a good spec soon. It's early in our release cycle. Rossen: So zcorpan do you have currently proposed text or a different proposal than the spec? zcorpan: Proposal is to change the spec to make .offsetParent return the ancestor that's the containing block of the abspos parent. Rossen: Did you say the nearest ancestor for abspos element or simply the containing block of the element and if it has to be abspos. <bkardell> just absolutely positioned, or relatively too? <zcorpan> "return the first ancestor which is a containing block of absolutely-positioned descendants" zcorpan: Doesn't matter what the element itself is. Nearest ancestor that's a container for an abspos element, even if there isn't one. Rossen: And there's the quirk with table cells? zcorpan: Yeah, that's still there. Rossen: And smfr you said you'd be willing to try this out? smfr: Yes. Rossen: Does anyone object? Chrome people? Rossen: TabAtkins? TabAtkins: I'm fine. zcorpan: I spoke to rune and mårten from Opera and they preferred Gecko. They're likely not aware if it breaks the web. Rossen: Let's move to a resolution and we'll find out from webkit impl experience and see what compat looks like. Sound okay? Objections? RESOLVED: Adopt the Gecko/Edge behavior and specify that .offsetParent is based on the nearest abspos containing block or table cell Media Queries ============= device-width media feature and privacy -------------------------------------- Rossen: I believe most remaining topics are Florian's. Order preference? Florian: First is quick. <Rossen> https://github.com/w3c/csswg-drafts/issues/426 Florian: Maybe zcorpan can say more, but there's a change in OM View where various places that refer to the size of the screen are a problem. There's no great use cases, but it leaks private info. In order to allow browsers to hide that anywhere that you're supposed to give a screen measurement you can do the exact measurement or another measure. <zcorpan> the other thing is indeed the viewport Florian: In the MQ spec where we have ones that refer to screen size we propose we allow either the screen or the new area. It doesn't force a change, but it allows browsers to provide more privacy. <zcorpan> https://drafts.csswg.org/cssom-view/#web-exposed-screen-information Florian: They're deprecated, but we have to support them. TabAtkins: I strongly agree with this. Rossen: How does this align with screen object? Rossen: zcorpan? Rossen: The screen available width and height may return different values? zcorpan: Other way around. CSSOM View spec says now that screen-available-width or screen-width you can do what browsers do today or return size of the viewport. zcorpan: For not device-width leaks screen size. Florian: By using the same term browsers switch both or neither. Rossen: That's fine. For browsers in full screen it'll evaluate to the same. I don't have a disagreement. TabAtkins: We're not looking for the OM change, we're looking to make these things do the same thing. Rossen: So do we have a summarized proposal for resolution? Rossen: Any objections to the proposal? RESOLVED: Accept the proposal (Proposal: Make the device-width/etc MQs use the same concepts as CSSOM is using for returning device dimensions.) Consider making device-pixel-ratio a standard alias --------------------------------------------------- Rossen: Anything in 2 minutes? <Rossen> https://github.com/w3c/csswg-drafts/issues/417 Florian: We have resolution MQ that use to be under a prefix. Gecko has/will implement both resolution and -webkit-device-pixel-ratio, but they find it distasteful to have -webkit only, so they're considering device-pixel-ratio. This is just so that we have unprefixed as well as prefixed. I say don't because unprefixed is resolution. MaRakow: I agree with Florian. We haven't seen this in the wild and if we're trying to push authors we should move to resolution. Pressure is in one direction and fragmenting to two is detrimental. dbaron: I tend to think there's a lot of mind-share to device-pixel-ratio and so resolution doesn't make sense for what people want to use. <zcorpan> there's also window.devicePixelRatio, https://drafts.csswg.org/cssom-view/#dom-window-devicepixelratio <tantek> so basically, "resolution" lost the bike-shedding battle in the market hober: There's no disagreement from me that the name 'resolution' is bad Florian: It's out there so I don't think dropping resolution is an option. <bkardell> it seems like an alias is easier for authors Rossen: Do we believe we can resolve? We're top of the hour Rossen: One proposal is to drop -device-pixel-ratio. Florian: Reject proposal to add it. Rossen: Would people object to that? Especially people from Gecko? <tantek> flip the proposal around since the intent is to implement device-pixel-ratio <tantek> that's the question for which it should be asked if there are any objections dbaron: I'm pretty uncomfortable not simultaneously implementing the same thing unprefixed. Rossen: We have a bunch of those. Florian: Isn't that the same as doing -webkit gradient where we have old webkit syntax or the new syntax and they're not the same dbaron: From the names people can figure out what the new one is. Florian: Yeah, true. <tantek> the problem is that "resolution" is a crappy name, and has no easy discover-ability from -webkit-device-pixel-ratio smfr: Question on resolution. Does it change under page zoom, or is it capabilities of hardware? Florian: I don't remember, but it's the same as prefix. smfr: We've got this difference with window.devicePixelRatio. It seems to me that window.devicePixelRatio and the resolution MQ should be the same. dbaron: I think a bunch is not interoperable. myles: I think it's time. Rossen: We are at top of hour. I propose we leave this for next week and we can continue on github if people have opinions. Florian: smfr can you bring your question to github? smfr: Sure. Rossen: Remember to register for TPAC if you haven't. Talk to you next week.