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

[CSSWG] Minutes TPAC F2F 2013-11-10 Sun II: Shapes Syntax

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 19 Nov 2013 21:01:10 -0500
Message-ID: <CADhPm3tCqUbFvNXAUXM6dz7cq_dg5Rpk-sQK_EPfpRw0eDcU5g@mail.gmail.com>
To: www-style@w3.org
Shapes Syntax
-------------

  - RESOLVED: Keep inset() and polygon() as they are in the editor's
              draft. Change circle() and ellipse() to use radial
              gradient syntax and postpone rectangle() until we can
              define it in a way that satisfies everyone.
  - RESOLVED: shape-outside/inside accepts <box> || <shape> where
              * <box> alone indicates the contour of that box
              * <box> and <shape> together indicate that <shape> sized
                and positioned relative to the specified <box>
              * <shape> alone defaults the relative box appropriately
  - RESOLVED: Keep box, not edge, in the shape keywords

=====FULL MINUTES BELOW======

Shapes Syntax
-------------
  ScribeNick: fantasai

  <astearns> http://lists.w3.org/Archives/Public/www-style/2013Oct/0695.html
  astearns: Issue is shapes draft has set of shapes functions that are
            derived from how shapes are defined in SVG
  astearns: They have arguments of position and extent.
  astearns: fantasai pointed out that we have similar arguments in CSS,
            e.g. in gradients.
  astearns: In such syntax extent is before positioning, and all
            arguments are optional.
  astearns: The main difference between SVG shapes and CSS shapes is
            that percentages in the position are handled differently.
  astearns: My proposal is to keep the shapes syntax in the draft now,
            and in L2 create CSS shape function;
  astearns: That would use radial-gradient syntax.

  astearns: fantasai points out that this will result in an SVG circle
            and ellipse function and a CSS circle and ellipse function
            that pretty much do exactly the same thing,
  astearns: And she's objecting to that duplication.
  astearns: We're at a standstill: we understand each others positions,
            but disagree on conclusions.
  <astearns> rectangle (x y w h)
  <astearns> shape (rectangle w h <new-position>)

  <dbaron> was it this email:
http://lists.w3.org/Archives/Public/www-style/2013Oct/0734.html ?
  <dbaron> or this email:
http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html ?
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Oct/0520.html
           was the email fantasai meant

  chrisl: We changed a lot of syntax in CSS gradients
  chrisl: SVG has been around a lot longer
  ChrisL: Better to have that,
  ChrisL: Because it's consistent with expectations.

  sylvaing: Shape functions also used in clip-path in SVG,
  sylvaing: So consistency with SVG might make sense.
  sylvaing: But working with HTML+CSS ...

  Rossen: The initial motivation for adding shapes was so that we could
          have syntax as close to SVG as possible.
  Rossen: Even an ask of why even have CSS inline function, instead of
          referencing SVG.
  Rossen: Plan is ti to have this in L2, actually.
  Rossen: But having basic shapes close to SVG is the right way to go.
  shepazu: Canvas differed from SVG in subtle ways, and people didn't
           like that.

  fantasai: We already have conventions in CSS; you're proposing that
            instead of being consistent with the rest of CSS we be
            consistent with SVG.
  fantasai: We've had shapes in CSS in gradients, and positioning syntax
            in CSS since CSS1.
  fantasai: My point in that email was that we have this desire for
            consistency, you can argue for consistency in either in
            either direction.

  astearns: I'd propose adding the CSS-consistent forms in level 2; I
            want both.
  fantasai: I'd object to the duplication.
  fantasai: But for level 1 you'd have the inconsistency with CSS.
  astearns: But we have circles and ellipses in gradients, but we don't
            have rectangles.
  astearns: We'd still need to define the extrapolation from
            background-position syntax to rectangles.

  fantasai: My point in this email is that we're arguing over
            consistency, and you can argue in various directions.
  [interrupted by ChrisL]
  chrisL: SVG has been around longer,
  chrisl: So we should be consistent with it.
  dbaron: I think there are still a lot more people hand-writing CSS
          than hand-writing SVG.

  ScribeNick: dbaron

  fantasai: There are lots of ways to argue about consistency. Why don't
            we discuss use-cases instead?
  astearns: Percentage handling is different, so I want to have both
            syntaxes so that we can have both ways of handling
            percentages.
  fantasai: I think this syntax is not an obvious way to express that
            the only functional difference is how % are handled.
  krit: That's not the only difference.

  fantasai: But you wanted examples, lets put up examples.
  fantasai: We should look at what people actually want to do with these
            functions.
  fantasai: [goes to whiteboard]
  fantasai: We're trying to do positioning, that's what the main
            difference.
  fantasai: So where do people want to position things?

  fantasai: Common things are: align to the center or one of corners, or
            one of edges.
  ChrisL: [inaudible]
  ChrisL: I disagree those are the most likely.
  astearns: You also might want to position top-left corner at a
            particular % width and height.
  fantasai: Isn't bottom-right equally likely?
  astearns: No, top left is positioned most often.

  Bert: Can we take one more step back about use cases -- talking about
        rectangles only?
  fantasai: We have circle, ellipse, rectangle. Gradients and SVG are
            both consistent that circles are positioned by center and
            radius.
  Bert: So I can understand why you'd want a circle or some other shape.
        What are the cases for a rectangle shape when you already have a
        rectangle?
  krit: You can have rounded corners.
  fantasai: Shouldn't there be an easier way?
  plinss: Follow rounded corners of border?

  astearns: You might have something that gets displayed with gradient
            and the gradient has some portion on the content side that
            ok to display content over. So you'd reduce flow ??? using a
            rectangle.
  astearns: If wrapping around drop cap with upright ascender at
            trailing edge, you might want a rectangle that approximates
            glyph.

  Doug: Can I ask a followup?
  Doug: Let's grant that these are the most likely positions -- then
        what's your conclusion based on that?
  fantasai: Common things should be simple and easy, and other things
            should be possible.
  fantasai: Common cases should be really easy.

  Doug: Where does it differ from SVG?
  ChrisL: SVG positions by top left. This does percentage matching like
          background position so you can easily get to all 4 corners.
  Doug: So the percentages is the difference?
  fantasai: For these things you can just use a keyword. In SVG you need
            a calc() to get to the bottom right, calc(100% - w)
  fantasai: This is duplication.
  fantasai: rectangle(n, m, calc(100% - n), calc(100% ' m)
  fantasai: That's great for people who like coordinate systems, but not
            great for a lot of designerns.

  Doug: As somebody who's written SVG, inability to position something
        at bottom or right has hampered.
  fantasai: The alternative is rectangle(n, m at bottom right)

  Doug: The only difference is what % means?
  fantasai: That's where they're incompatible.
  fantasai: Could put positioning syntax in SVG style function too, but
            that would mean % interpreted differently in rectangle() and
            background-position.
  fantasai: We have x,y,w,h,o so function in draft right now would look
            like rectangle(calc(100%-n), calc(100%-m), n, m).
  fantasai: Instead of having 2 lengths we could have it be a position
            that takes 2 or 4 values.
  fantasai: So it would be rectangle(bottom right n m)

  astearns: We'd have to switch it around so that ...
  krit: fantasai, don't have to.
  fantasai: We could restrict it so ...
  astearns: Then you're introducing an inconsistency with
            background-positioning

  krit: How would rounded corners fit in?
  fantasai: Just as now in draft.
  doug: So you suggest putting CSS syntax of finto another draft?
  doug: I see some risks there in terms of -- if only thing implementors
        are doing is parsing and interpreting syntax as opposed to
        implementing the new feature -- doesn't seem a stretch to put
        both new syntaxes in the first draft.
  doug: It's a matter of when somebody learns something and when it's in
        the browser
  doug: I think having both in 1st draft would be not big implementor
        burden and help developers.
  astearns: I've been trying to reduce level 1 draft to improve chance
        of additional implementations.
  doug: I think the extra syntax isn't a big deal.

  krit: fantasai, you wanted to limit position to what again?
  fantasai: ... ... can't do 3 arguments, 2 or 4 would be possible
  fantasai: But then the number of arguments inconsistent with
            background-position in addition to percentage difference.
  astearns: I think ability to drop things and have defaults is nice ...
            is a valuable thing to maintain.

  plinss: Matching shape to background gradient -- I don't want to see a
          designer to specify gradient in one format and have to do a
          lot of math to figure out matching shape.
  plinss: It should be almost copy-paste.
  astearns: I think it is because we allow shapes from image, and image
            value can be gradient, so can use gradient in both and
            extract shape from gradient.

  plinss: Does it get you ability to override part?
  astears: You can choose opacity threshold.

  doug: Anyway to leverage variables for this?
  sylvain: Depending on the variables maybe it's not great for quick
           implementation.

  fantasai: You said use case of matching border even if curved -- I
            think that should be a keyword and should be in level 1.
  astearns: I think the value in that case should be some
            self-referential element function.
  doug: Also use clipping?
  astearns: no (?)

  fantasai: Bert had a proposal for floats(?) to use contour keyword
  fantasai: Wouldn't it make sense to add that keyword right here?
  astearns: Perhaps, but we discussed in Tokyo that following contours
            of arbitrary something can be security risk because you can
            determine contours of thing being displayed.
  astearns: My reasoning for using element() is that element() has the
            same security implications so the solution for addressing
            those implications gets reused.

  krit: element() can't reference itself.
  astearns: It can't reference itself or things that will affect layout
            of element, but can use data you get out for defining a
            shape-outside.
  astearns: There are other uses of self-referential element function
            such as mirror images that have been discussed.

  fantasai: Even if we have self-referential elements, for the use cases
            of just wanting wrapping to follow border, it should be dead
            simple and available immediately.
  fantasai: One of most common things along with following image
            threshold.
  fantasai: I don't think it should be hard to duplicate arguments
            when already given to border-radius.
  astearns: I agree that common cases we should solve, but it's a
            question of what we can get done now vs what we need to work
            on without solving the security issue.

  astearns: I think images are more common use case than rendered
            content wrapping.
  fantasai: let's just solve that right now, and make
            shape-outside:contour then the shape of border-radius gets
            projected out to margins and followed for wrapping/

  doug: I didn't see inherent conflict between SVG and CSS syntax.
  doug: I think we should have both.

  krit: rectangle() can easily have one or other but not both?
  astearns: No, the proposal is for it to have both.
  fantasai: proposal is:
  <fantasai> shape(circle <size> at <position>)
  <fantasai> shape(rectangle <size> at <position>)
  <fantasai> circle(x y <size>)
  <fantasai> rectangle(x y <size>)
  fantasai: Alan's proposal is to have all of these.
  fantasai: The author would have to know that #2 and #4 have slightly
            different behavior,
  fantasai: #1 and #3 are just different syntax.

  Rossen: ... we wanted to have shape keyword reserved so you can
          express outside shape and inside shape.
  astearns: Never used shape shorthand, just wanted ...
  Rossen: We had a version with shape shorthand that captured both
          outside and inside,
  Rossen: Then you'd have nested functions: shape: <outside-shape>
          <inside-shape>
  astearns: You'd end up with shape: <function> <function> where one is
            outside and one is inside.
  Rossen: ...
  astearns: That doesn't follow shorthand conventions.
  fantasai: Shorthand should just be shape: <shape>{1,2}
  fantasai: The order controls outside vs. inside.

  plinss: I think that's a red herring; this is the issue on the table.
  fantasai: What bothers me: (1) inconsistency and duplication (2)
            switching shapes from circle to ellipse to rectangle is
            totally different.
  fantasai: (3) there's only one functional difference between the 2
            which is percentages, which is not clear from difference in
            syntax,
  fantasai: So as an author you have to know there's a weird difference
            between them.

  doug: Nothing about CSS is intuitive.
  fantasai: But we have to try to have conventions.
  fantasai: This difference is not evident at all

  krit: Back to interpretation: with rectangle having width/heigh of 50%
        and position 50%, would it now be centered?
  fantasai: yes
  krit: ... would ... ? (something about about covering the bottom right
        quadrant of an element)
  fantasai: inset(50% 50% 0 0), or use calc()

  krit and fantasai argue about what's intuitive

  plinss: Is the SVG percentage behavior something that's useful?
  plinss: Does the SVG behavior make sense for someone writing CSS?

  astearns: fantasai- for putting the top left corner of the rectangle
            in the center of the box you said just use calc(), which was
            your objection?
  fantasai: My objection was having to use calc() to put something in a
            corner to align something against the bottom or right edge,
            which is a common case. Putting the top left corner at 50%
            50% is not a common case. Also, even in the SVG system, if
            you want to put any corner other than the top left corner at
            50%, 50% you have to use calc() Why are we so fixated on the
            top left corner?
  astearns: People had differing opinions.
  astearns: Some people like each, so I want to have both.

  astearns: I don't think people are going to be confused about which
            they need to use for this purpose or that.
  astearns: They'll have a preference for x,y,w,h or CSS positioning
            syntax depending on which they grew up with.
  astearns: People won't be making a hard decision about ...

  Bert: In order to have preference they have to understand both
  krit: For radial gradient and circle, define center point.
  krit: So my problem is you can't really compare to radial gradient
        this way.
  krit: So I'd even be with you to use position.

  Lea: I think most authors won't have hand-coded SVG... they'll just
       wonder why we have 2 functions for the same thing, slightly
       differently.
  Rossen: With a tiny difference in behavior.
  Lea: The only people who want this are those who have hand-coded SVG,
       but I think these people are rare (though I have).

  plinss: You said this would be used in SVG also?
  krit: Shape... is the future, currently it's only clip-path in SVG
        that uses basic shapes.
  krit: What about a 'middle' or 'center' keyword -- and keywords go to
        corner, but percentages function in the SVG way?
  asteans: There's good reasons for percentages to work CSS way,
           especially around animations.
  asteans: I like both; I can't come up with one single syntax that does
           everything.
  plinss: Have a keyword in the function to pick percentage behavior and
          then pick one to default on?

  doug: The 2 positions I hear are (a) have both (b) only have one
        because people would be confused by two.
  fantasai: I think a lot would be confused.
  doug: Can we have one be default but still allow other?
  doug: Can we have no way to have CSS as default and SVG syntax be an
        option?
  dbaron: If we're doing something like that, then I prefer Peter's idea
          of having a specific obvious toggle rather than having two
          totally different syntaxes that have a slight difference of
          interpretation.
  doug: ...
  Simon: Should toggle be available for shape, or also
         background-position?
  <dbaron>: (I'm not convinced we should have the toggle, though.)
  ...

  fantasai: We don't have to pick "svg-like" as the keyword.
  fantasai: One thing I came up with on list was say which corner you
            want to position: <corner> at <position>, e.g., top left at
            50% 50%.
  astearns: What would the default CSS value of corner thing be?
  fantasai: If it's omitted, then the magic thing.

  krit: I'd like to get an agreement on the syntax during TPAC... we
        have 2 specs in/near LC.
  ChrisL: With gradient syntax, it would have been better to agree on
          *any* of the proposals a year earlier.

  krit: We should remove rectangle() and inset-rect() for now.
  fantasai: I don't think we need to remove inset-rect().
  krit: I don't think rectangle is that important at this point... You
        can easily do it with polygon() or inset-rect()

  plinss: We need to wrap up or come back after lunch.

  fantasai: Krit's proposal: Level One: circle, ellipse, inset polygon
            Level Two: rectangle.

  fantasai: I'd also suggest having a way to get the border-box shape.
  astearns: That's a separate issue.
  fantasai: We haven't decided internal syntax yet -- deciding what goes
            in these functions is a separate issue.
  fantasai: "copy border shape" is also separate issue.

  astearns: So moving rectangle() to level two to avoid incompatibility
            with percentage?
  krit: And that gives more time to argue.
  RESOLVED: rectangle() moves to level 2 of shapes

[Lunch Break]
  ScribeNick: Liam

  <astearns> Summary - keep inset() and polygon() as they are in the
            editor's draft
  <astearns> Change circle() and ellipse() to use radial gradient syntax
  <astearns> and postpone rectangle() until we can define it in a way
            that satisfies everyone.

  RESOLVED: Keep inset() and polygon() as they are in the editor's
            draft. Change circle() and ellipse() to use radial gradient
            syntax and postpone rectangle() until we can define it in a
            way that satisfies everyone.

  fantasai: Next issue, following contour of the border.
  asteans: I mean the contour of the rendered element.

  rossen: Couple of things here...
  rossen: Which box you use for the shape, e.g. the margin box works for
          float but maybe not for exclusions.
  rossen: So the auto shape is where we can have the border/margin/
          content box and snap to that shape.
  rossen: (for wrapping around).
  astearns: That's not the border box, e.g. because the border can have
            rounded corners
  atearns: So rendered contents, rendered border, not same as box.

  Simon: Would this be the border edge?
  astearns: Yes, but there's a different edge for inside/outside

  dirk: Is it necessary for level one?
  astearns: no :)
  dirk: Are we fine with pushing this to level 2?

  fantasai: I understand there are security issues, but for the simple
            case of saying just use rounded corner...
  astearns: It's not so simple as you can turn parts of the border off.
  astearns: E.g. if you turn off parts of the border to make a triangle,
            do you wrap around the triangle or around the partly-visible
            border?
  astearns: What's the user expectation?
  fantasai: If you put in background color, you get the whole box, so
            that's the expectation.
  alan: I agree that's defined and that people who understand CSS
        backgrounds would have that expectation.

  rossen: Instead of saying border box vs border edge, say border edge
          and specify as border, edge or padding.
  krit: Implementation-wise it's not that easy.

  fantasai: If it's considered as one of the most common cases it should
            be in level 1.
  rossen: Also, for exclusions the default area is the border box, and
          this is not what we have in shapes, there we take margin.
  astearns: For floats it makes sense to use margin box.

  rossen: I want to have shapes working with level 1 of exclusions,
  rossen: And the one place where there is quiet a bit of inconsistency
          is the auto behaviour of the shape, specifying it to be the
          margin box.

  [further discussion of margin vs border box in different cases]

  <zcorpan_> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2631
             is basically the case we're discussing, right?

  leaverou: A box shadow also affects the border even if the border
            isn't shown.
  fantasai: You're saying that should we account for the visibility of
            the border, and I'd say no.
  liam: If you want a triangular element you can use a polygon instead
        of turning off part of the border.

  astearns: This is an argument to defer following contour e.g.
            shape-outside: normal|countour|
  fantasai: It'd be good for us to say  that in level 1, just use the
            edge as defined in backgrounds & borders.

  Lea: I can see use cases for what Alan was saying, but what Elika is
       saying will work in most cases.
  fantasai: Because people expect that to "just work" it should be dead
            simple,
  fantasai: So we should have a straight-forward way to do that.

  fantasai: [draws on the flip-board a list:]
            * use margin box (square corners)
            * follow margin edge contour
            * follow border edge contour
            * follow content edge contour
            * use border rectangle
            * use content rectangle
  fantasai: We can also add the various box names, contour||<box>....

  zcorpan: One thing people use border radius triangles for is to make
           speech bubbles.
  astearns: That's where you have polygons.

  rossen: Things like that should be automatic should be intuitive and
          easy to understand ...
  rossen: If you want to have fancy shapes you can make them with an
          image or polygon.

  astearns: So the proposal is for level one to add one keyword that
            means follow the edge of the border.
  astearns: Having the shape defined at the border edge would be a
            better solution.
  astearns: Setting margin and border shape separately is useful for
            floats.
  fantasai: The fallback margin is going to be in many cases
            dramatically different from the actual border. That concerns
            me a bit.

  rossen: If you talk about shape margin being different from margin
          box, shape is additional to that.
  rossen: And for the fallback case where you use the margin box of the
          box model of the float, it'll almost always be different
          because you don't have a shape.
  astearns: In default shape is auto, you wrap around the margin box so
            fallback is same.
  astearns: But if you use border keyword you can set a separate
            shape-outside shape.
  fantasai: What if the values for shape-outside, default was to use the
            border box?
  fantasai: So, shape:margin: auto, would use the border box.
  astearns: We want that for the float case, but not the exclusion case.
  fantasai: The intent of margins is to provide visual space, we're
            using it here for positioning.

  [discussion between Alan and Rossen]

  astearns: I want to keep shape-margin zero by default.
  bert: The idea here was a single property would be enough.
  alan: You only need 2nd property if you want to wrap around the
        rounded box or shape.
  [clarification: -ve margins used for positioning when stacking
    multiple floats]

  rossen: If we leave margin as default, for the auto, and allow the
          border keyword, then the default will just work, as it's
          margin box, same as floats today.
  rossen: Allowing border box will give users what we speculate to be
          the most useful case.
  astearns: That's your analysis.

  bert: By default I want to wrap around the shapes margin box,
  bert: Not directly the border.
  Liam: The case where you want a separate margin shape and border shape
        is really for complex shapes with concave regions, which is not
        the case with a box with rounded corners.
  astearns: shape-margin is one value, you were talking abut having
            shape-margin: auto, to take the shape's margin.

  [question about backgrounds & borders spec answered]

  astearns: This is more complex than what we have in shapes.
  rossen: If you're supporting polygons you already do this.
  astearns: Since we only support one shape I would not want this more
        complex behaviour that you can't define for polygons.
  astearns: I would prefer to allow the border keyword, keep shape
            margin as it is.
  astearns: You could get a single offset from the border edge.

  fantasai: There are cases where you want more space in horizontal than
            vertical direction for floats.
  [bert draws a picture comparing border-shape and margin-top
  [picture was for question of clarification, answered]

  fantasai: A related issue, what does 100% mean?
  fantasai: I think we use box sizing for this,
  fantasai: But box sizing should just be about height and width.
  fantasai: I don't think 100% should be tied to box sizing.
  astearns: We tie 100% to the height or width, that's why we use box
            sizing.
  fantasai: But percentages aren't referencing height and width, 100%
            for the shape isn't the same as 100% for the width. They
            don't need to correspond.
  fantasai: Box sizing by default is the content box.
  fantasai: If I'm defining shapes for the border I'd want 100% to refer
            to the border box at least.
  fantasai: Shape-margin should always be referencing the same box

  dbaron: Box sizing using one property to control the meaning of
          another is bad enough already!
  astearns: I pressed to have percentages based on different boxes.
  dbaron: I think box-sizing would have better been an additional
          keyword on the value of 'width' and 'height', e.g., 'width:
          100% border-box'

  bert: When do you need 100%?
  fantasai: E.g. a triangle goes from top to bottom of the triangle, if
            you know the height, so it goes to 100% of the height.
  fantasai: I can imagine a property like background-origin to do the
            switching between the different boxes.

  astearns: Can we go back to the border keyword?
  fantasai: It's related because if we're going to have a way to switch
            for sizing...
  astearns: We're talking about a keyword instead of the shape
            functions.

  krit: Is it inside or outside?
  rossen: When we get to shape-inside, level 2, we'll probably add more
          keywords.
  bert, fantasai, rossen, krit: Want the content edge for inside.

  krit: Why not always use margin and let user specify shape-padding?
  fantasai: We don't want to duplicate lengths.
  astearns: It should be outer edge of border and then you add whatever
            margin.
  fantasai: shape-margin takes one value and margin takes 4 values.

  bert: On shape inside, you want to have the text follow the shape
        corner,
  rossen: Shape padding.
  bert: But the size of the box changes, e.g. a float with a rounded
        corner, the text inside the float.
  asteans: That's an issue with any of the shapes with text inside.
  asteans: Autoshaping is a hard problem but necessary.

  bert: I don't think it's useful to have text outside follow the shape
        of the border if you can't do it on the inside.
  bert: I think outside and inside belong together, same level.
  rossen: Yes.
  astearns: I agree we should get to them, but don't think they both
            have to be at the same level.
  fantasai: We have algorithms for wrapping round outside but not
            inside, so I think it makes sense to split into two levels.
  fantasai: You can reference an image, that gets you a lot of what you
             want to do.
  fantasai: E.g. oval shaped profile pictures in your Facebook

  astearns: I need to take a look about sizing based on the border box.
  fantasai: I'm still trying to see how to have the default for margins.
  rossen: The default can still be margin-box.

  astearns: The issue is, when the border is curved, the outside margin
             edge is also curved.
  astearns: And because you can give 4 different margins for the
            element,
  astearns: The outside margin edge cannot be achieved with a single
            shape margin value.
  astearns: So a suggestion is to have this auto shape-margin value to
            get to that shaped margin edge.
  astearns: But then how does that work with polygons?
  astearns: I'd rather not deal with that case.
  astearns: I want to add border keyword to shape-outside and leave
            shape-margin as it's currently defined.

  <fantasai> http://www.w3.org/TR/css3-background/#the-background-clip
  <fantasai> border-box
  fantasai [writes values for shape-outside:]
            auto | <box> || <shape>
            or, circle(100%)

  Bert's case: shape-outside margin-box
               shape-outside: border-box
               shape-outside: circle(100%) /* border-box */
               shape-outside: margin-box circle(100%)

  plinss: shape-margin would always be an addition to whatever this
          produces.
  alan: Except at the moment shapes are clipped to the margin box.

  bert: What does auto mean?
  fantasai: The square margin box, ignoring radius, the box model,
  fantasai: But for exclusions auto will be border box.
  astearns: Is border-box the border edge?
  fantasai: Yes, cf. clipping.
  <SimonSapin> +1 for fantasai's proposal.

  astearns: Should we fix the mistake and use border-edge instead of
            border-box?
  simon: The inside of the border is padding-edge.

  RESOLVED: shape-outside/inside accepts <box> || <shape> where
           * <box> alone indicates the contour of that box
           * <box> and <shape> together indicate that <shape> sized and
               positioned relative to the specified <box>
           * <shape> alone defaults the relative box appropriately

  plinss: Let's leave the edge vs box as name as an issue up to the
          editor's discretion.
  fantasai: We should resolve that now.
  krit: We need to resolve it before going to last call.
  bert: Since we have box in backgrounds and borders we should keep the
        same term.

  RESOLVED: Keep box, not edge, in the shape keywords

  plinss: Are we done with shapes?
  krit: When do we ask for last call?
  astearns, fantasai: After edits.
Received on Wednesday, 20 November 2013 02:01:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 November 2013 02:01:39 UTC