W3C home > Mailing lists > Public > www-style@w3.org > November 2011

[CSSWG] Minutes and Resolutions TPAC 2011-10-30 Sunday Afternoon I: UTR50, radial-gradient(), Exclusions and Shapes

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 28 Nov 2011 14:22:19 -0800
Message-ID: <4ED4099B.4040804@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Vertical Text Layout
--------------------

   John Daggett summarized what Unicode is doing with UTR 50, which will
   define the default orientation of each character in vertical text.
   Those interested are encouraged to review the draft and send Unicode
   comments: http://www.unicode.org/reports/tr50/

Gradients
---------

   RESOLVED: Stick with current set of features for radial-gradient()

Exclusions and Shapes
---------------------

   Rossen presented the current Exclusions and Shapes draft. Two major
   concerns were raised:
     - Error accumulation vs. performance in cases where there is a
       cyclic dependency between the position/size of the exclusion
       and the surrounding content it affects. (For example, when
       the exclusion is centered or otherwise referencing the bottom
       edge, actually getting the position right would require
       multiple-pass layout. The current spec limits it to two passes,
       which will give wrong results in many cases.)
     - Fluidity of the layout with respect to different amounts of
       content, different font sizes, different page sizes, etc. The
       feature seems to be designed assuming everything will always fit,
       and the examples make much use of fixed-size boxes.

   RESOLVED: Publish FPWD of Exclusions

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

http://www.w3.org/2011/10/30-css-irc#T20-04-28
http://krijnhoetmer.nl/irc-logs/css/20111030#l-630
http://krijnhoetmer.nl/irc-logs/css/20111031

<br type="lunch" dur="60min" />
Scribe: dbaron

Orientation and unicode properties for vertical text layout
-----------------------------------------------------------

   <jdaggett> http://www.unicode.org/reports/tr50/
   <glazou> "Orientation and Unicode properties for vertical text layout"
   jdaggett: I put this on the wiki.  Based on discussions from the summer.
             Current writing modes spec doesn't have an entirely normative
             defintion of orientation.
   jdaggett: So it wasn't clear what exactly the default orientation should be.
             This means that in vertical text layout, some characters, e.g.
             ideographic, stay upright, whereas roman characters are rotated
             on their side.  The question is which characters go which way.
   jdaggett: The current spec has an appendix which gives an algorithm; I
             don't know whether it's currently marked as normative.
   jdaggett: But the question is what the right way to do this is.  In
             talking with Eric Muller (sitting in the back), it would make
             sense to make a Unicode property for this specifically.
   jdaggett: This proposal is to make an additional property for Unicode
             that would specify the default orientation that the writing-modes
             spec could normatively reference.
   jdaggett: There's a comment period now, and there will be another review
             period.
   <jdaggett> http://wiki.csswg.org/spec/utr50
   Eric: Process-wise, UTC meets next week. Then produce a draft version of
         the TR and have another round of review.
   jdaggett: These http://wiki.csswg.org/spec/utr50 are Elika's and Koji's
             comments as to different issues.
   jdaggett: Very clear for ideographic and alphabetic characters, but there
             are a number of character ranges where it's more difficult to
             decide.
   <jdaggett> http://www.unicode.org/reports/tr50/bycp.html
   jdaggett: http://www.unicode.org/reports/tr50/bycp.html is the proposed
             list of codepoints and how they change
   <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf
   jdaggett: http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf
             is a PDF that shows ... scroll down to U+2000 ...
   jdaggett: These are some general punctuation characters.  Green column
             shows the vertical alternate that exists in the font (Hiragino
             Mincho, Kozuka Mincho, Meiryo).
   jdaggett: Where the character in the green column is different it means
             there's a vertical alternate for that codepoint.
   jdaggett: U+2014, em-dash, no fonts have vertical alternates for it
   ?: Using the VERT feature for this?
   ?: In Kozuka font, U+2014 is proportional -- covered by VRT2 but not
      by VERT.
   ?: In vertical, you do want U+2014 rotated to go along with other Latin
      characters that get rotated as well.
   jdaggett: On the Mac it's natural to use U+2014, on Windows it's natural
             to use U+2015.
   ?: In our fonts it's also a distinction between proportional and full-width.
   jdaggett: When you say proportional, the expectation is that it will be
             set sideways.
   ?: do that with VRT2
   jdaggett: scroll down to the arrows... high U+2190s
   jdaggett: See that the arrows are ... U+2190 pointing to the text that's
             coming before it
   jdaggett: I also have how the current IE and WebKit implementations
             handle this.
   jdaggett: These may not be totally accurate because it's a little tricky
             to figure out.
   <ChrisL> http://www.microsoft.com/typography/otspec/features_uz.htm#vert
            http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
   jdaggett: The problem we want to solve is that we don't want different
             implementations handling this differently.
   jdaggett: Once Unicode has a property that establishes this we have
             firmer ground to make text-orientation consistent across
             implementations.
   jdaggett: We won't get a solution that works 100% of the time, but we'll
             get a good default that authors can still change when they need
             to.
   Bert: Looks like an issue for Unicode, not us.
   jdaggett: Right now our spec is defining an equivalent of this.
   fantasai: Yes, once Unicode defines this we will reference it.
   jdaggett: When you go into the details there are still questions as to
             what the OpenType layout model is for vertical text, and
             questions for which way specific code ranges should go.
   fantasai: Details of code ranges don't need the whole room.
   SteveZ: In other words, if you think you care, look at these documents
           (wiki, tr50) and comment.
   jdaggett: We have two browser implementations of vertical text, and it
             would be nice if the implementors ...
   fantasai: ... looked at this and made comments as appropriate.
   jdaggett: There's wide variation between existing implementations.
   SteveZ: One thing that's important as a principle: we're trying to do
           it so the choice of whether something is rotated or upright
           can be made without looking at the font data.  One reason for
           that is that it's expensive or impossible given how the font
           data are encoded in OpenType (and may be impossible through
           some OS interfaces).  But it must work in the context where
           the fonts do things in certain circumstances, so it's a slightly
           messy problem.
   ACTION hober to review Unicode TR50 and compare to existing implementation
   <trackbot> Created ACTION-378
   ACTION sylvain to review Unicode TR50 and compare to existing implementation
   <trackbot> Created ACTION-379


[side-note wrt writing-modes] fantasai: we might want to discuss property
   to tailor UTR50 to handle e.g. greek/cyrillic being upright, but we can
   discuss that offline

Publishing
----------

   Bert: You said you wanted to publish regions as well?
   Bert: I also wanted to ask if we could publish a new template layout module.
   glazou: A little more than a week -- let's say two weeks to look at this,
           and then make a decision in 2 weeks?
   Håkon: Can we do the action points first before we publish?  I think it
          would be helpful for the specs to have code examples.
   jdaggett: replacing the pseudo-code with real code
   Håkon: maybe put in a couple of use cases
   SteveZ (?): There are use cases on the wiki.
   RESOLVED: publish regions and template if there are no objections in 2 weeks

Gradients
---------

   <bradk> http://wiki.csswg.org/ideas/radial-gradients
   Tab: I assume everybody has read all the mailing list discussion on
        the subject. :-)
   Tab: We have 2 proposed syntaxes for radial gradients.  The one in the
        draft and brad's simplification of it.
   Tab: The differences between them at this point are that:
    - draft allows arbitrary position;
      brad allows center/side/corners only
    - draft allows more options sizing the gradient;
      Brad has just circle or ellipse that fills the box
   Tab: The question is which one we're going to keep.
   Tab: This is the only remaining issue with css3-images; want to move to LC.
   fantasai: Do a pre-LC TR draft first.
   Brad: When we did linear gradients, we simplified it and made it easy to
         understand and learn.
   Brad: I think all the options in the draft are confusing and overcomplicated,
         and I think the way people use those options is really confusing.
   Brad: I think the layering of different properties that affect the length
         of the gradient line in different ways.
   Brad: In some cases position makes the gradient line larger or smaller.
   Brad: To understand what's going on you have to understand what wins when
         background-position and background-size change it
   Brad: The arguments for all this extra control seem to be centered around
         non-background use of radial gradients, which are, imo, edge cases.
   Brad: If you want to use a radial gradient as a list-style-image, and you
         can't get the clipping/styling/positioning you want, I think that's
         a minor issue that shouldn't drive the syntax.
   Tab: I disagree with that.  Making all the other image-bearing properties
        have properties analogous to background-position and background-size
        (list-style-image, border-image, masks) ...
   Tab: While you can do without it for the most part in backgrounds.
   Tab: I think what's there isn't that hard and is sufficiently useful to
        justify itself.
   Tab: There are 3 bits that require thinking about with a radial gradient:
        if you're using a position other than center then all the implicit
        sizing keywords and ? and ? are relatively simple to think about if
        you're only using 1 or 2 of them together.
   Tab: The one in Lea Verou's gallery that used all 3 and was very confusing
        was done that way because existing browsers don't have explicit sizing.
   Tab: This is the Hearts Grid example.
   Tab: You can do the "Syntax A" version
   Elika: Which is the position and which is the size?
   Tab: position, then size
   Brad: That's my whole point: we're saying that if you want explicit sizing
         you have to put in a value for the position, since you need that
         comma in there to distinguish.
   Tab: The problem of positions and sizes looking similar is also in the
        background shorthand.
   Brad: slash there, comma here?
   Elika: I'd prefer something that didn't involve comma-separating everything
          so we could tell what's what.
   Tab: Unless we did a slash I'm not sure what we'd do.
   Daniel: no slash
   Brad: ...
   Brad: If it's a problem that we can't size images for list-style-image
         then it's a problem for all images, not just gradients.
   Arron: It's the intrinsic size of the image.
   Tab: With a gradient you can't control the intrinsic size.
   Chris: I don't agree that non-background cases are minority:  I think
          we're going to see more of that.  I'm reluctant to see a solution
          that doesn't give full functionality to non-background images.
   Brad: Won't those types of images need that functionality anyway?
   Chris: There are things that know how to size themselves that are not
          background images.
   Elika: With a PNG image, you have the same problem.
   Elika: Wouldn't it be better to have a mechanism general enough to
          handle non-gradient images?
   Brad: Better not to have to use the gradient functions to solve that problem.
   Chris: Things I'm thinking of don't have that problem -- they know how
          big they are.
   Chris: The syntax that requires background-size and background-position,
          then we'd be very limited using CSS gradients for 'fill' and 'stroke'.
   <fantasai> radial-gradient(<size> <shape> from <position> as <color-stop>, ...)
   <fantasai> <size> would be one of the keywords
   Chris: existing syntax has % and absolute, corresponding to SVG's
          userSpaceOnUse and boundingBoxRelative
   (minute taker has trouble keeping up)
   Brad: simplicity is a feature, makes CSS easier to learn
   Elika: I'd prefer a halfway point between the two.
   Brad: I already went a little towards Tab's with putting center on
         edge/corner.
   Elika: farthest-corner, etc., make it easier for me to think about
   Brad: ... other colors going on past ...
   Elika: put a color stop at the nearest corner?
   Brad: That seems more complicated than just saying 142%
   Brad: When I'm desiging things I'm doing it visually.
   <tantek> would this qualify as an irrational discussion?
   Brad: It's can be important to hit the edges exactly when getting a circle,
         but matters less to be exact at the corners.
   Molly: None of this makes any sense to designers/developers -- I don't
          think this belongs in CSS.
   Molly: ok, let's leave the second point for dinner conversation
   Daniel: I implemented a visual editor for the gradient proposal -- it's
           very complicated because of the syntax.
   Daniel: I did the original WebKit proposal and the WG one afterwards.
   Tab: It should be a lot easier now with explicit sizing.
   Brad: I made a list of all the details I had to learn about how these
         parameters interact with each other.
   Brad: linear gradients are simple, one side to the other
   Brad: With this simplification, you're either going from one side to
         the other or center to the side
   Brad: keeping it simple makes it much more understandable
   Tab: Linear gradients are easier because it's one-dimensional.
   Tab: Any linear gradient can be represented using the current syntax.
        Can't do that with radial gradient -- many can't be expressed in
        simpler form.
   Brad: I'd want things more towards the simple side.
   Molly: Agree.  This is really SVG.  We're putting it in CSS because
          designers want it right now.  I think we need to keep it simple
          and respect what's in SVG.
   <Bert> +1 to Molly
   * Bert doesn't feel so alone anymore :-)
   Molly: Designers would love the perfect WYSIWYG.  As implementors you
          may be able to understand something, but putting it in language
          that people with less experience can explain...  Trying to stopgap
          a need from designers.  Concerned about simplicity and relation
          to SVG.
   Tab: Remember, the majority of gradient usage won't use the functionality
        we're talking about.
   Sylvain: We have 4 implementations.
   Daniel: Opinions of those who make tools that design gradients?
   Daniel: we have to reach a consensus
   Arno: I'd lean towards the simpler syntax.
   John: I would too
   Alan: There is an SVG fallback.
   Sylvain: Authors I've talked to have been more bothered by the change
            to bearing angles than by the complexity.  What seems complex
            now may not in the future.
   Brad: I don't think complexity goes away.

   Elika: I'm confused by both syntaxes.  I'd want something more readable.
   Elika: How can we make it obvious which part means what?
   Elika: Get away from commas, use keywords.
   Elika: linear-gradient(from left as red, blue, green)
   Elika: radial-gradient(circle from top left as red, blue, green)
   Elika: radial-gradient(<shape>? from <position> as <color-stop-list>)
   Brad: I do have the 'from' keyword, optional if not starting from the center.
   Bert: Why 'circle' at all?
   Elika: Otherwise it's an ellipse.
   Elika: gradients have no intrinsic ratio
   Elika: You can do Tab's set of functionality or Brad's with this syntax,
          but I think it'll be understandable

   Brad: I have the idea that if you specify 'circle' it does have an
         intrinsic ratio.
   Brad: That solves the what if you want a non-distorted circle that fills
         to the corners.
   dbaron: I don't think giving it an intrinsic ratio solves what you think
           it solves
   dbaron: I think what you were saying is that if you want a circle that
           fills out to the corners of a non-square box
   dbaron: so you want somehting where the extent of the gradient is that
           *draws rectangle inscribed in an ellipse*
   Brad: sorry, should have said "background-size: cover"
   dbaron: that'll be smaller than what you want
   Brad: I have a circle, used the circle keyword, and draw gradient to 142%
   Brad: and then ..
   dbaron: I don't know if we need to dig into this too much, though.
   Steve: You would get what you want if the diameter of the circle covers
          the box.
   Steve: Which is another way of saying...
   dbaron: Tab's syntax has keywords for those four possibilities.
   daniel: we've been working on gradient syntax for months without conclusion
   steve: one reason we might not have a conclusions is that neither are
          acceptable yet
   steve: there are good ideas in both, but still haven't gotten one that
          people understand and can communicate
   daniel: Both solutions are okay. That's the problem.
   daniel: But we need a resolution, and designers need this to ship
   sylvain: People are using this today.
   dbaron: And they're using it enough that this might wind up being the
           first -moz-prefixed thing we are unable to drop, given the number
           of changes.
   fantasai: I really want to go in this direction. I can't read this stuff.
   (this == using keywords)
   Tab: I want to resolve on this asap.
   Tantek: You're saying taking longer hurts more than complexity
   Molly: And then educators are stuck with this for eternity
   daniel: What's the plan?
   fantasai: I would like 24 hours with Brad and Tab and come back here tomorrow.
   Tab: What I want more than anything else for my birthday is to close this
        issue.
   <tantek> Dante's Inferno would have used radial gradients.
   * hober the 9 color stops of Hell
   <arno> :)
   the closest-side, etc. could be following a 'to'

   Tab: Brad's concern about complication is about position of the gradient
        line.
   Bert: What's the difference if it's not the syntax?
   fantasai: The ability to do arbitrary center, and the
             {farthest,closest}-{corner,side}, and explicit sizing of the
             ellipse.
   Brad: And the fact that I'm starting from edge or center means I can go
         from corner to the full width of the element maintaining a circle.
   dbaron: Isn't that farthest-side?
   Tab: My syntax gives you the option.
   Daniel: We are running in circles.
   (Aren't we running in ellipses?)
   Daniel: Straw poll, syntax A (Atkins) vs. syntax B (Brad)
   Luke MacPherson: A
   Shane: A
   Steve: no comment
   Molly: abstain
   Bert: B (set of features, not syntax)
   Stearns: abstain
   Alex: to Sylvain
   Arno: A
   Brad: B
   Tab: A
   Elika: abstain
   Daniel: B
   Koji: A
   John Daggett: don't like either, so abstain
   David: I guess A.
   Arron: A
   Sylvain: A
   John: I'll have to learn A.
   Håkon: abstain
   Peter: abstain
   Chris: A
   Vincent: A
   Rossen: A
   Tantek: A
   Hober: A
   RESOLVED: Stick with Tab's set of features.
   ACTION Tab and Elika: discuss improvements to syntax within this set of
                         features
   <trackbot> Created ACTION-380
   <dbaron> Can we teach tracker to give actions to 2 people?
   <fantasai> ACTION plinss: teach Tracker to give actions to multiple people
   <trackbot> Created ACTION-381
   <fantasai> :P

Scribe: fantasai

CSS Object Model
----------------

   Håkon: Anne will be at TPAC Monday and Tuesday.
   jdaggett: Shouldn't Anne be here?
   Daniel: Originally Scheduled for Tuesday at 9am.
   howcome: I can inform him that we'll discuss this Tuesday at 9am
   glazou: if he's not going to show up to discussions...
   glazou: Ok, next topic

CSS Exclusions and Shapes
-------------------------

   <Rossen> http://dev.w3.org/csswg/css3-exclusions
   <dbaron> http://dev.w3.org/csswg/css3-exclusions/
   Rossen: there were two independent spec works being done by MS and Adobe
           before we even brought any of this to the WG, and at some point
           Adobe brought in original Regions and Exclusions spec, and that
           was halfway when almost done with our part and getting ready to
           propose working on Floats
   Rossen: At that time we decided to see what the differences and similarities
           are and come up with one single spec
   Rossen: CSS Exclusions was split from CSS Regions
   Rossen: And since last F2F in Seattle our one major action was to redo the
           spec combine, css exclusions and positioned floats and present that
   Rossen: And get that towards WD
   Rossen: So CSS Exclusiosn and Shapes we are talking about today
   Rossen: We're going to see what CSS Exclusions are and how to use them,
           and what the CSS Shapes are and how to use them
   Rossen: The two concepts are currently separate concepts, but they actually
           work really well together. So keeping them in same spec for now

   Rossen: CSS Exclusions
   Rossen: Basic definition, it's an area that you want to preserv clear
           from any inline-flow layout
   Rossen: Many examples of this in magazine layouts: pull-quotes, figures
           with type wrapped around them, etc.
   Rossen: In CSS we already have floats, which are like exclusions, but we
           lack the ability to position them precisely
   Rossen: Currently we allow exclusions to be applied to any block-level element
   Rossen: so an exclusion can be any block-level element
   * ChrisL such as ins and del
   Rossen: Combined with abspos you can create some really magazine-like layouts.
   Rossen: I will show slides and spec side-by-side

   Rossen: So, declaring exclusions is done with the 'wrap-flow' property
   Rossen: Setting it to anything other than 'auto' creates an exclusion
   Rossen: 'auto' in this case is special because for regular flow elements
           the 'auto' value doesn't change the behavior of floats
   Rossen: Exclusions can be applied on the left, right, or both sides
   <BradK> Exclusions apply to block only, but floats turn inlines into blocks.
           Shouldn't they behave similarly?
   Rossen: maximum picks the left or right, whichever has the most space left
   Rossen: Last one is clear, which clears wrapping on both left and right
   jdaggett: Is there a typo with the maximum example showing up twice?
   Rossen: No, the example shows what 'maximum' does when there's more room
           on one side or the other.
   szilles: 'left' and 'right' don't work vertically.
   fantasai: It would probably map to line-left and line-right, but it should
             probably just be 'start' and 'end'.
   fantasai: Or have them both, since they do slightly different things.
   jdaggett: Why not just start and end?
   fantasai: If you have a design that doesn't depend on the writing direction,
             frex.
   howcome: Are there any restrictions on what elements can affect other things?
   Rossen: Next slide, containing model.
   Rossen: We're not changing things beyond what 2.1 already specifies.
   Rossen: We find the containing block, and that's the exclusion container too.
   Rossen: The definition we have for wrapping context is simply a collection
           of exclusion areas.
   Rossen: An exclusion area is the area defined by the element. Initially this
           is the border-box of the element
   Rossen: As we'll see later on, this can be changed into a shape

   howcome: I can't really parse this text here
   howcome: If an abspos comes from outside, will it affect layout of a
            deeply-nested <p> element?
   Rossen: Does everyone understand the containing model?
   Rossen: You have somewhere in a subtree of an element an abspos element,
           and it positions to a containing block.
   Rossen: The scope of the exclusion is the entire subtree of the containing
           block.

   howcome: Then you have 'wrap-through' property.
   Rossen: You can use that property to stop the propagation of wrap context
           at any level of the subtree. But in the subtree only
   Rossen shows the example of 'wrap-through' right above the 'wrap' shorthand
          definition
   jdaggett: ...
   Rossen: It's positioned and sized following CSS2.1 rules.
   Rossen: Once it is positioned, it is registered as an exclusion, and the
           flow layout will continue from that point on, respecting that
           exclusion
   jdaggett: The content of the exclusionary is what?
   jdaggett: What goes in that div that you're absolutely positioning?
   <TabAtkins> Shane suggests a 'rap' property to complement 'flow'.
   howcome: So 'wrap-through', it's similar to 'float-through'
   Bert: No, that's different
   dbaron: That's propagation to ancestors, not descendants
   howcome: If you have a <p> and you have a float on the side, you end the
            element, the float continues
   dbaron: Wrap through is about going through to descendants
   dbaron: This model can't describe float, basically
   howcome: But you're introducing a different concept.
   howcome: Could we not latch onto one of the other contexts that we have?
   howcome: I'm wary of introducing yet another reference model
   vhardy: We've been bouncing around on this for several months, this is
           what we ended up with
   Rossen: We started with floats, but it had a lot of issues that we were
           not able to solve.
   Håkon draws a box with a float inside it that's taller than the box
   Bert: I think you're talking about something else, howcome.
   Bert: The second paragraph that you (howcome) didn't draw. The wrap-through
         property isn't about whether the float goes through, but whether the
         line boxes in the second <p> wrap around it
   howcome: It's so similar to floats, we should extend floats
   Rossen: .. they do create exclusions, and in this respect they're the same
   Rossen: In this respect they're not completely normal. But it is the
           positioning that we want to address.

   Rossen: Do people understand 'wrap-through'?
   Rossen draws a diagram:
     circle marked CB at the top
     triangle extending down from it
     a squiggly line extending from the circle down to a small circle inside
       the diagram
     which then connects to the left corner of the big triangle and the middle
       of its base
     this part is shaded
     a thing on the base line on the non-shaded part points back up to the
       CB circle
   Rossen: wrap-through opts out of the wrapping. It's an opt-out model rather
           than an opt-in model.
   howcome: How common is this?
   howcome: If you have an exclusion, can't it just be an exclusion?
   Rossen: We did have use cases for this
   Bert: Say you have in that tree you draw there, the small black thing
         that's abspos, it pushes everything else aside.
   Bert: It has wrap-flow something.
   Bert: When you say wrap-through on the other circle, then you set wrap-flow
         on it.
   Rossen: Then you have multiple exclusions
   Alan: There was a bunch of discussion about overlapping and combining
         exclusion shapes and having portions be affected by this exclusion
         shape and not that one, to build up more complicated layouts that
         have that feature that was requested.
   dbaron: wrap-through is an attempt to do that?
   Alan: You don't do it by itself, you use it with other exclusion shapes,
         to chose which ones you'd be affected by
   Alex: ... my content doesn't wrap to anything, so the exclusions overlap
         but the content flows around
   Bert: The problem I see with wrap-through, if you have a floating element
         there, you still want to wrap around that floating element
   vhardy: Your question is if I have a float before here *draws a circle
           before the small circle*
   vhardy: Is that float still affecting wrapping
   vhardy: In our model, we have just one wrapping context, and if you exclude
           them [...]
   Rossen: We can scope the opt-out wrapping so that floats are not affected
           by it
   Rossen: In otherwords, floats would still contribute as they do today
   Bert: I'm still brainstorming here.
   Bert: You might also on this subtree set a z-index at a high value. And
         then you'd be in front of the exclusion. That seems easier.
   Alex: I think wrap-through needs a better name. I was confused for the
         longest time what it does.
   Alex: The meaning of the property is "make this container avoid wrapping
         anything"
   suggestion: 'wrap-off'?
   * fantasai thinks the name is fine
   Rossen: wrap-through means stop the propagation of wrapping context
   howcome: So it's the same as this thing I'm describing here. I'd like to
            have it for floats.
   dbaron: What's the use case for floats?
   dbaron: Why do you want this, and why do you want this here?
   <vhardy> http://wiki.csswg.org/ideas/css3-exclusions-use-cases
   Rossen shows UC2
   Rossen: In this case we have 2 exclusions affecting each other as well
           as the context around them
   Rossen shows example of two columns of black text, wrapped around:
          a red circle of text in the center, which has a blue square text
          intersecting with it; none of the text overlaps
   * fantasai wants to know what happens when you increase the font size of
              that red circle
   Rossen: One use case not in the wiki was to have for example tables, where
           data is really supposed to be presented in some manner, if you want
           to pop out of exclusion so that the table's contents aren't affected
           by it
   Rossen: There are layouts for which you don't want to have exclusions.
   jdaggett: How does z-index affect this?
   Rossen: thanks for moving us ahead

   Rossen: So, once you have a wrapping context computed for an element, you
           have a collection of many elements that want to be exclusions
   Rossen: we need to compute their order
   Rossen: By default the last item in the document will be on top of
           everything else
   Rossen: Naturally we'd want everything else would be affected
   Rossen: Ordering of exclusions is done in painting order. And you can use
           z-index to reorder them
   Rossen: Doing this work, at first it seemed kind of hard to wrap our heads
           around would z-index just work
   Rossen: Interesting thing is that all of the sorting is doable just locally
           on that element
   Rossen: You don't have to sort the entire document and figure out all of
           the stacking contexts in order to apply this, simply because the
           scope of exclusions is basically limited to the containing block
   dbaron: But it covers all descendants too
   dbaron: So it's not a local process. You still have to perform layout
           between each one.
   Rossen: Not a local process. It is a two-pass layout
   Rossen: in which you first lay out all of the descendants
   Rossen: Not abpsos though
   dbaron: Yes you do, because [...]
   dbaron: because there might be an abpsos descendant that creates an
           exclusion, but that that abspos descendant's containing block is
           still a descendant of your current context, and your current context
           has another descendant after that also establishing an exclusion
   Rossen: This second exclusion that you just discovered, its scope will be
           [...]
   Rossen: So this exclusion cannot affect any of the sibling exclusions
   dbaron: We have two abpsos containing blocks, one inside the other.
   dbaron: You have an exclusion inside the first, that affects the size of it
   Rossen: assume they're all abspos for simplicity
   dbaron: That's one of the problems, the spec assumes that but allows for
           things that aren't
   Rossen: Let's say that you have an abspos element that propagates up to
           this CB in the hierarchy
   Rossen: These are both position absolute *draws siblings*
   Rossen: And this one is also an exclusion (second one)
   Rossen: When the two are to be laid out on the level of this containing block
   Rossen: Your statement was that I also need to lay out everything inside
           the first abspos in order to figure out the stacking context
   dbaron: If you're doing this 2-pass thing, you just do 2 passes and get
           the wrong result.
   Arron: The first pass finds the static position of everything.
   dbaron: The static position will be wrong once you've done the second pass
   dbaron: It's not just static position, it's anything that creates an
           exclusion that's not absoluely positioned
   fantasai: Also if you position to the bottom, and your height depends on
             the contents.
   Rossen: Oh yeah, this is a known issue.
   dbaron: Fundamentally I think the absolute positioning model is the wrong
           thing to tie exclusions to. I'd rather connect them to the floats
           model.
   Steve: But that gives the wrong answer
   howcome: I think I support you (dbaron)
   howcome: You've introduced a bunch of wrap properties, but it doesn't affect
            floats, and I think it should do.
   Steve: That's a separate question. Let's look at this and then see how it
          affects floats.
   dbaron: One of the other problems with this, it sort of assumes you can
           apply it to things that aren't absolutely positioned.
   dbaron: But if you do, that won't work well because it only affects things
           inside the parent
   * scribe didn't quite catch that right
   Rossen: If you want to have an exclusion which is part of the flow, say
           a centered float
   Rossen: Today you have left float and right float, say you want a centered
           float.
   howcome: You add float: center;
   Rossen: That brings other problems. How do you interact with left and right
           floats?
   Rossen: Right now we have left and right areas of the float which compete
           for space with text in the center. Now you have a region in between?
   howcome: Don't you have that problem anyway?
   howcome draws.
   howcome: You have an exclusion here. Then you have a left float that
            doesn't fit. What happens?
   howcome: Do you have a clear ?
   howcome: By having a model that kindof interacts with floats and kindof
            interacts with abspos, you create all these problems in the wake
   Steve: The current definition of float moves the float down until it will fit
   Steve: The barrier just doesn't allow any text to appear there. So lines
          don't break, but flow across it, and don't render inside it
   howcome: Still seems like a viable option to me, don't see why it's not
   Steve: don't have enough control over positioning
   Steve: If you break it down, bunch of considerations about where things are
   Steve: Takes abspos items and make them behave like floats
   howcome: Why not extend floats?
   Steve: Because I don't want them to move
   Steve: Makes more sense to make abspos elements exclude
   vhardy: A positioned float is kindof an oxymoron.
   howcome: Want to explore doing it the float way
   jj: that's what we've done
   dbaron: Something Steve said I disagreed with
   <dbaron> q+ to respond to Steve's assertion that authors want it where
            they position it

   Tantek: The whole expand float vs new feature. There are a couple
           methodologies to apply to think about.
   Tantek: From author's perspective, there's a transition period. How will
           this behave during the transition period?
   Tantek: What's the fallback behavior?
   Tantek: One way to explore this problem space is to consider that.
   Tantek: Want to do this new exclusion thing, but not suck on these old
           browsers.
   Tantek: Without using css-conditional, if you had two float values you
           can have a fallback value
   Tantek: If you don't have a fallback, it will slow adoption.
   Tantek: Other question is, if new feature B is similar to old feature A.
           How complex is old feature A?
   Tantek: If it took only a few years to do old feature A, then building on
           it for B make sense.
   Tantek: But if old feature A took years and years and years to get it right,
           then it's naive ot think new feature B can be completed quickly.
   Steve: I'm wondering which of abpos and floats you think is simpler. :)

   Rossen: We don't want to mess with positioning complexity of floats today.
           Don't want to produce yet another layer of complexity
   Alex: I wanted this to CSS3 Floats module, and we should have one that
         includes new floats and page floats.
   Alex: This spec is scoped in a way that when this new floats spec appears,
         it doesn't need to say anything new about exclusions.
   Alex: This describes how objects with exclusions interact with content and
         each other.
   Alex: When we find smarter way to position floats, this should all apply.
   Alex: Should be able to implement just this, and then get smarter floats.
   Alex: Might be things here, like 2-pass algorithm, which is really about
         [...]
   vhardy: One big difference with floats is that floats assume rectangular
           shapes, so margin collapsing [..]
   fantasai: floats don't collapse margins with anything.
   Steve: Point you made earlier with overlays. These are positioned. If they
          overlap, one takes chunk out of the other.
   Steve: Simpler model, but gives you something you can't get with floats
   Bert: I wonder how that example works.
   Bert: The blue one is not in the flow of the containing block of the red
         one. The blue one has its own flow
   Rossen: Wrapping context is that of the *containing block* of the exclusion.
   Rossen: In this case they both hvae same containing block, so they're in
           the same wrapping context.
   ...
   howcome: So in this example, if the blue comes on top
   Rossen: Then the red will wrap around it
   ...
   Tantek: Is the circle a fixed size? What happens to overflow?
   Rossen: haven't talked about shapes yet.
   Rossen: All three elements here are exclusions, all in same containing
           block *shows example of three overlapping squares*
   Tantek: How adaptive is this to different amounts of content?
   Rossen: This one is done with overflow: hidden
   howcome: If you have a newspaper article, and you want to highlight the
            quote, you want to make sure the full quote appears.
   howcome: Your examples look good, but they cut off the text.
   Tantek: So the request is to use content and grow it
   Rossen: If the element is width or height auto, and you start excluding it,
           its size will change to accommodate the content.
   Rossen: If the size is fixed, then it will overflow.
   Tantek: I think the examples should show what designers will want, i.e.
           not clipping the content.
   * tantek wants to avoid more unintended cases of
            http://dev.w3.org/csswg/css3-ui/cssisawesome.png

   dbaron: I'd like to go back to the point Steve made about 11 minutes ago
   dbaron: So, when we were talking about differences btw floats and
           positioning, Steve made the assertion that authors want things
           where they've positioned it.
   dbaron: but thinking back to the examples Adobe showed when we met at
           Mozilla in the spring
   dbaron: I think in a bunch of those examples, you don't want that.
   dbaron: You will wind up in many cases where you're overlapping where you
           don't want overlap
   dbaron: For example, pull quotes in the middle of a page.
   dbaron: You're fine if the author can look at the resulting page on all
           the devices on which it will appear, and make sure there aren't
           two pull-quotes on the same page
   dbaron: But if you have different font sizes or different page sizes and
           you're doing a layout like that, you don't want two pull quotes
           that wind up on the same page to overlap each other.
   <fantasai> dbaron++
   Steve: I agree with your example. I don't think floats do a better job,
          though.
   Steve: If I wind up with two pull-quotes, I might want to only show one
          of them
   Rossen and howcome discuss how to position the pull-quote
   howcome: I want to put a pull-quote between 1st and 2nd column, 30% down
            from the top
   Rossen: How many columns?
   howcome: Depends on width of the screen
   Steve: that gets us more into grid-addressing issue
   howcome explains his use case in more detail
   howcome: You have the gr unit, yes.
   Steve: There's a separation between the positioning model and the ability
          to exclude
   Tantek and howcome discuss the issue, howcome says you can do this with gcpm
   Rossen: That solves horizontal position, but not vertical
   * tantek was wondering if/how you can set a float to have a margin-right
            of -50% of its width
   <tantek> and Håkon claims GCPM has the ability to do this.
   Rossen: If you can do something with abspos today, you can exclude it
   vhardy: We're not talking about positioning, just the exclusions part
   howcome: We have an opportunity to make floats better
   Tantek: floats are so fragile, we shouldn't touch them
   howcome: We need floats to the top/bottom of the column
   Rossen: You could have 'float' value to top/bottom/left/right
   Rossen: But that's orthogonal to what we're doing here
   howcome: This case is the most common case for pull-quotes in newspapers
   ...
   Tantek: I'm willing to accept that examples exist, but I want documentation
           that they're common
   Steve: I can provide examples in multiple scripts
   howcome: go to wikipedia and search for pull-quote
   <ChrisL> http://en.wikipedia.org/wiki/Pull_quote
   <ChrisL> http://en.wikipedia.org/wiki/File:Pull-Quote.PNG
   Alan: This spec is about, not where the pull quote is, but how things wrap
         around it
   Tantek: My experience is that pull-quotes are positioned relative to the
           page, not the columns
   dbaron: Does somebody have the Sunday NYT?
   howcome: You can do this already
   <bradk> http://blog.psprint.com/wp-content/uploads/2009/01/pull-quote.jpg
   <tantek> nice example bradk
   <stearns> the wikipedia pull quote example is incredibly ugly
   ...
   vhardy: Positioning is in a separate module. We're not trying to improve
           positioning at all.
   dbaron: I'm suspicious of the claim that we should think about positioning
           separately because the whole multi-pass layout issue is very tied
           into the positioning model we're using
   dbaron: Using a 2-pass approach will have different amounts of approximation
           error. In some models it'll be close, in others your content will
           be somewhere completely unrelated.
   Rossen: We had this note about 2-pass implementation. Almost all of the
           concerns I saw on the mailing list was about scaling this for
           interactive media
   Rossen: Based on that, Dave Hyatt and you were asking how do we make this
           not exponential ...
   Rossen: because abspos elements' positions, once they're exclusions, can
           be affected by themselves.
   Rossen: We're proposing this approximation to solve the exponential problem.
   Rossen: Can it be improved, sure. Would like to keep running times fairly
           linear and keep approximation better.
   <tantek> does "how do we make this not exponential" mean "how do we make
            this not max out the CPU and fans on our laptops" ?
   dbaron: I agree that we shouldn't have an exponential performance problem.
           But I'd rather solve that by coming up with a system that doesn't
           need it than by coming up with the wrong results.
   dbaron: ... If people want to z-index things, they'll use relpos ...
   dbaron: If you use exclusions with in-flow things, you'll still end up off.
   ...
   Alex: Better algorithm is known to exist, but isn't used due to perf.
   Alex: For exmaple if you do layout for floats, you can have O(n) or more
         than that.
   Alex: I'm still worried about it.
   vhardy: Maybe best way is to publish WD and collect issues
   vhardy: There were 3 proposals that were considered, we went over them in
           Seattle, and this is the result of consolidating
   vhardy: Our request is to publish as WD so we can have comments and iterate
           on it
   vhardy: People say its hard or complicated, put it to the test by
           implementing.
   dbaron: Basically once we decide to publish something as a WD, it keeps
           moving whether we like it or not. So to some extent, that's the
           point we decide whether this a model that we want.
   dbaron: And I'm not at all convinced that this is a model that we want.
   Steve: What exactly are you not convinced about?
   dbaron: Largely the tie-in to the abpos model
   Molly: Is that a preference for a float model, or not specific?
   Rossen: What's the alternative?
   Alex: Would you prefer this kind of exclusions to only apply a new kind
         of floats and define that to have a better behavior?
   dbaron: I would like to see some of this stuff work in terms of new types
           of floats, like what howcome's done with page floats.
   Alex: this doesn't do anything about float collisions, they overlap
   Alex: There are issues with error accumulation
   Alex: I think both are really almost out of scope of the exclusions spec.
         they define what happens with shapes
   Alex: If we define new kind of layout, still have to figure out these
         problems of overlap and positioning backwards.
   Alex: There are problems in the spec. If the things exclusions apply to,
         if they were not anything including abspos. If they only applied
         e.g. to page floats, it would still have these problems, right?
   dbaron: Not exactly, because the page float model still has places in
           document order I believe
   Alex: can you have them overlap?
   howcome: Only if you do negative margins. By nature they avoid each other
   Rossen: Would they affect each others' wrapping?
   howcome: no
   Bert: All the examples of exclusions seem to be doable with shapes
   Bert: maybe you only need shapes
   vhardy: ...
   Bert: assume this is one <p> element with 2 columns. The shape is a donut
         shape, but it's still the shape of the <p> itself. Don't need any
         other elements for it
   Bert: Advantage of that is you don't need to invent some pseudo-element
         to create that circle.
   Bert: oh, you're using an empty element. Oh that is a no-no. Don't create
         elements just to create shapes.
   several: It's just an example
   Bert: In the next example, you don't need exclusions, you just need three
         shapes
   Rossen: What you're suggesting was also suggested by glazou. He suggested
           using bg image as exclusion.
   Arno: Works for static layout only
   dbaron: I don't think this works for interactive media either.
   Bert: The circle there is not expanding.
   Rossen: It's percent sized
   Tantek: In terms of content, it's not expanding

Scribe: TabAtkins
   fantasai: So I see several concerns here.
   fantasai: One is error accumulation vs. performance
   fantasai: Another one is the actual fluidity of the layout with respect
             to different amounts of content, different font sizes, different
             page sizes, etc.
   fantasai: I see a lot fo example here that have fixed sizes, that wouldn't
             work well if you increased the font size.
   arno: That's just an example with the examples, though, right?
   fantasai: Not necessarily.  A circle would have an explicit size in real
             content.  You may need a shrink-to-fit circle.
   fantasai: To see that the spec authors aren't considering this kind of
             concerns me, because you have to make sure that dynamic
             unpredictable content is handled.
   fantasai: because that's the kind of environment CSS operates in
   Rossen: We're not doing anything to prevent shrink-to-fit. Any abspos will,
           by default, be shrink-to-fit.
   Rossen: So making it an exclusion won't change that.
   Rossen: What you may be actually concerned about is a problem with *shapes*,
           not exclusions.

   <fantasai> Note, shouldn't the term "flow container" be "block container"
              per 2.1?

CSS Shapes
----------

   Rossen: Shapes are a way to define geometry for exclusions (how stuff
           outside the element wraps around it) or the inside (how contents
           are wrapped inside of it).
   Rossen: We are proposing 2 ways to define the shape itself.
   * tantek is very happy to finally see CSS Shapes formally proposed.
   * tantek refers to circa 2001 example: http://tantek.com/CSS/Examples/shapes.html
   <tantek> developed soon after / based on: http://tantek.com/CSS/Examples/polygons.html
   Rossen: An SVG-like syntax, with functions matching the SVG geom primitives.
   Rossen: And a way to reference an image (raster or SVG) that defines the
           shape automatically.
   Rossen: The idea here is that wrapping around elements becomes quickly
           boring if done solely around rectangles.
   Chris: can it point to path in that case
   Rossen: yes
   Rossen: So for that, we're introducing 'shape-outside', which can be
           applied to exclusions.
   Rossen: Initial value is 'auto', which computes to the box of the element.
   Rossen: 'shape-inside' has the same values plus one, ''outside-shape'',
           which refers to the outer shape.
   Rossen: By default, we want content that is nicely wrapped around as a
           circle to also wrap its contents as a circle.
   Rossen: You can do that, or define an entirely new shape.
   Rossen: -inside and -outside are coupled by default, but you can give
           different values if you want.
   * fantasai supposes we'll need 'outside-shape' and 'inside-shape' keywords
              for 'background-clip', too
   jdaggett: With 'shape-inside', if you have a donut, does text flow around
             the hole?
   fantasai: The 'outside shape' represents the border box/margin box.
   fantasai: outside shape shapes the impact of the element on surrounding
             content
   fantasai: Shape-inside shapes the content box.
   fantasai: inside shape affects the containing block shape for the content
             of the element
   Rossen: [shows an example from the spec with "C" shapes and content flowing
            into the "space".
   vhardy: [explains the example in more detail]
   Rossen: The contents of an element with a donut shape fill in the entire
           area of the shape.
   jdaggett: I'd like to use this with a type shape, like having a giant A
             with text flowing around and through the holes.
   Rossen: Yes, that can be done if you extract the shape.
   jdaggett: It would be nice to have text as a built-in shape.
   Bert: Q about shape-outside.
   Bert: Some time ago we came up with the case that the shape to wrap around
         is an image.
   Bert: So it looks like you'd have to repeat the url of the image both in
         <img> and in 'shape-outside'.  We previously had a value called
         'contour' that would automatically grab the image when specified
         on an image.
   <ChrisL> If you point to a raster image, does it threshold the alpha map
            to get the image shape?
   Vincent: Yes there is a threshold
   <img id=shape-me url=foo><style>#shape-me { shape-outside: contour; }</style>
   // equal to 'shape-outside: url(foo)'
   <TabAtkins> So that would be shape-outside: attr(src as url);
   ACTION fantasai: Make attr() function do the right thing wrt resolving
                    relative URLs
   <trackbot> Created ACTION-383
   bradk: Another feature request - have a keyword to grab the background image,
          rather than repeating yourself.
   Bert: What about if there are multiple background images?
   Rossen: Daniel brought that up in the last f2f - there were a lot of
           limitations.

   dbaron: In CSS2 there was a property called 'clip', where the examples had
           commas and the formal syntax didn't.  We resolved that by allowing
           both.
   dbaron: This spec has the same problem, but the other way around.
   TabAtkins: I'd prefer to match SVG and make commas optional.

   Rossen: Our preference now is to move forward on a WD.
   Tab: I'll note the spec is silent on what to do for animated GIFs
   howcome: What if we throw out shapes and only do images?
   Rossen: We looked at a lot of examples  in print media, where wrapping
           around images was used a lot.
   Rossen: Like SI with lots of athletes with text around them.
   Rossen: But with shapes, it makes it nice to have a really simple way to
           do this.
   ChrisL: Agreed.
   Rossen: Maybe we could reduce the set of types to circle, maybe polygon?
   TabAtkins: While howcome was joking about animated gifs, I'm not. That
              needs to be defined.  Maybe first frame?
   jdaggett: What about animating shapes in Transitions?
   TabAtkins: SVG knows how to animate shapes, so we can do that.
   ChrisL: I'd like to see this pushed out for wider review at this point.
   dbaron: I'm scared that what's happened lately is that pushing something
           to TR means we're calling for implementations.
   TabAtkins: Could we address dbaron's concern by adding a scary notice?
   glazou: It's a Working Draft. It's already a *Draft*.
   glazou: Proposal is to publish FPWD provided the issues list is updated
   RESOLVED: Publish FPWD of Exclusions
Received on Monday, 28 November 2011 22:23:06 GMT

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