- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 Sep 2016 20:10:15 -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. ========================================= Does 'align-self: auto' compute or behave as 'start' for abspos? ---------------------------------------------------------------- - RESOLVED: Don't have the computed value dependency. url parsing contradiction between 2.1 and Syntax ------------------------------------------------ - This conversation needed TabAtkins, dbaron, and Bert and none of them were available today so it was postponed. Bounds of an inline box vs font fallback ---------------------------------------- - There was a strong leaning toward using the metrics of the first available font. - Rossen wanted to confirm there was minimal compat implications so he asked that the formal resolution wait until TPAC. Can tab-size be zero? --------------------- - RESOLVED: Don't disallow 0 width tab size. ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2016Sep/0038.html Present: Rossen Atanassov Tantek Çelik Dave Cramer Alex Critchfield Daniel Glazman Dael Jackson Brad Kemper Ian Kilpatrick Peter Linss Myles Maxfield Thierry Michel Anton Prowse Liam Quin Andrey Rybka Geoffrey Sneddon Alan Stearns Greg Whitworth Steve Zilles Regrets: Rachel Andrew Tab Atkins Bert Bos Tony Graham Chris Lilley Florian Rivoal Jen Simmons Scribe: dael Rossen: Let's get started. Rossen: As usual, are there additional agenda topics to discuss today? Rossen: I'll take that as a no. Is koji on for the first topic? Rossen: So fantasai what if we proceed to topic 2 to see if koji can join us? fantasai: Give me one second. Does 'align-self: auto' compute or behave as 'start' for abspos? ---------------------------------------------------------------- <Rossen> https://github.com/w3c/csswg-drafts/issues/440#issuecomment-244791183 fantasai: There's an auto value for the align-self property which computes to the value of align items on the parent. Issue here is right now auto is defined to compute to normal if you have no parent. fantasai: We also have a situation for abspos elements where it needs to behave as normal and not take from the parent. If you're abspos you mostly are positioned to an ancestor in which case having your parent effect your position doesn't make a lot of sense and is likely to create confusion as that's not where you're going to layout out. fantasai: And a lot of times you want to set align-items to effect ink-flow children. We have defined that if you had abspos you take from the normal. Is that computed value time or used time calculation? Rossen: And so, to make sure I get this, I wasn't sure if you're talking about only alignment or computing the auto position different fantasai: This is just the value of align-self on the abspos which might effect other things, auto position of final position depending on align-self. Rossen: align-self should affect auto but it would take it into account, right? So indirectly the parent's alignment will affect the alignment of the element as far as the auto-positioning is concerned. Do you see what I mean? fantasai: Yeeeah. It's a question is static position effected by align in parents. Rossen: I don't see how it wouldn't be. With this the auto position would be effected. I think the two are coupled, static and alignment when static is used for computing size and position. It's tighter than we want. Rossen: I'm with you, I'd prefer if alignment applies in layout context where ever that happens to be, but we'd have to make sure that 80% of that won't happen independent and 20% dependent. fantasai: Okay. This issue was focused on is this computed or used value time issue. I didn't have an opinion. That rarely affects authors. If we're questioning if we should have this dependency that's a broader question that we could talk about. That's not this issue. fantasai: I don't have an opinion on this issue, we need implementor feedback. Do you want computed value depend on position or not? Rossen: On our side I wouldn't like to have property dependency based on computed value of other properties. I'd vote independent. Rossen: Both are implementable, though. Rossen: I'd be interested to hear from Mozilla and webkit or Blink. * fantasai dropped off, calling back in Rossen: It sounds like we don't have enough feedback here. We can postpone the issue until more implementors look. Or we can continue talking now. Rossen: I don't see to topic being engaged too much. Rossen: Right. While fantasai calls back in... fantasai: I'm back Rossen: I was going to propose we push this topic to a later time. fantasai: Is anyone planning to give feedback? Rossen: For now it's you and me. We can try and engage more people through feedback. We can otherwise put and see if it comes back. fantasai: So we'll go with don't have the computed value dependency. Rossen: Yes. Rossen: But I would be reluctant to resolve solely on my opinion. I can call for objections. Rossen: Does anyone object to resolving on this issue? <liam> on the phone but no objections :) RESOLVED: Don't have the computed value dependency Rossen: People can re-open if they feel strongly otherwise. url parsing contradiction between 2.1 and Syntax ------------------------------------------------ <Rossen> https://github.com/w3c/csswg-drafts/issues/412 gsnedders: I brought up the issue, but I don't have an opinion. We should resolve somehow. Rossen: fantasai added it to the agenda. I'm with you we should resolve. Rossen: Did anyone look at this issue? Rossen: If not, maybe you can summarize. gsnedders: I think TabAtkins did more analysis. There were changes of syntax parsing between 2.1 and the syntax module Rossen: And the specific contradictions are summarized as what? Rossen: In the issue you say 3, 4, 12, and 14 should fail according to syntax spec. <astearns> Tab said the tests were wrong Rossen: TabAtkins said tests are wrong? <gregwhitworth> currently Edge/FF render green, Chrome renders them as red (thus correct I guess) <gregwhitworth> what was the change & why gsnedders: gregwhitworth, Firefox has changed and current nightly matches Chrome. <gregwhitworth> ahhh gsnedders: Blink and Gecko do syntax, Edge does 2.1, Webkit does neither. gsnedders: My only opinion is not what webkit does. myles: Webkit is impl new CSS parser so take what we do now with less of a grain of salt than you would normally. fantasai: Main issues are string termination causing url to not match and closing brackets and braces; how that's handled. I think to have a useful discussion we need TabAtkins, dbaron, and Bert and I don't know if any of them are here. fantasai: If they're not here it's not useful to have this conversation. Rossen: So I'm hearing webkit is willing to follow whatever we decide in the future. Rossen: But let's move on because we can't resolve. Bounds of an inline box vs font fallback ---------------------------------------- <Rossen> https://github.com/w3c/csswg-drafts/issues/391 fantasai: There's a contradiction in 2.1 about how the height of an inline is calculated. One hand is that it's exactly line height. Other hand it says it depends on the top and bottom of the glyphs after they're aligned. If the two baselines aren't identical you'll get shifting with character. Deciding that it's one line height or the bounding box is two different things. fantasai: I did testing and I think the most sense is maintain it's exactly that height. Else wise you'll get jittering when there's font fallback and we don't want that. I think we should resolve line height is from first available font. Rossen: Which impl do this? fantasai: I posted in the issue. Let me see. Rossen: I only see webkit <gregwhitworth> Here is the test: http://jsbin.com/lixoqijadi/edit?html,css,output fantasai: Blink and Gecko use the metrics of the first available font. I didn't get results on Edge. fantasai: There's two advantages. 1 is we have interop. Second is it reduces line height inconsistencies. So this is the way to go. Rossen: Edge and IE have different behavior than Gecko and Blink from what I can test. Rossen: Seems like we're closer to Gecko than Blink. I would need to do a bit more testing before I can agree. I'm not sure what the compat would be. Rossen: Have we done any queries as to what the impact on compat could be? fantasai: Since we've got two impl that do the same thing and authors want that I haven't tried to do compat. <gregwhitworth> on Linux does the border overflow the black box? <gregwhitworth> sorry - dotted border Rossen: I don't see the behavior as the same between...let's see the versions...between FF 48 and Chrome 53 Rossen: I still see some variance. The border calc...the red dotted border in Gecko exceeds the box. Rossen: From what I'm hearig they match. fantasai: That's what I get on Linux. Rossen: Nope, not the same for me. <gregwhitworth> anyone on OSX? <gsnedders> gregwhitworth: yes? <liam> gregwhitworth - firefox and chrome behave differently here on Linux, chrome clips the top of the accents at the red dotted border, outside the black box fantasai: Basically the red dotted border should be the same... Rossen: As the black. I get the point but it's not in Gecko. In Edge it's even larger. fantasai: Okay. Rossen: Given the difference and the variance as an implementor I'm reluctant to go with any of those without knowing what compat risk is. iank: I just tried ours on mac and the red border doesn't match for us. <gregwhitworth< interesting, so it's OS specific myles: Did blink change recently? Mine is older. iank: We match with webkit but not Gecko. Sorry. <iank> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmeta%20charset%3Dutf-8%3E%0A%3Cstyle%3E%0Ap%20%7B%20border%3A%20solid%201px%20black%3B%20color%3A%20silver%3B%20font-size%3A%20100px%3B%20line-height%3A%201%3B%20margin%3A%200.1em%3B%7D%0Ap%20%3E%20*%20%7B%20border%3A%201px%20dotted%20red%3B%20%7D%0A%3C%2Fstyle%3E%0A%0A%3Cp%20style%3D%22font-family%3A%20Ahem%2C%20SimSun%22%3E%3Cspan%3E%C3%89p%E4%B8%8D%3C%2Fspan%3E%0A%3Cp%20style%3D%22font-family%3A%20SimSun%2C%20Ahem%22%3E%3Cspan%3E%C3%89p%E4%B8%8D%3C%2Fspan%3E%0A%3Cp%20style%3D%22font-family%3A%20Ahem%2C%20SimSun%22%3E%3Cspan%3E%E4%B8%8D%3C%2Fspan%3E myles: Can someone post screenshots? Rossen: I'm trying. <fantasai> Screenshot of FF on Linux with the named fonts installed: https://lists.w3.org/Archives/Public/www-archive/2016Sep/att-0003/ff-linux.png <liam> [actually i take it back, the difference between chrome & ff here is just different font choices] <liam> [here = on Linux ] myles: In IRC liam said it's just font choices for Chrome and FF which is what I see. liam: For me on Linux the difference is font choice. If I change the font to be the same they'd be identical. myles: Sounds to be that Chrome, Webkit and FF do the same thing. Rossen: Potentially. Rossen: So. I'd like to go back and figure out what this would mean for us in terms of implementation before I can feel comfortable not objecting. Rossen: My suspicion is this shouldn't be too difficult to change for us. And given that blink and webkit are already in agreement I don't believe we'll have too much of a compat issue. I hope. I'd like to take some time. gregwhitworth: It would also be good...both of you are using the same font and FF is exceeding the border on windows. It would be good if someone from FF would look at why you're exceeding the border on Windows and not elsewhere. Rossen: To move this forward; fantasai are you asking for a resolution today or would everyone be okay postponing this for a week and we resolve at TPAC. fantasai: I'm happy to resolve as soon as convenient. Rossen: Okay. I wanted to make sure you weren't pushing for this really hard and it doesn't sound like it. <liam> [ on Linux 64bit - http://jay.w3.org/~liam/dottedborder.png ] Can tab-size be zero? --------------------- <Rossen> https://github.com/w3c/csswg-drafts/issues/460 Rossen: Koji isn't on, fantasai can you discuss? fantasai: I think I can. Let me pull up the issue. fantasai: The main issue is we said negative values aren't allowed, but what do you do with 0? Koji is concerned about impl that. It seems that basically all you have to do is if 0 is your tab size you have a 0 width tab. I don't see a problem, if other people are fine with it I'll define what happens with a 0 width tab character. Rossen: On our end I don't see a reason why we wouldn't have 0 or why that would cause any problems. <astearns> seems least surprising to allow 0-width tabs myles: Same thing on our side. 0 width tabs should be fine. Rossen: Do we have anyone from Gecko or Blink that feels otherwise? Rossen: Okay. Rossen: Objections to not disallow 0 width tab size? Rossen: glazou from an editor perspective would this make any difference? glazou: I'm not sure. Rossen: Because all the character advancement happens on the content side and you will have basically no visual indication of the caret movement. In terms of OM it's just a 0 width character and no different from any other one. But I want to give you a chance to interject. glazou: I have to think about it. Rossen: Are you okay with us resolving? glazou: I'm fine. RESOLVED: Don't disallow 0 width tab size Rossen: That's the top of the agenda. Rossen: I didn't hear additional items, so we'll have a short day. Rossen: Safe travels to TPAC and I'll see all of you on Monday in Lisbon.
Received on Thursday, 15 September 2016 00:11:15 UTC