- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:50:20 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Regions
-------
- RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary
amounts of content in a region chain.
- RESOLVED: bug 15824 - keep the current spec text, where regions all
create stacking contexts for the stuff flowed into them.
- Discussed issue of elements becoming regions; agreed to leave it open.
- RESOLVED: Need to split the ICB concept into two parts, as necessary
for the different things the ICB is currently used for.
Multi-column Layout
-------------------
Discussed rules for sizing "available-width == unknown", what that
means, and whether various parts of the sizing pseudo-algorithm
should be removed. No conclusion.
====== Full minutes below ======
Regions
-------
<stearns> http://lists.w3.org/Archives/Public/www-style/2012Oct/0304.html
stearns: First issue is box generation.
stearns: I posted how I think this issue should be handled in the spec.
stearns: I don't think box generation is required for CSS regions.
stearns: The issue is how to handle more content than will fit in a fixed
region chain.
stearns: We've added auto-height regions and the regions processing model
to address this.
stearns: So handling more content in a region is the same as in any other
element.
stearns: So I'd like to close this issue.
howcome: Examples?
stearns: The very first example in the spec has an example - the last
region is auto height and will just take the rest of the flow.
howcome: What about pagination?
stearns: No effect on printing - it'll break across pages just like a
normal element.
stearns: I got one response on the list from Anton saying it was reasonable.
howcome: What dimensions does it expand?
stearns: Same as an auto-height div.
stearns: The email goes into what you can do with the last region - you
can make it auto height, scrollable, overflow:visible; everything
you can do with a normal element.
TabAtkins: I'm satisfied that this concludes the issue - the last region
in a chain is no longer restricted, and you can do everything
you can do with a normal element.
stearns: The issue as stated is that region chains can't handle a variable
amount of content. At the time the issue was raised, this was
true. It's no longer.
stearns: We could close this issue and let you raise further issues.
fantasai: Can you have a region in the middle of the chain that's
auto-height with a max-height, where it overflows to the
next region in the chain?
stearns: Yes, that's what the processing model now addresses.
RESOLVED: Close issue 15186 in Regions, concerning handling arbitrary
amounts of content in a region chain.
Rossen: Can you swap css3-ui with something in the afternoon?
I'm waiting for Tantek and Sylvain.
break-duration: calc(15 * 60s);
Regions (continued)
-------------------
Alan: 3 issues left
stearns: The draft currently says that Regions create their own stacking
contexts. There's an issue on the draft that perhaps we shouldn't
do that, and allow them to be non-stacking.
stearns: My contention is that regions should behave more like the things
that *do* create stacking contexts, like fixpos/flaots/etc,
because we are taking content out of the flow and putting it
somewhere else.
stearns: Same justification for those applies to Regions. Little case
for interleaving content.
dbaron: Floats actually create a pseudo-stacking context.
antonp: I don't think authors like stacking contexts.
hober: I think most authors don't know what a stacking context is, and
when things interleave in weird ways, that's funky behavior.
hober: Will probably result in performance issue, which we can avoid...
hober: I don't think authors would interleave on purpose.
antonp: The reason the funny painting model exists is because people
had overflow they weren't expecting; floats and next paragraphs
and etc.
antonp: That's why text is painted after all background/borders/etc.
antonp: Makes overlaps less painful.
antonp: So it was historically because there was a lot of overflow,
and impls thought it was better to see content.
dbaron: I'm not sure it was that logical of a process.
dbaron: There's a decent chunk that was Hixie and I interpreting a vague
chunk of the spec, and coming up with the one precise definition
that satisfied it, then wrote tests and got impls, and that was
that.
dbaron: Never really learned how much of that was intentional.
dbaron: The spec never quite said that the backgrounds of the next
paragraph drew under the text of the next paragraph, but you
could infer it from a rule about floats, which was similar.
dbaron: The thing I'm slightly worried about is...
dbaron: You're talking a region being a stacking context?
dbaron: Each region?
stearns: Each region is a context for the fragment of the flow in it.
dbaron: My problem is when people put regions close to each other to
give the illusion of continuous flow
TabAtkins: Like using them to make a "non-rectangular grid cell".
dbaron: yeah. But I think there might be weird issues now.
stearns: That's only a problem if they break outside of the bounds of
the region.
dbaron: Not necessarily rare, with text slightly overflowing, etc.
dbaron: Don't have a strong opinion, but I'm a little worried about
that case.
stearns: I'm not really sure what to say about that case.
Rossen: No real opinion...
Rossen: From the pov of having valid use-cases for where it's really
interesting to have interleaving, we struggled to find such a
use-case.
Rossen: The one David is bringing up is somewhat valid for the content
being laid out between the regions themselves.
Rossen: It is more interesting to see how the rest of the content
outside the regions interacts with the content inside.
Rossen: This is why we'd prefer regions being their own stacking context.
Rossen: So you don't have weird interleaving between parts of the regions.
antonp: I buy that point.
antonp: I'm kinda thinking, you got stuff flowing down the left, you got
regions on the right, and you're directing flows through each,
and if you've got a long word on the left it'll interleave with
what's on the right.
antonp: What about a pseudo-stacking context, so abspos doesn't have to
be constrained by it?
TabAtkins: I think that limiting abspos is actually an important part
of it.
szilles: This seems a bit like the problems of composition in SVG -
they introduced groups to denote what things are part of
"the same thing" versus a different thing.
szilles: Conceivably one could introduce a similar property that groups
things like that.
TabAtkins: Like explicitly turning on stacking contexts without side
effects?
szilles: No, other way around. Declaring that some stacking contexts are
part of a group, so within that group they can interact, but
they're still shielded from the rest of the group.
Rossen: To add to this, it becomes more apparent once you bring content
that's not quite in the same document into regions.
Rossen: Then you have content from separate documents that can interleave.
TabAtkins: You're talking about IE's addition that lets them flow iframes
into a region flow?
* hober runs screaming from the room (re: region flow sourced from <iframe>)
Rossen: Yeah. You don't want an iframe to be interleaved with anything
else.
antonp: At the very least that says you want pseudo-stacking contexts.
It doesn't necessarily talk about abspos.
antonp: abspos is a weird beast. But when people use it, they get
frustrated that you can't choose where things are positioned from.
antonp: By locking it into the region box, it seems you're taking away a
little of the freedom they otherwise have.
TabAtkins: There's a workaround - flow the abspos into *another* region
chain, and flow-from it somewhere outside higher in the document.
Bert: That loses the auto position, though.
TabAtkins: If you're using the auto position, you probably don't need to
worry about stacking context.
Bert: Most of the time when I use regions, I started using columns,
then found a weird case, and had to replace the columns with regions.
Bert: That means that I'd like them to act like columns.
glazou: [something about columns across pages, and how regions would work
the same way maybe?]
Bert: Point is that I'd like columns to act the same way as regions.
stearns: So that's an argument for Steve's suggestion - the ability to
group contexts together.
dbaron: So you say that having flow-from on an element makes it a stacking
context automatically?
stearns: yes, that's part of the spec right now.
stearns: I have been arguing both sides of the issue with my team for
months now, and I think I've come down on the side of stacking
contexts.
stearns: Possibly with a future mechanism to aggregate stacking contexts.
TabAtkins: I'm cool with that. I just don't want automatic grouping,
from a performance standpoint.
stearns: Hyatt's doing some work with identical regions, which might be
relevant there.
stearns: So, are there any objections to keeping what the spec currently
says?
stearns: (I was arguing for the opposite position in my team, and I lost
the argument)
Bert: It doesn't sound quite right - it's like an implicit relpos, which
limits what you can do with abspos.
TabAtkins: I think that there are enough implicit positioning containments
already that we can argue this is a general limitation of
*abspos*, not of any individual other spec, and should be fixed
in abspos properly, by letting you override what you're
positioning relative to.
antonp: Bear in mind that we're not just talking about positioning, but
also painting.
antonp: If in the future we're going to let you throw your positioning
root around, you're also changing painting.
TabAtkins: yeah, you're more or less moving it in the box tree.
Bert: Another comparison is with shapes - if you can make two regions
and flow between them, or put a shape on a single paragraph that
duplicates the same size, why do those act differently?
antonp: To be fair, you'll have different behavior anyway - the
fragmentation is probably going to be different anyway.
Rossen: Currently in shapes there's nothing talking about this.
Rossen: In the multi-shapes section, we're allowing multi-shapes.
Rossen: Like if you extract a shape from an image, and it creates two
circles.
Rossen: The spec currently says its allowed, but doesn't define how it
works.
Rossen: Making a comparison based on that right now is a bit premature imo.
Bert: maybe, but the examples I worked through often didn't matter -
I could use multicol or regions, shapes or regions, they worked
roughly equally well either way.
Bert: So I thought that if they were so similar, they should perhaps
all be the same.
Bert: With their own possibilities, but the common elements should be
the same.
stearns: If we have stacking contexts, the only part that might be
different is that content that overlaps at the boundaries
might get painted over.
stearns: That seems like a tiny edge-case for me. You generally avoid
overlap.
Bert: I was thinking about abspos, actually.
Bert: But I'm not sure how important it really is. I generally use
abspos only as a last resort.
stearns: It's certainly a limitation, and that's why I argued against
it with my team.
stearns: But finding use-cases where you want interleaved content...
stearns: From another direction, in all the use-cases we looked at,
when you *have* interleaving, you always *want* a stacking
context to prevent that from interleaving accidentally.
TabAtkins: So most interleaving is accidental and would benefit from
stacking contexts, and the cases where it might be good
are a corner-case, which might be best addressed in the
future by a specialized property to group stacking contexts
together.
antonp: So are columns changing any?
stearns: No.
szilles: You'd need later to define that the stacking-context-grouping
property auto-groups columns by default.
arronei: Does it become a stacking context as soon as flow-from is set,
even if it has no content?
stearns: Yes, but then there's no content to be stacking-contexted.
antonp: There was a comment from Hyatt about how content that flows
through a region physically belong to the region.
antonp: Is this true, or does the content just flow through the space
of the region?
stearns: I think that's relevant. If you're defining Regions to have
stacking contexts, then it's the principle box of the Region
that contains them, and the fragments of the flow are children
of that in the box tree.
antonp: Hyatt has said that would significantly complicate his
implementation.
stearns: He's gone back and forth on the issue. Not sure where he is
on the issue right now.
Rossen: I'm having a little trouble understanding what "physically
belongs to" means.
Rossen: Our model so far is that content flows through the region,
and the regions are little viewports through which you view
the content.
Rossen: As you interact with the region, you change how much content
is in each region.
Rossen: But that doesn't mean actually changing the content in the
document.
Rossen: That complicates region styling.
Rossen: Region styling has proven to be complicated for that reason.
TabAtkins: Wrong level of discussion. Are the box-tree stuff from the
flow children of the region's box? Or are they independent
and just happen to be rendered with a geometric restriction
that makes them look like the same?
Rossen: The former (though it's complicated).
antonp: Makes sense - otherwise you get weird effects with things like
a float "belonging" to another box entirely, which changes the
rendering order.
Bert: Is this similar to the relationship between lineboxes and inline
content?
TabAtkins: Yes, very similar.
stearns: Especially given the connection with styling ::first-line.
Same exact problem as region styling.
stearns: So back to the issue at hand - stacking contexts. Yay/nay?
dbaron: I don't have strong opinions. I don't think we have a strong
performance reason to prefer full stacking context versus pseudo.
But I'd have to ask roc about it.
Rossen: I don't think performance is a strong reason to make a decision
either way.
TabAtkins: yeah, not strong, but an input.
Rossen: Right. I'm hearing, though, that some impls prefer it for
performance reasons, and some don't care.
RESOLVED: bug 15824 - keep the current spec text, where regions all
create stacking contexts for the stuff flowed into them.
howcome: [something along the lines of I'm not sure whether pseudo-stacking
contexts would be good enough, rather than full stacking contexts]
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16858
stearns: Should creation of regions from elements be disallowed?
stearns: This came up about a year ago.
stearns: I think there's a good reason to have this.
stearns: It can inherit part of the structure of your document.
stearns: Particularly for scripting/events.
stearns: I think we should have the ability to flow it into css-created
boxes, but we shouldn't disallow this.
TabAtkins: This is completely the issue I was talking about yesterday,
with changing over to dbaron's proposal.
stearns: Actually, you were doing an either-or. Either do dbaron's thing
(no explicit region flow at all) or do Regions thing (explicit
flow, with elements and such). So I'd like to resolve that,
*if* we do that latter, we can use elements.
TabAtkins: I'm fine with that.
TabAtkins: I'm not happy about being forced to use dummy elements, but
it's better in my book than the alternatives, given the lack
of dedicated pseudo-element creation right now.
stearns: There's an example by implication in note 3 about how you don't
necessarily have to use dummy elements.
howcome: ...
<dbaron> (Tab also said something unminuted after the "howcome: ...")
Scribe: divya
TabAtkins: we don't need to handle eventing on pseudo-elements
TabAtkins: if we end up going with current regions proposal there are
a lot of things that won't work well and won't work accessibly
if we just stick to pseudo elements
<stearns> http://wiki.csswg.org/spec/css3-regions/regions-use-cases#converting-hard-breaks-to-named-flows
TabAtkins: if we go with dbaron's proposal we will still have …
howcome: if we need the DOM thing, then put up a proposal for that.
glazou: you raised a problem then why don't you do it?
howcome: I don't have dom issue.
glazou: this is lower in priority.
glazou: I am just saying people like regions given …
howcome: I am never going to agree to a solution based on dummy html
elements. You are not going to get my okay for that.
TabAtkins: I use dummy html as wrappers all the time, it is going to be
necessary sometimes.
howcome: You are creating a separate structure next to content structure
stearns: that visual structure in a lot of interesting pieces has to have
a structure, you have to have nesting in child-parent rels
stearns: one of the args against … is that you are reinventing html in css
glazou: when you do TOCs and extract them, you do want elements.
* fantasai suggests adopting XSLT as a solution this ;)
<Bert> (HTML could add a <toc> element.)
stearns: it is quite similar to what is being done in SHADOW DOM
stearns: You have an insertion point that is an empty element in your
shadow dom tree. That seems to be something people want as well.
We are providing a similar facility.
TabAtkins: the point of shadow dom is recognizing that you need dummy
elements and taking them from the main flow.
stearns: in MS you have two separate html documents you have content and
vi…
howcome: I don't think you can make the argument that they are semantic
howcome: we need representation of visual structure, we should not abuse
html documents for that.
SteveZ: I am sorry visual structure is semantic
TabAtkins: philosophically opposed but not practically opposed
<Bert> q+ to say using an external (XML) document for the visual structure
is a different case again, and OK
howcome: building on what you said, if we agree on going David's way we
should do that.
TabAtkins: within option b lets not screw around and allow that, as it
is required for regions proposal to work well.
howcome: it is not well defined if it requires html
[lots of arguments]
glazou: authors already use elements for layouts.
glazou: they will continue to do it
TabAtkins: my arg is that strictly speaking, what stearns suggests is
an improvement over what we have right now.
TabAtkins: you would have to explicitly break contents between the
elements right now.
TabAtkins: you have same divs sitting around, but you get better semantics
with the content and more reliable styling.
howcome: Things break as soon as you change the font size.
dbaron: The "strictly better than right now" is assuming that people will
do things in the same proportion to the rate they do them right
now
dbaron: But having this ability will change the rate at which people do
such things.
<divya> fantasai would you like to take over
<fantasai> not really :)
<fantasai> but could if you want
* divya has lost a few seconds
* fantasai doesn't think anything was lost, it's all in the minutes
from February ;P
TabAtkins: if we are selecting columns you are using pseudo elements
TabAtkins: there is no reason to cripple the alternative right now.
TabAtkins: if we don't need it then stop caring about it.
glazou: all specs rely on implementation in the long run, if we don't
have 2 impl. then it would go away.
SteveZ: people being forced to divide content to make it look like what
it looks like.
SteveZ: you have restructured it in a form that defeats accessible access
SteveZ: you want to show content for different devices and you can't do it.
SteveZ: html as a suitable lang to express viz structure, it is possible
to explore restricting the use of regions to page templates and
in that context require they be empty boxes
Scribe: TabAtkins
howcome: I think the page template proposal is much more sensible in
that regard.
szilles: In that case regions would end up with addressable things -
we'd get CSSOM access to them.
stearns: The OM stuff is in a separate spec entirely - the pseudo spec
Daniel and I are doing.
szilles: The main reason for this is exactly what Tab said - from a
practical viewpoint, elements work today, and they're eventable/
scriptable/etc. This needs to be there for a lot of use-cases.
szilles: If you're paginating a complex structure, you don't know what
the use-cases are today, and we won't know what they are until
we see them in the wild.
szilles: You can come up with a few simple rules, but they don't
generalize right now.
<Zakim> Bert, you wanted to compare regions with columns and to say using
an external (XML) document for the visual structure is a different
case again, and OK
Bert: Two remarks.
Bert: I've been waiting for regions for 15+ years.
Bert: If we're waiting for events to be defined on them, cool, let's do
that. If it takes a year, okay.
Bert: going back to an example from Alan was using an external document
to define the regions. This seems fine to me as well, as long as
those extra element are clearly marked as being in a document which
is defined as being for layout, not meaning.
stearns: Certainly something MS has been working on - content in one doc
and visual structure in the other - and we've been doing
experiments with Shadow DOM, with similar effects.
stearns: Either way, they're separated from the meaningful HTML.
* sylvaing "CSS Regions: they work in practice but fail in theory"
glazou: I was speaking at the Paris Web Conf last week.
glazou: I demoed Regions and other things, and people came to the end
of my talk.
glazou: they said pseudos were bad because screen-readers don't read pseudos.
TabAtkins: I think they misunderstand. The real content will still be
in the DOM, in a single element.
stearns: By the time you get to the reader, you're not looking quite at
the DOM.
TabAtkins: Not quite - they vary. You usually get an accessibility tree,
which is an expanded version of the DOM.
howcome: If pseudos don't work, then why don't multicol work? They're
pseudos too.
dbaron: There's a long-standing problem with people trying to put
*content* into the pseudos, rather than in the document.
Scribe: dbaron
dbaron: ... ...
TabAtkins: If that's a problem then we also need to throw away flexbox
and grid for the same reason.
TabAtkins: If people have learned that putting content in pseudos in bad,
they'll interpret what you say as the same bad thing.
TabAtkins: I think their concern is actually mistaken.
<antonp> +1
glazou: Let's take a flow that ...
glazou: The voice reader should say "moving from one column to ..."
?: why?
TabAtkins: Regions encourages you to have a semantically-whole piece
of your content even if it's split visually.
TabAtkins: Accessibility could be better in general when display order
is different from source order.
glazou: I was just reporting what I heard
Scribe: TabAtkins
stearns: Unless anyone has something to continue in this discussion,
I'd like to close it. Leave the issue in the spec and continue
on.
<Bert> As long as "leaving the issue in the spec" doesn't mean:
"we'll ask at every meeting until there's a meeting with so few
people that we can officially decide to do it anyway."
stearns: The next thing is quick.
stearns: I think it was resolved yesterday.
stearns: How the regions specification defines the first region box as
the ICB of the named flow.
stearns: I wasn't sure if that was exactly necessary, but in the discussion
yesterday about paged media and the talk about first page and
ICB and such...
stearns: I think regions just needs to follow what is going on in pages.
TabAtkins: I think arronei thought up a name for the concept you need:
"fragmentation containing block". For the concepts you need
to pull from the ICB, without the *full* assortment of baggage
from it.
<fantasai> fragmentaining block!
* sylvaing fragmentaining block party!
* divya now occurring @ Saint Clair 3A
TabAtkins: So we need to define exactly what parts of the current ICB
concept need to be pulled out into FCB, because non-initial
pages/regions/etc need them. Then write that down and
reference it in Page and Regions.
RESOLVED: What Tab said immediately above about ICB/FCB
Multi-column Sizing
-------------------
<dbaron> http://dev.w3.org/csswg/css3-multicol/#pseudo-algorithm
fantasai: The proposal is to replace the "available width" and "shrink-to-fit"
variables with just "used width".
fantasai: And remove lines 3-10 of the pseudo-algo and just swap out
refs for "used width".
fantasai: Where used width is defined by referenced formulas.
howcome: We presume when used width is handled, so we're shuffling where
things are done.
howcome: So it's a simplification of multicol, and it doesn't make a
compliant impl non-compliant, so I don't have a problem with it.
howcome: [something about min and max width]
fantasai: That's contained in "used width". It's the result of all
the computations about what the width is going to be.
howcome: It seems you've been wanting to have a discussion about min-width
in this spec, but maybe I'm wrong.
SimonSapin: When is the available width unknown?
SimonSapin: The spec has one example - in floats.
SimonSapin: but that's no longer unknown, and it's defined in Sizing.
howcome: So no other changes, just these removals/swaps? No additional
complexities?
Bert: I'm not completely clear on what the change is.
fantasai: The available width is always known.
dbaron: You're removing the stuff about shrink-to-fit into Sizing, so
for the purpose of this spec, available width is always known.
fantasai: Right, because this spec isn't defining things well enough,
and we shouldn't be dealing with this stuff in this CR right now.
SimonSapin: In 2.1, what we call available width is based on containing
block, but in here it's not the same.
howcome: Right, that's confusing.
Rossen: Another is the "used width", which in 2.1 terms is the final
width, can still change here afterwards.
Rossen: If you came in with width:auto and have a column-count, it
can still change here.
Rossen: So you're either going to have a complete used-width spec
somewhere else, and thus yank out these two usages.
Rossen: or redefine shrink-to-fit elsewhere and don't call it used width here.
fantasai: The sizing spec defines the used width (in conjunction with 2.1).
fantasai: The purpose of this algo is not to figure out the width of
the element, but to figure out how many columns and how wide
they are.
fantasai: So we can assume that we've already figured out the width.
Bert: but you need that information to figure out the width.
TabAtkins: Right, you do use that in Sizing to figure out the width.
Bert: So all that happens *before* you figure out the intrinsic size.
fantasai: It's more complicated. [summarizes the shrink-to-fit algo in Sizing]
fantasai: So this formula in multicol is technically wrong - it overflows
when unnecessary in some cases.
howcome: It's not *wrong*, but it might not be what you want.
<fantasai> http://dev.w3.org/csswg/css3-sizing/
TabAtkins: Lines 5-8 aren't great. Sizing defines a slightly better
definition that doesn't overflow as often.
fantasai: Because this definition is a bit complicated, I don't think
this CR (multicol) is the right place to deal with this.
glazou: We brought this up weeks ago, and deferred it to the f2f to
resolve on it.
howcome: I agree we should kill lines 9-10.
howcome: I don't think we need to remove lines 3-4, seems like useful
information.
howcome: 5-8 gives *a* definition, even if it's not ideal.
TabAtkins: We should kill it if we know we have a better definition,
which we do in Sizing.
dbaron: The definition in 19-23 is more complicated - you don't want
to get a different result from 5-8 as from 19-23, once you get
a definite width.
<fantasai> The point is, that this pseudo-algorithm should restrict
itself to determining the number and width of the columns,
because the rules for sizing a multi-col are not clear,
not interoperable, and not agreed-upon
Bert: But that's in a float situation. I asked for column count and width,
shouldn't I get it?
TabAtkins: Floats don't overflow their containing block unless absolutely
necessary. Our better definition tweaks things if necessary
to maintain that invariant.
SimonSapin: Importantly, what does "unknown width" actually mean?
dbaron: You could interpret it as two different things, one is "you are
currently doing preferred / minimum intrinsic width calculation",
the other is "that, plus you have a shrink-to-fit width or any sort".
dbaron: I think Simon's proposal is taking the first.
<dbaron> I think
glazou: It seems that some work has to be done on this in any way,
because some definitions are missing or unclear.
fantasai: Yes. So we should not be leaving these in the spec. We
should pull them out and let Sizing define it.
dbaron: I think we should take the proposal, and raise further issues
as they come up.
glazou: Straw poll, 6 for, 1 against, many abstain/undecided
glazou: Those who are undecided, can you trust the group?
<fantasai> The proposal is, remove lines 3-10 in the pseudo-algorithm,
use the term "used-width' rather than "available-width",
and define in css3-multicol that "used-width" is undefined;
work on it in css3-sizing
Rossen: There seems to be some conflicting terminology. It seems to
be complicated.
Rossen: I'm interested in resolving this in favor of Sizing. I just
want to minimize damage on this spec.
glazou: Okay, so discuss before tomorrow evening, and we will resolve.
Otherwise, deferred.
<dbaron> lunch break until 2pm
Received on Wednesday, 14 November 2012 06:53:38 UTC