- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 19 Nov 2013 21:01:10 -0500
- 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