Brief   Full   Jump  

Small
Medium
Large

Teal
High contrast
Bluish
Black

Sans-serif
Serif
Monospaced
Close
d
?
Styles

Minutes Telecon 2017-05-31 [css-variables] [CSS22] [css-display] [css-ruby] [css-text-decor]

1 message.

Minutes Telecon 2017-05-31 [css-variables] [CSS22] [css-display] [css-ruby] [css-text-decor]
Dael Jackson   Wed, 7 Jun 2017 08:20:29 -0400

www-style > June 2017 > 0009.html

Received on Wednesday, 7 June 2017 12:21: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. ========================================= Specs to Rec ------------ - ChrisL will review the pending changes from gregwhitworth to Variables. - RESOLVED: Add gsnedders as editor to CSS2.2 Does inlinification really need recursion? ------------------------------------------ - RESOLVED: Blocks are turned into inline-blocks. Blockification doesn't seem backwards-compatible for inline-blocks ------------------------------------------------------------------ - RESOLVED: We are provisionally going with option b (inline-block -> block; inline flow-root -> flow-root). - TabAtkins will open a new issue to decide if you maintain separate computed values for just this one case or the whole possible space of values. Depending on that discussion the previous resolution may need to be revisited. Propagation of text-decoration with display:contents ---------------------------------------------------- - RESOLVED: Define this as a box-tree concept. Should anonymous boxes always inherit through the box tree? ----------------------------------------------------------- - RESOLVED: Let's try it out, go forward with the diff (https://github.com/w3c/csswg-drafts/issues/1118#issuecomment-301942276) ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0059.html Present: Rachel Andrew Rossen Atanassov Tab Atkins David Baron Tantek Çelik Dave Cramer Benjamin De Cock Elika Etemad Tony Graham Brad Kemper Chris Lilley Myles Maxfield Anton Prowse Liam Quin Melanie Richards Jen Simmons Geoffrey Sneddon Alan Stearns Lea Verou Greg Whitworth (IRC only) Regrets: Bert Bos Daniel Glazman Vlad Levantovsky Peter Linss Florian Rivoal Scribe: tantek astearns: Next week we are trying a AUS friendly time for telcon - 7 hours forward astearns: 16:00 Pacific time astearns: any more items? (silence) Specs to Rec ------------ astearns: Things going to REC. Chris gave an update on Fonts. Still waiting for info on Writing Modes impl & test report. astearns: 3 things I see. astearns: 1 bunch of things with resolutions but editing has not caught up, like values & units. astearns: smfr or bogdan here? astearns: I will ping them separately to get transforms edits done. Rossen: bogdan is out sick today, belated regrets. astearns: Another thing, we expect a bunch of tests in Mozilla to contribute to test suites, but dbaron? dbaron: No [progress]. astearns: What can we do to move it along? dbaron: Probably difficult in next month or two. astearns: Someone we can delegate to? dbaron: Organizationally, lots happening in next month or two taking up everyone's time. astearns: Noted. astearns: Another, gregwhitworth is looking for test review of submission for variables- astearns: he has pinged a few people in the github pr. astearns: Any volunteers to look at those and get them into the test suite? tab? chris? astearns: Just a review of a submission. TabAtkins: I can review them then. ChrisL: What bits? variables tests? <gregwhitworth> yes ChrisL: I started looking at them, didn't finish reviewing them, I can look at them astearns: Tab you're off the hook. ChrisL will get to them in the next week or two. <gregwhitworth> please do - I'd love to wrap this up :) astearns: Last thing, pending edits to CSS2.2 astearns: gsnedders suggested adding an editor astearns: because Bert is on vacation. astearns: CSS2.2 is an odd duck astearns: in terms of editing. ChrisL: I would be happy to add gsnedders ChrisL: It is an odd duck because it uses the old pre-processor. ChrisL: We cannot use bikeshed because it is a multi page document. astearns: It is a monumental task to convert even if bikeshed could. astearns: gsnedders you sure you want to take this one? gsnedders: yes? not sure about time, but so little has happened. i can certainly start getting through some of the back log <dbaron> For what it's worth, I *used* to have the old spec preprocessor working locally, although various distro updates broke that... astearns: I think adding an editor is something I can do by fiat <ChrisL> +1 RESOLVED: add gsnedders as editor to CSS2.2 astearns: Not sure when Bert is back but it is in noted in the mailing list. <ChrisL> 5 weeks gsnedders: What is the name? css 2.1 second edition? astearns: I forgot. As editor, please figure that out. Does inlinification really need recursion? ------------------------------------------ github topic: https://github.com/w3c/csswg-drafts/issues/1341 astearns: let's get to the first github issue on the agenda astearns: inlinification and recursion TabAtkins: I can take it. TabAtkins: our current ... does ... but not ... TabAtkins: In order to keep certain inline layout modes in particular ruby from being broken up by blocks showing up TabAtkins: we use inlinification TabAtkins: but as currently defined in the display module it might be too aggressive. TabAtkins: In particular it turns plain blocks (not bfcs) into inlines TabAtkins: which preserves the inliniciation but almost certainly messes up your intended layout. TabAtkins: Blocks become inlines. TabAtkins: The other way we could do it: TabAtkins: make all types of blocks, flow root or flow, turned inline blocks. TabAtkins: This would preserve display a bit more closely to what intended TabAtkins: inline block TabAtkins: but is a little more complicated in the spec. TabAtkins: On the other hand we probably have to do the opposite for blockifications, turning inline blocks into block flow, not block root. TabAtkins: If anyone knows of any impl difficulty one way or another, let us know. TabAtkins: Otherwise we may go the latter way, inline blocks turning into plain blocks. <fantasai> in favor of inlifying into inline-block <Rossen> <div> text <span> more text <div>am I inline?</div> end text </span></div> Rossen: I have a question and just pasted an example Rossen: (describes example) TabAtkins: Inlinification is not triggered by that TabAtkins: but if instead of a span you had a ruby. TabAtkins: It would no longer be a block. Rossen: What does inlinification apply to? TabAtkins: Ruby bases and text, and I think there is one more context, run-ins? Rossen: In that case if it is only tied to those 2-3, then it shouldn't be much of a problem. <dbaron> Isn't part of the problem here that there's not inline-block variant that *isn't* flow-root -- and that such a thing doesn't necessarily make sense? <dbaron> But inlinification of block -> inline-block does seem to make sense, as long as there aren't compatibility problems. <fantasai> dbaron, I think the complexity here is that 'flow' for blocks can mean flow-root depending on various external things, and historically these cases have a display type of 'block' not 'flow-root'. <dbaron> What do implementations do? TabAtkins: dbaron, they do inconsistent things, bc run-in not impl yet, ruby spec describes different thing that is broken in its own way, because it doesn't stop blocks from breaking things, so it is doing something, but inconsistent with many things, unclear what impls actually do. fantasai: One thing to keep in mind for ruby, the only impl that even remotely follow the spec is Firefox, the other two impls are tag-based hacks in layout that hook into inline-layout code. fantasai: As far as we are concerned there is only one impl of CSS Ruby spec. Rossen: How many impls follow HTML ruby spec? Rossen: Ruby spec as it is not ready for imply in our opinion that is why we are not impl it * fantasai would agree the css-ruby spec is not really ready for implementation :) Lots of outstanding issues. Rossen: re: ruby interop, HTML ruby interop is good. Rossen: Then there is the spec in the works which it is hard to argue what is interop and what is not. Rossen: Question, do we know what is from the author / content point of view the expected behavior? Rossen: Do we not break anything in the ruby context e.g. blocks? or do we need to blockify? fantasai: The general case is that ruby is not expected to contain block level content, generally just text, not enough text to wrap, though there are some pathological cases where the text does wrap. fantasai: We are trying to stop the bleeding. fantasai: We don't want to have to deal with how do you break ruby annotations across lines fantasai: so we are inlinifying. fantasai: Similar for run-ins fantasai: e.g. if you have a headline and want to run into the next paragraph fantasai: if you stuck a block in that headline, then it's not going to run-in properly. fantasai: We could say if you have a block inside, then you could say it does not run-in fantasai: but then you have to inspect all the way down. <jensimmons> +1 fantasai: We just want to check the element its properties and parent(s) fantasai: ... inline-block ... fantasai: or we ... to turn into inlines fantasai: ... everything is contain in a bfc that is now inline <TabAtkins> (A simple test-case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5218. Chrome's rendering is *incoherent* here, so our behavior can't be depended on.) Rossen: I agree with that logic <jensimmons> what fantasai just said sounds right to me. Turn it into an inline block. Rossen: Is this an error case? Rossen: In which case I expect exceptions or something more dramatic Rossen: so as an author I can see something wrong and go fix it Rossen: rather than us trying to make it sorta work. <jensimmons> as an author I would expect that is the ‘right’ behavior Rossen: If this is an error, let's make this very obvious. Rossen: Otherwise if we patch it up so it sorta looks ok, then it's not going to be as good. <ChrisL> I agree with Rossen on this fantasai: Whatever we come up with is going to look weird. dbaron: To some extent, inline is a more obvious error than inline-block for something that was originally a block. fantasai: But is also more work fantasai: and I don't see that that is necessary. <liam> not sure about "let's break existing pages" - can't assume people will fix it fremy: what about display none? fantasai: Absolutely not. fantasai: This is the web platform and we do not make things disappear as an error case [except for XML draconian heads :P ] Rossen: Inlineness down recursively... Rossen: I would be in favor of either inline-block or block. jensimmons: I hear about things breaking more badly, but in a practical reality, most authors struggle to understand inline-block vs block vs inline does. jensimmons: I think make it inline-block make it seem less broken. jensimmons: Feels like make the outer inline while everything stays block is how it supposed to work? jensimmons: Authors are already struggling. Making it more broken for them is not going to help. fantasai: It is not really an error case fantasai: but we need to do something with it. TabAtkins: While doing inline-block is a little more complicated from the spec perspective, it is fairly insignificant, it's fairly straightforward, I'm happy to go with what makes more sense. astearns: I am hearing people are ok with either inline or inline-block astearns: but some pref for inline-block astearns: so we should resolve inline-block and see how it goes. astearns: Any objection to inline-block in this instance? RESOLVED: inline-block because they're awesomeish Blockification doesn't seem backwards-compatible for inline-blocks ------------------------------------------------------------------ github topic: https://github.com/w3c/csswg-drafts/issues/1246 <fantasai> issue under discussion https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850 TabAtkins: Exact opposite case TabAtkins: When you blockify an inline-block what happens? TabAtkins: Right now blockification just changes the outer display type to block TabAtkins: in particular for an inline-block, it becomes a block flow root TabAtkins: which when you ask its display type it says block flow root TabAtkins: but for legacy reasons it has to be block. TabAtkins: We probably need to do same sort of exception. TabAtkins: When you blockify an inline-block, it becomes a plain block TabAtkins: now that we have the opposite thing, it is reasonably consistent. fantasai: This is on the agenda because it is more complicated than that. <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850 <TabAtkins> Two possibilities ^^^ fantasai: We can treat inline-block and inline-flow-root as the same fantasai: alternatively we can treat ... as ... <fantasai> Treat inline-block and inline flow-root as syntactically equivalent. Make both of them blockfy as display: block. Treat inline-block and inline flow-root as syntactically distinct. Make inline-block blockify as display: block; inline flow-root will blockify as flow-root. fantasai: The advantage of first approach, is that the inline-foo are all syntactic equivalents. fantasai: The advantage of the second approach is ... <jensimmons> I vote (b). It makes sense that the flow-root-ness would stick around, imho. Rossen: The 2nd approach will round trip nicer through the OM right? TabAtkins: Doesn't matter yet. Rossen: The distinction between display outside and inside, which one will round trip more gracefully. fantasai: We have defined all the inline-* to all the inline-space-* etc. fantasai: We didn't have the display module in time to avoid the inline-... and inline-... fantasai: if you have a inline-space-table and read it back out in the OM it will take the shortest most compat form and return inline-table. fantasai: If we want the 2nd approach we have to not convert, maintain as a separate thing, e.g. inline-flex two ways to syntactically define it and would not collapse. Rossen: If we blockify a display block rather than inline flow root, and you read back the display and set it back on the same element, you are now going to turn an inline block into a block. fantasai: Yes that happens right now fantasai: for flexes and other things that blockify fantasai: happens in 2.1 and flex and grid. <fantasai> (via abspos, floats, etc.) Rossen: My understanding is ... blockification as opposed to flow root in terms of where positioned, it will try to be block as much as possible. TabAtkins: I am confused about what you are trying to say Rossen TabAtkins: anything inline-ish becomes blockish TabAtkins: inline-root becomes flow-root TabAtkins: inline-block becomes block. Rossen: The inline block will become a flow root? TabAtkins: Yup. Rossen: If I read back (static) what will be different. Rossen: Which one of those will be (static) be better (siren) Rossen: which of those two if re-parented, if any will have more expected behavior. TabAtkins: The flow root one will TabAtkins: that is the reason why blockificiation turns a inline-block into a flow root Rossen: ok that is why I am leaning more towards flow root. TabAtkins: So that sounds like you are suggesting 2nd one: TabAtkins: inline-block becomes block for legacy reasons TabAtkins: but inline flow root becomes block flow root. <fantasai> Option A: inline-block -> block; inline flow-root -> block <fantasai> Option B: inline-block -> block; inline flow-root -> flow-root astearns: Any other conversation on this? astearns: Any obj to inline space flow become inline flow root? fantasai: Main concern, we no longer treat inline-* and inline space * as equivalent. TabAtkins: For this specific value. astearns: In part for legacy reasons. TabAtkins: Entirely for legacy reasons. fantasai: But that means if you compute inline foo ... fantasai: But now we have to keep them distinct in the OM as well. TabAtkins: Yeah we will have to. astearns: Is your desire for syntactic equiv an obj? fantasai: No, just wanted to make it clear. dbaron: It is an extra point of confusion in that before we could say these two things are equivalent dbaron: but it is now more complicated because in this one case they are not. dbaron: The other question is whether you maintain separate computed values for just this one case or the whole possible space of values. TabAtkins: hmm. astearns: I would expect we would maintain equivalent where we can and this is the exception that proves the rule. <dbaron> I'm not crazy about the idea, but I'm not objecting to it... astearns: So. astearns: Do we resolve to use option b and work through the details? or shall we spend some more time working the details in the issue and come back to this? TabAtkins: I think we should resolve on b and I can open a separate issue on the point that dbaron just raised. TabAtkins: I'll open a separate issue for that. fantasai: My concern is that if we go with option b and then we have the other discussion, then we find we don't like and want to come back to option a. fantasai: b implies at least two things that a does not in terms of how other values behave fantasai: but that was not discussed in the issue in terms of a vs b. astearns: fantasai do you want to postpone making the resolution? or ok to have provisional resolution for b? fantasai: That is a more important discussion to have fantasai: and then decide this issue because I think it is less important. fantasai: The resolution here should depend on that discussion. TabAtkins: I disagree but I have no problem with changing the resolution later TabAtkins: if based on another discussion we decide we resolved wrong. astearns: When you open the new issue TabAtkins please link back to this one, so once we decide on the other one we can see if this resolution still holds. ACTION TabAtkins open new issue on what we are doing with the syntax equivalencies and linking back to this issue so we can revisit this resolution <trackbot> Created ACTION-852 astearns: Any objection to resolving on option b for current issue? RESOLVED: We are provisionally going with option b. Propagation of text-decoration with display:contents ---------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1136 astearns: Propagation of text-decoration. TabAtkins: Question: how do text-decorations propagate? on what tree do they propagate? they are not inheritance. something after inheritance. on box tree? element tree? or something else magic? TabAtkins: There are several arguments for box tree, in particular compat constraints. TabAtkins: If you have an inline with an underline TabAtkins: if you have a span underline ... <TabAtkins> <span underline>foo <div>INTERRUPTION</div> bar</span> TabAtkins: If you have this^ TabAtkins: the foo and the bar get underlined, the INTERRUPTION does not TabAtkins: because the block has broken the span apart. TabAtkins: If the decorations propagated through the element tree then the div would get the decoration TabAtkins: but if propagate through the box tree then that is what we see. dbaron: It is already specified in terms of the element tree, and just specifies that case <fantasai> https://drafts.csswg.org/css-text-decor-3/#line-decoration TabAtkins: It is not well specified from what we can see. dbaron: I believe we implemented it from a spec that was relatively clear. fantasai: I believe that was 2.1 fantasai: which does not distinguish between elements and boxes very well. dbaron: It was readable in terms of elements, and describes that case as don't do this thing dbaron: It explicitly said that. <fantasai> https://www.w3.org/TR/CSS21/text.html#decoration TabAtkins: That implies that display:contents as implications on how we treat that TabAtkins: whether that affects the decision. fantasai: It shouldn't make a difference element vs block tree in general, but it will affect once we have display:content fantasai: Question is whether you can propagate to text nodes which are new thing now. TabAtkins: Side question if you specify it on a display:contents element does it propagate to its contents? dbaron: In terms of that we impl on the box tree. TabAtkins: According to r... so do we. astearns: Any other interop data? <dbaron> we walk up the box tree, but through placeholders for out-of-flows fremy: Technically I can try... in IE. TabAtkins: I got it the opposite. TabAtkins: Fix up will interrupt decoration. fremy: example? <TabAtkins> https://bugs.chromium.org/p/chromium/issues/detail?id=553174 TabAtkins: Yes I have a CR example^ TabAtkins: This is interruption due to inline table. We are propagating, other browsers do not. dbaron: Beware of tables when testing text-deco because there are quirks mode diffs. fremy: ... apparently ... <dbaron> The Gecko code is at https://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/generic/nsTextFrame.cpp#5373 TabAtkins: What about the 2nd case? where element is an inline table? TabAtkins: (describes bug) fremy: I see what you mean. TabAtkins: Our impl is inconsistent. TabAtkins: The fact that these two cases should be identical in any sensible interpretation implies that it should be a box tree concept possibly with some nods to the element tree e.g. block that splits inline. fremy: I don't know either we would have to change something either way. astearns: Sounds like we need to spec this as box-tree concept and file bugs on browsers. TabAtkins: Chrome has a bug filed. astearns: Any objections to defining this as a box-tree concept? RESOLVED: Define this as a box-tree concept. Should anonymous boxes always inherit through the box tree? ----------------------------------------------------------- github topic: https://github.com/w3c/csswg-drafts/issues/1118 TabAtkins: This is about inheritance, not normal inheritance. TabAtkins: Do they inherit through box tree or element tree? TabAtkins: We have a diff in the thread there as a suggestion. TabAtkins: Aside from a few nits we don't have obj. well we have anti as disagreement. TabAtkins: Also says webkit could impl without much trouble. TabAtkins: It touches several specs TabAtkins: the implication of it is that in the example, first post in the thread TabAtkins: using the code provided where section provides a color and div provides a color TabAtkins: but div is display contents, the text will still be green TabAtkins: it won't turn red just because there is display contents involved. astearns: But if the div had an underline? TabAtkins: Decorations are weird and should not impinge on this. TabAtkins: This is just about normal inheritance. TabAtkins: Recall these two examples: <TabAtkins> <section color:red><div color:green display:contents> Foo</div></section> <TabAtkins> <section color:red><div color:green display:contents> <span>Foo</span></div></section> TabAtkins: First example, should text be green or red. TabAtkins: Second example, there is an absolute correct answer, and no way to question it. TabAtkins: 2nd example span inherits from div in ordinary way, and then foo gets its color from span. TabAtkins: It's just the 1st ex that we have question about. TabAtkins: Putting in an empty span like that shouldn't change how inheritance works TabAtkins: so the edit we put together, makes node text be stuff in the tree. TabAtkins: We have text nodes in the element tree, text runs in the box tree TabAtkins: means inheritance works the same in both cases TabAtkins: (describes color and boxes) astearns: I have not reviewed the diff, but I like the concept as described, would like to go forward. TabAtkins: If people feel they need more review that would be fine but if they are ok with it I would like to commit it. fremy: For us I think it would be fine. astearns: Any obj to going fwd with diff? RESOLVED: let's try it out, go forward with the diff astearns: Almost to the hour. that's it for today. astearns: Thanks everyone for calling in. <astearns> REMEMBER that next week's meeting is shifted to 4PM PT