- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 12 Feb 2012 02:19:35 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Exclusions
----------
- Discussion of deriving shapes from images and other rendered content.
- Concluded to use first frame of animated images.
- Discussion of layout dependencies between exclusions and other
layout models, and problems of mutual constraint resolution
====== Full minutes below ======
CSS Exclusions
--------------
Scribe: TabAtkins
<smfr> http://dev.w3.org/csswg/css3-exclusions/
Rossen: We've made a few changes since the last f2f
Rossen: We've had several issues raised during TPAC that we recorded
in bugzilla.
Rossen: We tried to address as many as we could.
Rossen: We wanted to go over the remaining issues.
Rossen: Simple one first.
https://www.w3.org/Bugs/Public/showbug.cgi?id=15088
Rossen: previously we were using fixed-height examples, so it was hard
to see the effect of auto height stuff.
Rossen: Next, we took the updated syntax from Tab from Monday.
Rossen: Related to that was the bug https://www.w3.org/Bugs/Public/showbug.cgi?id=15091
Rossen: This was asking if we need to simplify the syntax for shapes.
Rossen: Questions were raised related to this - do we need them at all?
Rossen: And if we did, do we need all of them, and which ones?
Rossen: We discussed this quite a bit, and we still feel pretty strongly
that we need to give users that are hand-authoring the ability
to create something simple and straightforward.
Rossen: rectangle, circle, and ellipse definitely fit in that.
Rossen: Polygon, once you move past a few points, is a little hard, but
still doable.
Rossen: So our answer is that we want to keep the declarative syntax.
Rossen: And the set of primitives we're suggesting is sufficient.
howcome: Shapes can be useful. We don't have a history of them in CSS.
howcome: The problem of using shapes, in one of the examples, is that
you write a shape that follows the outline of a font.
howcome: But if that font isn't available, your shape will not match
what the user sees.
howcome: So by separating the shape and the data, this is a problem.
Bert: minor editorial point: 4.1.1 says "SVG shapes," but the SVG shapes
are actually in section 4.1.2. Section 4.1.1 is about CSS shapes.
ChrisL: What were the other issues with shapes in CSS?
ChrisL: I recall they just didn't have very tight definitions. They
weren't ever given a chance.
vhardy: It seems that both are useful. Looks like defining the shape
from text hasn't been addressed yet.
vhardy: I think that shapes are still useful.
plinss: I think what's being asked for then is "use the visible content
of this element".
astearns: There's one example where a shape is meant to correspond to
rendered content, but there are other examples where the shape
*doesn't* correspond to rendered content. There you want shapes.
ChrisL: And in some cases you have a raster image with an alpha, but you
don't actually want to use that alpha channel; you want a
simplified outline around it.
TabAtkins: So it sounds like shapes are great, but you also want a
currently-missing ability to wrap around some rendered content.
Rossen: Agreed.
TabAtkins: When I've manually done exclusions by splitting an image into
bands and floating it, I generally do things that would be
fine with shapes.
[some unminuted discussion about the applicability of using alpha channel
with a margin]
howcome: I recognize the value of the shapes, but I don't know if they're
useful for level 1.
howcome: I think we should start with the simple stuff first, and that's images.
[several]: No, shapes are much simpler.
vhardy: From a tooling perspective, people often draw shapes with those
tools, rather than extracting from a raster image or something.
* Bert expects to do this most of the time:
img {float: left; shape-outside: attr(src, url); shape-threshold: 0}
vhardy: One example in the spec has a car against a mountain background,
with the text flowing around the car, and that's fairly difficult
to threshold from the image. It's a large image, too, so sending
down a second image for the alpha mask would be costly.
plinss: Håkon's point is valid that we shouldn't have people forced to
use shapes for things like wrapping around letters. As long as
there are options to handle those properly too, it should work,
and we can have shapes too.
* Bert would still like to do it as proposed in 1996 or so: 'img {float: left contour}'...
ACTION vincent to add issue about handling visible content as a shape for Exclusions.
<trackbot> Created ACTION-440
Rossen: Next topic is a bug about animated images.
Rossen: Our proposal was something we all got an agreement with at TPAC,
where everyone felt either first or last frame.
Rossen: Looking at default GIF behaviors, first frame is always the
"default" when it's treated as a still image - in print, when
animations are disabled, etc.
Rossen: So using first frame seems the most sensible.
plinss: And we can always add a property if we decide it's not crazy later.
plinss: Can a GIF cycle just once?
vhardy: yes.
plinss: In that case, it stops on the last frame, right?
plinss: It might make sense to use the last frame for that.
vhardy: SVG animations similarly can run once, and it's somewhat hard to
wrap for the last shape there, since it can have script.
Rossen: So I think first frame is still the safest option there.
smfr: For SVG, "first frame" is the image without any animations?
vhardy: Yes.
ACTION vhardy to add a note to Exclusions that animated images use the first
frame (in SVG, render the image without animations).
<trackbot> Created ACTION-441
ChrisL: We want to write it in such a way, though, that later specs *can*,
say, respond to animated SVG.
vhardy: it seems we can add a property in the future to control that sensibly.
TabAtkins: Agreed - this seems future-friendly.
Rossen: Next issue is from Bert, about "contour"
Bert: It's about an idea a long time ago, that when you use an image both
for rendering and masking, to make it easy to specify that without
writing the url twice.
vhardy: It seems that this is similar to the previous idea of wrapping
based on the visible content of some element.
astearns: It seems we're proposing you can get a shape out of an alpha
channel, or out of rendered content. So if we're trying to
avoid duplicated urls, we'd need multiple keywords.
ACTION vhardy to investigate using the content of an <img> for wrapping
without duplicating the url, in light of earlier discussion about
shaping from rendered content.
<trackbot> Created ACTION-442
<Bert> 'img {float: left contour}' instead of
'img {float: left; shape-outside: attr(src, url)}'
<Bert> ... except that it is independent of which attribute the URL comes from.
howcome: Another issue - this spec says it can be used with any positioning
scheme.
howcome: So how do we get interop if some impls use exlusions with some
positioning schemes, while others do it with others.
astearns: The intention of that sentence is that it works with *all* of them.
dbaron: This is very interrelated to positioning schemes, since its
exclusions order model works in the reverse of the way most
positioning schemes place content.
howcome: But it's rather complex. What will you test? What if you set
an exclusion on a table cell?
szilles: If you write the conformance criteria, you'll wind up answering
the technical questions based on what you write there.
TabAtkins: So we should have a decent explanation for how each positioning
scheme interacts with exclusions (and possibly regions too).
howcome: For example, floats are exclusions already.
alexmog: It needs to explicitly say what happens with abspos, and with float.
alexmog: But other specs should mention how they work with exclusions.
howcome: [draws an example on the board with a float, and asks what
happens if it becomes an exclusion]
Rossen: Right now, the spec says that floats can't be exclusions.
howcome: Good answer.
Rossen: Also, as an impl experiment, I did floats using exclusions and
it worked. Less performant, but it worked.
astearns: We do specifically mention how floats work with this.
szilles: So if we have a section called "Positioning Schemes" that lists
the schemes and any additional constraints that are introduced,
it should satisfy Håkon.
Rossen: That sounds pretty good. It would address testability.
howcome: If they don't work with floats, what if I have a float and want
it to have a shape?
alexmog: I think that anything in 2.1 that interacts with Exclusions
should go in the Exclusions spec. New positioning schemes
should talk about Exclusions in their own spec.
smfr: It concerns me if a spec like exclusions has to reference a bunch
of other specs about layout models.
smfr: I would much prefer it if exclusions could reference CSS fundamentals
like the box model, rather than referencing specific positioning
schemes.
smfr: maybe we don't have the right fundamentals defined yet, but it seems
dangerous to do anything else, or else we'll have combinatorial
explosions.
vhardy: I think that was the original intent. We had a two-pass algorithm
that let it be defined simply by finding the position of each
element, then the effect of each element.
Bert: It's probably not doable in practice. If you refer to the box model,
it needs an intrinsic width.
<Bert> (My colleague Dom once extracted a tree of dependencies from our
modules. Maybe we should make a cron job that makes that tree every
week or so, so we can check that it is indeed still a tree...)
howcome: I think with floats, how can you position them in the first pass?
You need to lay out the content first.
szilles: I think we're getting sidetracked
howcome: Possibly not. If the processing model in Exclusions excludes
certain positioning schemes (particularly floats), then we have
a problem. Then it's no longer agnostic.
szilles: To simon's point, embedding references to particular other specs
can produce a rats nest of cross-references. But there's an
equal problem of *not* specifying what schemes were assumed at
the time the specs were written.
smfr: Is it an issue with constraints, or is it an ordering problem as well?
Do exclusions first, then layout, or something like thta?
vhardy: I don't think we'll resolve this today. Can we take an action to
work out the processing model further, and demonstrate how it works
with the existing positioning schemes.
szilles: The results of those experiments will tell you what to put in
the spec.
ACTION vhardy to investigate the processing model of Exclusions further,
and report results/figure out what to put in the spec for
various layout modes.
<trackbot> Created ACTION-443
howcome: New issue! We should really use background images as a source
for exclusion shapes.
howcome: We have a lot of tools for background images right now, and
should just reuse those.
glazou: I agree. I don't know if it's compatible with your current model,
but it's a novel way of doing things that's consistent with some
graphical editors.
Rossen: When we did all the model analysis and comparisons, your proposal
was one of those.
Rossen: At the time we discussed it and we agreed that it wasn't desirable.
Rossen: but actually, it would fit with what we have now.
Rossen: Only difference is, when we use background images, the exclusion
will be part of the wrapping context of the element itself, but
wouldn't make the element itself an exclusion.
Rossen: Which glazou disagreed with in Seattle.
glazou: yes, and I commented on it. It's different, but both are useful.
ACTION vhardy to add background-image support to the Exclusions spec
<trackbot> Created ACTION-444
smfr: There may also be utility for using border-image support for the
shape outside the box.
smfr: I was thinking of something like a rounded rectangle with some
flourishes, or a picture-frame shape, with bumps on the corners
but straight sides, and using that as an exclusion.
Rossen: Sounds like you're signing up for it.
astearns: We should probably put all of these ideas in the spec and
then trim afterwards.
vhardy: We'll at least put a note in about border-image, yes.
howcome: Another issue. Our current float approach can implement
roughly half of the examples in the spec.
howcome: It may be worth pointing that out - "if you want to use exclusions
today, use floats with X method. This spec allows for more powerful
stuff as well."
* dbaron notes the minute taker can't hear the discussion
howcome: Possible also just remove the simple stuff entirely from Exclusions,
since floats do it already.
howcome: We're defining the same functionality with two different properties.
Rossen: Exclusions can penetrate through BFCs, unlike floats.
Rossen: If you manage to position an exclusion over a table cell, it will
penetrate through and affect it.
Rossen: The scope of the exclusion wrapping context is the containing block
for the exclusion algorithm.
TabAtkins: I have no idea how this will work with Flexbox.
alexmog: Layout will happen without reference to exclusions.
TabAtkins: So flexbox layout will happen normally, and then if an exclusion
changes how the text lays out, it'll just overflow? That's fine.
dbaron: I don't think it's fine. It's *defined*, but I don't think it's
what people want.
TabAtkins: I think what people *want* is "iterate layout until stable".
dbaron: That's why I'm not very happy with this whole thing.
howcome: [draws a diagram showing an exclusion covering parts of four
separate cells]
Rossen: It would make the cell taller because the text flows...
TabAtkins: But that contradicts what Alex just said. He said the layout
wouldn't be affected. If it *is* affected, I'm back to not
knowing how Flexbox will work.
alexmog: We need to explain this more carefully.
Rossen: [shows a live example of an exclusion crossing an element.
[discussion of rossen's example]
[summary: layout *is* affected by exclusions. The meaning of this with
other layout models is confusing and unknown]
<dbaron> we didn't get to the bit about how the way layout is affected
is one-pass and therefore only works "correctly" when there's
only one exclusion
<dbaron> (in other words, the spec is broken)
howcome: A common use-case is to position a pullquote centered on a
column rule. If it's abspos, then if you change the window
size, it will no longer be centered.
howcome: This is example *number 1*.
plinss: This seems out-of-scope. This is a generic problem of positioning
schemes that can be handled outside of exclusions.
howcome: You're willing to put that positioning scheme as the required
line for exclusions? If not, example number 1 can't be done.
alexmog: If we look at together GCPM and exclusions, and there are holes
or inconsistencies, we need to raise those as issues.
howcome: So are we willing to solve this use-case?
vhardy: I think we already took actions on trying to solve these problems.
szilles: Håkon, you were the author of GCPM floats. You have the obligation
to take into account how that works with exclusions.
howcome: That might be more multicol, but yeah.
szilles: You can't say *we* have to progress float positioning. That's
your spec.
[argument about where positioning schemes]
plinss: We agree that we'll address this use-case, and I put it in Håkon
and the exclusions guys to work out where this goes, offline.
Bert: A different issue, about the dark text on dark background.
Bert: A recent exampe I had was two images. There was text that partly
overlaps an image. At the point where it overlaps the image, the
text changed color to maintain contrast.
alexmog: Can we come up with a sufficiently general requirement that,
normally, new layout specs shouldn't need to add a ton of text
to deal with Exclusions?
TabAtkins: That would be nice, yes.
<br type=lunch>
<fantasai> ~~ Why do people keep randomly CCing me on mails to www-style?
I thought it was obvious that I'm subscribed already.
<fantasai> </gripe>
Received on Sunday, 12 February 2012 01:20:04 UTC