- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 15 May 2012 16:28:21 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Regions
-------
Alan and Florian presented several ideas for generating styleable
pseudo-elements to hold content flows:
* overflow: repeat, which would redirect overflow into creating
a repetition of the element as it's sibling. Individual repetitions
can be targetted and styled with an ::nth-copy(An+B) pseudo-selector.
* A generic ::slot() pseudo element
* Page Templates proposal
http://dev.w3.org/csswg/css3-page-template/
There was consensus to replace all the examples in Regions with some
combination of the above techniques. There was also consensus that
the proposals need to be developed further, and that overlap and
interaction among them needs to be carefully considered.
Shapes and Exclusions
---------------------
- Discussed how shapes/exclusions impact wrapping content (it's just like
floats)
- Discussed using background images to define shapes/exclusions
- Discussed concerns about mixing with abspos and the resulting
collision-prone layouts
====== Full minutes below ======
<alexmog_> have agenda? is there a reason for me to call in?
<vhardy> alex: we are talking about regions, exclusions and box generation,
good time for you to join :-)
<tantek> is text-size-adjust on the agenda for today?
Present:
+Tantek Çelik (via IRC)
+Alex Mogilevsky (via phone + IRC)
Regions
-------
Scribe: Bert
Alan: box generation... regions vs elements... floats...
Alan: will take max. until 11:00
Alan: Some real-world examples from magazines.
Alan: We're starting to formulate proposals for them.
<sylvaing> http://wiki.csswg.org/spec/css3-regions/regions-print-use-cases
<vhardy> http://wiki.csswg.org/ideas/css3-exclusions-print-use-cases
Alan: About box generation:
Alan: 3 ways (at least):
Alan: pseudos, page templates, overflow-repeat.
Alan: We probably want all of them, at different times.
Alan: (Don't read the text on the screen, just the images.)
Alan: Wired magazine example, floats, side article.
Alan: Blurbs in the gutter or along the side.
Alan: on a page-to-page basis these are generated, until the text runs out.
Alan: Can do that with page templates that create regions.
Alan: Uses @template with @slots inside to define the slots.
Alan: And then flow-from to assign named flows.
Alan: Generates pages until the content runs out.
howcome: This is paged mode? What determines that this is paged?
Alan: It uses 'overflow-style: paged-x'
Alan: Syntax of templates not really that important to me.
Alan: Might need a "shadow DOM."
Alan: Important is the use case.
Alan: We just need a page template mechanism.
howcome: It looks like @page, why call it @template?
alan: @template in this example only applies to the content box of @page.
<vhardy> http://dev.w3.org/csswg/css3-page-template/
howcome: @page has already margin boxes, which are similar to this
@template in generating regions.
Alan: I'm open to different syntaxes.
Alan: This is one way, and it is a way without needing mark-up.
howcome: Good start, it takes pages seriously, it uses CSS instead of XML.
And good that you implemented it.
Vincent: it's a shim, a prototype in JS.
[several]: that is reasonable.
Glenn: Is flow-from & flow-into necessary? Seems redundant.
Alan: That's a syntax from Regions. There are ways without.
Alan: Could use a syntax with 'overflow-style' as well.
Alan: Without a 'flow-from', it gets the default content.
Alan: And those regions are chained.
howcome: is the order well-defined? What about @imports?
Vincent: That's good point and we haven't gone through all the cases.
Alan: Another thing is making sure that all the content is indeed displayed.
Alan: This is just the general idea, one possible way.
Vicnent: We'll get back to this later in the discussions.
Alan: We should have a general mechanism for dealing with overflow by
generating a new box.
howcome: Auto-generation.
Alan: Yes, by means of a repeat.
Alan: Any box could have a overflow style of repeat and it will duplicate.
glazou: And you can style those boxes individually? Idea from Dreamweaver.
Alan: Works well with multicol, in continuous media adds more columns.
Alan: Would like to use this in general for regions.
howcome: It was rejected when I proposed that many years ago.
Vincent: It is useful not just with multicol.
<howcome> http://lists.w3.org/Archives/Public/www-style/2008Oct/0148.html
<howcome> http://www.w3.org/2008/10/20-css-irc.html
florian: Note that my demo is based on Adobe's idea, it's not mine.
[Florian gives demo of a repeating block mock-up]
Florian: Multicol in a fixed height, and then the repeat creates a new
box with columns *below* the first.
Florian: It is not part of multicol, it is independent.
howcome: You have to position those boxes and the scrollbar of the
window will not match the height of the boxes.
florian: vh and overflow-style: paged
Alan: The repeating boxes give the reader some context.
howcome: [scrolls down the example to see four columns all cut off at
the screen edge]
florian: With pseudos you can style the nth copy of the box.
Florian: Warning: my example is fake, the style rules don't really work!
Florian: It is also backward-compatible, because the styling of the
copies is inside a pseudo that old UAs don't know.
#main::nth-copy(n) { overflow-style: repeat; height: 12em; }
#main::nth-copy(even) { background: #ddd; }
#main::nth-copy(3) { /* more special styling */ }
Florian: 'nth-copy(n)' means all copies, 'nth-copy(1)' means a specific
copy.
dbaron: So you have to evaluate the pseudo for all elements to see if
you have a match?
florian: I was looking for something that was backward compatible.
glazou: To answer dbaron: no, you don't have to. It is for graceful
fallback. You can *also* set the style on the elements themselves.
fantasai: But you need it if you only want the last one to scroll, e.g.
<dbaron> I'd rather overflow-style:repeat not be able to come from
::nth-copy(1), which requires we look at it for every element
Florian: Let's argue the details later.
Florian: But different copies can be of different kind; it's as flexible
as regions, probably.
Florian: each copy is a region with its own style.
Florian: Can do a lot, and is compatible with regions.
plinss: It seems to solve a lot of use cases for regions, but it does
not mean we do not need regions.
Alan: We can discuss the different solutions on the mailing list.
plinss: This *should* not address the same problems.
plinss: I don't like us to go down that path.
plinss: A new feature is fine, but that does not mean we don't need
the other feature.
howcome/florian: We didn't say it replaces regions.
Alan: We want to explore this. It does not replace all use cases for
regions.
<dbaron> ::nth-copy() seems just like ::region() in
http://dev.w3.org/csswg/css3-gcpm/#regions
(and I think I might prefer the ::region() name)
Alan: Back to ways to generate regions: let's look at pseudos.
Alan: Generating pseudos, incl. in the DOM. I think we want that.
Alan: We can use regions with all those box generations.
Alan: Would like to get Regions draft to the point that it uses all
those, and not need the empty DIVs.
howcome: Great plan!
Alan: Regions is interesting in that is works with all these things.
Repeating boxes is, too, because it is compatible with it.
Alan: We have an issue on the Regions spec that says we cannot use elements.
Alan: I don't want to disallow that.
howcome: if you can do it without elements, why do you still want to
abuse elements?
sylvaing: Want to use elements for programmatic access.
vincent: There are two other issues, let's look at those first.
vincent: How do we work on them?
vincent: Want a resolution where to put things like repetition and other
box generation mechanisms.
vincent: Add it now? Possibly split it later?
florian: Independently useful, so maybe develop at different speed.
fantasai: Seems to need regions to position.
florian: yes, but also useful without positioning.
<dbaron> It's not clear to me why positioning and floating depends on
regions.
florian: And we can do it faster than full regions.
howcome: That makes sense, even if we have too many specs already.
Alan: We can start by adding more pseudos.
Alan: Put it in Regions, in the examples.
Alan: Progress the spec in that way.
Alan: I think we want other pseudos as well.
Alan: But that may split out later.
Alan: But this could be enough for the spec that we have.
florian: so: page templates spec + Regions spec?
Alan: We indeed have too many specs.
florian: OK, doesn't really make a difference.
Alan: So should we add a single pseudo to the Regions spec?
Alan: A 'slot' pseudo that stands for a region, similar to Template
slots, but more general.
howcome: What is the difference with :repetition()?
Vincent: Instead of using an element to create a region, you could use
something else.
howcome: You always need an element.
Alan: True. But there is a general need for more pseudos. The 'slot' I
propose would be a generic region.
howcome: I don't understand. How do you solve the problems by adding
one more pseudo?
<dbaron> What's ::slot? Has it been described today?
(slot is in css3-layout)
florian: We can add it and drop it, or split it, when we know more.
plinss: Where there is commonality it makes sense to develop together.
florian: Not needed with the things we're proposing, maybe.
glazou: Takes too much time during ftf. When we have 5 proposals, need
to find out what overlaps.
howcome: I don't mean we need to do it today, but it needs to be done
in this group.
plinss: As we're developing different proposals, I don't want 5 different
ways to do the same thing.
plinss: identify the overlap, agree on working on it, and go off and work
on it.
glazou: Not sure we are at that point yet,
szilles: We see two or three different mechanisms today.
szilles: Overflow generates boxes. Also pagination creates pages and
content flows into it. Regions generalizes that idea of layout
structure. Is orthogonal to overflow/repeating. But there is a
dependency to make them useful.
szilles: Repeating doesn't really solve multiple flows case; you need both.
szilles: Consider them together, because they need to work together.
Cannot work on them independently.
szilles: Templates and Grids is an example of not working together enough.
Vincent: Mechanism for generating boxes [scribe missed]
florian: template mechanism is cool, overflow repeat is cool, too. But
what is the pseudo you're talking about?
szilles: That's the 3rd thing I mentioned.
szilles: Need a way to talk about another way pieces of content and regions.
szilles: Slots address things that do not exist as elements.
vincent: Say you have an article.
vincent: Can set the layout to a grid.
vincent: Grid cells can be regions.
vincent: Can then flow content into it.
vincent: But you need a way to address those regions.
Alan: The current Regions uses elements in the examples as regions.
Alan: If we had ::slots we could use that for styling.
howcome: How can that be only one pseudo?
Alan: I'm talking about a generic slot.
Alan: Can attach a slot to anything, including another slot.
florian: If you position it, where does it go?
Alan: We'd need to define that, could be before after sibling, etc,
fantasai: You also need to define the order.
Vincent: Yes we know, we had ideas for that in earlier versions.
plinss: This is example of the overlap I'm afraid of.
plinss: I'd rather like nth-copy to be a used as a slot.
<hober> plinss: something like div::foo:nth-child(2)?
<plinss> hober, yes
florian: We can work on that. But my example doesn't create a box
*unless* there is content for it.
Alan: Auto-gen and pagination are some ways, but auto-height is another.
howcome: Last copy with auto height would not generate more boxes.
florian: I now understand peter's point. Let's not talk about that right
now.
szilles: florian summarized as there seems to be agreement on regions
and overflow repeat. There is not enough details on what is
needed or not.
szilles: Is that indeed consensus?
szilles: Trying to understand and come back with proposal for 3rd piece.
howcome: Makes sense. Anybody can work on anything and come with a proposal.
glazou: Seems we're all interested.
glazou: We need written things.
Vincent: We can take an action to work on slot ideas.
florian: template and repeat are orthogonal.
Alan: But may want to repeat a template, too.
plinss: Orthogonal on how you generate the box. Overlap on how you *use*
them once generated.
plinss: Only one kind of thing.
szilles: Also natural DOM interface.
ACTION florian to work with Alan to work on overflow repeat and consider
how it interacts with slot pseudo element
<trackbot> Created ACTION-467
Alan: We need something in the spec before we address the issue.
Alan: Another issue, by Bert a few weeks ago, about disallowing elements
to be regions.
Alan: I think that would be a mistake.
Alan: Wrapper DIVs and such.
Alan: I don't know how to convince people, but I don't want to disallow it.
Alan: Seems to hamstring ourselves.
sylvaing: [missed]
howcome: Just make it so that we don't need elements.
howcome: That is enough. Too early to say what is in and what is out.
<dbaron> I agree with Hċkon.
sylvaing: So resolve to put everything in.
howcome: I object to putting in the element approach.
howcome: People will see that it works in IE10 and start using it.
sylvaing: it is too early, you said.
glazou: Let's wait and see if it indeed becomes common practice.
jdaggett: That is bizarre logic.
florian: It would be wrong to put examples in the spec that show elements.
florian: If it doesn't do that, it seems fine.
florian: Imply, don't say, elements create regions.
howcome: there should not be examples with elements.
Alan: Examples are the only places where we still have elements.
Alan: But no prohibition.
Vincent: it is currently an issue. We can keep the issue.
howcome: We don't need to agree to remove it, we need to agree if we
want to put it *in*.
sziles: Issue suggests DIVs. Issue can be reworded to talk about
"restriction on what boxes can create regions"
howcome: No, we need to say explicitly what we need. Do not sweep under
the carpet.
howcome: It is a contentious issue.
Alan: There are clearly two camps.
howcome: We should not omit the word "element" from the issue?
sylvaing: Are we trying to resolve the issue now already?
[several]: no, just the wording of the issue.
Alan: Let's leave the issue as it is then?
howcome: OK
Shapes and Exclusions
---------------------
Alan: On to shapes and exclusions:
Alan: Shapes seems non-contentious.
Alan: People want those inside and outside shapes.
Alan: Still open how exactly you generate those shapes.
howcome: no code examples in the draft, so hard to say.
howcome: [scrolling down to shape-inside]
howcome: What goes in the shape? the content, the children?
glazou: I understood the spec. But what is the question?
fantasai: E.g., when you have a float intruding into an element, it
doesn't affect the element's box, only shortens the line
boxes. (Unless it's a BFC, in which case the box may also
become narrower.)
szilles: It works exactly like floats today.
glazou: there are exclusions in GCPM, too, and they don't say either.
howcome: Right, because it depends on Shapes and Exclusions.
Alan: We can add examples.
howcome: the shape also shapes floating children?
Alan: Yes.
vincent: We specify floats and shapes, and processing model
("wrapping context").
howcome: An example with a float...
szilles: ... or a table...
howcome: ... would be good.
szilles: in text world, each line of text is as if it has a float on
its side, where it intersects the line and the shape.
howcome: That is a good way to define the behavior.
Alan: At least a way to explain it and also a way people implement it
today.
szilles: In a BFC you need to consider the whole BFC as one.
Alan: One issue is extending wrapping functionality other things than
floats.
Alan: We have a section with processing model for wrapping functionality
to non-floats.
Alan: We had an objection to that.
Alan: WG hasn't agreed to pursue that.
Alan: If not, we need to tighten the wording of the note.
Vincent: The objection was that the model assumes absolute positioning.
That is not what the spec really says.
Vincent So hard to argue with what the spec doesn't actually say.
Alan: Objection is that exclusions for abspos is a bad idea.
Alan: But the spec says exclusions can be generated to *any* box.
florian: Objection probably comes from the fact that floats currently
cannot influence further back than their own line.
dbaron: That is a part of it, but not the main piece.
dbaron: The use of abspos, in this kind of thing creates fragile pages
that do not resize.
dbaron: But florian's point is also valid.
Vincent: Depending on how you use abspos, e.g, with percentages, it may
still resize correctly.
Alan: Examples in spec uses grid positioning and that can overlap.
And if there is overlap, it is nice to have wrapping behavior as
well.
szilles: Media Queries allows new mechanisms to scale.
dbaron: MQ is good for the case where the author thinks about the sizes.
dbaron: But the problem here occurs even in very small ranges,
practically within the same MQ.
dbaron: So this spec *encourages* abspos where abspos is otherwise a
bad idea.
howcome: Related point: we also need to exclude based in background.
howcome: If we had that in the spec, there would be less concern
about abspos.
szilles: If there is a simpler way that abspos, then people will use
that and not abspos.
vincent: Not yet an example of using background.
howcome: Masks are in there already in some other way.
howcome: Backgrounds have become very powerful in CSS.
howcome: We just need to "connect the dots."
Alan: Extend wrapping to other things than floats is the question.
szilles: howcome addresses dbaron's point; if we offer something
simpler than abspos, people will not use abspos.
vincent: we had a wiki with comparison of solutions.
szilles: The issue is not to encourage wrong approaches.
szilles: The average person will take the simplest solution, not necessarily
the best.
vincent: If abspos is so terrible, let's remove it from CSS.
dbaron: We haven't done any enhancements to abspos since 1998 or so.
This would be the 1st enhancement.
vincent: similar to discussion on elements in regions.
vincent: Why is that in these two specs we have to do things that other
specs don't have to do?
Tab: Difference between definitely adding and leaving it possible.
Tab: Background used to create exclusions is a good way. Can often use
it without extra content added to document
florian: Don't tempt people.
glazou: backgrounds is not enough.
howcome: Can't you put it in?
glazou: summary: change the spec so that people use the preferred way
that does not involve abspos.
Alan: So issue is: do we extend exclusion to anything other than float
and backgrounds?
szilles: I prefer a concrete statement about what concerns dbaron.
dbaron: two big things are collisions and the complexity of the processing
model
Alan: Complexity may be too much. Collisions?
dbaron: Causes fragile designs that cause collisions.
Alan: That is an objection to abspos.
dbaron: But exclusions make abspos more attractive by avoiding some
collisions, but still others exist that you can't all test.
dbaron: Take as example a pull quote, you test and you have a pull quote
centered on all pages.
dbaron: But resize slightly and, suddenly the pullquotes are on top of
each other.
Alan: There is a way to put abspos to the top of the page already.
fantasai: But with abspos, you currently don't have a lot of incentive
to use it.
fantasai: but the exclusions *appear* to solve their problems.
dbaron: if the author doesn't see the right example, he won't use it.
vincent: Today already people design on desktop and it doesn't work on
a phone.
dbaron: That ... is why we're working flexbox and grid, e.g.
vincent: grid example is in spec. But grid allows overlap.
howcome: We need to position things between two columns.
Alan: No, that is not for this spec.
Tab: Abspos is salvageable as a decent mechanism is in the future.
dbaron: Too fragile.
ACTION alan to add 2 issues to more clearly define issue 1
<trackbot> Created ACTION-468
ACTION alan to add background exclusions
<trackbot> Created ACTION-469
howcome: And please add examples for all properties.
howcome: I think we had decided that in general.
glazou: Let's take that to e-mail.
vincent: Complex regions in the spec. Please, check and send feedback.
vincent: See if it is implementable.
vincent: Auto-sizing part ditto.
glazou: The specs are quite readable.
szilles: The choice of simplicity and efficiency over best results is
worth pointing out.
szilles: Sometimes thus less than optimal results.
szilles: Related to dbaron's points.
* alexmog off to sleep. dudes and dudettes, enough fighting for what
not to do, let's come up with something that works already!
<br/>
Vincent: I sent an e-mail.
Vincent: Implementation is available for download.
Vincent: You can play with it. Source is also there.
Vincent: It is based on public Webkit trunk.
Present:
-Tantek Çelik
-Alex Mogilevsky
Received on Tuesday, 15 May 2012 23:28:54 UTC