- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:35:44 -0800
- 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
layouts.
- 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 GCPM’s @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
top....
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
differently?
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> I’ve 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
fragmentainer
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
consumed
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
zero-height
....
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
element
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
mechanism
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
overflowing.
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
redirection
Alan: Using media queries, using named flows to reorder things
Alan: e.g. Chris Coyier uses responsive layout with ads on the right or
bottom
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
things.
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