[CSSWG] Minutes F2F 2009-06-05 Part III: CSS3 Backgrounds and Borders

CSS3 Backgrounds and Borders
Scribe: jdaggett

   fantasai: I've split out border-image in the current draft
   other issues
   <fantasai> http://dev.w3.org/csswg/css3-background/#border-images
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Jun/0074.html
   interaction of border-image and box shadow
   fantasai explaining responses to border-image survey
   fantasai: open issues are fifth question
   fantasai: exact syntax for fallback colors
   fantasai: using border-image to mask box shadow
   <fantasai> seems to be a slight preference for masking
   <fantasai> people cite JavaScript manip
   fantasai: first question just needs a decision by us
   fantasai: clipping the border image
   fantasai showing spec
   dbaron: names for these keywords
   fantasai: fill and empty
   fantasai: fill means clipped by default, use fill to trigger
   dbaron: with 9 slices, do you draw the middle ones or not?
   <fantasai> A) Keep the middle by default. Add 'empty' to clip it.
   <fantasai> B) Clip the middle by default. Add 'fill' to use it.
   <fantasai> C) No keyword, always kept. (Make transparent as needed.)
   stevez: simplest is (c)
   dbaron: don't like the name 'empty'
   <fantasai> keyword, if added, would be added to 'border-image-slice' party
   bert: empty is good
   stevez: doughnut?
   anne: clip-middle?
   fantasai: no donuts please
   howcome: we're talking about a border, it shouldn't cover everything by
   stevez: relation to background?
   fantasai: on top of bg
   chrisl: how does this tile?
   fantasai: depends on repeat values
   <Bert> empty / doughnut / hollow...
   <Bert> or donut
   stevez: i like (b), with or without fill keyword
   fantasai: use case for filling: aqua buttons
   dbaron: i vote for (c)
   discussion of image types used for this, whether have alpha or not
   fantasai: straw poll?
   howcome: idea of border-image is to allow any image format
   several: most use cases of border image would need transparency around
            the outer edge any way
   dbaron: you're not going to chop and slice a picture of your face
   stevez: I'm in favor of anything that increases photoshop sales ;)
   chrisl: b
   arron: c
   fantasai: c
   molly: b
   alex: abstain
   howcome: b
   jdaggett: abstain
   anne: c
   bert: c
   dbaron: c
   glazman: abstain
   stevez: b
   sylvain: b
   glazman: survivor wins?
   glazman: no use of sticks...
   stevez: why c?  simpler?
   <fantasai> and if people complain, then you can add it later
   jdaggett: abstain to c
   don't have consensus here
   bert: didn't designers ask for (a)
   fantasai: hyatt wanted a way of clipping but doesn't care
   howcome: anybody who doesn't like (a)?
   howcome: can the (c) people live with (a)?
   stevez: (b) makes sense for performance, get high perf by default
   bert: why better perf?
   stevez: by default, don't need to draw
   bert: but how slow is it to blit
   howcome: i can live with (a) or (b)
   howcome: want to make a border out of a jpeg
   daniel: conversions like this happen all the time (jpeg <==> png)
   howcome: with (c) what if you have to scale the png?
   howcome: worried about half pixels
   dbaron: guess i'm ok with (b)
   fantasai: i'm ok with (b)
   anne: (b) is useless but, sure, whatever
   howcome: but this should be the default
   daniel: so?
   arron: don't like empty, fill not so much
   <dbaron> (sense that people dislike (a) because of the 'empty' keyword,
             not the concept)
   chrisl: i like what (b) does, whatever the keyword
   fantasai: I think hyatt would like (b) for perf reasons
   fantasai: but i haven't talked to hyatt in a long time
   RESOLVED: Clip middle by default, add 'fill' to use it
   bert: the keyword 'fill' has other uses?
   <dbaron> I don't like 'fit: fill'
   chrisl: fill is overloaded
   molly: need to use context
   stevez: fill-center, clip-center?
   fantasai: no, god damn it, don't need to be so explicit
   dbaron requests HTML syntax
   <break over>?
   <glazou> jdaggett: no, clear:both :-)
   <anne> <br clear=all>

   fantasai: next topic - masking issue
   fantasai: chrisl to think about this
   fantasai: last issue - syntax for fallback colors
   chrisl: and the shorthand
   fantasai: people want fallback colors
   fantasai: proposal from dbaron to require background-size to follow
   dbaron: already require that if both are present
   dbaron quotes spec
   <dbaron> http://dev.w3.org/csswg/css3-background/#the-background-shorthand-property
   <fantasai> <final-bg-layer> = <bg-image> || <bg-position> || / <bg-size> ||
              <repeat> || <attachment> || <bg-origin> || no-clip ||
   <dbaron> where / <bg-size> must occur after <bg-position> if both are
   <dbaron> I thought "after" meant "immediately after".
   <fantasai> that part was added recently, when I was trying to fix this issue
   dbaron: i think it should be immediately after
   dbaron: weird to use slash as a delimiter if don't have both sides
   and solves ambiguity problem
   dbaron: and that would require background-position if background-size is used
   fantasai: i don't like the idea of requiring one when using the other
   fantasai: don't have any other ideas...
   <pregnant pause>
   <fantasai> Someone suggested that the fallback color should go on the
              background-image property
   <fantasai> background-image: url(wavy.png) / blue;
   <Bert> (I think that is grammar #3 in
          http://lists.w3.org/Archives/Public/www-style/2009Apr/0358.html )
   dbaron: i'd rather say "has to come after"
   <fantasai> then you could say bg-size can't come immediately after url()
   <fantasai> background-image: url(wavy.png) / blue;
   <fantasai> background-image: url(wavy.png) / blue;
   <fantasai> er
   <fantasai> background: url(wavy.png) / 100%;  /* invalid */
   <fantasai> background: url(wavy.png) / blue / 100%; /* valid */
   dbaron: that's why i want to require these together
   molly: doesn't make sense?
   <fantasai> background: url(wavy.png) top / 100%; /* valid */
   <fantasai> background: url(wavy.png) /blue repeat-x / 100% /* valid */
   <fantasai> dbaron proposes
   <fantasai> background: url(wavy.png) / blue / 100%; /* invalid */
   <fantasai> background: url(wavy.png) / blue center / 100%; /* valid */
   <ChrisL> background: url(wavy.png) /* if css.gt.3 blue */
   <fantasai> background: url(wavy.png) / lightblue blue center / 100%; /* valid */
   anne: fallback color needs to be the last one
   dbaron: can't distinguish that from bottom layer being color only
   fantasai: the fallback color has to be associated with last image
   anne: can we drop this?
   fantasai explaining cgriego's example of why it's needed
   <fantasai> http://skitch.com/cgriego/bmay8/tabs-and-css-fallback-colors
   molly: yeah, this is useful
   molly: i see the issue
   anne: turn off css altogether if that's the problem
   mumbling about shift-g
   jdaggett: i officially hate this feature...
   molly: the only thing that needs to be there is the text
   molly: if the image doesn't load
   fantasai: We also had some suggestions for a generic fallback mechanism
   anne suggests that everyone has a fast enough connection
   fantasai: the dsl in tehran is really slow
   fantasai: and most people have dialup, nevermind dsl
   <fantasai> background: image(wavy.svg, wavy.png, wavy.gif, blue);
   anne: this is still feature bloat
   molly: this makes sense
   anne: this isn't needed at all
   molly: if you want the feature, this notation is better
   dbaron: can have commas in urls
   <ChrisL> image(url(), url(), blue)
   dbaron: what about other values?
   anne: this is way more complex
   fantasai: we've wanted fallbacks for urls for years
   <dbaron> like regions within the image
   <fantasai> Chris, I really would prefer to avoid the nested parentheses
   molly: should come to consesus that this is needed
   bert: not so black and white
   <dbaron> FWIW, we designed the background layers and fallback stuff at
            the October 2004 meeting.
   bert: needed or wanted?
   howcome: what's the motivating factor for this?
   stevez: defines images off behavior
   <ChrisL> ain one is to have a fallback color
   dbaron: drop this feature from background
   dbaron: add a value
   <dbaron> we have two feature requests for the image value, fallback
            and https://bugzilla.mozilla.org/show_bug.cgi?id=113577#c3
   fantasai: color is treated as having no intrinsic size
   anne: yeah, because of me
   szilles figures out network connection
   anne: my main concern is that we add so many features
   dbaron: i think we should drop the fallback color from the background syntax
   <anne> and especially that we haven't had any deployment of them, actual
          usage feedback
   dbaron: whether we go forward with the image syntax
   discussion of which spec to use
   bert recommends writing it in chinese, less space used
   RESOLUTION: fallback color dropped, explore image() syntax in another draft

   other discussions of gcpm
   howcome: changing discussion to gcpm
   large discussion of soviet union ==> russia transform
   general feeling is that this transform is definitive use case
   fantasai: i'm done
   daniel: all cooked and roasted

   dbaron: resolution on clipped?
   fantasai: dropped
   dbaron: implications of dropping background-clip: context-box
   dbaron: from the shorthand
   dbaron explains current behavior
   fantasai: background-clip: content-box is not desirable
   dbaron enumerating possible sequences of keyword sequences
   <dbaron> So I guess we're ok with being able to hit only 4 of the six
            combinations of 'background-clip' and 'background-origin'
            with the shorthand.
   multiple editors editing...
   molly: wow
   molly: wow, thank you daniel
   big clap for daniel
   thanks to bert
   bert: come back soon
   daniel: all done
   <mollydotcom> </html>
   <anne> parse error

Received on Wednesday, 17 June 2009 07:48:26 UTC