[CSSWG] Minutes Seattle F2F Tue 2014-01-28 PM III: 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 ======


   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
   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

   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
   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

   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
   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

   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