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

[CSSWG] Minutes and Resolutions San Diego F2F 2012-08-28 Tue AM II: Regions, Exclusions, and Collisions

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 28 Aug 2012 23:48:44 -0700
Message-ID: <503DBB4C.3080004@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Publish a new WD of Regions.
   - Discussed collision problem with exclusions and abspos
   - Discussed Florian's proposal for collision handling

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


   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.


   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
   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
   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
   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
   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
   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.
   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:

   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
   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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:20 UTC