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

[CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 Wed AM II: Exclusions

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 12 Feb 2012 02:19:35 +0100
Message-ID: <4F3713A7.2050008@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - Discussion of deriving shapes from images and other rendered content.
   - Concluded to use first frame of animated images.
   - Discussion of layout dependencies between exclusions and other
     layout models, and problems of mutual constraint resolution

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

CSS Exclusions
Scribe: TabAtkins

   <smfr> http://dev.w3.org/csswg/css3-exclusions/
   Rossen: We've made a few changes since the last f2f
   Rossen: We've had several issues raised during TPAC that we recorded
           in bugzilla.
   Rossen: We tried to address as many as we could.
   Rossen: We wanted to go over the remaining issues.
   Rossen: Simple one first.

   Rossen: previously we were using fixed-height examples, so it was hard
           to see the effect of auto height stuff.

   Rossen: Next, we took the updated syntax from Tab from Monday.
   Rossen: Related to that was the bug https://www.w3.org/Bugs/Public/showbug.cgi?id=15091
   Rossen: This was asking if we need to simplify the syntax for shapes.
   Rossen: Questions were raised related to this - do we need them at all?
   Rossen: And if we did, do we need all of them, and which ones?
   Rossen: We discussed this quite a bit, and we still feel pretty strongly
           that we need to give users that are hand-authoring the ability
           to create something simple and straightforward.
   Rossen: rectangle, circle, and ellipse definitely fit in that.
   Rossen: Polygon, once you move past a few points, is a little hard, but
           still doable.
   Rossen: So our answer is that we want to keep the declarative syntax.
   Rossen: And the set of primitives we're suggesting is sufficient.
   howcome: Shapes can be useful. We don't have a history of them in CSS.
   howcome: The problem of using shapes, in one of the examples, is that
            you write a shape that follows the outline of a font.
   howcome: But if that font isn't available, your shape will not match
            what the user sees.
   howcome: So by separating the shape and the data, this is a problem.

   Bert: minor editorial point: 4.1.1 says "SVG shapes," but the SVG shapes
         are actually in section 4.1.2. Section 4.1.1 is about CSS shapes.

   ChrisL: What were the other issues with shapes in CSS?
   ChrisL: I recall they just didn't have very tight definitions.  They
           weren't ever given a chance.
   vhardy: It seems that both are useful. Looks like defining the shape
            from text hasn't been addressed yet.
   vhardy: I think that shapes are still useful.
   plinss: I think what's being asked for then is "use the visible content
           of this element".
   astearns: There's one example where a shape is meant to correspond to
             rendered content, but there are other examples where the shape
             *doesn't* correspond to rendered content. There you want shapes.
   ChrisL: And in some cases you have a raster image with an alpha, but you
           don't actually want to use that alpha channel; you want a
           simplified outline around it.
   TabAtkins: So it sounds like shapes are great, but you also want a
              currently-missing ability to wrap around some rendered content.
   Rossen: Agreed.
   TabAtkins: When I've manually done exclusions by splitting an image into
              bands and floating it, I generally do things that would be
              fine with shapes.
   [some unminuted discussion about the applicability of using alpha channel
    with a margin]
   howcome: I recognize the value of the shapes, but I don't know if they're
            useful for level 1.
   howcome: I think we should start with the simple stuff first, and that's images.
   [several]: No, shapes are much simpler.
   vhardy: From a tooling perspective, people often draw shapes with those
           tools, rather than extracting from a raster image or something.
   * Bert expects to do this most of the time:
           img {float: left; shape-outside: attr(src, url); shape-threshold: 0}
   vhardy: One example in the spec has a car against a mountain background,
           with the text flowing around the car, and that's fairly difficult
           to threshold from the image. It's a large image, too, so sending
           down a second image for the alpha mask would be costly.
   plinss: Håkon's point is valid that we shouldn't have people forced to
           use shapes for things like wrapping around letters.  As long as
           there are options to handle those properly too, it should work,
           and we can have shapes too.
   * Bert would still like to do it as proposed in 1996 or so: 'img {float: left contour}'...
   ACTION vincent to add issue about handling visible content as a shape for Exclusions.
   <trackbot> Created ACTION-440

   Rossen: Next topic is a bug about animated images.
   Rossen: Our proposal was something we all got an agreement with at TPAC,
           where everyone felt either first or last frame.
   Rossen: Looking at default GIF behaviors, first frame is always the
           "default" when it's treated as a still image - in print, when
           animations are disabled, etc.
   Rossen: So using first frame seems the most sensible.
   plinss: And we can always add a property if we decide it's not crazy later.
   plinss: Can a GIF cycle just once?
   vhardy: yes.
   plinss: In that case, it stops on the last frame, right?
   plinss: It might make sense to use the last frame for that.
   vhardy: SVG animations similarly can run once, and it's somewhat hard to
           wrap for the last shape there, since it can have script.
   Rossen: So I think first frame is still the safest option there.
   smfr: For SVG, "first frame" is the image without any animations?
   vhardy: Yes.
   ACTION vhardy to add a note to Exclusions that animated images use the first
          frame (in SVG, render the image without animations).
   <trackbot> Created ACTION-441
   ChrisL: We want to write it in such a way, though, that later specs *can*,
           say, respond to animated SVG.
   vhardy: it seems we can add a property in the future to control that sensibly.
   TabAtkins: Agreed - this seems future-friendly.

   Rossen: Next issue is from Bert, about "contour"
   Bert: It's about an idea a long time ago, that when you use an image both
         for rendering and masking, to make it easy to specify that without
         writing the url twice.
   vhardy: It seems that this is similar to the previous idea of wrapping
           based on the visible content of some element.
   astearns: It seems we're proposing you can get a shape out of an alpha
             channel, or out of rendered content.  So if we're trying to
             avoid duplicated urls, we'd need multiple keywords.
   ACTION vhardy to investigate using the content of an <img> for wrapping
          without duplicating the url, in light of earlier discussion about
          shaping from rendered content.
   <trackbot> Created ACTION-442
   <Bert> 'img {float: left contour}' instead of
          'img {float: left; shape-outside: attr(src, url)}'
   <Bert> ... except that it is independent of which attribute the URL comes from.

   howcome: Another issue - this spec says it can be used with any positioning
   howcome: So how do we get interop if some impls use exlusions with some
            positioning schemes, while others do it with others.
   astearns: The intention of that sentence is that it works with *all* of them.
   dbaron: This is very interrelated to positioning schemes, since its
           exclusions order model works in the reverse of the way most
           positioning schemes place content.
   howcome: But it's rather complex.  What will you test?  What if you set
            an exclusion on a table cell?
   szilles: If you write the conformance criteria, you'll wind up answering
            the technical questions based on what you write there.
   TabAtkins: So we should have a decent explanation for how each positioning
              scheme interacts with exclusions (and possibly regions too).
   howcome: For example, floats are exclusions already.
   alexmog: It needs to explicitly say what happens with abspos, and with float.
   alexmog: But other specs should mention how they work with exclusions.
   howcome: [draws an example on the board with a float, and asks what
             happens if it becomes an exclusion]
   Rossen: Right now, the spec says that floats can't be exclusions.
   howcome: Good answer.
   Rossen: Also, as an impl experiment, I did floats using exclusions and
           it worked.  Less performant, but it worked.
   astearns: We do specifically mention how floats work with this.
   szilles: So if we have a section called "Positioning Schemes" that lists
            the schemes and any additional constraints that are introduced,
            it should satisfy Håkon.
   Rossen: That sounds pretty good.  It would address testability.
   howcome: If they don't work with floats, what if I have a float and want
            it to have a shape?
   alexmog: I think that anything in 2.1 that interacts with Exclusions
            should go in the Exclusions spec.  New positioning schemes
            should talk about Exclusions in their own spec.
   smfr: It concerns me if a spec like exclusions has to reference a bunch
         of other specs about layout models.
   smfr: I would much prefer it if exclusions could reference CSS fundamentals
         like the box model, rather than referencing specific positioning
   smfr: maybe we don't have the right fundamentals defined yet, but it seems
         dangerous to do anything else, or else we'll have combinatorial
   vhardy: I think that was the original intent. We had a two-pass algorithm
           that let it be defined simply by finding the position of each
           element, then the effect of each element.
   Bert: It's probably not doable in practice. If you refer to the box model,
         it needs an intrinsic width.
   <Bert> (My colleague Dom once extracted a tree of dependencies from our
           modules. Maybe we should make a cron job that makes that tree every
           week or so, so we can check that it is indeed still a tree...)
   howcome: I think with floats, how can you position them in the first pass?
            You need to lay out the content first.
   szilles: I think we're getting sidetracked
   howcome: Possibly not. If the processing model in Exclusions excludes
            certain positioning schemes (particularly floats), then we have
            a problem.  Then it's no longer agnostic.
   szilles: To simon's point, embedding references to particular other specs
             can produce a rats nest of cross-references. But there's an
             equal problem of *not* specifying what schemes were assumed at
             the time the specs were written.
   smfr: Is it an issue with constraints, or is it an ordering problem as well?
         Do exclusions first, then layout, or something like thta?
   vhardy: I don't think we'll resolve this today.  Can we take an action to
           work out the processing model further, and demonstrate how it works
           with the existing positioning schemes.
   szilles: The results of those experiments will tell you what to put in
            the spec.
   ACTION vhardy to investigate the processing model of Exclusions further,
                 and report results/figure out what to put in the spec for
                 various layout modes.
   <trackbot> Created ACTION-443

   howcome: New issue! We should really use background images as a source
            for exclusion shapes.
   howcome: We have a lot of tools for background images right now, and
            should just reuse those.
   glazou: I agree.  I don't know if it's compatible with your current model,
           but it's a novel way of doing things that's consistent with some
           graphical editors.
   Rossen: When we did all the model analysis and comparisons, your proposal
           was one of those.
   Rossen: At the time we discussed it and we agreed that it wasn't desirable.
   Rossen: but actually, it would fit with what we have now.
   Rossen: Only difference is, when we use background images, the exclusion
           will be part of the wrapping context of the element itself, but
           wouldn't make the element itself an exclusion.
   Rossen: Which glazou disagreed with in Seattle.
   glazou: yes, and I commented on it.  It's different, but both are useful.
   ACTION vhardy to add background-image support to the Exclusions spec
   <trackbot> Created ACTION-444

   smfr: There may also be utility for using border-image support for the
         shape outside the box.
   smfr: I was thinking of something like a rounded rectangle with some
         flourishes, or a picture-frame shape, with bumps on the corners
         but straight sides, and using that as an exclusion.
   Rossen: Sounds like you're signing up for it.
   astearns: We should probably put all of these ideas in the spec and
             then trim afterwards.
   vhardy: We'll at least put a note in about border-image, yes.
   howcome: Another issue.  Our current float approach can implement
            roughly half of the examples in the spec.
   howcome: It may be worth pointing that out - "if you want to use exclusions
            today, use floats with X method. This spec allows for more powerful
           stuff as well."
   * dbaron notes the minute taker can't hear the discussion
   howcome: Possible also just remove the simple stuff entirely from Exclusions,
            since floats do it already.
   howcome: We're defining the same functionality with two different properties.
   Rossen: Exclusions can penetrate through BFCs, unlike floats.
   Rossen: If you manage to position an exclusion over a table cell, it will
           penetrate through and affect it.
   Rossen: The scope of the exclusion wrapping context is the containing block
           for the exclusion algorithm.

   TabAtkins: I have no idea how this will work with Flexbox.
   alexmog: Layout will happen without reference to exclusions.
   TabAtkins: So flexbox layout will happen normally, and then if an exclusion
              changes how the text lays out, it'll just overflow?  That's fine.
   dbaron: I don't think it's fine.  It's *defined*, but I don't think it's
           what people want.
   TabAtkins: I think what people *want* is "iterate layout until stable".
   dbaron: That's why I'm not very happy with this whole thing.
   howcome: [draws a diagram showing an exclusion covering parts of four
             separate cells]
   Rossen: It would make the cell taller because the text flows...
   TabAtkins: But that contradicts what Alex just said.  He said the layout
              wouldn't be affected.  If it *is* affected, I'm back to not
              knowing how Flexbox will work.
   alexmog: We need to explain this more carefully.
   Rossen: [shows a live example of an exclusion crossing an element.
   [discussion of rossen's example]
   [summary: layout *is* affected by exclusions. The meaning of this with
             other layout models is confusing and unknown]
   <dbaron> we didn't get to the bit about how the way layout is affected
            is one-pass and therefore only works "correctly" when there's
            only one exclusion
   <dbaron> (in other words, the spec is broken)

   howcome: A common use-case is to position a pullquote centered on a
            column rule.  If it's abspos, then if you change the window
            size, it will no longer be centered.
   howcome: This is example *number 1*.
   plinss: This seems out-of-scope.  This is a generic problem of positioning
           schemes that can be handled outside of exclusions.
   howcome: You're willing to put that positioning scheme as the required
            line for exclusions? If not, example number 1 can't be done.
   alexmog: If we look at together GCPM and exclusions, and there are holes
            or inconsistencies, we need to raise those as issues.
   howcome: So are we willing to solve this use-case?
   vhardy: I think we already took actions on trying to solve these problems.
   szilles: Håkon, you were the author of GCPM floats. You have the obligation
            to take into account how that works with exclusions.
   howcome: That might be more multicol, but yeah.
   szilles: You can't say *we* have to progress float positioning. That's
            your spec.
   [argument about where positioning schemes]
   plinss: We agree that we'll address this use-case, and I put it in Håkon
           and the exclusions guys to work out where this goes, offline.

   Bert: A different issue, about the dark text on dark background.
   Bert: A recent exampe I had was two images. There was text that partly
         overlaps an image. At the point where it overlaps the image, the
         text changed color to maintain contrast.

   alexmog: Can we come up with a sufficiently general requirement that,
            normally, new layout specs shouldn't need to add a ton of text
            to deal with Exclusions?
   TabAtkins: That would be nice, yes.

<br type=lunch>

<fantasai> ~~ Why do people keep randomly CCing me on mails to www-style?
            I thought it was obvious that I'm subscribed already.
<fantasai> </gripe>
Received on Sunday, 12 February 2012 01:20:04 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT