- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 May 2017 16:30:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `inlinification`, and agreed to the following resolutions: * `RESOLVED: inline-block because they're awesomeish` <details><summary>The full IRC log of that discussion</summary> <ChrisL> topic: inlinification<br> <tantek> github topic: https://github.com/w3c/csswg-drafts/issues/1341<br> <tantek> TabAtkins: our current ... does ... but not ...<br> <tantek> TabAtkins: in order to keep certain inline layout modes in particular ruby from being broken up by blocks sohwing up in<br> <tantek> TabAtkins: we use inlinification<br> <tantek> TabAtkins: but as currently defined in the display module it might be too aggressive<br> <tantek> TabAtkins: in particular it turns current blocks bfcs into inlines<br> <tantek> TabAtkins: which preserves the inliniciation but almost certainly messes up your intended layout<br> <tantek> TabAtkins: Blocks become inlines.<br> <TabAtkins> s/current blocks bfcs/plain blocks (not bfcs)/<br> <tantek> TabAtkins: the other way we could do it<br> <tantek> TabAtkins: make all types of blocks, flow root or flow, turned inline blocks<br> <tantek> TabAtkins: this would preserve display a bit more closely to what intended<br> <tantek> TabAtkins: inline block<br> <tantek> TabAtkins: but is a little more complicated in the spec<br> <tantek> TabAtkins: otoh we probably have to do the opposite for blockifications, turning inline blocks into block flow, not block root<br> <tantek> TabAtkins: if anyone knows of any impl difficulty one way or another, let us know<br> <Rossen> <div> text <span> more text <div>am I inline?</div> end text </span></div><br> <tantek> TabAtkins: otherwise we may go the latter way, inline blocks turning into plain blocks<br> <tantek> Rossen: I have a question and just pasted an example<br> <tantek> Rossen: (describes example)<br> <tantek> TabAtkins: inlinification is not triggered by that<br> <tantek> TabAtkins: but if instead of a span you had a ruby<br> <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?<br> <tantek> TabAtkins: it would no longer be a block<br> <tantek> Rossen: what does inlinification apply to<br> <tantek> TabAtkins: ruby bases and text, and I think there is one more context, run-ins?<br> <dbaron> But inlinification of block -> inline-block does seem to make sense, as long as there aren't compatibility problems.<br> <dbaron> What do implementations do?<br> <tantek> Rossen: in that case if it is only tied to those 2-3, then it shouldn't be much of a problem<br> <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'.<br> <tantek> 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<br> <tantek> 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<br> <tantek> fantasai: as far as we are concerned there is only one impl of Ruby spec<br> <fantasai> s/inline/inline-layout/<br> <fantasai> s/Ruby/CSS Ruby/<br> <tantek> Rossen: how many impls follow HTML ruby spec?<br> <tantek> Rossen: ruby spec as it is not ready for imply in our opinion that is why we are not impl it<br> <tantek> Rossen: re: ruby interop, HTML ruby interop is good<br> <tantek> Rossen: then there is the spec in the works which it is hard to argue what is interop and what is not<br> <tantek> Rossen: question, do we know what is from the author / content point of view the expected behavior?<br> <tantek> Rossen: do we not break anything in the ruby context e.g. blocks? or do we need to blockify?<br> <tantek> 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<br> <tantek> fantasai: we are trying to stop the bleeding<br> <tantek> fantasai: we don't want ot have to deal with how do you break ruby annotations across lines<br> <tantek> fantasai: so we are inlinifying<br> <tantek> fantasai: similar for run-ins<br> <tantek> fantasai: e.g. if you have a headline and want to run into the next paragraph<br> <tantek> fantasai: if you stuck a block in that headline, then it's not going to run-in properly<br> <tantek> fantasai: we could say if you have a block inside, then you could say it does not run-in<br> <tantek> fantasai: but then you have to inspect all the way down<br> <jensimmons> +1<br> <tantek> fantasai: we just want to check the element its properties and parent(s)<br> <tantek> fantasai: ... inline-block ...<br> <tantek> fantasai: or we ... to turn into inlines<br> <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.)<br> <tantek> fantasai: ... everything is contain in a bfc that is now inline<br> <tantek> Rossen: I agree with that logic<br> <tantek> Rossen: is this an error case?<br> <jensimmons> what fantasai just said sounds right to me. Turn it into an inline block<br> <tantek> Rossen: in which case I expect exceptions or something more dramatic<br> <tantek> Rossen: so as an author I can see something wrong and go fix it<br> <tantek> Rossen: rather than us trying to make it sorta work<br> <jensimmons> as an author I would expect that is the ‘right’ behavoir<br> <tantek> Rossen: if this is an error, let's make this very obv<br> <tantek> Rossen: otherwise if we patch it up so it sorta looks ok, then it's not going to be as good<br> <ChrisL> I agree with Rossen on this<br> <tantek> fantasai: whatever we come up with is going to look weird<br> <tantek> dbaron: to some extent, inline is a more obv error than inline-block for something that was originally a block<br> <tantek> fantasai: but is also more work<br> <tantek> fantasai: and I don't see that that is necessary<br> <tantek> ??? : what about display none?<br> <tantek> fantasai: absolutely not<br> <fantasai> s/???/fremy/<br> <tantek> fantasai: this is the web platform and we do not make things disappear as an error case [except for XML draconian heads :P ]<br> <gsnedders> s/???/francois/<br> <tantek> Rossen: inlineness down recursively...<br> <tantek> Rossen: I would be in favor of either inline-block or block<br> <tantek> 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<br> <tantek> jensimmons: I think make it inline-block make it seem less broken<br> <tantek> jensimmons: feels like make the outer inline while everything stays block is how it supposed to work?<br> <tantek> jensimmons: authors are already struggling. making it more broken for them is not going to help<br> <tantek> fantasai: it is not really an error case<br> <tantek> fantasai: but we need to do something with it<br> <tantek> 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<br> <tantek> astearns: I am hearing people are ok with either inline or inline-block<br> <tantek> astearns: but some pref for inline-block<br> <tantek> astearns: so we should resolve inline-block and see how it goes<br> <Rossen> inline-block ftw because they are awesome(ish)<br> <tantek> astearns: any objection to inline-block in this instance?<br> <tantek> RESOLVED: inline-block because they're awesomeish<br> <tantek> astearns: next thing<br> <tantek> TabAtkins: exact opposite case<br> <tantek> TabAtkins: when you blockify an inline-block what happens<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1341#issuecomment-305242572 using your GitHub account
Received on Wednesday, 31 May 2017 16:30:34 UTC