- 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