[CSSWG] Minutes and Resolutions 2011-10-26


   - Reviewed Tab's proposed note for unmaintained specs
   - Discussed TPAC logistics, observers (probably all cannot fit)
   - RESOLVED: Deferred cap-height unit proposal to level 4
   - Discussed minimum ranges/precision for CSS values
   - RESOLVED: Not moving value serialization into CSS3 Values and Units
   - RESOLVED: Rename 'vm' as 'vmin'.
   - RESOLVED: vh/vw/vm stay as percentages of viewport size; clarify spec
   - RESOLVED: Move Stages of Value Computation section to CSS3 Cascade, and
               update CSS3 Cascade and sync to 2.1 so that it's no longer
               obsolete, just unmaintained.

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


   Rossen Atanassov
   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Peter Linss
   Eric Mueller
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/10/26-css-irc
ScribeNick: fantasai


   glazou: Extra items?
   TabAtkins: Would like quick yay/nay on proposed note for obsolescence of
              old WDs
   <TabAtkins> http://lists.w3.org/Archives/Member/w3c-css-wg/2011OctDec/0047.html
       This specification is not being actively maintained, and must not be
       used as a guide for implementations. It may be revived in the future,
       but for now should be considered obsolete.
       If you have questions or comments on this specification, please send
       an email to the CSSWG's mailing list at www-style@w3.org.
   fantasai proposed s/must/should/
   <dbaron> In addition to the use of "should" and "must", I think you should
            change "CSSWG" to "CSS Working Group"
   Bert: Tab can add to the editors' drafts, but what about published drafts?
   Tab: Should republish WD as well, possibly add a sentence or two
   glazou: Add link to www-style
   <glazou> http://lists.w3.org/Archives/Public/www-style/

   Bert: Do we have a list of all the obsolete drafts?
   Tab: I started a list in the thread, two emails asking for changes to
        the list
   Tab: Would go with that list amended
   fantasai suggests putting the list on the wiki
   <fantasai> http://wiki.csswg.org/spec


   glazou: Has everyone seen the details for the Sunday meeting at Adobe?
   <glazou> http://wiki.csswg.org/planning/tpac-2011
   vhardy: We're thinking of setting up dinner at 6:30pm in San Jose, that
           sound ok?
   glazou: Some people are vegetarian?
   TabAtkins: Given Vincent's vegetarian, I'm sure he's handled that. :)
   glazou: I will browse agenda items for TPAC tomorrow and try to schedule

   Florian: There was on the W3C site a very long list of ppl who would
            like to observe
   glazou: I got some requests from Adobe for observers from Adobe
   glazou: I also got some requests for other observers. I gave them rules
           we gave the Japanese observers at Mozilla. We usually accept
           all observers, as long as there is space.
   Florian: The list on w3c site was O(tens)
   <Bert> (We have 35 people signed for the meeting up as *member*, assuming
          they all clicked the right button, we'll not have much room for
          the 32 observers...)
   <Bert> https://www.w3.org/2002/09/wbs/35125/TPAC2011/registrants
   ACTION glazou: send an email to people who requested observer status
   <trackbot> Created ACTION-373 - Send an email to people who requested
              observer status [on Daniel Glazman - due 2011-11-02].

   glazou: I notice a lot of ppl arriving Friday, could make dinner plans
           for Friday night over email

   glazou: anything else about TPAC?
   vhardy: How are we arranging carpool?
   fantasai: I'm just going to assign people to cars on Friday.

CSS3 Values and Units

   Issues list: http://www.w3.org/Style/CSS/Tracker/products/8

   ISSUE-77 http://www.w3.org/Style/CSS/Tracker/issues/77
   TabAtkins: Cap-height unit proposal from dbaron
   fantasai: Question is add or don't add; should be similar to ex-height to
   <Rossen> How is this going to impact the line height itelf?
   Florian: What about Japanese text?
   dbaron: The use case is fitting something on the baseline to be the size
           of the letters
   sylvaing: what kind of use case?
   szilles: introducing new glyphs, e.g. for math
   Florian: Not sure introducing one unit will be enough to solve the problem
   TabAtkins: For Japanese, em-height should do it. For lowercase letters,
              ex-height will do it
   sylvaing: Is this common? Do people like Brad have to do this often and
             have to hack it?
   TabAtkins: If I'm putting a sparkline inline with the text, you don't
              want it to be bigger than the text.
   fantasai: Wouldn't that be em-height?
   TabAtkins: Not if you want it baseline-aligned
   sylvaing: Is it a height issue or baseline issue?
   fantasai: The height you choose depends on the baseline you choose
   TabAtkins: Right now, if you want something to extend from top to bottom
              of the line, you set vertical-align to bottom and give it 1em
   TabAtkins: You can make it ex-height and baseline-aligned to fit within
              the lowercase area
   TabAtkins: But you can't do baseline to top because we don't have this case
   Florian: If we can solve all languages with one or two units, then it's
            good, but if it's many new units for all scripts, then maybe
            that doesn't work so well and we should use a different solution
   szilles: The ratio of ascender to descender can vary between fonts. So
            cap-height will be different for different fonts.
   <stearns> there are a lot of font metrics we could expose - we may want
             to defer doing this until we have the time/interest in exposing
             it all
   Florian: I think the idea is good if it extends to other scripts
   sylvaing: And if the fonts support this data
   some discussion of international considerations: ideographic, indic,
        vertical-flow, thai
   fantasai: So the plan is, afaict, to defer this to the next level
   szilles: I'll ask font guys about metrics for things like sparklines
   RESOLVED: Deferred to level 4

   ISSUE-173 http://www.w3.org/Style/CSS/Tracker/issues/173
   TabAtkins: next issue is required ranges for CSS
   TabAtkins: Implementations must go at least up to this number; may go beyond
   szilles: Didn't we resolve on this?
   fantasai: We resolved to have this requirement, but not what it is
   Florian: Let's assign action items to browser vendors to investigate
   TabAtkins: I've never heard anyone complain about overflow, so whatever
              we're doing now is fine.
   arronei: I have most of the information/testcases for this
   <glazou> we need a test case for z-index for the max
   arronei: new properties would be tricky if they're different
   <Bert> (Range? Or precision?)
   fantasai: Can you make a proposal for what to put in Values and Units?
   arronei: I can collect the data
   Bert: I wonder if this is 2 different things. Range - do we accept 10km?
         But also precision. Do we handle 1 part in 1000?
   ACTION arronei: collect data and make a proposal
   TabAtkins: I know Opera goes under 2^31 on some things
   Rossen: If something like this goes into the spec, it should be on the
           lower bounds so that we don't have to go fix anything depending
           on the type
   Florian: Why are we doing this?
   TabAtkins: For the test suites, we need to know what's a valid range to test
   TabAtkins: Right now we could know implementations support up to .. 8
              but nothing beyond that.
   TabAtkins: It's primarily a quality-of-implementation issue, but want some
              minimum to meet or exceed
   Florian: It's not intended to be an exercise where we have to change the
            implementations, right?

   ISSUE-186 http://www.w3.org/Style/CSS/Tracker/issues/186
   TabAtkins: proposal to move CSSOM value serialization from CSSOM to
              CSS3 Values
   dbaron: That's moving them from a less stable spec to a more stable spec
   dbaron: I'd like to review them carefully... may not have gotten a lot of
           atttention yet.
   fantasai: Question here is, do we even want to move them
   glazou: Seems like a Pandora's box
   glazou: Would want to add serialization to all the other CSS constructs
   glazou: Also, might be useful to implementers to have it all in one place
   fantasai: Could be a separate, parallel module, e.g. CSSOM Values and Units
   sylvaing: or just have Serialization be its own thing
   sylvaing: I think if you want to move Values and Units forward, doesn't
             seem like a good idea.
   sylvaing: I think having a single core Serialization spec would be a good
   glazou: I'd like time to investigate that.
   glazou: I think we should leave it in CSSOM spec for now, and decide later
           when we know better what needs to be split out and dispatch to the
           various modules.
   glazou: It's a lot of work.
   fantasai: So close this issue no change?
   glazou: That's my recommendation.
   RESOLVED: Closed no change

   * dbaron Zakim, who is noisy?
   * Zakim dbaron, listening for 10 seconds I heard sound from the following:
           glazou (69%), Bert (4%), tabatkins_ (20%)
   * sylvaing 69% of the noise is produced by one person #OccupyGlazou
   <glazou> ROFL

   ISSUE-190 http://www.w3.org/Style/CSS/Tracker/issues/190
   Removing or renaming 'vm' unit
   sylvaing: There is one implementation, but at this point no clue on how ...
   fantasai: I'm strongly in favor of renaming, b/c I think it's vague and
             ambiguous and confusing.
   Florian: The objection was based on most units being 2 letters
   TabAtkins: We already have 3-letter units, so ehh.
   arronei: Have an implementation, but not a strong objection.
   TabAtkins: Should've prefixed it!
   arronei: That's why it's not a strong objection. :)
   RESOLVED: Rename 'vm' as 'vmin'.
   Florian: Should we keep it at-risk?
   fantasai: Could do, but I doubt someone implementing 'vh' and 'vw' would
             skip it: it's trivial once you have those.
   fantasai: So we could keep it at-risk, but that won't really mean much.

   ISSUE-194 http://www.w3.org/Style/CSS/Tracker/issues/194
   Florian: ppl are confused about whether it's 1/100th or just 1x
   Florian: Do we want to change that?
   fantasai: I think part of the problem is the spec was not very clear in
             tying these to the idea of percentages, which make the 1/100th
             factor seem less arbitrary.
   fantasai: Also, since IE has an implementation: chances are vh and vw
             are more used than vm, also this would be an interpretation
             difference, which is more of a problem; vm -> vmin would just
             trigger a parse error
   fantasai: So I'm leaning towards not changing it
   RESOLVED: vh/vw/vm stay as percentages, clarify spec

   ISSUE-192 http://www.w3.org/Style/CSS/Tracker/issues/192
   Move "Stages of Value Computation" spec to CSS3 Cascade
   glazou: what means "mostly" in 2.1?
   glazou: what's missing?
   fantasai: Only examples afaict
   glazou: I'm ok to move it if CSS3 Cascade is not marked as obsolete
   fantasai: Ok, I'm willing to work with that conditional. Does anyone else
             have an opinion?
   dbaron: If someone starts fixing them up, shouldn't be marked obsolete
   szilles: mark it unmaintained, not obsolete
   Florian: Would need the spec to have an editor
   TabAtkins: Doesn't need one if it's identical to 2.1
   fantasai: So if we update CSS3 Cascade and sync it to 2.1 and post a WD,
             and then leave it there without taking to LC because there's
             nothing new or useful in it, is that ok?
   florian: Why not move it along the rec track?
   TabAtkins: Editors' time better spent elsewhere
   glazou: And test suite is work
   * sylvaing we need more editors...
   RESOLVED: Move this section to CSS3 Cascade, update CSS3 Cascade and sync
             to 2.1 so that it's unmaintained but not obsolete, and when
             someone has a reason to move it forward along the rec track
             (i.e. someething to put in it that's not already in 2.1) then
             they can move it forward from there.

Meeting closed.

Received on Wednesday, 26 October 2011 20:56:02 UTC