W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Sun 2012-10-28 PM II: Paged Media, Box, Fragmentation, Overflow Regions

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:35:44 -0800
Message-ID: <50A33BC0.9050903@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

Paged Media

   - Current variable-size margin box calculation rules are quadratic;
     Simon Sapin has a better proposal, which will be incorporated
     into the spec.

   - Discussed concept of "initial containing block", which is used
     for various things, and needs to be clarified wrt fragmented

   - RESOLVED: Add :blank @page selector to css3-page

CSS3 Box Module

   - Discussed various approaches for alignment in block layout

CSS Fragmentation

   - Discussed fragmenting into too-small and zero-height fragmentation
     containers. No conclusions. Need a concrete proposal

   - RESOLVED: Relpos happens after fragmentation

   - Filed issue on clarifying how positioning coordinates cross pages.

Overflow Regions

   Tab proposed focusing on the overflow method of region auto-generation,
   instead of working on making random elements become regions containing
   randomly-spliced flows. Arguments in favor were that it solves the
   junk-elements-in-document problem, and that the enforced one-to-siblings
   relationship of the overflow-regions model avoids crash-prone complexity
   in the layout engine. Alan countered that it can't handle all the use
   cases. There was some dispute about to what extent this was true.
   Rossen also requested that programmability of region containers not
   be ignored as a requirement.

====== Full minutes below ======

CSS3 Page

   fantasai: margin box sizing rules in paged media spec
   SimonSapin: spec has an algo with quadratic
   SimonSapin: this is not what people do, its too hard to implement
   dbaron: quadratic in what?
   SimonSapin: need to minimise square values of margin
   TabAtkins: we can minimize linear measures but not squares so we iterate
              and hope to converge
   SimonSapin: spec does not say which values to pick
   fantasai: spec the text, put it in and then we can publish a WD as the
             other pending edits are done

   <hober> http://xmlgraphics.apache.org/fop/fo.html#fo-blank-pages
   plinss: Need a pseudo-selector for blank pages
   fantasai: There's a proposal there in GCPM. Could pull it into css3-page
   RESOLVED: Pull :blank into css3-page
   <SimonSapin> I actually implemented GCPMs @page :blank  should I prefix it?
   Florian: I think the answer is, don't ask and don't prefix.

   <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0769.html
   SimonSapin: second issue is initial containing block
   SimonSapin: apparently, in pages we have a different idea of what it
               should be, e.g. based on first page even if other pages are
               different sizes so we need multiple values for this
   SimonSapin: in general ICB with pages is fuzzy
   fantasai: one for normal flow and another for abspos
   fantasai: we have an open issue on that
   stearns: decision for pages would apply to regions as well?
   antonp: ICB has been elevated to a status it does not deserve
   antonp: need to be open to a related but different concept
   TabAtkins: would this go in page?
   fantasai: paged media includes all of fragmentation, but poorly.
             Needs to be removed
   ChrisL: fragmentation sucks as a name btw
   (general disagreement)
   (real break this time)

<br duration=900s>

CSS3 Box Module
Scribe: fantasai

   Bert asks what the topics are
   glazou reads from some list

   Bert: Question about direction to go in for centering
   Bert: We have in flexbox centering with auto margins, and justification
   Bert: But what do we do for things in normal flow?
   Bert: How do we push Box to the bottom of a flow, for example?
   Florian: Wasn't there something in the Alignment module?
   Bert: One option is to extend properties in alignment module to apply
         to normal flow
   Bert: Some text about that in the draft, leftover from before
   Bert: Another way would be to use auto margins, but not with auto
         margins keyword
   Bert: my preference is to use a keyword on the margins

   Bert: But also other proposal to use alignment properties
   Bert: I'm not quite sure how that works in the vertical direction
   florian: There's a property called justify-self
   Bert: That would work for horizontal direction, but how do I push
         something down in vertical direction?
   TabAtkins: [...]
   fantasai: Currently, the alignment module allows a box in normal flow
             to push its contents to the top or bottom, or to center it.
             Or even to justify it; if we want we can allow that
   fantasai: There's no way to push a box down by itself
   TabAtkins: Can do that in flexbox with auto margins, though. I think
              that's what Bert is suggesting
   Bert: yes

   Bert: For example, I want to have a slide where I want the heading
         at the top, but the paragraphs centered in the middle
   Bert: If I had an auto margin above/ below, could do that
   Bert: Could do that in Flexbox, but this is just some normal text
   Bert: Could maybe put a div around the paragraphs and center that,
         but have to change the markup
   Bert: also, want to center it below the heading, not across the whole side
   Bert: Some examples I showed on slide...
   Bert: Magazine where all columns have one paragraph aligned at the bottom
   Bert: last paragraph is an address or summary, that's always aligned at
         the bottom
   antonp: In that sense very similar to flex layout
   antonp: to do with spacing rather than to do with alignment
   antonp: you could want both things, paragraph in the middle and
           paragraph in the bottom. Wouldn't solve the problem properly
   antonp: Would want to combine several things
   antonp: ... this is kind of how flexbox works

   antonp: I suppose doing it on margin does make to me some sense
   antonp: but authors don't understand auto margins at all
   antonp: it's very unexpected
   Bert: Well, we have one similar case. Leaders work in horizontal direction
   Bert: if you use two leaders, will center thing
   Bert: Andrew Fedoniouk has %% unit that does similar things
   Bert: Don't know what is most intuitive
   Bert: Want it to be intuitive, but also powerful
   Bert: leaders already compromised, e.g. can't align on a decimal point
   Bert: I would want true centering in horizontal centering. if can do
         them the same way, could be elegant

   Florian: What's missing from align-self: center true?
   Bert: If it's defined to work for flow, that's good
   fantasai: Not defined to work in Flexbox, but alignment module defines
             it for block flow
   Florian: If we assume the alignment spec does what it says it does,
            the thing that's missing is magic margins
   Florian: If we have these two things, do we solve the problems you're
            talking about?
   Bert: Those are all the cases I've come across

   SteveZ: One thing missing I don't want to tackle right now...
   SteveZ: baseline alignment
   SteveZ: If I push these paragraph to the end, would want the last
           baseline to align across each of the paragraphs in the columns
   SteveZ: there may be different sizes
   SteveZ: Line grid would do some of that, but not all of it
   SteveZ: Inline blocks align on their last line.
   SteveZ: Table cells align on their first line Ste
   vhardy: probably would like some mechanisms to say which line is used
           for alignment
   SteveZ: ... eventually also want to talk about how to align initial
           caps, too
   SteveZ: it's not always the baseline of the Nth letter, sometimes the
   SteveZ: I think there's an opportunity in the long term for expanding
           baseline alignment in that direction, but don't want to tackle
           it now
   Florian: Are the things you're wanting to do eventually compatible with
            what we're doing now?
   SteveZ: If you use springs-based approach, then baseline alignment
           would be an additional constraint to solve there
   SteveZ: depends on how you solve things. But as long as it is a
           distribute-remaining-space kind of alignment, just need to
           specify order of relaxing over-constraints is
   Bert: I guess that means once we have a line grid, we can't always
         increase margins; might sometimes decrease margin in order to
         align on the line grid
   SteveZ: With line grids will very quickly get over-constrained situations
   Bert: Cases I've seen were pretty simple. Whole pages had same font
         size + line height
   SteveZ: But you can easily see where the central paragraph could be
           in a larger font

   Bert: So, inline direction try a property, and maybe find a
         for margins in vertical
   antonp: it's been brought up on the list by Andrew the idea of spring
           units. But never gained any traction. But interesting idea.
   antonp: Would be interested if anyone has any immediate "interesting,
           but doesn't work ..." reactions
   TabAtkins: Spring units are similar to flex, but don't normalize to
              fill all the free space unless they're overflowing
   TabAtkins: They will shrink but not grow to fill free space
   TabAtkins: means you can transition from zero to nonzero smoothly,
              which you can't do with flexbox
   TabAtkins: It's kindof not great. Investigated spring units while
              working on flexbox, but nobody that excited about it
   SteveZ: Could you do it by adding a property interpreting flex units
   TabAtkins: maybe. Would affect flex units less than one
   fantasai: I would hesitate to add a mode-switching property, maybe a
             keyword on flex property
   SteveZ: wouldn't want another unit
   fantasai: could use the fr units, not using them atm :)

   TabAtkins: I don't like the name of the spec.
   TabAtkins: This is a block & inline layout spec
   TabAtkins: box is too generic
   antonp: In my mind it's really two specs, but can't convince Bert :)
   Rossen: Call it flow layout
   Bert: Also talks about borders/padding/margin
   antonp: It's got a lot of generic box-related stuff
   TabAtkins: I'd like to use box as name of a box-generation spec for
              generating the box tree

[discussion of what to discuss; we went through agenda already]

CSS Fragmentation

   <stearns> http://lists.w3.org/Archives/Public/www-style/2012Sep/0304.html
   Alan: Have some issues
   Alan: First issue is about zero-height fragmentainers
   Alan: In Regions spec you can have a fragmentation context: content flows
         through them
   Alan: If you have a fragmentainer that has no area
   Alan: Or too small to fit anything useful
   Alan: Less than the next bit of monolithic content that can't be sliced
   Alan: I'd like to ignore that fragmentainer, push the content to the
         next one that's bigger
   Rossen: But then you're in an infinite loop
   dbaron: Might want different behavior depending on whether there's a
           taller fragmentainer later
   dbaron: Similar problem if you have a line box taller than the page,
           but every page is the same height
   dbaron: Need to force something on every page, to make progress
   dbaron: Makes sense when you know that the next page has the same problem
   <SimonSapin> Ive had actual infinite loops like this in implementation
   dbaron: But might to allow some heuristics
   dbaron: If we have a 10in item and 50 landscape pages, followed by
           portrait page, do you push to the landscape page and print
           50 blank pages?
   Alan: ... slicing decision
   Alan: If you decide not to slice, for whatever reason, would like it
         not to consume e.g. any margin of stuff going into next
   fantasai: I remember Melinda raising this issue; can't remember the
             discussion that went with it

   Rossen: Really the behavior you're asking for is, your question is not
           whether or not we fragment monolithic elements that happen to
           be at the beginning of the fragment, but whether we have the
           ability to skip ahead, what dbaron was talking about
   Rossen: This is not about fragmentation, but about higher-level layout
           that deals with that
   Alan: Think it's a fragmentation issue
   fantasai thinks it belongs in the same spec anyway

   SteveZ: There's two questions: does the whole of the item fit here or not?
   SteveZ: If not, what fits, and do you put it there.
   Alan: The thing that does not fit, and at that point you have a decision:
         fit part of it or not
   Alan: If you decide not to slice, want us to really stick with that
         decision not to slice and have it not consume any margin for the
         element that you decided not to slice, to ignore that fragmentainer
         and be positioned in the next one
   SteveZ: That goes to dbaron's comment: you need to know that somewhere
           in the future there will be a next fragmentainer

   Rossen: Then there's issue of always slicing, and still not making any
           progress: zero-height fragmentainer
   Rossen: Making zero-height slices means never making any progress
   Rossen: Question of, if I'm fragmenting, need to consume something.
   Rossen: currently don't have anything in spec that calls out exactly that.
   Rossen: If on the next fragment you didn't make any progress [...]
   Rossen: If you fragment and didn't make any progress, can assume current
           piece of content has been consumed. Then always assuming some
           kind of progress.
   Rossen: Suppose you have a line, one character
   Rossen: Zero-height fragmentainer.
   Rossen: you have to make progress in the content.
   Rossen: So if you consume zero height, make zero progress on your
           monolithic element, you need to assume that this element is
   Rossen: If your fragments are the same
   Alan: If there is no other fragmentainer in the fragmentation context
         that can retain the monolithic element, need to bail
   Florian: What if you have a series of zero-height fragmentainers
            followed by a positive-height fragmentainer?
   Florian: Then you lose a bunch of content.
   Florian talks about auto-height regions
   Florian: with your algorithm things will disappear

   fantasai: An alternative to deal with this is to assume that each page
             makes at least X amount of progress, e.g. X=1px
   Alan: In region chain case, if the rest of your region-chain is
         zero-height regions, then would prefer the last region to overflow
   SteveZ: I'm very concerned about not showing the content
   Florian: If you can eventually show something, probably should show it
   Rossen: What you're saying makes sense for regions, but not pagination

   Alan: I don't know that we'll make any progress on this today. Could
         we address this at least in part in the css3-break module? I
         can build on that in regions if we want regions be different
   Florian: I don't think there's a conceptual difference just more common
            for pages to be the same size and less likely to be zero-height
   Rossen: Same thing goes for multi-col, too
   Rossen: If your columns are zero height, you know they will all be
   Rossen: There needs to be a notion that the fragmentainer knows if there
           are any fragments ahead that are able to consume content
   fantasai: I think we need some concrete proposals here
   SteveZ: One constraint is you're trying to make progress
   SteveZ: Other is you want to fill the area
   Florian: Third is you want to show the content
   SteveZ: Decide order of decision-making from that

   Bert: Another different case; if you have an infinite number of regions,
         e.g. pages
   Bert: If you have finite number of regions, might be different.
   antonp: need to know whether there is a last region or not
   SteveZ: Need to know which order you relax constraints
   fantasai: I agree it's an issue, but not going to make any progress
             without concrete proposals
   alan likes steve's approach
   Bert: Boxes outside printable area, sometimes meant to be invisible,
         sometimes contain something important. difficult decision whether
         it's just meant for bleeding, or an error case. We don't say what
         you do, just warn about that case.
   ACTION Alan: propose handling for making progress in fragmentation
   <trackbot> Created ACTION-513

   <stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0428.html
   Alan: Other break issue I had was, say you have a 2-column multicol element
   Alan: And each column has a fragment
   Alan: each fragment has a relpos element in it
   Alan: There's no spec that says where to position those relpos'ed elements
   fantasai: My position is you fragment, and then relpos is taken as a
             graphical transformation of that
   Alan: Would like that define
   TabAtkins: Other option is to relpos it first, then fragment it
   SteveZ: relpos isn't really that useful for printing
   plinss: There's also paged modes in browsers, too
   fantasai: I stick by my original answer, treat it like transform
   Florian: Does anyone implement the other behavior?
   Alan: webkit
   TabAtkins: Overall our fragmenting behavior is really shitty.
   dbaron: Idea of relpos is you do it after layout
   dbaron: This would break that
   fantasai: fragmenting affects layout -- it changes the effective height
             of an element
   TabAtkins: ... you're right
   RESOLVED: relpos after fragmentation

   TabAtkins: On that topic... abspos, is that currently undefined?
   [for regions]
   Alan: It's defined, but defined badly
   Alan: If you have abspos elements in the named flow, that don't have a
         parent that is relposed in the named flow, we use the box for the
         initial region. So everything piles up
   fantasai: That's how it works for abspos in general currently
   fantasai: The initial containing block is either the first page or the
             viewport before scrolling
   fantasai: that gives your coordinate space
   fantasai: you have something that flows below the bottom edge of that
   fantasai: then it will paginate
   antonp: I don't think that's defined
   antonp: Do you have a parallel canvas that gets sliced across, for
           positioned elements?
   fantasai: In terms of 2.1, you have to have abspos elements fragment
             across pages because there are lots of websites out there
             that put everything in the page inside an absolutely-positioned
   fantasai: So if you can't fragment abspos, then you can't print those pages
   antonp: Asking not whether the element fragments, but whether the offset
           from the top fragments
   fantasai: yes
   antonp: need to define that more clearly
   Florian: isn't that different from relpos?
   fantasai: Yes, relpos is after fragmenting, abspos before it
   [discussion of relpos and whether something relposed down would show up
    on the next page]

   plinss: If you have a spread, then relpos something to the side should
           show up on other half of spread
   plinss: visual arrangement of pages should be in pairs if double-sided
   SteveZ: Need a concept of spreads. [...]
   plinss: Abspos canvas that slices... want to make sure we're not just
           literally slicing
   plinss: that we're fragmenting
   fantasai: No, you fragment it.
   fantasai: But this is very difficult for bottom-positioned abspos,
             because you have to fragment backwards.
   antonp: It's not obvious to me... I agree with what we're deciding,
           but it needs to be defined
   ?: What's the result on relpos?
   fantasai: Open question is how do pages relate to each other in space
   some discussion of bleeding
   plinss: When you're printing bleeds, e.g. I have a black box that's
           background of my page, I want it to print to edge of paper.
           Not going to print that 10inch, will print to near the edge
           of the page.
   plinss: say only allow overflow, but only this much
   plinss: Changes bounding area of where overflow becomes hidden
   plinss: need some way to control that
   ISSUE: define relation of pages in space, and how this interrelates with bleed
   <trackbot> Created ISSUE-283 at http://www.w3.org/Style/CSS/Tracker/issues/283
   <Bert> (Re relation in space: GCPM has 'overflow-style: paged-x' to say
           that pages are side by side instead of above each other, but
           that isn't powerful enough to say there are two-page spreads
           that are one above the other.)

<SimonSapin> (Actually, I lied about WeasyPrint not being a browser 
               http://i.imgur.com/dSgNx.png )

Overflow Regions

   Florian: Any new thing on dbaron's overflow regions spec?
   dbaron: Not really, though someone else said we should discuss it
   dbaron: I don't have anything to say

   TabAtkins: We prefer the dbaron's overflow regions proposal to the syntax
              to the regions proposal, because it satisfies all the use
              cases we care about
   Alan: It doesn't satisfy first example in the regions spec
   TabAtkins: No, it's totally fine
   Florian: Does it satisfy use case of parallel languages?
   Florian: There's markup somewhere using page templates
   Alan: Want to go back to 1st example
   Alan: You have an element with overflow: fragments;
   Alan: And you can style the various boxes that get generated
   Alan: It generates lots of sibling
   Alan: How do you position some of them not others?
   TabAtkins pulls up the example
   TabAtkins: You'd use a grid
   Florian: You could also do it with multicol
   TabAtkins: I think that would be awful

   SteveZ: What about page templates? Also use regions for page templates
   TabAtkins: The page template generates a bunch of pseudo-elements,
              attached to grid that template defines, define a region-chain
   TabAtkins: You'd have to recast the semantics a bit, that the page
              template consumes overflow boxes
   SteveZ, Alan: Interleaving example
   Alan: Position of each, alternating threads,
   TabAtkins: I don't think that's problematic...
   TabAtkins: I'm thinking that the interaction of grid ...
   TabAtkins: That grid can be appropriately powerful to handle this
   <Bert> (Example of interleaving: 'p:even {flow: a} p:odd {flow: b}')

   florian: To backtrack, you like dbaron's proposal because it solves
            all or many of regions use cases. Therefore, what?
   TabAtkins: I believe dbaron's proposal is easier to understand and
              implement, and would prioritize it over Regions
   TabAtkins: We believe that Regions is going to keep our fuzzers busy
              for a long time
   TabAtkins: This is just a more complicated version of multicol
   TabAtkins: If we can simplify the implementation as much as possible,
              while maintaining as much power as possible, it's better
              because it reduces the number of crashers
   TabAtkins: The technical weakness is that you can't start from multiple
              elements into single flow, then split across elements
   TabAtkins: Regions give you many to many. dbaron's proposal gives you
              one to many, therefore simpler
   fantasai: It also restricts you to all boxes being siblings.
   Alan: For use cases we're considering, too much of a limitation
   Alan: Sibling boxes aren't sufficient as far as we can tell

   TabAtkins: Let's go into more detail later.
   TabAtkins: I think as-written, or with minor additions, it can handle
              it when combined with our layout specs
   SteveZ: will it be easier for users?
   SteveZ: You have to go back and make selectors with dbaron's model
   SteveZ: with regions, can use page templates
   SteveZ: have graphical model of what's happening to pieces
   Tabatkins: I'd like to go over exactly how page templates work.
              Think it's similar to dbaron's model as well
   SteveZ: It's simple, hard part is deciding which page template you use next
   SteveZ: may have multiple components that are threads flowing through

   Alan: Nice thing about Regions and my page templates proposal
   Alan: Can say that these boxes have this flow-from value
   Alan: With overflow proposal would have to have particular page-targeting
   TabAtkins: I think I disagree because I believe that it should be possible
              to rework page templates a little bit so that they essentially
              consume overflow blocks, rather than directly consuming content
              out of a flow
   TabAtkins: Should hopefully give you same results with similar semantics
   Alan: There you're taking a page and targetting an overflow box
   TabAtkins: Idea is, take grid. You can have two boxes that are region
   TabAtkins: Page templates would be able to work similarly, just have to
              invert relationship from go-to relationship to take-from
   TabAtkins: Still grid positioning, with niceties of that layout, but with
              inverted relationship of how you target elements to grid cells
   Florian: I generally agree with most of what Tab said
   Florian: Essentially can, or can easily extend, into doing regions
   Florian: Don't think we have to check that right now
   Florian: We should just pursue as it is, and [...]
   Florian: Then when we run into cases where use cases aren't handled yet,
            decide whether extend it or use regions.
   Florian: what we have right now they work together just fine
   TabAtkins: My goal is to see if we can do enough without regions, to do
              that first. And then only do regions if it's necessary, later
   <dbaron> (earlier:)
   <dbaron> dbaron: Florian, what did you mean by ???
   <dbaron> Alan: In Hamburg, I introduced the idea of using overflow:fragments
                  as a way to handle the overflow for the last box of a region.

   Alan: My concern is taking those sibling boxes, and extending them to
         all use cases identified for regions, that you'd get something
         as complicated as the column-styling situation you disliked
   SteveZ: I would like the user model should also be easy and simple,
           not just the implementer model
   TabAtkins: I think it should be as easy to use, yes

   Bert: Wrt push-> pull
   Bert: Regions are not in a tree. They don't have an order. Don't know
         if pulling from two regions, which pulls first.
   Bert: Just a warning, if you go that way, you may need extra properties.
   TabAtkins: That problem exists right now.
   * antonp thinks that when Bert says regions he means page template "cells"
   TabAtkins: I think we're talking about different things now.

   Bert: ... pseudo-elements ...
   TabAtkins: Need to establish an ordering then, because if individual
              pseudo-elements flow from a particular flow, need to establish
              an ordering. Need to establish an ordering no matter what.
   TabAtkins: Regardless of flow-from or flow-to
   SteveZ: need ordering for both content and containers
   Bert: content has ordering already

   Alan: While you said your main concern was fuzzing the named flows...
   Alan: It's something that's going with insertion points of shadow dom
         as well
   Alan: The street has found named flows useful for things we didn't intend
   Alan: People think it's very interesting to use it as general content
   Alan: Using media queries, using named flows to reorder things
   Alan: e.g. Chris Coyier uses responsive layout with ads on the right or
   Alan: Use named flows to intersperse ads in mobile layout
   TabAtkins: It works with dbaron's as well. Can show you how you would
              mark it out
   Alan: Florian wasn't able to, so would be interested why you think you can

   Rossen: Since the overflow module relies entirely on pseudo-elements,
           will you have eventing and programmability built into that?
   Rossen: Regions give you that for free
   TabAtkins: Only if you put a bunch of dummy elements in your markup
   sylvaing: shadow dom
   TabAtkins: On that note, actually a lot of us in Webkit do believe that
              pseudo-elements are the same concept of shadow dom and are
              investigating how to unify them
   Florian: I think it's a good chance that we can do everything we want
   Florian: That said, what difference does it make right now?
   TabAtkins: We have a regions Webkit implementation... because implementations
              are showing up now, we will lock into regions model
              where simpler model would be sufficient
   Florian: So just don't ship it

   Florian: What action or resolution are we aiming for?
   TabAtkins: I need to discuss use cases more with Alan.
   TabAtkins: If we can establish to our satisfaction that use cases are
              solved, then discuss as a group whether to switch as a group
   SteveZ: Why is the overflow model simpler?
   TabAtkins: one, you have lost flow-into multiple things. Always origins
              from same element
   TabAtkins: i haven't heard anything yet here that is actually needed
   TabAtkins: Secondarily, because you're only flowing into a particular
              type of thing, not every element/pseudo-element potentially,
              because Webkit does a lot of weird things for
              pseudo-elements [...]
   TabAktins: Generating single set of sibling boxes, make a lot of simplifying
              assujptions that avoid a lot of crasher boxes
   TabAtkins: e.g. WebKit right now is rationalizing pseudo-elements
              that we could add more in the future. Before were handled at
              layout time, made things really messed up
   TabAtkins: Scattering the flow around the dom can result in very weird stuff
   Alan: Would be happy to say you can't make before/after pseudos into regions
   <stearns> and have some future pseudo-element made for that purpose
   fantasai: Having worked on Mozilla's layout engine, I think I agree with
             Tab that it would be a lot simpler.
   fantasai: And we have all kinds of crashers that result from fragmenting

   Rossen: wrt flow-from/flow-into
   Rossen: Saying something you lose with dbaron's proposal? Do you need to?
   Rossen: What is reason why you cannot ... flow is a general concept which
           is orthogonal to regions
   TabAtkins: Technically ability to flow multiple elements into a single
              flow is separable from this
   TabAtkins: Since separate, could potentially still have it
   Rossen: Named flows and regions are two separate concepts
   TabAtkins: Right, and dbaron's proposal properly deals just with regions
   Florian: I agree with you that dbaron's proposal is significantly simpler,
            and agree it will cover a very substantial subset, not sure about
            all. But let's not close any doors right now.
   TabAtkins: Agree

   Rossen: Want to again minute concern wrt programmability and pseudo-element
   sylvaing: and shadow dom work
   Rossen: Good to solve the layout problem, but don't overlook other side
   sylvaing: Don't want to create another shadow dom
   TabAtkins: no, let's just create the same shadow dom :)
   TabAtkins: We've been thinking about implementing all our pseudo-elements,
              as a built-in always-on-top shadow tree
   TabAtkins: could implement pseudos as a shadow tree, and you get benefits
              of shadow dom for free
   TabAtkins: might make eventability and whatever possible
   glazou: we're out of time.

Meeting closed.
glazou: Thanks very much to members who made this meeting possible:
         Adobe, Microsoft, Opera
glazou: Bert and Alexandra
(and Google, if various red tape gets sorted out?)
Received on Wednesday, 14 November 2012 06:36:35 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:21 UTC