[CSSWG] Minutes and Resolutions 2009-07-01

Summary:

   - Multicol has been published
   - Flexbox and Image Values to be published as FPWD
   - RESOLVED: accept that overflow: visible does not allow
               replaced content to overflow
               css3-background and css3-page to be updated

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

Present:
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman?
   Alex Mogilevsky
   Peter Linss

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

Agenda
------

   Bert: Multicol has already been published
   <dbaron> Regrets: Øyvind Stenhaug, Anne van Kesteren, Dave Singer,
                     Tona Henderson, Håkon Wium Lie, Steve Zilles,
                     César Acebal, Molly Holzschlag
   <arronei> I'm here on IRC and will be on the call in 5 minutes or so
   dbaron: Any status on publishing flexbox?
   ACTION: Bert publish flexbox as FPWD
   Bert notes that lots of people are on holiday, but he will try to
     get that done
   <glazou> phone span, sorry for the noise

CSS3 Image Values
-----------------

   <fantasai> http://dev.w3.org/csswg/css3-images/
   <Zakim> +[Microsoft]
   <dbaron> Zakim, [Microsoft] has alexmog
   <Zakim> +alexmog; got it
   <dbaron> I'm ok with publishing
   RESOLVED: Publish css3-images as FPWD
   ACTION: Bert publish css3-images as FPWD

Anonymous Table Boxes
---------------------

   http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0184.html
   fantasai sent a request for Opera, Microsoft, and Apple to contact
     their engineers and collect feedback on Boris Zbarsky's anonymous
     table box generation proposal and testcases
   fantasai: I don't think we can productively discuss this ourselves,
             we should get feedback from the engineers who are working on it
   fantasai: and have that feedback sent to www-style
   Peter suggests we set a deadline for hearing back, perhaps two or four weeks
   fantasai: four weeks should be plenty... that's the 23rd
   <dbaron> four weeks is the 29th
   ACTION: arron send feedback on anonymous table boxes to www-style
   <fantasai> anne?
   ACTION: Peter send emails to Opera and Apple requesting feedback on
           anonymous table boxes from their engineers

IPTV
----

   fantasai: I'm happy to leave that to the chairs.
   fantasai: dsinger wrote a very nice template you should be able to use

border-radius and overflow on replaced elements
-----------------------------------------------

   http://lists.w3.org/Archives/Public/www-style/2009Jun/0115.html
   Hyatt's comments on css3-background:
     Looks good.  To address dbaron's concern about overflow, we implemented
     a very lightweight form of overflow:hidden for replaced elements that
     doesn't allow programmatic scrolling, etc. All it does is clip.  This
     is kind of gross, however, as we now have two types of overflow:hidden
     in the engine.
     Form controls in WebKit also clip their contents anyway completely
     independently of overflow.
     The most elegant solution is probably just to say you always clip
     replaced element contents to the curve even when overflow is visible.
     I can't really think of any scenario where you'd want the contents of
     a replaced element to spill out of the curve.
   roc's comments on this issue:
     http://lists.w3.org/Archives/Public/www-style/2009Jun/0117.html
   fantasai: So are people happy with always clipping replaced element
             content to the curve?
   <sgalineau> that is what I'd expect from a border, whatever its shape
   dbaron: My one concern is Robert's comment on form controls
   dbaron: for some replaced form controls, we might need to allow overflow
   dbaron: e.g. on Mac the focus ring is this blue glow that overflows
   fantasai: can we make an exception for form controls then?
   Bert: Why are we doing this?
   fantasai: because for authors, they would expect replaced elements to
             clip to the curve when they specify one
   fantasai: and because applying overflow: hidden triggers special
             scrolling behavior in UAs like Mozilla and WebKit that they
             don't want to have for images that don't need it
   <sgalineau> fwiw, i don't expect replaced elements to stick out of
               borders. i'd assume a designer want either the border to
               clip or expand around the element but not cause an ugly
               overflow...
   Bert is concerned that we are introducing different behavior for
     replaced elements and other elements
   fantasai explains that from an authors point of view, given that most
     of the time content fits within its border box and that border-radius
     clips the background, replaced elements are just acting weird if they
     don't clip to the curve
   <sgalineau> what happens if overflow:visible is set on a replaced element
               with a border ?
   Bert: we'll need css3-page to be updated to not imply that replaced
         elements can overflow their border box
   fantasai: yes
   fantasai: I'll need to update css3-page to say that
   <fantasai> sgalineau, right now nothing happens
   <fantasai> sgalineau, setting other values of overflow also doesn't do
              anything
   <sgalineau> so then i wouldn't expect overflow:hidden behavior to be an
               issue...?
   <fantasai> sgalineau, because right now replaced elements never overflow
              their border
   <fantasai> sgalineau, but with border-radius and image-fit this becomes
              possible
   <sgalineau> I prefer keeping the current behavior; it's consistent and,
               i think, what authors expect
   <sgalineau> i.e. clipping
   <fantasai> the currently-specified behavior allows overflow, it is not
              clipping.
   <fantasai> The proposal is to require clipping
   <fantasai> except in cases where the UA determines it to be necessary not
              to, e.g. form controls
   dbaron: my personal preference would be to require authors to specify
           overflow: hidden if they want this behavior
   dbaron: if we only end up with it in the case where authors request it,
           it's not that huge of a perf issue
   dbaron: creating it by default for every image is expensive
   sylvain: I would not expect a replaced element to overflow its border,
            at least by default, that just seems weird
   sylvain: If I put a border on an image or a video or anything ...
   Sylvain: As an author, I might set a border and put an image inside it
            or set an image and put a border around it, but I wouldn't
            expect to have a border and the image overflow the border
   dbaron: I don't think we can implement this in time for CR
   peter: I'm uncomfortable with special-casing things
   peter: currently you can't make it overflow, what about in the future?
   peter: we're introducing new properties that cause overflow
   sylvain: ... why do we want these new properties introduce the ability
            to overflow for these elements?
   sylvain: Did we have authors complaining about not being able to overflow
            replaced elements before this?
   Peter: it's just an implementation artifact
   sylvain: FWIW I'm just more comfortable with the existing behavior
            remaining where it was, i.e. no overflow
   Sylvain: Rather than requiring people to specify extra properties
   Sylvain: Especially since there seems to be no demand or use case
            scenario for it
   Sylvain: Rounding the border shouldn't cause overflow, I just would
            not expect that
   <sgalineau> I just would not expect that styling the border differently
               would affect overflow.
   Peter: Why can't we just require people to set overflow: hidden
   Bert: CSS2 currently says that overflow doesn't apply to replaced
         element, it would be easy to keep it that way
   Bert imagines someone creating a map with a small viewport with scrollbars
   Peter is averse to special-casing things, but isn't going to hold
     things up here for it
   peter: we can always unwind it with further properties if necessary
   RESOLVED: accept that overflow: visible does not allow replaced content
             to overflow

Received on Thursday, 2 July 2009 18:33:28 UTC