- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Feb 2014 01:20:02 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Regions ------- Long discussion of - whether or not elements (as opposed to just pseudo-elements) should be allowed to become regions - whether or not / how this question is blocking progress - whether we care about flowing through chained boxes (we do) - various other concerns with regions and handling of issues thereof RESOLVED: close issue 1 on regions. Noted that there was a formal objection from at least one person. ====== Full minutes below ====== Regions ------- astearns: I am not Napolean. astearns: I'm Dr. Evil, apparently. astearns: I have "named flows", which will destroy the web. <glenn> anyone who says he's not napolean is napolean astearns: The issue is that Regions has a flow-from property that works on anything that can give it a box. Including HTML elements. astearns: So we can have empty non-semantic elements providing the presentational boxes for region chains. astearns: This is the only issue. astearns: But I think people use it as a proxy for other issues they have with Regions. ChrisL: Does anyone think CSS Zen Garden is "non-semantic"? They have tons of empty divs. astearns: So let's just talk about this one single thing. SimonSapin: Are there things other than elements that can take flow-from? astearns: It's designed to apply to anything that can generate a block container box. astearns: Currently that's only ::before/after with display:block. astearns: But there are proposals for lots of other things, like grid slots or page template slots. astearns: If we were to resolve in favor of the issue, flow-from would apply to *some* pseudo-elements, not others, and not elements. astearns: I think this issue is a big deal. Regions violates the separation of concerns, and this has to be justified. astearns: Right now we do this out of necessity, because there's no other way to generate boxes. I think it's justified. astearns: I'd like the poll to be "Who thinks we should resolve that Regions only apply to pseudo-elements that can generate block container boxes, and not elements?" dbaron: I'm not sure I agree with either position. <dbaron> ...I think the issue is an issue, but that's not how I would want to see it solved. Bert: My position is that there's no point putting out a Regions draft without a way to make regions in CSS. This leads to bad pages. Bert: Whatever we allow later, we should first allow people to do it the right way. astearns: That's new information for me. I thought your position was that we should only have this mechanism work for in-CSS boxes. Bert: With the 'content' property you can do anything. I don't think we should disallow that. Bert: (With syntax quibbles.) Bert: But my point is, before we allow people to do things the wrong way, we need to allow them to do it the right way. <glazou> Bert's position is reasonable * fantasai agrees with Bert, fwiw glazou: We had ::slot on the radar before. ChrisL: The separation isn't a religious position. It has practical effects. ChrisL: There isn't ever a piece of content for all possible purposes. You have to decide how much to rewrite vs restyle. ChrisL: So we don't want to encourage people to write content with drastic rewriting just to restyle. ChrisL: But still, we must accept that in some cases there will be rewriting - mobiles might get smaller chunks of content. ChrisL: So content/style is often only one way anyway - most stylesheets are deeply connected to the content they're applied to. ChrisL: But also, the important thing is just that it not *prevent* reasonable restyling without significant rewriting. ChrisL: So I don't think we should preclude people putting content into HTML boxes. florian: I'd like to get back to David's position. dbaron: I think there are multiple pieces. dbaron: One is that I think Chris's reasons for separation are incomplete - there are more. dbaron: A bunch of technology designed around that separation in various ways assumes that the content is in the content. dbaron: Various APIs, UIs. Selection, event models, etc. ChrisL: Searching, indexing. dbaron: I think some of what this issue has come to represent is that the design is very different than CSS in ways we can't quite put our finger on. dbaron: We can't quite say what is weird about it. dbaron: I think it's different from a bunch of things in a bunch of different ways. dbaron: e.g. you have to do things in two pieces, and if you don't do both (correctly), content just disappears astearns: I agree that it's different, and that there are other concerns. astearns: That do need to be addressed. dbaron: Some concerns are about how it fits with APIs. dbaron: How the author experience is different from the rest of CSS. dbaron: And how it interacts with other layout algorithms. astearns: As I said, I'd like to just talk about this one issue right now, and discuss the rest after. astearns: I'd like to get past this one issue and get past it to everything else. astearns: The messages you've put on the list recently, concerns about processing model, I'd like that to be a conversation rather than a pronouncement and then nothing. dbaron: I think that whittling down a problem sets one at a time... it's troubling taking them one at a time. dbaron: You bring up an issue, say this one issue by itself is not enough to block spec in order to close the issues one by one. astearns: I find it heartening, Bert, that even if we had any slot mechanism, you'd still allow that escape valve to use other boxes, such as from elements. Bert: I just think 'content' should be more powerful. Bert: From that, it falls out that you can omit the content of an element by using 'content'. glazou: In the past we designed a mechanism for dispatching content to various boxes. glazou: You can say an element should be rendered on a page with a given selector. glazou: Basically flow-from/to is the same. TabAtkins: I don't think it's sufficiently close. florian: As many people have been wrestling with as well, I think why I'm uncomfortable is that it seems we're introducing a new separation, in addition to styling/content. florian: So far, the thing that contains your semantic document is also the thing you style. florian: With regions, you have a set of elements on your page. You fetch your markup, then inject it somewhere else. florian: So should that be additional elements, should it be CSS, something else? florian: But it seems we're not styling the original markup. We're styling what you inject it into. ChrisL: You're styling the container. You could make the same argument about abspos - it's not in its original placement anymore. <dbaron> I make many arguments against absolute positioning. astearns: And it's already common practice to template in HTML, slurp in content and fill out the template. florian: I'm not necessarily saying this is an argument against regions, just that realizing this made it clearer to me. leif: It does seem that we are talking about a new mechanism. dauwhe: There does seem to be an extra layer of indirection that feels odd, not necessarily bad or good. astearns: Templating layers have been attempted before, between HTML and CSS. We haven't come up with one that works yet. astearns: I expect people will continue working with that. dauwhe: Yeah, we have content like a monolithic HTML file that can be rendered in many different ways. At this point it seems hard to imagine using our content with Regions. astearns: I think your use-case is good for HTML templates, where you have that separate layer of concerns. astearns: So, looping back to the issue. astearns: It sounds like a concern that people have about the issue is that regions-as-elements is currently the only way to use flow-from, because we don't have the CSS box generation. astearns: And they'd be much more comfortable with defining the CSS box generation before we continue. astearns: I can sympathize with that. astearns: I think grid slots are going to be a perfect mechanism to use with Regions. astearns: But I don't see that happening for at least another year or two. astearns: I'm a bit impatient, so I'd like to continue on with Regions without having to wait. astearns: Particularly since we've defined Regions to be compatible with anything that CSS comes up with. Bert: I'd rather work on 'content' first, since 'flow-from' conflicts. Bert: That's a detail of the syntax. Nothing against the feature. Bert: I think a missing feature is the ability to order the regions. astearns: We had it, we took it out. It could go back in. dbaron: Order is currently document order of the regions? glazou: Yeah. <dbaron> I think putting that back in makes it extra scary in terms of implementation complexity. astearns: I think we should certainly have the discussions about the feature itself. I just want to close this issue itself. astearns: I'm not going to ask for LC anytime soon. fantasai: What's blocking us from working on this? astearns: Beating us about the head about this one issue. ^_^ astearns: I think using flow-from on CSS-generated boxes needs to be done. glazou: Alan and I put together a proposal for more pseudo-elements. Wasn't perfect, but we have to continue in that. astearns: There just doesn't seem to be impl interest in generating CSS boxes. Lots of interest in Regions themselves. I think that should balance what we do first and progress with. dbaron: I think they're all hard to implement. dbaron: You've gone and done that work for one of them - there's demos and impls for it. dbaron: To some extent that's good - stuff to test - but there's still a bias because it's done for Regions and not for anything else. astearns: The effort we put into evangelizing it also shows the interest. astearns: There are Windows devs I didn't evangelize to that started using it in IE and love it. astearns: We hope people will start using it in iOS, and their use will inform the evolution. glazou: I think starting from a prototype and getting usage data is very common in this WG. Happens all the time. ChrisL: Something that tends to happen is that another browser does it, and you see if it's actually interoperable. ChrisL: I think we have a second impl in IE, but it's based on earlier stuff. Is it comparable? Rossen: When we implemented Regions, the spec was at a much earlier stage. Rossen: I'm happy to keep moving the spec forward, and think it's favorable. Rossen: Moving our impl toward the spec won't be a problem when it stabilizes won't be a problem. ChrisL: Right, but one of the things that helps stabilize is another impl actually implementing it. astearns: I agree. It would be fantastic for IE to move up to the current level of the spec. astearns: But I understand the dev costs - twice as much to sync now and when finished. astearns: We think that if you author content in Safari, it's a very light shim to make it work in IE. Just a difference about where it comes from. Rossen: From our POV, Safari just released this 2 months ago. Before that there was nothing else public. Not much incentive for us to track closely. Rossen: Apps built on it seem to be very successful. Rossen: The people developing apps are embracing elements. They have everything they need to do to make a working app. astearns: And their use there should inform how we design the CSS feature. [...] Rossen: Regions are just used in lots of applications. Rossen: All sorts of ways to present content. Rossen: They create HTML templates into which they feed content. <ChrisL> "In blink we're pushing for simpler primitives that empower developers to build frameworks and applications." <ChrisL> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/kTktlHPJn4Q/0r4yjDGWJFEJ <ChrisL> "It's important to understand that Blink has different goals than WebKit. It's not that I don't care about viewing books or magazines, it's that I'm more interested in making the web a compelling platform for applications" -- Adam Barth <ChrisL> (same url) glazou: To summarize, I'm hearing there are use-cases for this, shipped by several vendors. We need a mechanism to create CSS boxes. But for the time being, the fact that it applies onto to HTML elements is just a side-effect of the lack of that mechanism. astearns: Is there anyone in this discussion that would object to closing this issue, so we can focus on everything else? [?] leif: I don't want it to apply only to elements either, but I don't want to stop work on the spec either. leif: Not sure that I caught the proposed resolution. [Bert and astearns talking about doing things in the right order. Bert agrees that some application use cases are handled well enough here, but that many others need a box generation mechanism.] florian: So I think we have three options. astearns: 1) Disallow flow-from on elements. (What the issue says.) astearns: I think we've rejected that. astearns: 2) Close the issue with no change - allow it to apply to elements and existing block pseudos, and allow it to apply to more pseudos when they get invented. astearns: 3) Allow it to apply to both, but don't close this issue until there's another method to create boxes. leif: I want to maintain the separation of concerns indefinitely into the future. I think this is the biggest step CSS has made in this direction. leif: I think we should give better solutions a place, rather than doing elements for temporary convenience. florian: That matches (1). Does anyone have a fourth thing? dbaron: I think fourth would be recognizing that we have a proposal with some advantages and disadvantages, and I don't like just crossing off the disadvantages one by one. szilles: We only have one solution on the table, though. Any others are off in the air so far. florian: I think I share a number of David's concerns. florian: I'm not yet comfortable with the general concept of Regions, but I think the point we're currently discussing is not a blocker. florian: So in the interest of getting the other issues on the table, resolving this one which *is* well defined, seems like a reasonable thing to do to me. fantasai: I think Regions is useful and well-designed if we have a box-generation mechanism. And if you have an iframe as a source. fantasai: I think I can see an element pulling in the contents of another document and flowing things in. That makes sense to me structurally. (This is the reader-app use case.) fantasai: Having a document that is then styled using box-generation mechanisms, templates, etc. also makes sense to me. fantasai: Having a document with lots of empty elements doesn't make sense to me. I don't think we want that as an end result. astearns: I agree. I think that third thing is only forced on us by the current state of the web platform, and I'd very much like to see it replaced by box generation. fantasai: Okay. And I think Leif's point is that if a feature is designed in a bad way, we shouldn't create it even temporarily, because we'll be stuck with it forever. szilles: An important aspect of what fantasai said - there are three components that are necessary to do this: content, styling, and template. szilles: What fantasai said is that one way to get all three is to have a document that's the template, and a document that's the content, and I can pour the content document into the styling document. szilles: So your content document doesn't change, and you get good separation. fantasai: I think the objections you're getting are largely through the flow-from capability, and not the rest of processing and layout model. astearns: I disagree. The fragmentation model, the way named flows are constructed... I think David has deep-seated concerns about all of these things that I'd like to get discussed on the list. shepazu: I agree that you can get into a bad state by just doing things one issue at a time rather than holistically, but also with Alan's statement that we can't look at it holistically until we deal with this issue. dauwhe: You said holistically - is it blasphemy to say that Regions should be attached to a document that does the box generation? Bert: I think in the ideal case we should say that the template part isn't text/html, some other format. astearns: I have my opinion on what it'll end up with, but I don't think it matters for Regions specifically how that templating mechanism gets expressed. Bert: Not for the spec, but for impl perhaps. astearns: Certainly. That's why we've been working on the Regions processing model. * fantasai thinks we should work on the overflow: fragments; proposal, and that would be a way of making technical progress on regions in a non-controversial way * hober thinks that Alan is not preventing the overflow:fragments proposal from being advanced by those who want to work on it * fantasai isn't saying he is <astearns> +1 hober. I like the overflow:fragments proposal :) <astearns> I just don't think it addresses the same use cases <TabAtkins> it covers a strict subset of the use-cases. * fantasai is saying that using that, rather than flow-into/flow-from, as the mechanism to develop the relevant aspects of the CSS Regions spec, would be a better way to make progress. And then once you have solved all of those problems, can move onto more problems. * fantasai also thinks, on a completely different tangent, that CSS needs a Table of Contents <ChrisL> an autogenerated cross-document index of defined terms would be lovely, too florian: David, you mentioned that Regions does things in an unusual way, and it makes you uncomfortable. florian: Is the indirection I said the same thing as what you said? florian: What makes me feel weird is the whole indirection concept in the first place. Is that also what concerns you? Or is it something else? dbaron: There are parts of CSS where the way the spec is written is close to how it's implemented. dbaron: There's not a ton of weird derivation you have to deal with. dbaron: Layout systems are quite different. To implement them, you have to read separated parts of specs, and derive their interactions. dbaron: That's something that worries me a lot. dbaron: There are a lot of implicit ordering constraints. dbaron: For example, you have to lay out floats interleaved with inlines on the line they're anchored on, but abspos at the end of laying out their containing block. dbaron: Part of what worries me is that we don't even understand the system well enough to understand the implications of changing this to allow flowing between these layout systems. dbaron: And what that means for what authors expect. dbaron: 'order' only applies in very limited circumstances, for Flexbox, and it barely depends on ordering anyway. astearns: That's also why we took out ordering - it makes things way more complicated. dbaron: I don't even fully understand the implications for how pagination interacts with auto-sizing. dbaron: And what things would get us into interesting infinite loops if we weren't limited to 2-pass. fantasai: There's a bunch of problems in Regions. Some of them are also overflow:fragments problems. Afaict, everyone thinks overflow:fragments is okay. fantasai: I propose that instead of spending 2 hours every f2f arguing over flow-from, we focus on the overflow:fragments proposal for solving the technical problems with flowing through chained boxes. Get that spec nailed down. fantasai: And then, when that's working, we've solved all the problems in regions that also apply to overflow:fragment, and we can look at the next chunk of things to bite off. astearns: We've done that analysis. We found that overflow:fragments is not generic enough for the applications we want to put Regions to. astearns: It doesn't fit anything people put regions to with IE. astearns: We have two impls of Regions that are being used, and devs that are super-excited about it. astearns: I don't see the interest in overflow:fragments, I think because it has limitations. TabAtkins: I don't quite agree. Regions has been sold very well, but overflow: fragments has been barely talked aobut. TabAtkins: There are some things you can't do with it, but a lot of things you can. Rossen: Layout is the least interesting thing here. We take it for granted. Rossen: For us, if people can't use the Regions primitives, it's useless. TabAtkins: Note that "fragmenting like pages" is what overflow:fragments does. ^_^ Rossen: Right. But with elements you get OM, events, etc too. TabAtkins: Granted. astearns: We're not currently interested in just doing overflow:fragments. TabAtkins: Well, we have two browsers that want to use Regions, and two that want to do simpler things first. fantasai: [draws a list of things on the board] fantasai: #4 (elements as regions) isn't part of our eventual goal. We both agree on this. astearns: Right. It's a stepping-stone. smfr: I think WK is interested in having that long-term. astearns: I think it's good for solving some things forever. I'd like to keep it. Bert: Talking about documents, we don't want this. Talking about GUIs, we're fine with this. fantasai: That's #2 (reader-content, document-in-document). astearns: #2 can be done with #4. smfr: also has concerns about multiple-document approach Scribe: ChrisL (fantasai has 4 cases on the whiteboard) sylvaing: don't understand how fragments solves all the use cases fantasai: it doesn't fantasai: alan want to close the one issue sylvaing: how does closing it solve those issues dbaron: also solved the ordering layout issues but not sure how many dbaron: regions lets you flow between different types astearns: currently allows you to do the same thing sylvaing: for everything else, don't see how fragments currently fixes the issues dbaron: there are paths for fixing some of the problems that would not apply to regions shepazu: this separation is irrelevant for svg which wants to do complex wrapped text but was blocked by css shepazu: the proposal works very well for svg and could work well in html later smfr: sounds more like exclusions to me shepazu: want to see this move forward at minimum for svg fantasai draws a complex meme-worthy mind map on most of the board ... with a happy place fantasai: can start with regions, then build templates and overflow fragments fantasai: or start with overflow fragments, then build templates, and iframe flows fantasai: for the super advanced cases, eventually work on regions astearns: see your point but this loooong path is much longer than the small loop because we worked on regions for 2 years with two engineering teams astearns: getting it shipping in 2 browsers, while overflow fragments is not implemented and has the longest list of issues astearns: a lot is already built on top of regions, and those can't be built on fragments without a lot of scripting florian: if we discover the happy place is actually not nice, by fixing all the "how" before examining the "should" we waste time florian: not convinced its a bad idea but we need that discussion astearns: getting examples of regions in actual use is valuable. we learn from how developers actually use them astearns: we can talk in theory about what is good or not good, but the actual uses people put it to is more convincing florian: less worried than dbaron but understand his worry. It's not that we have a lot of issues, its more that we are not sure if we should be doing it at all astearns: have not heard that sentiment. More that there are crucial issues that affect the platform. dbaron: am hearing that, and hearing "name specific things to fix" instead shepazu: what in particular is not a good idea? fantasai: having those elements be there in the document just to flow into florian: if I was alone i would drop my concerns, but want to back up dbaron SteveZ: what is the goal here shepazu: dbaron you said it was not clear from the beginning. It's what we should be doing. What should we be doing? dbaron: mainly worried about the complexity shepazu: ok so not the functionality itself, just the complexity shepazu: (call for straw poll, gets about 2/3 or room in favour of the functionality of flowing content through chained boxes) shepazu: it's necessary to have the flow, to have the shaped flow astearns: Shaped flow is in shapes level 2. It's hard. dbaron: question isn't just about whether it's desirable, but whether it's the best (or reasonably good) thing we could do with the resources we put into it, relative to alternative uses of those resources krit: overflow:fragment would not help for svg, it creates pseudo boxes shepazu: not hearing agreement about wanting to do flow-like things. Not up to the people in the room. It's up to the developers that want this feature glazou: shapes-like, exclusion-like stuff is all over books, magazines, will be in ebooks who are a css custoomer glazou: if we decide we don't want this, then it means we refuse to address this market or their feedback florian: the question alan posed has been used as a proxy for exactly that question. Do we address that market or not? florian: worth answering explicitly. We have not said yes. As a group we have said maybe. florian: Personally would answer yes. ChrisL: agree dbaron: you are asking "does it have value" not "what is the value/cost tradeoff" compared to "content working at a range of device sizes". Some of these are not scaling. shepazu: media queries lets you make scalable designs <dbaron> and what is the tradeoff against other requirements astearns: chrome has decided to not do that. ff has too. safari and ie have jumped in with both feet. not clear where opera stands. so at least half the implementors think the tradeoff is worth making fantasai: When Microsoft first came to us with a proposal for solving grid layout, we told them it had fundamental design flaws (due to being based on absolute positioning). fantasai: They went back to the drawing board, then came back with a proposal that solved all of those concerns, which is now our Grid Layout spec. fantasai: Adobe has not done this with Regions. astearns: we have had actionable feedback on regions and incorporated it shepazu: point is, is there a consensus in the group to work on it. at least two vendors have said this is a use case they want to adderess. have not seen commitment from the others <fantasai> shepazu, I don't think anyone here things the problem of flowing content through various boxes is not worth solving <fantasai> shepazu, the argument is that the Regions proposal does it in ways that do more harm than good. TabAtkins: As a rep of one browser not doing it right now. We don't have problem with people working on Regions, but don't want it finalized until we're ready to implement. TabAtkins: We are happy to let Regions continue as WD TabAtkins: would not like regions to go to LC until we are ready to implement but for now happy to see it continue krit: you want to stop it going to last call? krit: so you say we should wait until blink implements it to declare it stable peter: (rathole) shepazu: straw poll on whether we want to solve content flowing through disjoint boxes? fantasai: *not* the question of whether Regions is the way we want to do it (no objection) <dbaron> no objection to taking it on as a work item fantasai: no-one is objecting to the problem, only the proposed solution Rossen: can we get back to the original issue then <liam> [something _like_ flows and regions is very central to needs of publishing, flows through disjoint boxes] dbaron: not sure on tradoff to other problems worth solving SteveZ: each group of participants is pursuing their own agenda and may get another participant to ride along but we are all heading off in different directions SteveZ: lots of things not making much progres SteveZ: so your comment applies to many things on our agenda SteveZ: concerned that 2.1 was a very focussed effort while post-2.1 has been much more diffuse. slowing down and broadening faster than we are finishing SteveZ: hence some concern from w3m about finishing things SteveZ: this is a meta comment TabAtkins: we have done significant consensus building around the idea of shadow dom [Tab was implying that Regions does not have such consensus] dauwhe: see lots of different efforts, no sense of an overall goal glazou: correct dauwhe: coming from content creation so have my own biases and interests. wonder what the overall priorities are glazou: each vendor had their own strategy based on target audience. compromise is thus weak glazou: many areas of focus on the radar, everything relies on what the implementors are willing to implement and ship glazou: needs of content creators not so much considered. general feeling that a spec at last call or cr is good enough florian: if we ask the questions explicitly, most will say yes go ahead. florian: so the second question, dbaron: depends on wording of the poll astearns: would rather deal with reservation as they arise, do not want to cut off discussion fantasai: Clear to me that there is a substantial part of wg that feels this is very important. Shipping products on it. So we work on it. fantasai: There is no point in arguing that the CSSWG should not work on chained flows because you personally want the WG to have different priorities. fantasai: Different vendors have different priorities. Nobody cares to work on e.g. vertical text, but it's important to some people so we work on it and don't block it. fantasai: However, there *is* a point on arguing how to make a good solution so people are happy to implement when it becomes a priority for them. * dauwhe +1 to fantasai astearns: If we have about half the wg engaged in this and the consensus is that this technology should allow flow-from to apply to elements as well as other boxes astearns: blocking discussion on other things leif: will stop being a proxy if you disallow it applying to elements astearns: leif you were the only one to want that disallowed fantasai: How is this issue blocking discussion of other issues? astearns: blocking and the issue should be resolved without change because nearly everyone thinks that will be the end result anyway bbos: think we will not have a flow-from property bbos: want to talk about region-based styling astearns: do we a) solve by waiting for a css box generation model b) no change c) stop progress on regions glazou: (reads earlier formulation from irc) 1) Disallow flow-from on elements. (What the issue says.) 2) Close the issue with no change - allow it to apply to elements and existing block pseudos, and allow it to apply to more pseudos when they get invented. 3) Allow it to apply to both, but don't close this issue until there's another method to create boxes. 2 3 2 2 - 2 2 2 - 2 2 2 (3) 2 2 - 2 2 1 2 - 2 2 2 the twoes have it glazou: declare a consensus RESOLVED: close issue 1 on regions. Bert: formal objection <dbaron> I'd note that I abstained. <fantasai> I think I probably agree with Bert <fantasai> and I don't really understand why dbaron abstains, he seemed pretty opinionated <dbaron> I hadn't decided which option of those 3 that I actually preferred. <dbaron> (the other three abstentions were from observers) <dbaron> I'd have preferred to leave the issue open <dbaron> but the reason I'd want to keep it open wasn't "until there's another method to create boxes", but because it's an existing disadvantage with the spec that we should consider when deciding whether to advance the spec. <dbaron> so I suppose my vote was a semi-3 <dbaron> except that 3 was overconstrained Meeting closed.
Received on Tuesday, 4 February 2014 09:20:34 UTC