W3C home > Mailing lists > Public > www-style@w3.org > September 2011

[CSSWG] Minutes and Resolutions 2011-09-28

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 28 Sep 2011 18:18:25 -0700
Message-ID: <4E83C761.9030300@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: Publish updated Working Draft of CSS Fonts Module Level 3
   - RESOLVED: Publish Transitions, Animations, Transforms 2D, Transforms 3D,
               with merge note at top of Transforms.
   - RESOLVED: Future documents need Changes sections before publication.
   - Discussed margin collapsing of column-spanning elements
   - RESOLVED: Add Animatable: line to property definition tables
   - RESOLVED: Adopt :drag-over for CSS4-UI as :valid-drop-target
   - Note: CSS Speech Last Call comment period ends in 2 days.

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

Present:
   César Acebal
   David Baron
   Kimberley Blessing
   Bert Bos
   Cathy Chan
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   David Singer
   Alan Stearns
   Daniel Weck (via IRC)
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/09/28-css-irc
<danielweck> Dear CSS WG, I am only on IRC, no audio link.
<glazou> danielweck: ok
ScribeNick: fantasai

Publishing
----------

   glazou: Any other items?
   glazou: Ok, publishing CSS3 Fonts
   ChrisL: I had asked for a publication a few weeks ago, and jdaggett said
           there were a few edits pending.
   ChrisL: I agree with publishing
   Bert: publish
   fantasai: In favor
   glazou: Hearing no objection.
   RESOLVED: Publish update to css3-fonts
   ACTION Chris: prepare publication
   <trackbot> Created ACTION-366

   glazou: Request from Dean to publish Transitions, Animations, and Transforms
   vhardy: Talked with Dean about this, [... merge document ... ]
   glazou: Are you saying Transitions and Animations are ok, but Transforms
           need more work?
   vhardy: Yes
   sylvaing: Merging 2D and 3D?
   vhardy: Yes. Also, work to make it work for both CSS and SVG
   ChrisL: .. FXTF ..
   florian: At the F2F we agreed to merge, but didn't agree to block progress
            until the merge
   ChrisL: But if we agreed to merge, it'd be guiding people in the wrong
           direction to publish unmerged
   sylvaing: The only one reason to keep it split imo is because we have
             interop on a lot of the 2D stuff already
   sylvaing: if we want to unprefix
   smfr: It means that we snapshot the current [...]
   smfr: I'd like to publish 2D and 3D
   <dbaron> Whatever you say about publishing being misleading -- the current
            draft on the TR page is *more* misleading.
   <fantasai> dbaron, say that out loud?
   smfr: I see no harm in pushing to WD
   vhardy: I don't have a strong feeling about it
   dbaron: I think whatever you say about publishing being misleading, the
           drafts on the TR page right now are *more* misleading. There are
           errors that have been corrected since the last TR draft
   Florian: We can publish a draft with a note at the top saying that this
            is planned to be merged, so be careful
   smfr suggests changelogs
   sylvaing: I was looking more for a Disposition of Comments thing, since
             there have been many changes
   * glazou is happy we don't have hyatt-style cvs log messages :-)
   <glazou> "whatever, r=me"
   fantasai: You can point to CVS logs if someone wants every detail, but
             it's better to summarizing what the significant changes were
   sylvaing: Would be good to have, but not sure I'd hold up the publication
             for it
   sylvaing: There have been a lot of changes since the last publication
   glazou: Hearing group prefers to publish before merge, also that we'd
           prefer a changes section for all documents
   ChrisL: Also a note saying that the merge is happening
   <sylvaing> note that i don't necessarily need to see a change log/comment
              disposition in the spec; it can be a wiki issue page. As long
              as it's in a single spot i'm happy
   RESOLVED: Publish Transitions, Animations, Transforms 2D, Transforms 3D,
             with merge note at top of Transforms.
   fantasai: Are we requiring the changes section here, or is it just a
             recommendation for the future?
   RESOLVED: Future documents need Changes sections before publication.

column-span and margin-collapsing
---------------------------------

   howcome: We're trying to solve some edge cases, not core multicol layout,
            but should resolve it anyway
   howcome: Tried to write down 3 options we have
   <glazou> Tab's WebKit investigation:
            http://www.w3.org/mid/CAAWBYDDsU4AbBk=g5bWQKN5aP9DqOHZW80VBbtXsWQsO7QvAOg@mail.gmail.com
   // note see update at http://lists.w3.org/Archives/Public/www-style/2011Sep/0491.html
   <glazou> Håkon's summary of proposals and implementations:
            http://www.w3.org/mid/20099.15290.322422.741716@gargle.gargle.HOWL
   ------
      > Extra input from Håkon:
      > http://www.w3.org/mid/20096.43085.472727.657197@gargle.gargle.HOWL

     Adding to this, I think we have three possible solutions to this
     issue, informally named "fantasai", "MS" and "Opera":

                   Do spanners create BFCs?                MC       XF

     fantasai      no, but consecutive spanners            yes      yes
                   with identical column-span value
                   are wrapped in one anon BFC

     MS            yes, but the margins of the BFC         no       no
                   don't collapse (unlike other BFCs)

     Opera         Yes, and they collapse as other BFCs    yes      no

       where

       MC = margin-collapse between consecutive spanners
       XF = cross floats between consecutive spanners

     I believe Opera's solution is what the spec currently describes. But,
     like I said last week, interoperability is more important than the
     exact solution in this case.
   ------
   howcome: One is fantasai's proposal -- spanners create an anonymous BFC,
            which allows margin collapsing as well as cross-spanner floats
   howcome: One is MS's proposal -- spanners are each BFCs, but their margins
            don't collapse
   howcome: Opera's behavior is that each is spanner is BFC, but margin
            collapsing is allowed between them
   alexmog: We're trying to solve a very specific case, and not trying to
            create something where colspans behave as a float
   alexmog: It's a workaround for ?
   alexmog: If what we want to have is that a number of spanners would be
            as if it wasn't in multicol, that would make much more sense
   alexmog: If you have content that wouldn't look like that in another
            browser, it would look like that in this case
   alexmog: Something in the middle, I'm really uncomfortable with that
   howcome: Have I written up the proposals correctly?
   * glazou thinks we should try to avoid discussing stuff sent 20 minutes
            before the call...
   <fantasai> TabAtkins, you didn't check floats behavior for WebKit, we
              need that info
   howcome: I would prefer Opera's solution, since it already states that
            spanners create BFCs, so it's most consistent.
   howcome: Second most consistent with current spec is MS
   howcome: fantasai's proposal would require most changes
   howcome: I checked WebKit and they do have cross-floats
   Florian: We should clarify the spec so we can all do the same thing instead
            of all different things
   <Bert> (I prefer: 1. fantasai, 2. Op,.... 9. MS.)
   fantasai: Mozilla hasn't implemented yet, probably ok with any of these
   fantasai: I think we should ask some authors for what they want
   fantasai: It's a deeply technical issue to understand, but it has a
             significant impact on what they do and how they will use this
             feature
   fantasai: They care a lot about margins and spacing, if it's a few px off
             they're upset. They're going to be dealing with whatever behavior
             we decide
   howcome: I don't think authors care much about margin-collapsing, my
            priority is to make sure we all pass the test suite
   bradk: fantasai's proposal is closest to what we get with collapsing when
          no support for multicol
   alexmog: It's not just margin collapsing, but also cross-float interactions
   glazou: Sounds like everyone agrees we need more input
   glazou: howcome, you have action to post message to mailing list with
           request for help
   ACTION howcome: Post to mailing list asking for input on margin-collapsing
                   col-span issue
   <trackbot> Created ACTION-367
   ACTION howcome: post testcase
   <trackbot> Created ACTION-368
   glazou: If we could have the input for the F2F, that would be cool.
   * fantasai can post to the WG blog as well, to get a wider audience.
   * Bert thinks *everybody* can post to the blog now :-)
   <glazou> fantasai: yes please

Tracking Animatable Properties
------------------------------

   smfr: This came out of some emails on www-style about property lists for
         animatable stuff being incorrect
   smfr: The problem is we have one centralized list, it has to track
         everything that's changing
   smfr: Proposal is to move things into each property definition, whether
         it is animatable or not
   glazou: Animatable and transitionable, is it the same thing?
   smfr: Idea would be adding extra line to table to describe whether it's
         animatable and how it interpolates
   fantasai: would go in proptable.
   fantasai: Anne wanted a line for serialization order -- we can add both
   dbaron: The Transitions spec should define how each value type is animated,
           so they can link to that
   dbaron: Wrt serialization, maybe get further on how we want to define
           serialization
   dbaron: Transitions spec should list animatable properties for specs
           further ahead of it in the Process, e.g. 2.1
   RESOLVED: Add Animatable: line to propdef tables
   ACTION smfr: Create examples of Animatable: lines so we can put in template
                for copy/tweaking
   <trackbot> Created ACTION-369

CSS Conditional
---------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0182.html
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2011Sep/0468.html
   dbaron: I think it's a reasonable proposal, but I'm a little worried of what
           the effects are going to be.
   dbaron: All of @supports has that worry, but I just worry that this might
           tend a bit too much towards accidentally writing something
           browser-specific.
   dbaron: once you have the thing, you tend to stick stuff in it, and then
           you wind up requiring more and more, even though it's not actually
           required
   fantasai: What about combining that with the !supports proposal from
             earlier? That way you'd have to mark what you're actually
             requiring, but you don't have to write it twice.
   dbaron: Mixed feelings about that syntax, but it doesn't have that problem.
   <dbaron> (I think it was !required at the time...)
   Florian: I completely see the worries you have about this 'all' thing,
            but at the same time from a coding point of view you get problem
            of things getting out-of-sync between body and @supports list
   fantasai: Don't see us coming up with a solution here, so let's kick back
             to mailing list
   glazou: So no resolution

New pseudo-class for CSS4-UI :drag-over
---------------------------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0402.html
   glazou: Proposal to rename to :valid-drop-zone
   dbaron: That doesn't seem to imply there's something being dragged over
           it right now
   smfr: :valid-drop-target
   Florian: :active-drop-zone
   <sylvaing> :drop-zone-hover
   ChrisL: :active for links implies activation right now, not quite the same
   ChrisL: I can imagine things being considered an active drop zone without
           there being any mouse activity
   ChrisL: Do we want this specifically tied to mouse activity? Or not?
           Should be clear what we're targetting.
   ???: Tied to drag-n-drop
   smfr: Might be touch events, not just mouse events
   <bradk> :active-drag-target
   ChrisL: Right. <gives example>
   <sylvaing> bradk, should be drop-target imo...
   <ChrisL>  :active-dragged
   <bradk> syvaing, yes, right. :active-drop-target
   fantasai tries to give an example of keyboard control of dragging things,
            but this seems not to be an example of drag-n-drop
   <bradk> :active-dragged could be the thing you are dragging
   <sylvaing> :drop-focus ? The element current has focus for dropping purposes...
   <ChrisL> happy with . :active-drop-target too
   glazou: Seems we like :active-drop-target, but did not discuss proposal
           itself
   glazou: Does everyone agree we should have that in CSS4 UI?
   RESOLVED: Adopt :drag-over with some better kind of name
   fantasai: On the mailing list there was some discussion of having
             :drop-zone with :not(:drop-zone) vs :valid-drop-zone and
             :invalid-drop-zone with :not(:valid-drop-zone):not(:invalid-drop-zone)
             being neither
   <ChrisL>  :schroedinger-drop
   smfr: Thinks its a platform difference, Apple we never show invalid drop
         targets, but some platforms might show targets differently if you
         can drop to them, but not with the thing you're dragging
   smfr: Would prefer to keep it simple and not have :valid vs. :invalid
   <sylvaing> :drop-bikeshedding
   glazou: In that case we should use :valid-drop-target, to keep that door open
   RESOLVED: Adopt as :valid-drop-target
   <sylvaing> fwiw, to me :valid-drop-target does not imply the class applies
              only when something is dragged over it

<em> and text-emphasis-style
----------------------------

   glazou: jdaggett suggested we should wait on this, since we don't have
           wide support for that yet
   Florian: That's quite reasonable. Italics look wrong in Japanese, but
            if half browsers are doing that and half not, that's not going
            to be interoperable
   glazou: One cool thing, using @supports we can style <em> conditionally
           on support for text-emphasis-style

glazou: any other topics?
<sylvaing> tabs vs. spaces ?

CSS Speech LC
-------------

   fantasai: CSS Speech closing LC period in 2 days
   fantasai: dweck has started a Disposition of Comments on wiki
   <fantasai> http://wiki.csswg.org/spec/css3-speech
   fantasai: If no other issues come in, let's plan to adopt the DoC next week
   smfr: Apple has some comments, need to send them in
   glazou: anyone here implementing a voice browser?
   fantasai: Opera has some support for CSS Speech

Meeting closed.
Received on Thursday, 29 September 2011 01:19:06 GMT

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