[CSSWG] Minutes and Resolutions 2010-07-28

Summary:

   - Collecting agenda items for Oslo F2F at end of August
       http://wiki.csswg.org/planning/oslo-2010
     Will need to discuss WG recharter.

   - RESOLVED: Leave text-align case defined, position of bullet in presence
               of floats undefined for issue 86
               http://wiki.csswg.org/spec/css2.1#issue-86

   - RESOLVED: Accept bz's proposal as worded by fantasai for issue 110
               http://wiki.csswg.org/spec/css2.1#issue-110

   - Discussed Issue 118, need definition of em-box or equivalent.
       http://wiki.csswg.org/spec/css2.1#issue-118

   - ACTION: Everyone - one week to review proposal for CSS2.1 Issue 120
                        accepted if no comments given
       http://wiki.csswg.org/spec/css2.1#issue-120

   - RESOLVED: Proposal accepted for CSS2.1 Issue 166

   - ACTION: Everyone - review proposal for CSS2.1 Issue 167
       http://wiki.csswg.org/spec/css2.1#issue-167

   - Reviewed issue 170 (min/max-width/height on table cells)

   - RESOLVED: Add missing values from writing-mode in SVG to CSS

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

Present:
   César Acebal
   Tab Atkins
   David Baron
   John Daggett
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Chris Lilley
   Peter Linss
   Brad Kemper
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2010/07/28-CSS-irc
Scribe: fantasai

Administrative
--------------

   <glazou> http://wiki.csswg.org/planning/oslo-2010
   glazou: F2F coming up, only a few topics listed on agenda
   <ChrisL> http://www.w3.org/Style/Group/2010/Oslo.html
   glazou: Anyone have other topics?
   ChrisL: We need to recharter, so we need to discuss what's going into
           the next charter period
   jdaggett: I'd like to talk about CSS3 font feature support
   glazou: Please add to the wiki page the length of time you need for
           the discussion
   glazou: Anything else? Ok let's move back to CSS2.1 issues
   * bradk is having computer problems. Can't launch anything since updating
           Safari, including Google voice. This message sent through my phone.

CSS2.1 Issues
-------------

   http://wiki.csswg.org/spec/css2.1#issue-86
   bert: I posted a list of issues I edited
   bert: Issue 86 is a problem, just sent an email about that
   bert: My task for 86 was about the position of the list marker box,
         and my task was to tweak the text and make an edit, but after
         I tried and fantasai responded to that I wasn't sure what I
         was supposed to do there.
   bert: Wanted to discuss how far exactly the marker should be undefined
   bert: the marker is supposed to be outside the box
   bert: we decided it doesn't scroll
   bert: we decided it's on the left for ltr and on the right for rtl
   bert: we decided the marker could create a first line if there wasn't one
   bert: For 86 we decided it would be undefined
   bert: the issue was for floats and centering
   fantasai: It should only be defined for cases where the start of the
             inline content is not at the start edge of the containing block
   fantasai: i.e. in the presence of floats
   fantasai: And when text-align: center or end (or equivalent)
   bert: We do have implementations that leave the bullet on the outside
         edge in the presence of text-align
<Zakim> +bradk
<Zakim> -TabAtkins
   dbaron: I thought some people wanted the bullet to move with text-align
   bert: On the mailing list people said that should be handled by
         position: inside
   * dbaron thinks there's actually a good bit of interop in the floats
            case too
   * glazou thinks we should test interactive properties only with batch
            processors :-)
   fantasai: If we have implementations for the text-align case, then
             let's just undefine the case for floats
   fantasai: We do want to leave the marker alone in text-align for CSS3;
             the bidi group concluded that was desireable for certain cases
   RESOLVED: Leave text-align case defined, position of bullet in presence
             of floats undefined for issue 86

   http://wiki.csswg.org/spec/css2.1#issue-110
   http://lists.w3.org/Archives/Public/www-style/2010Jul/0404.html
   http://lists.w3.org/Archives/Public/www-style/2010Jul/0372.html
   fantasai: My action item is done, proposed text as bz wanted
   <TabAtkins> At this point I'm just going to go with what fantasai suggested.
   Bert: I don't like it, but I guess it's not that common
   <dbaron> I'm deferring to bz
   fantasai: my position is the same as Bert's. I don't like it, but if
             we have to do it, we have to do it
   SteveZ: Mine is the same
   RESOLVED: Accept bz's proposal as worded by fantasai

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-118
   fantasai: I think the text is fine. I agree with Anton that it's
             a little confusing about whether leading affects the
             content box area
   Bert: That's explicitly undefined, so I tried to avoid talking about it
   <dbaron> Is the term "em-box" defined?  Should it be?
   Bert: This is not the first time the em box appears in the text. I
         don't think we have a formal definition of it
   <ChrisL> if em box is used then it should be defined
   <Bert> (10.6.1. says the height of the content area is explicitly
           undefined, that's why I didn't talk about content box in
           issue 118.)
   SteveZ: I don't think anyone's disagreeing with the text, but what
           the right way to say where the spacing goes
   SteveZ: The problem has to do with describing where the extra leading occurs
   Bert: We need some measure of what gets centered. It's not the ink
         of the glyph, because that may be far outside the em box
   <ChrisL> http://www.d.umn.edu/~lcarlson/csswork/inline/embox.html
   <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-size-props
   <bradk_> http://www.google.com/search?hl=en&safe=off&client=safari&rls=en&q=define%3A+em+box&aq=f&aqi=&aql=&oq=&gs_rfai=
   <ChrisL> "The em-box is the theoretical box (or square) around a font
            character of a given 'size' as designed by the font designer.
            It is sometimes referred to as an em-square. It is the
            theoretical square that glyphs are designed upon. Its height
            is the intended distance between lines of type in the same
            type size. In other words its height is the distance between
            baselines when the font is set without any extra leading
            (line-height).
   SteveZ: I would prefer a definition from the font specs
   ChrisL: That's taken from a discussion of fonts in the context of CSS.
           Let me get another one.
   <ChrisL> http://meyerweb.com/eric/css/inline-format.html
   fantasai notes we'd have to get permission from the author
   <ChrisL> actually we don't need permission since that definition is
            drawn from CSS2
   <ChrisL> Certain values, such as width metrics, are expressed in units
            that are relative to an abstract square whose height is the
            intended distance between lines of type in the same type size.
            This square is called the em square and it is the design grid
            on which the glyph outlines are defined.
   <ChrisL> http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#emsq
   dbaron: The other thing here is that you need something that both has
           a measurement, and one that provides a position with respect
           to the baseline
   SteveZ: That's why I want to go back and check with the font guys
   glazou: ok, deferred to next week
   <szilles> dbaron: sometimes things are expressed in terms of "ascent"
             and "descent" which are positioned metrics
   <dbaron> szilles, yeah, that's how our code works :-)

   http://wiki.csswg.org/spec/css2.1#issue-120
   glazou: Has anyone reviewed this?
   No response
   glazou: I give one week to everyone to review this and if there's no
           response it's accepted
   ACTION: Everyone - one week to review proposal for 120

   glazou: issue 137
   fantasai: need to discuss with bzbarsky

   glazou: issue 154 open to jdaggett, arronei, and zwol (zack)
   jdaggett: Arron pinged me, but I don't know what we want to come up with
   arronei: I'll talk to you right after the meeting if you have time?
   jdaggett: Maybe tomorrow morning / late afternoon your time?
   arronei: ping me when you're available tomorrow
   * dbaron thinks jdaggett means tomorrow for Japan and today for US :-)
   * jdaggett it's 2am which means today is today everywhere!

   http://wiki.csswg.org/spec/css2.1#issue-166
   Bert: The diff looks good, and is very easy to apply for me. :)
   Bert: I suggest we accept it
   glazou: Other thoughts?
   Bert: ... changes seems a bit finicky, but should be okay
   <smfr> -property does not accept percentages as values.
   <smfr> +property does not accept percentages in its values.
   glazou: No objection?
   RESOLVED: Proposal accepted for CSS2.1 Issue 166

   http://wiki.csswg.org/spec/css2.1#issue-167
   dbaron: Zack said he'd respond with another proposal. Maybe he did and
           we forgot to put it on the issues list?
   fantasai: Latest message from him on that is 15 July
   glazou: Ok, add to wiki and action everyone to review for next week
   ACTION Everyone - review proposal for issue 167

   http://wiki.csswg.org/spec/css2.1#issue-170
   dbaron: There was some amount of agreement on leaving things undefined,
           question is what things exactly we want to leave undefined
   glazou: I remember that web designers expect these properties to apply
           to cells and rows
   glazou: If we disable them, we should explain it very carefully.
   glazou: Let's defer and wait for Tab
   <bradk_> Both Tab and I had posted to the list about the TD TR
            max-height min-height thing...
   <bradk_> http://lists.w3.org/Archives/Public/www-style/2010Jul/0052.html

writing-mode
------------

   RESOLVED: Add missing values from writing-mode in SVG to CSS

Meeting closed.

Received on Thursday, 29 July 2010 22:52:25 UTC