W3C home > Mailing lists > Public > www-style@w3.org > November 2008

[CSSWG] Minutes and Resolutions 2008-11-12

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 18 Nov 2008 16:40:54 -0800
Message-ID: <49236096.8030807@inkedblade.net>
To: www-style@w3.org

Summary:

   - Discussed margin collapsing. Agreement that min-height/max-height should
     not prevent margins from collapsing in order to preserve continuity
     (current behavior causes jumps in content when you cross the min/max
     threshold). General agreement that we won't introduce partial collapsing
     because it would be new, complicated, and not of significant benefit.
     Will discuss later once we have a detailed wording proposal.

   - RESOLVED: For CSS2.1 Issue 84 (word-spacing)
       http://wiki.csswg.org/spec/css2.1#issue-84
     add proposed text from
       http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
     with sentences reversed.

   - Discussed @font-face and duplication: whether various source URLs should
     override each other or become fallbacks for each other. Conversation
     deferred to mailing list.

   - Discussed CSS2.1 Issue 85 (backslash before newline in an identifier),
     but came to no conclusion. Browser behavior is inconsistent, open question
     is whether to be consistent with strings (newline gets dropped) or spaces
     (newline is escaped and is part of the identifier).

   - Peter reminds WG that we have been asked to make last call comments on the
     Selectors API.

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

Attendees:

   David Baron
   Bert Bos
   Giorgi
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Melinda Grant
   Peter Linss
   Hakon Wium Lie
   Saloni Mira Rai
   Jason Cranford Teague
   Jeff Willson

ScribeNick: sylvaing
agenda: +f2f dates

:enabled/:disabled
------------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0295.html
   fantasai: spec does not do a good job defined :enabled and :disabled
   fantasai: need to change spec to make definition more vague/less
             dependent on user interaction
   <sylvaing> if we make it more vague, how do we converge on interop ?
   <fantasai> " which the user can select or activate in some fashion
              (e.g. clicking on a button with a mouse)"
   <fantasai> I would suggest removing that
   glazou: not sure this solves the issue
   <dbaron> How about something more like "represents an element whose
            element type can be enabled by the user but cannot currently
            be activated by the user due to the semantics of the markup"?
   <fantasai> s/whose element type//
   dbaron: definition of enabled/disabled should not depend on CSS but
           semantics of the markup and object model
   <dbaron> not sure if "element type" is the right thing, but it is precise
   fantasai: we already have implementations that match type=hidden.
   <glazou> what happens for :enabled { display: none  } ?
   fantasai: html5 should define enabled/disabled
   fantasai: I personally think type=hidden should be able to accept
             :enabled/:disabled because that distinction exists
   fantasai: but that should be left up to HTML5, we should not define
             that here
   plinss: there was discussion to use CSS to determine whether something
           was editable i.e. its state
   dbaron: IIRC we decided that was a bad idea
   <Hixie> http://lists.w3.org/Archives/Public/www-style/2008Oct/0161.html
           is relevant here
   <Hixie> I prefer the first mechanism proposed
   ACTION fantasai: write rewording proposal for section CSS3 Selectors 6.6.4

::selection
-----------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
   dbaron: two issues 1) 3 proposals for ::selection 2) have not looked at
           existing impls and tests
   fantasai: unclear what Hixie's test assumes/expects
   glazou: discussion postponed to next week
   fantasai: When I looked at Hixie's tests, it looked like he set properties
             on everything, so it was not possible to see how values
             inherited/cascaded through the tree

Ideographic Space
-----------------

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-84
   no objection
   <glazou> change accepted
   <fantasai> RESOLVED: proposal accepted for issue 84

border-parts
------------

   hakon wonders whether repeat() should be kept in GCPM border-part
   melinda: agree it will be hard to preserve
   melinda: combinations can get very complex
   melinda: should we ask designers ?
   melinda: agree that border parts are generally useful
   discussion of what designers want
   jason: Control over spacing of dashes is a standard tool designers use
   fantasai: feature set for 3 is good and should get locked down for
             impl.; new proposal for dotted/dashed lines can go in
             borders & backgrounds 4

CSS2.1 Publication
------------------

   glazou: bert sent email today about CSS21 publication plan
   bert: SVG Tiny 1.2 depends on CSS2 since they need to depend on a REC
   bert: people cannot use CSS21 for their specs
   glazou: yes we do need to deliver this spec
   bert: we give the appearance to move backwards; we could avoid
         publishing anything until we have a PR
   fantasai: we said we'd do that in Cambridge
   fantasai: we can't go to PR without the test suite
   fantasai: and implementations that pass
   bert: should we give up on implementations ?
   fantasai: conflicts with the process document
   melinda: should we see where we are wrt test coverage and estimate
            time left
   plinss: we have not spent enough time on the test suite yet to decide
           today whether we should change the exit criteria to fasttrack REC
   bert: we seem to never get out of issues
   fantasai: we'll never be out of them; but once in REC we address them
             in errata
   bert: we should not wait for implementations to complete the spec
   plinss: we're waiting for the test suite, without which we don't know
           whether we have implementations
   bert: do we have estimates for how long it will take to complete the
         test suite and have test reports ?
   melinda mentions msft's coming test suite
   fantasai: once we have their test suite, reviewing them is the next item
   dbaron: are we designing a system to allow us to review tests or are we
           going to do something simpler
   fantasai: right now, simple system. wiki and mailing list
   dbaron: is there a wiki linking to tests needing review
   dbaron: in one place
   melinda: agree.
   dbaron: we should not gate progress on building a complex review system
   dbaron: I just want a list of what needs to be done.
   dbaron: otherwise it is hard to get involved and help
   <fantasai> http://wiki.csswg.org/test/css2.1/pending-review
   fantasai: record of which tests have been reviewed is not centralized
   glazou: should we move tests that need work, that have been reviewed,
           pending review etc be in different places in the repository ?
   fantasai: will look for a solution that does not involve moving things
             around all the time since moving files can lose versioning
             history if you don't do it right
   plinss: individual contributors should not do this, only reviewers
   glazou: expose a web frontend to do this so the backend does it right
           in subversion

F2F Planning
------------

   glazou: moving on to Tokyo f2f meeting
   plinss: can we lock dates within the first two weeks of march
   fantasai: is february a possibility ?
   arguing dates around sxsw
   glazou: we stick to the first week of March; 4, 5 and 6


Attendees:

   Bert Bos
   David Baron
   Giorgi Chavchanidze
   Elika Etemad
   Melinda Grant
   Molly Holzschlag (via IRC)
   Howcome Wium Lie
   Peter Linss
   Saloni Mira Rai
   David Singer
   Jason Cranford Teague

<RRSAgent> logging to http://www.w3.org/2008/11/12-css-irc
<Molly> hi, not on phone today, just IRC
* Bert has to run after the call, prefers not to scribe today...
Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0065.html

ScribeNick: fantasai
Margin Collapsing
-----------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2008Nov/0109.html
   Sylvain: At the F2F we discussed min-height and margin collapsing and
            how it creates discontinuities
   Sylvain: We left the max-height clause in there, which also creates
            discontinuities.
   Peter: Did we get a resolution on whether we should adopt the partial
          collapsing?
   Sylvain: I don't think we did, but I also don't think we want to get
            into that now for 2.1
   Peter: Right. We should be consistent with min-height and max-height,
          though
   Sylvain: If we want to avoid discontinuities then we need to either
            drop both clauses or define partial collapsing
   Melinda: Is there a description of partial collapsing?
   Sylvain: See thread for Alex's proposal
   Peter: The issue here is that you have a parent and a child. Parent
          is now bigger than it needs to be due to min-height. Does
          parent and child margins collapse?
   Peter: The question is how to deal with the child's bottom margin
          being large enough to extend past the parent's bottom margin
   Peter: Can we at least agree that min-height and max-height should
          have the same behavior?
   Bert: Yes, I agree with that. Also I like Alex's text in that second email
   Bert: Not the partial collapsing, I mean the other part
   Bert: The part that makes min-height and max-height
   David: I assume we're talking about negative margins. I agree min-height
          and max-height should behave the same
   * glazou is here only for ten minutes, between two meetings ; hi everyone
   <dbaron> No, I said I assume the case where there's a discontinuity for
            max-height is a negative margin case
   <dbaron> I'm ok with what we were discussing at the F2F, where margin
            collapsing is not changed by min/max-height even if they do
            change the size of the box.
   Peter: opinions on partial collapsing?
   Peter: Can we add it later?
   Bert, Elika: Don't think we can add it later.
   Bert: I don't mind adding it now /if/ it can be implemented quickly
   Alex: It didn't seem like any of the implementors were particularly
         excited about implementing partial collapsing.
   Alex: It's a really new concept, and I'm not sure there's a lot of
         benefit to adding that to the spec.
   Alex: We would do something like that if we have to, I'm not sure why.
   Alex: Are we getting to agreement that we can remove min-height and
         max-height from that paragraph and that would be the only change
         we would make?
   fantasai: I think you might need to make some other changes.
   <fantasai> http://www.w3.org/TR/CSS21/visudet.html#min-max-widths
   fantasai: There aren't any specific mentions of margin collapsing there,
             but there are rules for how they apply.
   <fantasai> "If the resulting width is smaller than 'min-width', the
               rules above are applied again, but this time using the
               value of 'min-width' as the computed value for 'width'. "
   <fantasai> 10.7 points to that with s/width/height/.
   dbaron: Basically it needs to say that the new computed height does
           not affect margin collapsing.
   Melinda: I think this gets into the concern I was trying to raise.
   Melinda: We have an auto-height box which starts behaving like a
            fixed-size box, where we have overflow and margin collapsing
            issues
   Peter: max-height has to trigger overflow, the point is to constrain
          the height
   Peter: min-height won't trigger overflow because it'll be at least
          big enough for its contents.
   fantasai: only the margins will spill out for min-height, and they
             don't trigger overflow
   ACTION: Alex propose min/max-height text for 10.7
   * glazou has to go, meeting pending
   * glazou bye people

word-spacing issue
------------------

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-84
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
   David: Why are we leaving things undefined?
   fantasai: there are other characters we aren't sure about, or others
             that we don't know about/haven't been added to Unicode yet
   fantasai: This needs more research. Hopefully get some clarification for
             CSS3 Text as well. But shouldn't disallow implementations from
             doing this correctly if they are more knowledgeable than the
             CSS2.1 spec.
   Sylvain: Our concern is CSS2.1 and testing conformance there
   fantasai: CSS3 Text is likely to add at least one or two characters to
             this list
   fantasai: If people are uncomfortable with this being explicitly undefined,
             we could make it implicitly undefined but leave the "don't apply
             to these characters" sentence.
   David: I'm ok with the concept. How about reversing the order of the
          sentences.
   Sylvain, fantasai: ok
   RESOLVED: Add proposed text for CSS2.1 Issue 84 with sentences reversed.

@font-face and duplication
--------------------------

   fantasai: Might want to wait for John Daggett
   dbaron: Might want to wait for more feedback
   Howcome: I sent my comments in. I think we have agreement on the first
            issue. The other two are difficult
   dbaron: I'm interested in what Michael Day's use cases are.
   Howcome: I quoted from Prince's user style sheets. They use @font-face
            to implement generic font families
   Howcome: They list several src()s to make sure you get enough glyphs.
   Howcome: You could perhaps have another src descriptor that has the
            fallback behavior.
   Howcome: both behaviors are useful
   dbaron: if we go with one option for 2 and one option for 3 then you
           get both
   Howcome: if you go for A -- taking the first font that you find -- how
            would you solve Michael's use case?
   dbaron: You'd duplicate the rule with the same font family but a different
           src
   Howcome: Doesn't that conflict.. I guess that depends on 3
   dbaron: If you choose 2 goes one way and 3 goes the other way
   dbaron: Authors can do either, because they have 2 different mechanisms
           that do 2 different things.
   Howcome: I'm ok to hear from Apple on that, maybe if we poke them.
   dsinger: I'll pass the poke onto Mr. Hyatt
   Howcome: I don't think this is a contentious issue. If we can find a way
            to describe both use cases, which it seems like we can.
   Peter: So if you have multiple values in a single declaration you combine
          those in a fallback chain, and if you have multiple @font-face
          rules you overwrite each
   dbaron: No, the other way around.
   fantasai: Peter's way seems more consistent
   dbaron: But it wouldn't work well to combine with the addition of new
           descriptors over time.
   dbaron: For example the unicode-range descriptor.
   dbaron: could be used to split up a font into multiple segments, you only
           download the one you need
   dbaron: but an implementation that doesn't support it would download just
           the last one
   dbaron: if you did it that way
   dbaron: and would therefore only get a partial font
   Peter: I'm a little concerned because I'm wondering if a designer would
          want a  way to override an @font-face declaration
   dbaron: They could just use a different name
   dbaron: also the last @font-face declaration wins
   dbaron: other people have other opinions here
   Peter: I think John Daggett is mainly concerned to give designers both
          options

CSS2.1 Issue 85
---------------

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-85
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0039.html
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0078.html
   <fantasai> Proposal is to remove \r\n\f from escape token class
   fantasai explains how spec prose implies one thing, and escape token forbids
            it while being inconsistent between spaces and newlines
   Sylvain: what do other browsers do?
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/att-0039/escape-newline-in-css-identifier.html
   Sylvain: I don't expect this to affect authors, but we should define
            something
   Sylvain: Can we agree that space and newline should be handled the same way?
   dbaron: It matters more to me which way they're handled than that they're
           consistent
   dbaron: I'm more concerned about consistency between strings and identifiers
           than between spaces and newlines

Selectors API
-------------

   Peter: Reminder that we have been asked to make last call comments on the
          Selectors API
Received on Wednesday, 19 November 2008 00:41:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:17 GMT