W3C home > Mailing lists > Public > www-style@w3.org > January 2009

[css3-background] Resolutions on some minor issues, impending LC publication

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 14 Jan 2009 12:22:58 -0800
Message-ID: <496E49A2.5070609@inkedblade.net>
To: www-style@w3.org

Bert and I met up this morning to resolve some issues in the spec.
   - For 'space' and 'round', calculations on size and spacing are
     with respect to the background positioning area, not the
     background painting area.
   - Defined what happens when image size resolves to zero.
   - Decided breaking across lines breaks the element such that
     if you paste it back together *in the order given by its
     'direction' property* then it looks unbroken.
   - Decided to keep 'inset' as the keyword for inner box shadows.

The changes have all been checked into the spec at

We expect to publish a Last Call within a week or two, so if you've
got any issues in your outbox, please send them in soon. :)


Full log provided for the benefit of future generations...

====== Full log below ======

* fantasai waves to Bert
<Bert> Hi fantasai. Slept well?
<fantasai> yep
<fantasai> ready to go?
* Bert reading CVS log...
<fantasai> :)
<Bert> I'm ready to go. Any particular place to start?
<fantasai> mm, maybe we scan the document first for issues
<fantasai> then look at tracker
<fantasai> 1st one is background-repeat
<fantasai> "Should background positioning area be background painting
            area here or vice versa?"
<fantasai> I think the main concern is what do we want to happen for
            the :root
<fantasai> the bgpos area for :root is the :root's box
<fantasai> the bgpaint area for :root is the canvas
<fantasai> Bert?
<Bert> I think you'll never want the paint area to be clip any of the
        tiles, so I prefer not to separate paint and pas areas.
<Bert> But the canvas is indeed special.
<Bert> It is infinite, you cannot base tile size on it....
<Bert> s/to be clip/to clip/
<Bert> (All this in the case of 'space' and 'round', it doesn't matter
        for the other kinds of tiling.)
<fantasai> right
<fantasai> you could say that the size of the canvas for the purpose
            of 'space' and 'round' size/pos calculations is the initial
            containing block
<Bert> We've in the past referred to the canvas as "stealing" the bg
        from the root. I like that metaphor. It suggests that the root
        is in fact a normal element, but then the canvas steals (repeats)
        the bg of the root for its own purposes.
<fantasai> but that's not exactly true
<fantasai> because the bgpos area of the canvas is the :root box
<fantasai> if the canvas stole the background, then it wouldn't have
            anything to do with the size of the :root box
<Bert> Not sure I understannd that last sentence.
<Bert> What is "it"?
<fantasai> the canvas's background
<Bert> The canvas bg doesn't have much to do with the root size, does
        it? It simply takes any repeating bg from the root and repeats
        it ad infinitum.
<fantasai> the canvas's bg tiles are positioned as if they belonged to
            the root only
<fantasai> the only thing that isn't as if it belonged to the root only
<fantasai> is that it tiles outside the root's border box
<fantasai> i.e. it's not clipped
<fantasai> but it's sized and positioned as for the root box only
<Bert> Not sure this helps us solve the issue...
<Bert> Canvas/root is special no matter what we do.
<fantasai> the other thing is that the background painting area is not
            necessarily a rectangle
<fantasai> whereas the bgpos area necessarily is
<Bert> I think the determining question is what we want for bgs drawn
        behind borders in case the bg is spaced/rounded:
<Bert> do you ever want a bg that is spaced to the padding box, but
        still tiles under the border?
<fantasai> no
<fantasai> but I never want a bg that is positioned wrt the padding box
<fantasai> but tiles under the border
<fantasai> it looks ugly
<Bert> If so, it seems it is simpler to say that the positioning area
        (along with the bg pos) simply has no influence on space/round.
<Bert> Although you're correct that we have non-rect areas to consider...
<fantasai> if we're going to be consistent with the way normal tiling
            backgrounds behave
<fantasai> which is they position in the top left padding corner and
            then tile through the border box
<fantasai> then round, which is almost the same use cases except more
<fantasai> should position in the top left and top right padding corners
<fantasai> and the tile through the border box
<fantasai> it is much simpler that way imo
<fantasai> hm, although then we have to say what happens to a background
            that is zero height
<fantasai> if the box is zero height and the tile continues out
<fantasai> into the border area
<fantasai> what does that mean
<Bert> Good question :-)
<fantasai> We should address that in bg-size
<fantasai> since you can get that effect with bg-size
<Bert> Isn't that already defined?
<fantasai> and I think we should say that the effect is the same as if
            the image had zero height, i.e. it's treated as bg-image: none
<fantasai> ah, yes
<Bert> sect 3.9: "A size of zero is allowed, but causes the image not to
        be displayed. (The effect is the same as if it had been a transparent
<fantasai> well in that case it's defined :)
<fantasai> but we need to shift it out, so that it applies to e.g. 100%
            resolving to 0
  * fantasai will do that
<Bert> Yes, and maybe not yet clear that it applies to round (assuming
        indeed we round to bg pos area).
<fantasai> done
<fantasai> reload
  * Bert doesn't see a change...
  * Bert ah, my fault.
<Bert> Good
<fantasai> so, back to the issue...
<Bert> We round/space to the bg pos area? (It is at least as powerful as
        the alternative and avoids having to deal with background-break
        separately for round/space.)
<fantasai> ok
  * fantasai will remove the issue text
<Bert> OK
<fantasai> next issue is for background-break
<fantasai> Then boxes on subsequent lines are ordered according to the
            {containing block's | element's} inline progression direction
            and aligned on the baseline.
<fantasai> I'm just noticing that there's a related issue in border-break
<fantasai> which is, we should pick the answer that is consistent with
            the way borders are rendered
<fantasai> so that if you have an element broken in 2 pieces
<fantasai> pasting it together makes sense
<Bert> You mean: when pasting them together, the extra borders inserted
        by border-break must be removed frst?
<fantasai> no
<fantasai> when there's no border at the break
<fantasai> but there is elsewhere
<fantasai> you get
<fantasai> [===
<fantasai> ===]
<fantasai> for ltr text
<fantasai> the answer to this shoudl be the same as what happens when you
            have an rtl span inside an ltr element
<fantasai> Mozilla renders the rtl span as
<fantasai> ===]
<fantasai> [===
  * fantasai checks Opera
<Bert> Not sure I understand. The [ is a left border?
<fantasai> run this in your favorite browser:
            <p style="width: 4em"><span style="border: solid; direction: rtl;">Some text</span></p>
<fantasai> [ is a left border, yes
<fantasai> and try removing 'direction: rtl' as well
<fantasai> to see the difference
<fantasai> Opera uses the containing block's direction
<fantasai> so it doesn't change depending on direction
<fantasai> we need to spec this...
<fantasai> oh, well, Opera doesn't use the containing block's direction either
<fantasai> it just treats everything the same
<fantasai> Bert, you getting anything on Safari?
<Bert> Not yet tried Safari.
<Bert> Not nice:
<Bert> [===]
<Bert> [===
<fantasai> o_O
<fantasai> I guess we need to check IE
<Bert> But I don't get what you got from Firefox.
<fantasai> what do you get?
<Bert> [===
<Bert> ===]
<fantasai> what build?
<fantasai> I'm using 3
<fantasai> 3.0.1
<fantasai> So I guess someone intentionally fixed it
<fantasai> makes sense
<fantasai> otherwise you'd have something that looks like
<Bert> Yes, just tried: 3 does it like you said.
<fantasai> =F=E=D=][=C=B=A=
<fantasai> instead of [=F=E=D=C=B=A]
<fantasai> if you tried to put it together
<fantasai> Should I spec FF's behavior?
<Bert> Seems reasonable
<fantasai> ok
<fantasai> RESOLVED
<fantasai> :)
<fantasai> Bert, do you think the section starting "The middle image's
            width is scaled"
<fantasai> is clear?
<fantasai> there's an issue marked there, I'm wondering if the wording
            needs tweaking or if I can just remove the issue
<Bert> I automatically read "failing that" as "zero or infinity" so I
        don't think a rewrite is really necessary.
<fantasai> ok
<fantasai> cool
<fantasai> last issue in the text is whether the 'inset' keyword for
            box-shadow should be renamed 'inner'
  * fantasai thinks 'inset' is fine, and avoids another parser token
<Bert> Will bg style and bg shadow  ever be used together in a shorthand?
<fantasai> I sincerely doubt it
<fantasai> bg-shadow is complicated enough on its own
<fantasai> er
<fantasai> box shadow
<Bert> Yes, my mistake.
<Bert> I think inset is fine. But I don't know if there is already a
        traditional name for the effect among designers.
<fantasai> ok
<fantasai> I'll remove the issue for now then
<Bert> If there is no strong reason to change it, I prefer keeping inset.
        Avoids having to remember an extra keyword.
<fantasai> yeah
Received on Wednesday, 14 January 2009 20:23:39 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:21 UTC