- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 28 Aug 2012 23:48:44 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish a new WD of Regions.
- Discussed collision problem with exclusions and abspos
- Discussed Florian's proposal for collision handling
====== Full minutes below ======
Regions
-------
stearns: We've been going through feedback on Regions.
stearns: The feedback on the OM has been very useful. The ED has gone
through a lot of revisions.
stearns: So I'd like to publish a new WD to reflect those updates.
RESOLVED: Publish a new WD of Regions.
florian: One thing about regions...
florian: We did @region because we didn't want to put things after the
pseudo-element. Should we change this now, given that we're
changing on that aspect?
jdaggett: Perhaps an issue in the spec about it.
stearns: We have some patches in WebKit already about region styling.
stearns: If we get to the point where we're able to chain pseudo-element
syntax, we're willing to change that.
stearns: But I'd like to have that shake out before I make changes to
the spec.
stearns: But I'll add an issue on the @region syntax if there isn't
already one.
Exclusions
----------
Rossen: We've made a lot of editorial changes to the spec, such as
updating a lot of images.
<Rossen> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15183
Rossen: One discussion we tried to revive was "Issue 1" in the spec,
which was put in by dbaron.
Rossen: [reads the issue]
Rossen: The processing model of exclusions - nowhere do we actually
insist on building the positioning scheme of exclusions on
top of abspos, but we don't forbid it either.
Rossen: So if you want to do abspos exclusions, you're allowed to.
Rossen: I don't see any reason to make an exception here and disallow
one type of positioning.
Rossen: I'd like to show a demo of exclusions used in grid, with no abspos.
Rossen: [shows demo]
dbaron: I'd like to explain why this demo doesnt' work well.
dbaron: First, unless you explicitly handle paging, you'll have to
scroll up and down for these multicol things.
dbaron: Now, if you produce more content, how is this exclusion paginated?
TabAtkins: I'ss just put in a cell in the grid, so that depends on how
grids are paginated.
stearns: If it's in a "page grid", it might be on every page. If it's
on an element grid, it's wherever it appears in the paginated
content.
Rossen: These questions seem to be about page templates in general,
not about exclusions at all.
* TabAtkins minuting failure.
Rossen: The placement of exclusions is driven by the templating system.
Rossen: Like a bunch of grids that are placed one after the other for
content that flows through them.
Rossen: It could be determined by the author or the app - the author
could have pull quotes that want to be displayed as exclusions,
or the host could insert an ad as an exclusion.
szilles: I don't see a connection between what's being said here.
szilles: David is seeing a document with a bunch of static declarations
putting things in various places.
szilles: He's wondering where these should go as pages vary or disappear
entirely.
szilles: But you seem to have a different model - an app, possibly with
JS, which takes the ocntent and builds the pages on the fly to
build the environment they go into.
szilles: So I can say "this figure goes with this text", and the app
will see this and can make choices about where to put things
in the template.
florian: Yes, this seems to be the difference in approach.
florian: We want to allow JS, but not rely on it.
florian: So if that's the model, that's a problem.
florian: However, I think we can easily agree that exclusions as we
currently have them (simple floats) are limited and we'd like
to do more with them.
florian: For floats as we have them so far, there's a collision system
built into the model.
florian: So you can't make an exclusions model that doesn't have a
collision system.
florian: Your model is more expressive - you can do *lots* of different
things with it.
florian: But by not combining it with a collision model, you lose the
safety of floats.
florian: You're saying that people will deal with it by using something
else. But they might not do that.
florian: Whether you have to activate the collision stuff by doing something
else in CSS, or by using JS, either way it's suboptimal, because
authors will forget to use it.
stearns: Two points - text wrapping is meant for occasions when things
collide.
stearns: Floats are allowed to collide with the inline content, but text
wraps around them.
stearns: Exclusions should be orthogonal to collision handling. You're
*trying* to create a collision.
TabAtkins: He's talking about multiple exclusions sitting on the same
point and colliding with each other.
stearns: I think that's sometimes desirable.
stearns: Back to the beginning example, if you have two of these exclusions
on a page and that was unintended,
stearns: If they're floats, you get float stacking behavior.
stearns: In most layout modes I've had experience with, float stacking
is an error. Nobody wants that to occur.
stearns: What you get out of float stacking is not anything a designer
would actually want.
stearns: So I think we need some additional controls for handling how
things get arranged when a collision occurs.
dbaron: I think one of the ways we can solve that is by adding additional
collision handling models for floats, so that stacking isn't the
only model.
dbaron: Like "if I don't have space, go to the next page".
stearns: That would be great. But I think it should be orthogonal to
exclusions.
florian: One thing that worries me is that if you're designing a webpage
without exclusions in a GUI environment, you won't use abspos
much.
florian: But if you do have exclusions, it's extremely natural to put
a box in a place and say "wrap around me", and you'll start
using exclusions in places where floats were just fine.
florian: You might have some logic in the GUI that creates floats
instead of exclusions sometimes, but I think that naively
it won't happen.
stearns: I think that 90% of the time, you'll have a single exclusion,
so conflicts won't happen.
florian: I'm worried that it's just too easy to do this kind of thing
with bad-behaving abspos.
* jdaggett pages are dead, long live screens of infinite variation!!
szilles: I think that Grid will often be the easiest thing. People
will want columns, etc. Very natural to do it in a grid,
and no abspos is involved.
[argument about usefulness of abspos]
Rossen: One point I keep wanting to make is that the exclusions spec
is trying to describe a general model for propagating exclusion
areas through structures of content - any structure.
Rossen: Floats are an extremely document-centric tool that's intended
to work in a single flat flow of textual content.
Rossen: This is meant to provide a base level of exclusion handling on
the base level of floats, so when you have a higher-level layout
system, once they're positioned there, everything that needs to
be excluded is excluded.
[argument about running into things by default, or avoiding by default]
florian: *Because* this doesn't talk about positioning, it's possible,
even easy, to let things run into each other by accident.
glazou: I feel that you're afraid of people abusing or just inexpertly
using features.
[chaos]
glazou: Whatever we do, users will find ways to use it badly and good.
florian: We shouldn't try to prevent bad behavior - that's impossible.
We should make good behavior the default, though.
<sylvaing> it's entirely possible that there is no 'ideal' default here
Tab: Vincent, their point is that it doesn't talk about positioning --
that's *why* it gets bad behavior by default.
* fantasai is totally ignoring this entire discussion because we've had
the exact same discussion with the exact same points at every single
one of the past F2Fs since Exclusions was proposed.
* fantasai agrees 100% with dbaron and Florian fwiw, though
florian: You're seeing the complete independence of layout modes as a
feature, I'm seeing this as a bug.
Tab: The goal isn't preventing bad behavior -- the goal is making good
behavior the default. Taking the simplest route possible shouldn't
lead to bad behavior.
stearns: The simplest case possible is a single exclusion.
stearns: would like to discuss on mailing list
* hober is in the same boat as fantasai on this one.
szilles: I think they want graceful degradation under normal circumstances
on the web.
[more chaos]
Sylvain: We've had this discussion in 3 cities now.
dbaron: What's new this time?
Florian: Extend floats to cover more use cases, rather than ...
glazou: This is not being minuted.
Tab: This same discussion has been minuted twice already.
glazou: This discussion has to be minuted.
<fantasai> twice is an understatement, I'm pretty sure it's more than that...
* sylvaing .exclusions::nth-argument-repeat { overflow: visible; }
Florian: I think a number of people would be more comfortable with
extending existing float mechanism to cover more cases that
it currently doesn't cover
Florian: Rather than the model being proposed here, which solves a
bunch of things, and introduces a whole bunch of issues
that we don't currently have a solution for.
Steve: It's not proven to me that it introduces the problem.
vincent: the discussion we haven't been able to resolve is that ...
exclusions & absolute positioning
Florian: doesn't say that
vincent: here exclusions has a model such that you can use it with
other positioning schemes
vincent: The other option is to say that exclusions don't work with
that positioning scheme.
vincent: Specification takes care to make a generic model. The
repeated thing that says it's bad
vincent: The issue is an incorrect characterization of the problem.
vincent: I'd be ok with a specific technical issue the spec has
vincent: ... not with generic issues that the spec
<florian> not with generic issues about the spec relying on abspos
because that's not true
vincent: but not with saying the spec relies on abspos because it's
not the case
dbaron: The fundamental issue is that a whole bunch of us are saying
that we don't think you should have an exclusions model
without a collision model.
stearns: Can we put that in the issue?
Rossen: So if a collision model is expected at the same time as the
exclusions, that's an issue we can address.
stearns: There's a discussion on the mailing list where florian said
something like this.
stearns: I said that I'd be fine with exchanging the current issue
text with what florian provided.
stearns: If dbaron could respond and say that's okay, we'd be great.
szilles: I can add a property that says "avoid collisions", and define
what it does.
dbaron: It's really not that simple.
szilles: That's what XSL did.
Florian: 2 ways forward: either the exclusion model as it is gets
extended to deal with the bad cases or the model is dropped
and instead we try to extend the float model to cover more
of the use cases
Florian: Personally I don't know how to extend floats so I tried to
propose an extra property for dealing with collisions
Florian: Even though I proposed that I'm not sure it's enough.
Florian: ... go in the direction of making the current exclusion model
less bad.
Florian: If we can add sufficient ..., then I think the exclusion model
could survive.
Florian: If it turns out we can't enough, then we may have to look at
another approach.
Scribe: Tantek
rossen: it would be great if we can reword the current issue to state
the technical problem
rossen: exclusions as defined do not provide mechanism for avoiding
exclusion to exclusion collisions if/when they are abs pos'd
florian: that is narrower than what I meant to say
florian: we need to prove that a collision handling system compatible
with exclusions is possible
florian: the best way to do that is to design one
florian: whether it should be optional is a different question
florian: missing bits: collision handling, preventing things from
disappearing off the page
rossen: so changing how abs pos works?
florian: what the objectors want to see, is the addition of extra mechanisms
to handle those missing bits
florian: that apply to all layout schemes
florian: that can be used to workaround the collisions and graceful
degradation issues
rossen: could you summarize as an issue?
ACTION Florian: summarize the issue of missing mechanism(s) to handle
collision handling, preventing things from disappearing
off the page
<trackbot> Created ACTION-496
vincent: would like illustrations of things that have been characterized
as bad things
florian: I will give some examples
florian: exclusions will make people use positioning schemes that have
problems that they wouldn't use in this way if exclusions
weren't there.
ACTION Florian: come up with examples illustrating the issues on
exclusions as noted in previous action 496
<trackbot> Created ACTION-497
Collision Handling
------------------
Florian: to move forward I have a modest proposal for collision handling
florian: I'm not claiming this is a sufficient answer to all problems
for exclusions, but it is a step in the right direction
florian: proposing new property, let's call it 'collision'
florian: collision: auto | allow | avoid
florian: auto computes to allow to preserve existing behavior
florian: avoid: if two things which both have collision property of
avoid end up overlapping each other, the 2nd one in document
order is moved out of the way
florian: how it is moved out of the way - up to discussion
florian: e.g. if there is room to the right, move it to the right,
otherwise move it down
florian: could also have another property 'collision-mode'
florian: to switch between different kinds of clearance systems
florian: for now just need a way to say let things collide, or avoid
the collision
vincent: do you foresee this for all positioning schemes?
florian: yes
vincent: e.g. also for grid?
vincent: a 2x3 grid
florian: in general yes
florian: property should be available to all layout modes
florian: if there are layout modes where we don't understand what
'avoid' means, we can make it compute to 'allow'
florian: for example for floats
florian: auto would compute to 'avoid'
florian: if you turn it to allow
florian: then you could have something like this (goes to whiteboard)
Florian's diagram from that he drew on the whiteboard:
http://instagr.am/p/OUbY-Fg9c3/
vincent: this may introduce behaviors in all other schemes
florian: I'm going to have auto compute to whatever existing schemes
do for each
florian: e.g. on floats to 'avoid', on abs pos to 'allow'
florian: on top of that I would add
florian: because we are introducing exclusions now
florian: because they are likely to increase use of abs pos
florian: we have a chance of fixing it there
florian: on abs pos to which exclusions is applied
florian: auto should compute to 'avoid'
vincent: why are exclusions encouraging use of abs pos?
florian: i can answer, but it has been answered already
florian: a bunch of times
vincent: it's a different question
florian: it's the same, we've answered it a bunch of times
florian: it's maybe not answered well
fantasai: we keep having this same question/discussion
vincent: why do you think exclusions are encouraging the use of abs pos?
florian: I've answered this, but i would like to time answer it better.
szilles: vincent, why is the answer important?
<fantasai> vincent, http://lists.w3.org/Archives/Public/www-style/2012May/0531.html
<fantasai> search for "But exclusions make abspos more attractive by avoiding"
peter: given exclusions, people will use abs pos more. i see that as a
good thing.
<sylvaing> so we're worried about abspos behaving the way people always
wanted it to be?
<stearns> sylvain: yes, I think that's a good characterization
<stearns> sylvain: but there are other things that need to be fixed as well
<stearns> hober: I was thinking of http://lists.w3.org/Archives/Public/www-style/2011Mar/0229.html
(picture not in the archive) asking for complex wrapping behavior
peter: i have a question for you (florian)
peter: when you turn on exclusions for abs pos, you're defining how it
should behave when it collides, he's asserting that the default
behavior is that it shouldn't collide, and that doesn't make
sense to me.
florian: this is a small but significant misunderstanding
florian: when the collision property computes to 'avoid', it avoids
other things that have 'avoid'
florian: e.g. if you have 2 abs pos *both* with 'avoid' they will avoid
each other
florian: but not others
rossen: if they're on top of another exclusion?
florian: if you want a collision...
rossen: how do you avoid one but not the other
rossen: you are giving me only a binary choice
rossen: I want to avoid some but not others
tabatkins: what's the use case for it?
rossen: 15 or so examples in the wiki
stearns: www-style list post from apple
florian: you have several examples where exclusions are supposed to be
on top of each other, but avoid some other
florian: i don't think you have such things in the examples
<dbaron> So far, I don't like this 'collision' proposal all that much,
but I'd like to think about it more.
szilles: you have a notion of grouping which acts as an entity and an
exclusion goes into the group
szilles: that would allow you to define an appropriate method of the
exclusion process
florian: if it's really important we can do it, but i don't think it
is necessary
florian: this is most useful on abs pos which have exclusions turned on
(in response to a q from vincent)
florian: the whole point I designed this
florian: is to try to save exclusions
florian: from the folks that say it won't work
vincent: are you proposing to work on the exclusions spec?
florian: I'm interested in working on everything, not sure I can commit
the time.
florian: I am putting this out there, hoping folks find it interesting
florian: not promising I can carry it forward (time)
szilles: this is a proposal that you believe might lead to a suitable
graceful degradation
florian: this is one piece of a solution to make exclusions acceptable,
not sure it is sufficient
florian: this is useful, otherwise half the group will object to exclusions
molly: i can see this being very logical from the author perspective,
useful in the scenario you described
molly: would be useful on a global thing
molly: any time you might have a collision
molly: to have that choice
molly: what would be the default be?
florian: for abs pos, allow, for floats, avoid
florian: just have to work out the layout modes one by one
florian: it may be tricky where collisions seem impossible
florian: e.g. in flexbox
florian: so what should we do?
florian: I think we can work it out for layout modes where collisions
are *possible*
florian: and we can use 'auto' to preserve the existing behavior
<Bert> q+ to suggest using grid templates (of course :-) ), i.e.,
replacing abspos instead of trying to enhance it...
Molly: would be useful
Peter: this is scary when layout modes intersect
Peter: flex box, abs pos on top of it with avoid, what moves?
florian: with abs pos and float, we can move floats out of the way
florian: with flexbox there might not be an answer
florian: we may have to just say that with flexbox it computes to 'allow'
peter: if i have a flexbox with multiple items with collision values,
and then a grid item with collision item with avoid, then ...
florian: respect document order, don't move the first one.
florian: the 2nd one moves out of the way
florian: if we don't find an avoidance behavior for flexbox they'll overlap
florian: if we do find an avoidance behavior, they'll avoid
szilles: at the risk of complicating things
szilles: in grid, the default is that they overlay
szilles: e.g. two things in one grid cell
szilles: Bert's templates had the items stacking
szilles: there's at least one option of saying avoid on things in a grid cell
szilles: we could make them avoid
bert: that's a way to define exclusion, and then that's the grid
bert: either use grid-column and grid-row to put it there, it will overlap
bert: or the flow property and it will not overlap
(references previous a grid diagram on the whiteboard a a a ... b ... c c ... )
bert: but it's not an extension of abs pos
bert: it's an alternative way of doing the same thing.
florian repeats statement about defining for all modes.
molly: I think you're solving what will become a design problem for
designers
molly: no comment on syntax
molly: but makes sense and would be teachable
Florian: do the people who object to exclusions feel better if something
like this is in place?
Florian: just Tab?
Florian: I will try to write something up
florian: where should it go?
rossen: would prefer in positioning
rossen: CSS3 Positioning
<arronei> It works for me in CSS Positioning.
rossen: to me this makes sense to go with positioning.
<arronei> Rossen you and I can put all this in there
molly: I also see this as a relevant approach to add control
rossen: even if they're not exclusions
molly: yeah
florian: I want to make it work universally
florian: you can give me an action item
ACTION Florian: write a draft proposal for the 'collision' property
with values: auto | avoid | allow
<trackbot> Created ACTION-498
Received on Wednesday, 29 August 2012 06:49:17 UTC