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

[CSSWG] Minutes and Resolutions 2009-10-07

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 07 Oct 2009 13:58:42 -0700
Message-ID: <4ACD0102.60909@inkedblade.net>
To: www-style@w3.org
Summary:

   - RESOLVED: 'round' keyword for 'background-repeat' and 'border-image-repeat'
               scales to the nearest whole number of tiles. Will mark as an issue
               for feedback in case people prefer different behavior or would like
               additional control (e.g. 'round-down' or 'round-up' keywords)

   - RESOLVED: Add percentages to 'border-radius'. They refer to a percentage of
               the corresponding dimension of the box (so border-radius: 50% gives
               you an oval).

   - RESOLVED: Publish css3-background as Last Call Working Draft.

   - fantasai was asked to present on CSS at TPAC's developer meeting, and welcomes
     any suggestions for topics to cover

   - Last Call period has ended for css3-multicol, howcome will be compiling comments

   - Briefly discussed text-overflow: shrink

====== Full minutes below ======

Present:
   César Acebal
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Hĺkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/10/07-CSS-irc
Scribe: TabAtkins

CSS3 Backgrounds and Borders: round() vs. ceil() for 'round' keyword
--------------------------------------------------------------------

   fantasai: I want to discuss CSS3 backgrounds early in the agenda.
   Peter: Elika, I presume you want to discuss border images?
   fantasai: No, that issue is solved in CSS3 Images. The only issue I know of
             is whether to scale up or down for the "round" keyword.
   fantasai: Rather, the action of 'round' keyword.
   Chris: The issue is round up or down, right?  and it's only relevant at
          .5 of an image?
   <ChrisL> always round to the nearest, in my opinion
   fantasai: no, argument is whether we should round up/down, or always down.
             Round up/down is preserves the shape better, but always down may
             be better in raster images.
   fantasai: I'm convinced by Brad's argument that rounding up/down is okay.
   Chris: Choice between round and truncate.
   * dbaron notes ChrisL means numeric truncation rather than image truncation
   <fantasai> ceil() vs. round() in the formula
   Chris: If you get, say, 3.95 images to fit, rounding down means dropping
          to 3 images, right?
   fantasai: No, up to 4 images -- so that you *scale* down.
   * dbaron thinks it's floor() vs. round()
   Chris: What we want isn't floor or ceiling, but windowsill!  Halfway up!
   ?: So, when discussing 3.95 images, should we go to 3 or 4?
   <ChrisL> 4
   ?: We definitely want to be scaling to closest number.
   fantasai: With always rounding down, we get more *shape* distortion, while a
             high-enough resolution makes the stretching-up not bad.
   fantasai: You'll usually only be stretching up just a little bit.  And when
             the author still isn't happy with the effect, they can give a
             higher-resolution image and sizing it down in CSS.
   fantasai: Also, we'll later be able to specify how many image px go into
             a CSS px.
   Peter: The problem is that that's assuming the author knows the width, but
           what if they don't?
   fantasai: You'll often know approximately, but if you don't, just provide a
             higher-resolution image, especially if you think you'll have few
             tiles.  More tiles means less percentage scaling.
   fantasai: The author at least should have a good idea of whther it's 3-4
             tiles or 30-40 tiles.
   fantasai: And if they're really fussy, they can just provide a
             higher-resolution image every time.
   Peter: My concern is, the decision to scale up/down or always in one
          direction, kinda depends on the content of the image.  Why not give
          the author control of this - augment 'round' with 'floor' and 'ceil'?
   fantasai: I think that's too much.  I can't see any real justification for
             wanting to floor or ceil that can't be solved with vector images
             or higher-resolution.
   Chris: If the author doesn't need to decide, then we don't need to discuss
          this. We can just decide.
   <Bert> In my experience, scaling images down never looks bad, while scaling
          up often does. More so with JPEG, but even with PNG.
   Chris: But this really isn't an implementation cost. Two more keywords is just
          like 4 lines of code.
   <dsinger> but scaling down loses detail, whereas scaling up does not
   fantasai: I don't think people are asking for multiple options here.
   <dsinger> sure, scaled down looks better as nothing is invented;  but
             something is lost
   <dsinger> oh, we're talking non-proportional scaling?
   fantasai: In border-image, the height is fixed.  If you scale the image it
             changes dimensions - circle will become ovallike.  Using round()
             will produce less distortion.
   Chris: I don't think anybody is saying round() shouldn't be the default.
          We're saying that floor/ceil might be useful as an option when you
          need it.
   szilles: I think we can always add ceil and floor later.
   fantasai: And you can always provide an image with twice the resolution.
             It will always scale down.
   szilles: There may be times you don't want to go with higher resolution.
           But my point is we can add ceil and floor keywords later, so we
           don't have to decide yet.
   fantasai: Agreed.  We can add it later if there is demand for it.
   Sylvain: If the image is vector, not raster, does it get resampled?
   Chris: Well, with vector images the size will be telling you how large to
          draw it straight off.  You're not ever resampling.
   <Bert> Future extension (but not really what I hope for...):
         'background-repeat: repeat | space | round | ... | round-up | round-down'
   <glazou> CSS WG delirium tremens

   straw poll!  Who can't live with round()?
   * dbaron prefers hexagonal :-)
   <TabAtkins> I'm okay with it.
   <glazou> I should have bet !!!!!
   Bert: I don't like it.  I was doing some experiments, and scaling down always
         looked okay, while scaling up often looked bad.
   <ChrisL> interpolation with nearest-neighbor will usually look like crap
   Bert: Depends on the image, but you'll lose detail when getting small anyway.
   <ChrisL> also attempting to scale in an indexed color space. Promote to
            24bit first
   Bert: If you have a 1px line somewhere, it will become gray.  this is better
         than scaling up, where things that were gray will become blocks.
   Sylvain: But does detail matter that much?
   Bert: For backgrounds, no, but for borders it does.
   szilles: It seems unusual to round in this situation.
   fantasai: If you have just a few tiles, you can use background-size with
             border-image to effectively increase the resolution.  So when
             scaling 'up', you'll still be scaling down from the original.
   * sylvaing finds the background property set to be complex enough as it is
   * ChrisL would like to continue with the straw poll
   Peter: My objection is that you rejected round-up and round-down for
         complexity, but your workaround is a lot more complex than a keyword.
   Peter: Bert, I heard that you're not opposed to round, but concerned that
          it won't give enough control?
   <fantasai> He's concerned about quality, not about control.
   Bert: I know that scaling down is always okay, but am concerned that scaling
         up won't always look good.  I'm surprised that designers on the list
         are okay with this.
   ?: Pete, do you have an actual objection, or just a concern?
   Peter: Just a concern.  I don't think adding the keywords adds much
          complexity, and I think arguments about "this will look good" will
          depend on intent, which we can't predict.  Why not give control to
          the author?
   BradK: I'm not against this.
   Chris: I could live with rounding.  I also like the extra keywords, since
          they're not much of an implementor burden, but can live without
          them, since we can add them later.
   fantasai: I had text that required rounding for vector images and high-res
             images, but required scaling down for low-res images (where you
             would have to interpolate)
   fantasai: we could go back to that

   Bert: I think we should add text for the dividing by zero case.
   fantasai: Yeah, that's easy to fix.
   * ChrisL "implementations SHOULD avoid dividing by zero, but MAY do so
             within a try ... catch"

   fantasai: Bert, you're concerned about the quality of the images being
             scaled up.
   fantasai: We could go back to the text from a few revisions ago where you
             round with vector images or images that are high-enough resolution.
   fantasai: But only have scaling-down-always if you would have to interpolate
             pixels.
   BradK: But that seems a little worse than the extra keyword.  I *have* to
          provide a higher-resolution image to keep it from always rounding down.
   BradK: I'd prefer keywords to doing that auto-detection.
   Bert: fantasai, you were saying you wanted a distincction between raster and
         vector image?
   fantasai: No, distinction between when you have to interpolate pixels.
             Low-res raster vs (high-res raster + vector).
   Bert: So you can scale up as long as you don't exceed the original resolution?
   Chris: You can scale up as long as you don't scale up?
   Bert: No, two-step process.  First scale by background-size, then apply
         rounding.
   ChrisL: That's okay as long as it's clear you don't scale the image multiple
           times.  Need to make that clear to prevent implementors from thinking
           multiple-scaling is required.
   plinss_: Consensus?
   BradK: I prefer less distortion.
   Tab: I prefer the keyword approach.
   * bradk prefers less distortion, doesn't mind an extra keyword
   szilles: I prefer seeing more experience with how it's used rather than
            using a fairly complex algorithm that won't be obvious.
   ?: You have to think about what to do with browsers that don't recognize
      those new keywords.
   szilles: They round.
   fantasai: That won't be a problem.  There's not any deployed unprefixed
             versions yet.
   szilles: They'd end up ignoring what they didn't understand, which means
            they'd go with the default.
   fantasai: Which is 'stretch'.
   Peter: That's probably not the author's intent.
   fantasai: They can list it twice, without the new keyword and then with;
             that will work.
   Peter: I'm hearing two different dissenting opinions.
   <dsinger> I'm only asking questions, not dissenting
   szillees: I say pick the simple solution now, see how people use it, and
             extend it later if necessary.
   fantasai: I want no extra keywords unless people say "I'm unhappy with
             this pixelation."
   fantasai: We're not publishing CR here, we can have comments.  People
             can give feedback.
   Peter: That works for me.  We can let people comment and see what comes out.
   ChrisL: So go with round for now?
   fantasai: Yes.
   Peter: Not hearing any objections?
   Bert: Works for me.
   <fantasai> ACTION: fantasai mark this as an issue
   fantasai: Can we publish last call, or are there more comments?
   many: general agreement
   <sylvaing> LC! LC! LC!
   fantasai: Objections?
   voice of the people: no
   * glazou imagines sylvaing  in a monty python film, with a beard, shouting
       spam! spam! spam! :-)
   BradK: Is there a use for border-image-size?
   BradK: You can't do the background-size with border-image, so I don't think
          that's a good idea.
   fantasai: So you want to take an image and treat it as 2 device px equals
             1 CSS px. We can do that in css3-images.

CSS3 Backgrounds and Borders: Percentage border-radius
------------------------------------------------------

   BradK: I can't do percentages in border-radius, but I can simulate this
          with border-image.
   fantasai: I was thinking about dropping percentags from border-image.
   BradK: I think you should do so, or else add it to border-image.
   howcome: Do we have % on border-radius now?
   fantasai: no.
   howcome: we should add it.
   <plinss_> s/?/howcome/
   fantasai: Did we figure out what it means?
   howcome: I have one suggestion.  I can send an email, though.
   fantasai: That's the confusing thing.  We have impl that support % on
             border-radius, but they do different things.
   fantasai: Some scale border-radius separately, some do them together.
   howcome: I agree, but I think it's so useful that the spec should have it.
   ?: Is it mainly useful for ovals?
   <glazou> sorry guys I have to leave the call, bye
   howcome: Yes.
   <ChrisL> so 50% 50% gives you ovals
   ChrisL: In other words, 50% 50% gives you ovals.
   Tab: I like howcome's approach.
   Peter (to howcome): I don't think that's what you want.
   howcome: No, that's exactly what I want.
   fantasai: If there's consensus we can put it in.
   * sylvaing predicts those ovals will look perfectly square in IE6
   BradK: I think it should be the same in border-radius and border-image,
          so people don't get confused about how it works.
   Peter: I'm not sure if % scaling on the side it's from will give people
          what they want.
   fantasai: It's hard to switch between them.
   fantasai: One of the most common effects for wanting percentages is to make
             one side circular and longer sides flat.
   fantasai: For this you can rely on making a huge radius and allowing it
             to scale down proportionately.
   Bert: Yeah, it scales down, but equally.  If the box is taller than wide,
         it'll leave you straight sides.
   ?: It scales with the aspect ratio.
   dbaron: It only works if you know the aspect ratio of the box.
   ChrisL: Two use-cases.  One is a button, one is an oval.
   * dsinger lissajous figures
   <Bert> lozenge
   howcome: But you can hack buttons without %-per-side, but you can't do
            ovals with %-is-width.
   Bert: You can create lozenges by specifying "25in" for border-radius or
         someething, that will never be that big, so it will scale down.
   ?: But when you scale it down you're not going to get a straight line.
   howcome: are you talking about diamond shaped?
   bradk: for the lozenge shape, it would scale down until the two corners
          met and you'd have a lozenge shape.
   howcome: So it's a button you want?  A button you can specify today,
            currently.  You shouldn't have to rely on scaling down.
   howcome: Just set the border-radius and do whatever you want.
   ChrisL: You have to know the height.
   howcome: Okay, if you don't know the height, you set it to big and it
            rounds down.
   fantasai: typically you have only one line of text in which case you can
             use ems.  Not perfect, but a good approximation.
   plinss_: There are other options, like a %height or %width unit.
   fantasai: Yeah, but it's not important enough to add right now.
   howcome: I agree.  Of course, I want the percentage to be of whatever
            I want.  ^_^
   BradK: So %-per-side allows ovals, but you can get lozenges if you want.
   <Bert> Does 'border-radius: 50%' give you a quarter circle, or does it
          mean '50% / 50&'?
   howcome: yes.
   fantasai: So publish this as LC?
   Peter: I think people will want a corner that is round but not 50%.
   TabAtkins: Usually that's okay with a fixed size.
   Peter: I'm okay with leaving it for public feedback.
   plinss: People will use different sizes for corners with different types
           of boxes.  We can wait for public feedback.
   plinss: Objections, or are we good for last call?
   <sylvaing> LC! LC! LC!
   everyone: *silence*
   <ChrisL> Go CSS!
   Peter: Okay, go to last call.
   * ChrisL channels "We CAN" speech
   RESOLUTION: Add %ages to border-radius, scaled indep to each side
   fantasai: so add % to border-radius, scaling per side.
   bradk: And use the same language in border-image.
   fantasai: yeah.
   RESOLUTION: Publish css3-background as LC
   plinss: five minutes left.  anything that can be handled?

TPAC Developer Meeting
----------------------

   fantasai: Ian Jacobs asked me to give a talk at TPAC on developers day.
             If anyone would like to co-present, or has suggestions to talk
             about, let me know.
   ChrisL: Maybe a talk about some fairly new stuff, but that's implemented
           in at least one browser, maybe two, just to show progress being made?
   * sylvaing finds himself immediately off the hook every time people say
              'implemented in at least one browser'. And does not like it.
   * ChrisL thinks sylvaing could fix that by, well, implementing more stuff :)

MultiCol
--------

   howcome: LC period for multicol has ended.  Not too many comments, so
            I've prepared some notes.
   Peter: You think you'll have that for next week?
   howcome: Yeah.
   Peter: Okay, still have five minutes.

text-overflow: shrink
---------------------

   Peter: Have a proposal for text-overflow shrink.
   fantasai: We discussed that a while ago, decided to drop it.
   fantasai: Looks weird for last line, but I'm not actively editting CSS3 Text.
   <fantasai> I'd probably drop features rather than add them at this point,
              to try to stabilize what's there
   Bert: We do need to get the vertical text out, but stretching the last
         line of the block is very common.
   Bert: I was at a book fair and all the high-end printing used that.
   fantasai: Last line of the block?  Or all lines?
   Bert: Last Line?  I can't tell - it was printed on paper, so I can't see
         the specs.  But the last line is definitely the same line length
         as the previous.
   howcome: One way of doing that is adjusting the spaces.  Another way that
            is useful for headers is to increase the font size.
   Bert: It's very common to see either spacing out or changing the size.
   howcome: I think we tried to do this, but a certain implementor reacted
            negatively, saying it would bring us into unspecified situations.
   BradK: When I was doing print, i would often use horizontal scaling to
          squeeze things onto one line.
   BradK: I found that less objectionable than changing the whole height.
   fantasai: I can see it making sense for *one* line, or for *all* lines,
             but it seems strange for the paragraph to be one size and the
             last line being differenet.
   ?: I agree.  For headings it makees sense where you stretch it out, and
      the second line is a different size.
   fantasai: Yeah.
   Peter: Out of time, we'll take this up later.

Meeting closed.
<RRSAgent> http://www.w3.org/2009/10/07-CSS-minutes.html
Received on Wednesday, 7 October 2009 20:59:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT