Options:
- # Session Start: Thu Mar 25 00:00:00 2010
- # Session Ident: #css
- # [00:01] * Quits: arronei (arronei@131.107.0.74) (Ping timeout)
- # [00:07] * Joins: arronei (arronei@131.107.0.81)
- # [00:11] <TabAtkins> What rows of a propdef are required, and which can be omitted, if I'm just adding a new value to an existing property?
- # [01:02] <fantasai> I'm not sure. I guess don't repeat the ones that don't change?
- # [01:03] <TabAtkins> k.
- # [01:04] <fantasai> but yes, pop it into Images :)
- # [01:04] <fantasai> If we get implementations soon enough, we can shift it to css3-background, otherwise it can just stay there
- # [01:05] <TabAtkins> Next question: Is it okay to create a new section in Images defining the concept of coordinate spaces (like SVG), and defining how the background-* properties mutate this space?
- # [01:05] <fantasai> uh
- # [01:05] <TabAtkins> Heh.
- # [01:05] <fantasai> It probably is, but why?
- # [01:06] <fantasai> I don't think we should be mutating coordinates
- # [01:06] <fantasai> especially not in SVG
- # [01:06] <TabAtkins> The reason for this is to create a well-defined backdrop for me to define 'extend' on, in such a way that it can be easily and unambiguously used by other concepts down the line.
- # [01:06] <fantasai> use the idea of viewports
- # [01:06] <fantasai> not coordinate spaces
- # [01:06] <TabAtkins> The viewport coordinate space.
- # [01:06] <fantasai> you don't need to talk about coordinate
- # [01:06] <fantasai> just about sizes
- # [01:06] <TabAtkins> IE: The thing that gets compressed when you do background-size:50%.
- # [01:07] <fantasai> The thing that changes size is the viewport
- # [01:07] <fantasai> the image itself determines how to respond to the change in viewport
- # [01:07] <TabAtkins> Hixie is telling me that vieewport isn't the right term.
- # [01:07] <fantasai> Extend means don't clip to the viewport
- # [01:07] <fantasai> Because he's an HTML editor, not an SVG editor
- # [01:07] <TabAtkins> ?
- # [01:07] <Hixie> viewport in HTML means the same as in CSS
- # [01:07] <Hixie> er
- # [01:07] <Hixie> in s/HTML/SVG/
- # [01:08] <fantasai> background-size changes the size of the image's viewport
- # [01:08] <fantasai> not the CSS document's viewport
- # [01:08] <Hixie> no, it changes the size of the image's viewport coordinate system (equivalently, the size of the initial containing block)
- # [01:09] <Hixie> however background-clip is what sets the viewport
- # [01:09] <Hixie> (because it makes no sense to talk about overflowing the viewport)
- # [01:09] <fantasai> background-clip does not set the viewport, it clips the background after it's been positioned and tiled
- # [01:09] <Hixie> (unless we introduce another term "viewport" with a new definition)
- # [01:09] <fantasai> I'm talking about the viewport from the image's perspective
- # [01:10] <fantasai> CSS gives the image a box
- # [01:10] <Hixie> it's true that when background-repeat is not 'none' or 'extend' you would want the viewport to be the same as the viewport coordinate system
- # [01:10] <fantasai> and says "Here, draw yourself into that"
- # [01:10] <fantasai> that's the box we're talkinga bout
- # [01:10] <Hixie> and when it's 'none' too, for that matter
- # [01:10] <Hixie> i'm talking about the 'extend' case
- # [01:10] <fantasai> it's the same in the extend case
- # [01:10] <fantasai> except we say "draw yourself into this box, but don't clip to the box"
- # [01:11] <Hixie> well if you don't clip to the box it can't possibly be the viewport :-)
- # [01:11] <Hixie> since the viewport by definition is what you clip to
- # [01:11] <fantasai> yeah, that's a little weird :)
- # [01:11] * TabAtkins is glad to sit back and let others hash this out.
- # [01:11] <fantasai> but I don't think most images have a concept of the size of their containing box that's separate from the concept of their clipping bo
- # [01:12] <fantasai> x
- # [01:12] <fantasai> it's only when we introduced CSS gradients that this started to become a compelling idea
- # [01:13] <Hixie> tab raises the interesting point that when you have a bitmap, the viewport is really the size of the bitmap, not bte background-size
- # [01:13] <TabAtkins> Well, no, they do. The image's containing box contains what is repeated during a background-repeat, which is different from the clipping box of the background.
- # [01:13] <fantasai> background-clip is a mask on top of all this
- # [01:13] <Hixie> i'm confused
- # [01:14] <Hixie> about whether background-size stretches bitmaps
- # [01:14] <fantasai> the image doesn't need to know about that at all
- # [01:14] <Hixie> which changes this
- # [01:14] <fantasai> it does
- # [01:14] <fantasai> because bitmaps behave as image-fit: fill
- # [01:14] <fantasai> or preserveAspectRatio=don't
- # [01:14] <fantasai> or whatever
- # [01:15] <Hixie> right, the default -size is auto
- # [01:15] <fantasai> right
- # [01:15] <Hixie> so yeah, by default the viewport for the image is the background-size actual value
- # [01:15] <fantasai> which means we ask the image for its intrinsic size
- # [01:15] <fantasai> and then hand a box exactly that size back
- # [01:15] <Hixie> position by background-position
- # [01:16] <Hixie> it's then painted multiple times per -repeat
- # [01:16] <fantasai> and then clipped per background-clip
- # [01:16] <fantasai> yes
- # [01:16] <Hixie> with repeat:Extend, though, you want the viewport to match teh -clip region instead, while leaving the viewport coordinate system / ICB unchanged
- # [01:16] <TabAtkins> Hixie's problem is that, apparently, every definition of 'viewport' is 'the box you clip to'.
- # [01:16] <TabAtkins> And so he's disturbed that 'extend' means 'overflow the viewport'.
- # [01:16] <fantasai> ah
- # [01:16] <fantasai> we might want to define a new term then
- # [01:16] <Hixie> yeah i think it would be very confusing to overflow the viewport
- # [01:16] <Hixie> a new term would be fine
- # [01:17] <fantasai> but define it in terms of the viewport
- # [01:17] <fantasai> because that's the only existing concept that's related to this
- # [01:17] <TabAtkins> I've sent a mail to public-fx asking for collab from SVG people on naming this.
- # [01:17] <Hixie> well there are several concepts that are applicable here
- # [01:17] <Hixie> in svg, e.g., the viewport coordinate system
- # [01:17] <Hixie> in CSS, the ICB
- # [01:18] <fantasai> yeah, but we need a definition that's format agnostic, even if we provide format-specific examples...
- # [01:19] <Hixie> i'd just use both terms each time :-)
- # [01:19] <Hixie> for our purposes they mean the same
- # [01:19] <TabAtkins> That's why I was thinking of going in terms of coordinate spaces, as the box we're looking for is the one defined with edges at 0% and 100% in the x and y.
- # [01:20] <fantasai> where is x=100% defined?
- # [01:20] <TabAtkins> Wherever the coordinate space is defined.
- # [01:20] <TabAtkins> The space must carry a notion of percentage lengths.
- # [01:20] <fantasai> and if it doesn't?
- # [01:20] <TabAtkins> Then it's nonsensical wrt CSS?
- # [01:20] <fantasai> also, what if its concept of percentage coords isn't useful to you?
- # [01:21] <TabAtkins> If it doesn't carry a % notion, then it's an infinite canvas.
- # [01:21] <TabAtkins> Or at least an unbounded one.
- # [01:21] <TabAtkins> All finite canvases have a natural % notion.
- # [01:21] <fantasai> defined by what?
- # [01:21] <fantasai> if it's defined by the intrinsic size of the image
- # [01:22] <fantasai> then that's what you want
- # [01:22] <TabAtkins> Yes, by the intrinsic size.
- # [01:22] <fantasai> but don't rely on the image format's own spec to say that
- # [01:22] <TabAtkins> Yeah, I wouldn't.
- # [01:22] <TabAtkins> I'd say "if an image has an intrinsic size, 0% is the left edge and top edge, and 100% is right and bottom edge".
- # [01:23] <fantasai> what if it doesn't have an intrinsic size, only an intrinsic ratio?
- # [01:23] <TabAtkins> Then I jump to the rules we use currently to deal with images with only an intrinsic ratio.
- # [01:24] <TabAtkins> Which produces a used size.
- # [01:24] <fantasai> you're not looking for a size, you're looking for a clip boundary
- # [01:24] <TabAtkins> Yah, you're right.
- # [01:24] <fantasai> and you want to make it no longer clip
- # [01:24] <fantasai> the size and the coordinates are irrelevant
- # [01:24] <TabAtkins> "clip box"?
- # [01:24] <fantasai> it's the boundary you care about
- # [01:25] <fantasai> ok
- # [01:25] <fantasai> start with that :)
- # [01:25] <fantasai> if someone comes up with a better term, we can change: I think it's adequate for now
- # [01:26] <fantasai> make sure you associate that with the image, though, not with CSS-level masking
- # [01:26] <fantasai> (like background-clip)
- # [01:26] <TabAtkins> Now, how to talk about SVG being handed a clip box with an infinite viewport?
- # [01:27] <fantasai> hm, yeah, that gets confusing because we're not clipping to the box now
- # [01:27] <fantasai> bounding box maybe?
- # [01:27] <fantasai> anyway, first thing you do is define the bounding box of the image
- # [01:27] <TabAtkins> That might be a useful term.
- # [01:27] <TabAtkins> Yeah.
- # [01:28] <fantasai> Explain that it's usually the clip box, or viewport, or in the case of formats without an infinite canvas, the size of the finite image
- # [01:28] <fantasai> Give an example of a bitmap
- # [01:28] <fantasai> an SVG
- # [01:28] <fantasai> and a gradient
- # [01:28] <fantasai> Once you have a nice definition,
- # [01:28] <fantasai> then you can blow away the clipping that happens at the bounding box's boundary
- # [01:28] <fantasai> make sense?
- # [01:28] <TabAtkins> "If the image has an intrinsic height and width, the bounding box is the size of the image. If it has just an intrinsic height, just an intrinsic width, or just an intrinsic ratio, {defer to existing text about sizing such images in a CSS box}."
- # [01:29] <TabAtkins> And have gradients define their bounding box.
- # [01:32] <TabAtkins> Eh, I'll still need to talk to an SVG spec expert to coordinate with how to phrase things so as to sensically talk about them overflowing their viewport.
- # [01:32] <TabAtkins> I dunno if SVG needs to change, or if we can just specify something, or what.
- # [01:32] <TabAtkins> Do we do the clipping to the viewport ourselves, or does SVG just hand us an already-clipped image?
- # [01:35] * TabAtkins heads home for now. Will try to rouse Sheppers later.
- # [01:38] * Quits: TabAtkins (chatzilla@216.239.45.19) (Ping timeout)
- # [01:42] * Quits: Lachy (Lachlan@124.171.250.216) (Ping timeout)
- # [01:48] * Joins: Lachy (Lachlan@124.171.250.216)
- # [01:48] * fantasai supposes she didn't wind up making any sense to Tab after all
- # [01:57] * Joins: dydz (dydz@75.37.27.246)
- # [02:08] * Joins: Curt` (DorkeyDear@75.10.137.89)
- # [02:09] <jdaggett_away> fantasai: so in css grammar terms
- # [02:09] * jdaggett_away is now known as jdaggett
- # [02:09] <jdaggett> a || b || c
- # [02:09] <jdaggett> means any combination of a, b, c
- # [02:10] <jdaggett> so 'a b' or 'a' of 'c b a' are all valid
- # [02:10] <jdaggett> but 'c a c' is not
- # [02:10] <jdaggett> right?
- # [02:16] <fantasai> right
- # [02:17] <jdaggett> so you were thinking of using the || to define font-variant
- # [02:17] <jdaggett> font-variant: <numeric-values> || <caps-values> || ...
- # [02:17] <jdaggett> but...
- # [02:17] <jdaggett> that would mean that
- # [02:18] <jdaggett> font-variant: oldstyle-nums additional-ligatures slashed-zero
- # [02:18] <jdaggett> would be ever-so-subtlely invalid
- # [02:19] <jdaggett> because oldstyle-nums and slashed-zero were both part of the <numeric-values> production
- # [02:19] <jdaggett> ah, i love grammar issues...
- # [02:20] <jdaggett> oops, s/subtlely/subtly/
- # [02:36] <jdaggett> fantasai: ^
- # [02:39] <jdaggett> basically the double-bar operator is not associative (a || b) || c is not the same as a || (b || c)
- # [02:41] <jdaggett> a b c would be valid in one but not the other
- # [02:48] <jdaggett> argh, make that c a b
- # [02:52] * Quits: sylvaing (sylvaing@76.104.131.10) (Ping timeout)
- # [04:09] * Quits: Curt` (DorkeyDear@75.10.137.89) (Quit: Leaving)
- # [05:36] * RRSAgent excuses himself; his presence no longer seems to be needed
- # [05:36] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
- # [05:42] * Quits: fantasai (fantasai@66.55.71.177) (Connection reset by peer)
- # [05:47] * Joins: fantasai (fantasai@66.55.71.177)
- # [06:24] * Quits: fantasai (fantasai@66.55.71.177) (Ping timeout)
- # [06:25] * Joins: fantasai (fantasai@66.55.71.177)
- # [06:46] * Disconnected
- # [06:48] * Attempting to rejoin channel #css
- # [06:48] * Rejoined channel #css
- # [06:48] * Topic is 'CSS WG -- logs: http://krijnhoetmer.nl/irc-logs/css -- blog: http://www.w3.org/blog/CSS'
- # [06:48] * Set by anne on Thu Mar 11 21:03:19
- # [07:06] * Joins: zelda (476d5fc1@64.62.228.82)
- # [07:06] * Parts: zelda (476d5fc1@64.62.228.82)
- # [08:02] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
- # [09:28] * Quits: Lachy (Lachlan@124.171.250.216) (Quit: This computer has gone to sleep)
- # [10:30] * Joins: Lachy (Lachlan@124.171.250.216)
- # [10:43] * Quits: Lachy (Lachlan@124.171.250.216) (Quit: This computer has gone to sleep)
- # [10:53] * Quits: anne (annevk@83.85.115.123) (Connection reset by peer)
- # [10:53] * Joins: anne (annevk@83.85.115.123)
- # [10:57] * Joins: lstorset (lstorset@213.236.208.22)
- # [11:18] * Parts: lstorset (lstorset@213.236.208.22)
- # [11:18] * Joins: jdaggett (jdaggett@110.4.186.83)
- # [11:59] * Joins: Lachy (Lachlan@124.171.250.216)
- # [12:14] * Quits: jdaggett (jdaggett@110.4.186.83) (Quit: jdaggett)
- # [13:00] * Quits: Lachy (Lachlan@124.171.250.216) (Quit: This computer has gone to sleep)
- # [13:04] * Joins: Lachy (Lachlan@124.171.250.216)
- # [13:19] * Joins: dbaron (dbaron@69.140.1.234)
- # [13:36] * Joins: szilles (chatzilla@128.31.35.147)
- # [16:22] * Joins: TabAtkins (chatzilla@216.239.45.19)
- # [16:58] * Joins: dsinger (dsinger@67.218.103.133)
- # [17:32] * Quits: dsinger (dsinger@67.218.103.133) (Quit: dsinger)
- # [17:38] * Joins: dsinger (dsinger@17.244.75.154)
- # [17:38] * Quits: dsinger (dsinger@17.244.75.154) (Client exited)
- # [17:38] * Joins: dsinger (dsinger@17.197.20.4)
- # [18:01] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
- # [18:19] * Joins: sylvaing (sylvaing@131.107.0.78)
- # [18:57] * Quits: sylvaing (sylvaing@131.107.0.78) (Connection reset by peer)
- # [19:00] * Joins: plinss_ (plinss@192.6.114.30)
- # [20:09] * Joins: shepazu (schepers@128.30.52.169)
- # [20:09] * Quits: szilles (chatzilla@128.31.35.147) (Ping timeout)
- # [20:40] * Joins: jdaggett (jdaggett@110.4.186.83)
- # [21:40] * Joins: Curt` (DorkeyDear@75.10.137.89)
- # [23:20] * Quits: jdaggett (jdaggett@110.4.186.83) (Quit: jdaggett)
- # Session Close: Fri Mar 26 00:00:00 2010
The end :)