- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 28 Nov 2011 14:22:19 -0800
- 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 UTC