SV_MEETING_TITLE -- 29 Jan 2014

elements as regions

<TabAtkins> astearns: I am not Napolean.

<TabAtkins> astearns: I'm Dr. Evil, apparently.

<TabAtkins> astearns: I have "named flows", which will destroy the web.

<glenn> anyone who says he's not napolean is napolean

<TabAtkins> astearns: The issue is that Regions has a flow-from property that works on anything that can give it a box. Including HTML elements.

<TabAtkins> astearns: So we can have empty non-semantic elements providing the presentational boxes for region chains.

<TabAtkins> astearns: This is the only issue.

<TabAtkins> astearns: But I think people use it as a proxy for other issues they have with Regions.

<TabAtkins> ChrisL: Does anyone think CSS Zen Garden is "non-semantic"? They have tons of empty divs.

<TabAtkins> astearns: So let's just talk about this one single thing.

<TabAtkins> SimonSapin: Are there things other than elements that can take flow-from?

<TabAtkins> astearns: It's designed to apply to anything that can generate a block container box.

<TabAtkins> astearns: Currently that's only ::before/after with display:block.

<TabAtkins> astearns: But there are proposals for lots of other things, like grid slots or page template slots.

<TabAtkins> astearns: If we were to resolve in favor of the issue, flow-from would apply to *some* pseudo-elements, not others, and not elements.

<TabAtkins> astearns: I think this issue is a big deal. Regions violates the separation of concerns, and this has to be justified.

<TabAtkins> astearns: Right now we do this out of necessity, because there's no other way to generate boxes. I think it's justified.

<TabAtkins> 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?"

<TabAtkins> dbaron: I'm not sure I agree with either position.

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

<dbaron> ...I think the issue is an issue, but that's not how I would want to see it solved.

<TabAtkins> Bert: Whatever we allow later, we should first allow people to do it the right way.

<TabAtkins> astearns: That's new information for me. I thought your position was that we should only have this mechanism work for in-CSS boxes.

<TabAtkins> Bert: With the 'content' property you can do anything. I don't think we should disallow that.

<TabAtkins> Bert: (With syntax quibbles.)

<TabAtkins> glazou: We had ::slot on the radar before.

<fantasai> Bert^: But my point is, before we allow people to do things the right way, we need to allow them to do it the right way.

<glazou> Bert's position is reasonable

<TabAtkins> ChrisL: The separation isn't a religious position. It has practical effects.

<TabAtkins> ChrisL: There isn't ever a piece of content for all possible purposes. You have to decide how much to rewrite vs restyle.

<TabAtkins> ChrisL: So we don't want to encourage people to write content with drastic rewriting just to restyle.

<glazou> major discussion about the CSS Regions frenzy right noz here

<TabAtkins> ChrisL: But still, we must accept that in some cases there will be rewriting - mobiles might get smaller chunks of content.

<TabAtkins> ChrisL: So content/style is often only one way anyway - most stylesheets are deeply connected to the content they're applied to.

<TabAtkins> ChrisL: But also, the important thing is just that it not *prevent* reasonable restyling without significant rewriting.

<TabAtkins> ChrisL: So I don't think we should preclude people putting content into HTML boxes.

<TabAtkins> florian: I'd like to get back to David's position.

<TabAtkins> dbaron: I think there are multiple pieces.

<TabAtkins> dbaron: One is that I think Chris's reasons for separation are incomplete - there are more.

<TabAtkins> dbaron: A bunch of technology designed around that separation in various ways assumes that the content is in the content.

<TabAtkins> dbaron: Various APIs, UIs. Selection, event models, etc.

<TabAtkins> ChrisL: Searching, indexing.

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

<TabAtkins> dbaron: We can't quite say what is weird about it.

<TabAtkins> dbaron: I think it's different from a bunch of things in a bunch of different ways.

<TabAtkins> dbaron: [something about two pieces]

<ChrisL> to-pieces

<TabAtkins> astearns: I agree that it's different, and that there are other concerns.

<TabAtkins> astearns: That do need to be addressed.

<fantasai> dbaron: e.g. you have to do things with two pieces, and if you don't do both (correctly), content just disappears

<TabAtkins> dbaron: Some concerns are about hwo it fits with APIs.

<TabAtkins> dbaron: How the author experience is different from the rest of CSS.

<TabAtkins> dbaron: And how it interacts with other layout algorithms.

<TabAtkins> astearns: As I said, I'd like to just talk about this one issue right now, and discuss the rest after.

<TabAtkins> astearns: I'd like to get past this one issue and get past it to everything else.

<TabAtkins> astearns: The messages you've put on the lsit recently, concerns about processing model, I'd like that to be a conversation rather than a pronouncement and then nothing.

<TabAtkins> dbaron: I think that whittling down a problem sets one at a time... it's troubling taking them one at a time.

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

<TabAtkins> Bert: I just think 'content' should be more powerful.

<TabAtkins> Bert: From that, it falls out that you can omit the content of an element by using 'content'.

<TabAtkins> glazou: In the past we designed a mechanism for dispatching content to various boxes.

<TabAtkins> glazou: You can say an element should be rendered on a page with a given selector.

<TabAtkins> glazou: Basically flow-from/to is the same.

<TabAtkins> TabAtkins: I don't think it's sufficiently close.

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

<TabAtkins> florian: So far, the thing that contains your semantic document is also the thing you style.

<TabAtkins> florian: With regions, you have a set of elements on your page. You fetch your markup, then inject it somewhere else.

<TabAtkins> florian: So should that be additional elements, should it be CSS, something else?

<TabAtkins> florian: But it seems we're not styling the original markup. We're styling what you inject it into.

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

<TabAtkins> astearns: And it's already common practice to template in HTML, slurp in content and fill out the template.

<TabAtkins> florian: I'm not necessarily saying this is an argument against regions, just that realizing this made it clearer to me.

<TabAtkins> leif: It does seem that we are talking about a new mechanism.

<TabAtkins> dauwhe: There does seem to be an extra layer of indirection that feels odd, not necessarily bad or good.

<TabAtkins> astearns: Templating layers have been attempted before, between HTML and CSS. We haven't come up with one that works yet.

<TabAtkins> astearns: I expect people will continue working with that.

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

<TabAtkins> astearns: I think your use-case is good for HTML templates, where you have that separate layer of concerns.

<TabAtkins> astearns: So, looping back to the issue.

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

<TabAtkins> astearns: And they'd be much more comfortable with defining the CSS box generation before we continue.

<TabAtkins> astearns: I can sympathize with that.

<TabAtkins> astearns: I think grid slots are going to be a perfect mechanism to use with Regions.

<TabAtkins> astearns: But I don't see that happening for at least another year or two.

<TabAtkins> astearns: I'm a bit impatient, so I'd like to continue on with Regions without having to wait.

<TabAtkins> astearns: Particularly since we've defined Regions to be compatible with anything that CSS comes up with.

<TabAtkins> Bert: I'd rather work on 'content' first, since 'flow-from' conflicts.

<TabAtkins> Bert: That's a detail of the syntax. Nothing against the feature.

<TabAtkins> Bert: I think a missing feature is the ability to order the regions.

<TabAtkins> astearns: We had it, we took it out. It could go back in.

<TabAtkins> dbaron: Order is currently document order of the regions?

<TabAtkins> glazou: Yeah.

<dbaron> I think putting that back in makes it extra scary in terms of implementation complexity.

<TabAtkins> astearns: I think we should certainly have the discussions about the feature itself. I just want to close this issue itself.

<TabAtkins> astearns: I'm not going to ask for LC anytime soon.

<TabAtkins> fantasai: What's blocking us from working on this?

<TabAtkins> astearns: Beating us about the head about this one issue. ^_^

<TabAtkins> astearns: I think using flow-from on CSS-generated boxes needs to be done.

<TabAtkins> glazou: Alan and I put together a proposal for more pseudo-elements. Wasn't perfect, but we have to continue in that.

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

<TabAtkins> dbaron: I think they're all hard to implement.

<TabAtkins> dbaron: You've gone and done that work for one of them - there's demos and impls for it.

<TabAtkins> dbaron: To some extent that's good - stuff to test - but there's still a bias.

<TabAtkins> astearns: The effort we put into evangelizing it also shows the interest.

<TabAtkins> astearns: There are Windows devs I didn't evangelize to that started using it in IE and love it.

<TabAtkins> astearns: We hope people will start using it in iOS, and their use will inform the evolution.

<TabAtkins> glazou: I think starting from a prototype and getting usage data is very common in this WG. Happens all the time.

<TabAtkins> ChrisL: Something that tends to happen is that another browser does it, and you see if it's actually interoperable.

<TabAtkins> ChrisL: I think we have a second impl in IE, but it's based on earlier stuff. Is it comparable?

<TabAtkins> Rossen_: When we implemented Regions, the spec was at a much earlier stage.

<TabAtkins> Rossen_: I'm happy to keep moving the spec forward, and think it's favorable.

<TabAtkins> Rossen_: Moving our impl toward the spec won't be a problem when it stabilizes won't be a problem.

<TabAtkins> ChrisL: Right, but one of the things that helps stabilize is another impl actually implementing it.

<TabAtkins> astearns: I agree. It would be fantastic for IE to move up to the current level of the spec.

<TabAtkins> astearns: But I understand the dev costs - twice as much to sync now and when finished.

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

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

<TabAtkins> Rossen_: Apps built on it seem to be very successful.

<TabAtkins> Rossen_: The people developing apps are embracing elements. They have everything they need to do to make a working app.

<TabAtkins> astearns: And their use there should inform how we design the CSS feature.

<TabAtkins> [...]

<TabAtkins> Rossen_: Regions are just used in lots of applications.

<TabAtkins> Rossen_: All sorts of ways to present content.

<TabAtkins> 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." -- 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

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

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

<TabAtkins> astearns: Is there anyone in this discussion that would object to closing this issue, so we can focus on everything else?

<TabAtkins> [?]

<TabAtkins> leif: I don't want it to apply only to elements either, but I don't want to stop work on the spec either.

<TabAtkins> leif: Not sure that I caught the proposed resolution.

<TabAtkins> florian: So I think we have three options.

<fantasai> [Bert and astearns were 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.]

<TabAtkins> astearns: 1) Disallow flow-from on elements. (What the issue says.) I think we've rejected that.

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

<TabAtkins> astearns: 3) Allow it to apply to both, but don't close this issue until there's another method to create boxes.

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

<TabAtkins> leif: I think we should give better solutions a place, rather than doing elements for temporary convenience.

<TabAtkins> florian: Taht matches (1). Does anyone have a fourth thing?

<TabAtkins> dbaron: I think fourth would be recognizing that we have a proposal with some advantages and disadvantages, and I dont' like just crossing off the disadvantages one by one.

<TabAtkins> szilles: We only have one solution on the table, though. Any others are off in the air so far.

<TabAtkins> florian: I think I share a number of David's concerns.

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

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

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

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

<TabAtkins> fantasai: Having a document that is then styled using box-generation mechanisms, templates, etc. also makes sense to me.

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

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

<TabAtkins> fantasai: Okay. And I think Leif's point is that if a feature is designed in a bad way, we shouldn't use it, because we'll be stuck with it forever.

<TabAtkins> szilles: An important aspect of what Elika said - there are three components that are necessary to do this: content, styling, and template.

<TabAtkins> szilles: What Elika 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.

<TabAtkins> szilles: So your content document doesn't change, and you get good separation.

<TabAtkins> fantasai: I think the objections you're getting are largely through the flow-from capability, and not the rest of processing and layout model.

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

<fantasai> [notes to minute-splicer - flowing content from one document into another is reader-application use case]

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

<TabAtkins> dauwhe: You said holistically - is it blasphemy to say that Regions should be attached to a document that does the box generation?

<TabAtkins> Bert: I think in the ideal case we should say that the template part isn't text/html, some other format.

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

<TabAtkins> Bert: Not for the spec, but for impl perhaps.

<TabAtkins> astearns: Certainly. That's why we've been working on the Regions processing model.

<TabAtkins> florian: David, you mentioned that Regions does things in an unusual way, and it makes you uncomfortable.

<TabAtkins> florian: Is the indirection I said the same thing as what you said?

<astearns> +1 hober. I like the overflow:fragments proposal :)

<astearns> I just don't think it addresses the same use cases

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

<TabAtkins> dbaron: There are parts of CSS where the way the spec is written is close to how it's implemented.

<TabAtkins> dbaron: There's not a ton of weird derivation you have to deal with.

<TabAtkins> dbaron: Layout systems are quite different. To implement them, you have to read separated parts of specs, and derive their interactions.

<TabAtkins> dbaron: That's something that worries me a lot.

<TabAtkins> dbaron: There are a lot of implicit ordering constraints.

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

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

<TabAtkins> dbaron: And what that means for what authors expect.

<TabAtkins> dbaron: 'order' only applies in very limited circumstances, for Flexbox, and it barely depends on ordering anyway.

<TabAtkins> astearns: That's also why we took out ordering - it makes things way more complicated.

<TabAtkins> dbaron: I don't even fully understand the impliciations for how pagination interacts with auto-sizing.

<TabAtkins> dbaron: And what things would get us into interesting infinite loops if we weren't limited to 2-pass.

<TabAtkins> fantasai: There's a bunch of problems in Regions. Some of them are also overflow:fragments problems. Afaict, everyone thinks overflow:fragments is okay.

<TabAtkins> fantasai: I propose that instead of spending 2 hours every f2f, we focus on the overflow:fragments proposal for solving the technicla problems.

<TabAtkins> fantasai: Get that spec nailed down and solve all the regions problems.

<TabAtkins> fantasai: And then, when that's working, we've solved all the problems in regions, and we can look at the next chunk of things to bite off.

<TabAtkins> astearns: We've done that analysis. We found that overflow:fragments is not generic enough for the applications we want to put Regions to.

<TabAtkins> astearns: It doens't fit anything people put regions to with IE.

<TabAtkins> astearns: We have two impls of Regions that are being used, and devs that are super-excited about it.

<TabAtkins> astearns: I don't see the interest in overflow:fragments, I think because it has limitations.

<fantasai> TabAtkins: I don't quite agree. Regions has been sold very well, but overflow: fragments has been barely talked aobut.

<fantasai> TabAtkins: There are some things you can't do with it, but a lot of things you can.

<TabAtkins> Rossen_: Layout is the least interesting thing here. We take it for granted.

<TabAtkins> Rossen_: For us, if people can't use the Regions primitives, it's useless.

<TabAtkins> TabAtkins: Note that "fragmenting like pages" is what overflow:fragments does. ^_^

<TabAtkins> Rossen_: Right. But with elements you get OM, events, etc too.

<TabAtkins> TabAtkins: Granted.

<TabAtkins> astearns: We're not currently interested in just doing overflow:fragments.

<TabAtkins> TabAtkins: Well, we have two browses that want to use Regions, and two that want to do simpler things first.

<TabAtkins> fantasai: [draws a list of things on the board]

<TabAtkins> fantasai: #4 (elements as regions) isn't part of our eventual goal. We both agree on this.

<TabAtkins> astearns: Right. It's a stepping-stone.

<TabAtkins> smfr: I think WK is interested in having that long-term.

<TabAtkins> astearns: I think it's good for solving some things forever. I'd like to keep it.

<TabAtkins> Bert: Talking about documents, we dont' want this. Talking about GUIs, we're fine with this.

<TabAtkins> fantasai: That's #2 (reader-content, document-in-document).

<TabAtkins> astearns: #2 can be done with #4.

<dauwhe> smfr: also has concerns about multiple-document approach

<ChrisL> scribenick: ChrisL

(elika has 4 cases on the whiteboard)

sylvaing: dont understand how fragments solves all the use cases

fantasai: it doesn't
... 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
... regions lets you flow between different types

astearns: fragments currently allows you to do the same thing

sylvaing: for everything else, don't see how fragments fixes the issues

dbaron: there are paths that would not apply to regions

<dbaron> s/paths for fixing some of the problems for fixing some of the problems/

shepazu: this separation is irrelevant for svg which wants to do complex wrapped text but was blocked by css
... thei 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
... 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
... getting it shipping in 2 browsers, while overflow fragments is not implemented and has the longest list of issues
... a lot is already built on top of regions, and those cant be build 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

<glazou> TabAtkins, forgot Perl ?-)

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
... we can talk in theory about whatis good or not good, but the actual uses people put it to is more convincing

florian: less worried than dbaron but understand his worry. Its not that we have a lot of issues, its mmore thatwe 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 it but want to back up dbaron

SteveZ: what is the goal here

shepazu: dbaron you said it was not clear from the beggining its what we should be doing. what should we be doing

dbaron: mainly worried about the complexity

shepazu: ok so not the funcrionality itseld, just the complexity
... (call for straw poll, gets about 2/3 or room in favour of the functionality)
... its necessary to have the flow, to have the shaped flow

astearns: its in shapes level 2

<dbaron> 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. No up to the people in the room. its 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
... if we decide we dont 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
... worth answering explicitly. we have not said yes. as a group we have said maybe
... pwersonally 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: (example of grids changing tack)

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

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

<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

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

<dbaron> 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 originall 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 particuipants is pursuing their own agenda and may get another participant to ride along but we are all heading off in different directions
... lots of things not making much progres
... so your comment applies to many things on our agenda
... concerned that 2.1 was a very focussed effort whjile post-21 has been much more diffuse. slowing down and broadening faster than we are finishing
... hence some concern from w3m about finishing things
... this is a meta comment

TabAtkins: we have done significant consensus building around the idea of shadow dom

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
... many areas of focus on the radar, everything relies on what the implementors are willing to implement and ship
... 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.
... 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
... if anyone has reservatiosn they should fix them
... not say stop
... (example of vertical text. very important. can't say not important)
... there is a point on arguing how to make a good solution peiople are happy to iimplement when it beciomes a prioority

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 elelents as well as othe r boxes
... 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: its blocking discussion

astearns: blocking and the issue shjould 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
... want to talk about region-based styling

astearns: dow 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)

<tantek> OH: "There doesn't have to be a queue, I'm minuting."

<AdobeSeattle> 1) Disallow flow-from on elements. (What the issue says.) I think we've rejected that.

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

<tantek> welcome AdobeSeattle!

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

(adjourned)

Bert: formal objection

<dbaron> I'd note that I abstained.

resolution: the issue is closed

<glenn> signing off

RRESOLVED: thclose issue number 1 on regions

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

<dbaron> overconstrained

<glazou> ScribeNick: SimonSapin

<scribe> ScribeNick: SimonSapin

dauwhe: Talk about page selectors
... Simple HTML (projecting) with <section>
... When paged, the first page of the chapter is special
... Several kinds of pages: left/right, start of sections, …
... special graphics, bg images, colors, etc.
... CSS Paged Media defines ways to select :left/:right/:first (of the document)/:blank
... When we demand starting on a left page, we may create a blank right page
... In particular, first page of chapters
... In previous GCPM drafts and some impl… Prince has idea of page groups
... <section> element creates pages, forming one group
... The page group is the fragmentation container of the pages
... Prince has a 'page-group' property
... :first will apply to the first page of the group
... conflicts with 2.1 where :first is only the first of the document
... also :nth() selector for pages
... concerned about terminology, others have nth-something
... proposing :nth-page() to clarify
... This is not about styling the content of the page, only the page rule, headers, footers, etc.
... if you assign an element to a named page, haven’t figured out why not automatically create page groups

(projecting an example)

dauwhe: :nth-page() on a named page, selecting withing that page group
... would help to style first page of chapters

<dbaron> A:nth-page(1) being nth within the context of A isn't how selectors normally work...

<fantasai> right, I think that's a syntactic mistake

astearns: How there are two page group cases?

<fantasai> it's like expecting foo:nth-child(even) to select every other "foo"

dauwhe: I create a page group on a <div> element. Every new <div> creates a new page group

<fantasai> but we're solving that with :nth-child(even of foo), we could tweak the syntax here similarly

dbaron: Any div that create page groups has page breaks before and after?

dauwhe: yes

fantasai: You’re proposing that giving a page name should automatically create a group

dauwhe: yes

fantasai: that’s better. No awkward binding between properties
... but backward compat with existing impl of css-page. If you give the same page name to sibling elements, if the fit they can be on the same page
... we can’t have 'page' cause a new page break every time
... we can still have it create a page group. It won’t force a break
... whatever page it starts on will be the first of that group

SimonSapin: 'page' does create breaks with different names

dbaron: how would selectors work?

fantasai: Match multiple page names/selectors

astearns: I understand why page 6 does not match A:nth-page(1)

dauwhe: the element that created everything here is the ancestor

dbaron: A:nth-page(1) is not how selectors work usually
... people want p:nth-child(4) to match the 4th p, but it’s the 4th child

fantasai: we exetended :nth-child() in Selectors 4, :nth-child(4 of p)

dauwhe: it’s hard to know what pages are, they’re not elements in the DOM
... do we like :nth-page() better than :nth()?

SimonSapin: yes

fantasai: In @page context, :nth() is clear enough
... :first is not :first-page
... not sure it should be -page

dauwhe: I’d be fine with that, whatever the group thinks is reasonable

<fantasai> SimonSapin: One issue with :nth() as it's currently specified

<fantasai> SimonSapin: or maybe as implemented in Prince

<fantasai> SimonSapin: Usually selectors are independent of each other, this is why we have :nth-child(.. of ..)

fantasai: space is optional: @page:nth()
... do we have a :last selector?

dauwhe: no. People want that. See requests all the time

dbaron: what happens when the special style make it no longer the last page?

dauwhe: usually it’s about margin boxes, not affecting page count

SimonSapin: we still have to define what happens in "bad" cases

dbaron: It might make sense disallow changing page margins in :last

fantasai: or borders, or …

dauwhe: makes sense

- DRAFT -

SV_MEETING_TITLE

29 Jan 2014

Attendees

Contents

elements as regions

Summary of Action Items

Scribe.perl diagnostic output