W3C home > Mailing lists > Public > www-style@w3.org > August 2009

[CSSWG] Minutes and Resolutions 2009-08-05

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 05 Aug 2009 11:06:27 -0700
Message-ID: <4A79CA23.3050507@inkedblade.net>
To: www-style@w3.org

   - RESOLVED: Accepted proposal for item 1 of agenda [Administrative]

   - RESOLVED: Proposal accepted for CSS2.1 Issue 129 (Backup in Tokenizer)

   - RESOLVED: For CSS2.1 Issue 30, remove 'default' and 'initial' from
       example list, remove 'e.g.', and add a sentence that says 'initial'
       and 'default' are reserved as keywords for future use and must also
       be quoted when used as font names.

   - RESOLVED: For CSS2.1 Issue 133, say that 'height' is undefined for
       row groups.

   - RESOLVED: CSS2.1 Issue 134 (percentage offsets for relpos in
               auto-height containers) closed No Change.

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

   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Dave Hyatt
   Brad Kemper
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   David Singer
   Řyvind Stenhaug (Opera Software) via IRC

<RRSAgent> logging to http://www.w3.org/2009/08/05-CSS-irc
ScribeNick: fantasai
Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0042.html


   RESOLVED: Proposal accepted for item 1 of agenda.

CSS2.1 Issues

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-120
   <dbaron> this is issue 8 in the email
   fantasai: I'm not suggesting we solve the issue on the call, but that
             we decide how to approach it
   fantasai: whether we want to audit the entire spec to make sure the
             explicit lists are everywhere they need to be and in sync
   fantasai: or whether we want to remove explicit lists and define
             special display types in terms of blocks
   Bert: I think it's easier to have explicit lists, make sure we think
         about where the exceptions are
   Daniel: I think it's easier to have just a sentence saying
           table-captions are like blocks, much fewer edits
   dbaron: Need to be careful, it's like a block inside but not outside
   fantasai: There are many places in the spec that mention blocks in
             passing, we can't have explicit lists everywhere
   fantasai: Maybe at the top of the section, "blocks in these cases
             means ..."
   dbaron and Bert discuss lineboxes and baselines
   fantasai: It's not as simple as a sentence fix here. Basically we
             need to audit the spec, because we have a lot of this
             kind of problem
   fantasai: Question here is which approach should the person auditing
             the spec take
   ChrisL asks what the proposals are
   fantasai: First is to audit the spec and make sure there explicit
             lists whereever we talk about blocks, and make sure
             those lists are in sync
   <dbaron> I think we should leave it to the editor to propose an
            appropriate fix.
   <hyatt> same. up to the editor imo.
   <dbaron> "letting the editor decide" == doesn't need to make the
            decision while we wait
   fantasai: Second is to audit the spec to just talk about blocks,
             and then in the definition for table-caption etc. define
             those to behave exactly like blocks except ... and list
             the exceptions
   Several in favor of second option, Bert in favor of first (?),
     dbaron and hyatt want editor to decide
   dbaron: I think the solution here is to reword the sentence to
           define a block's baseline
   dbaron: So maybe Bert's suggestion to rename to line box's baseline
           is good
   <dbaron> (rename and make it a definition)
   ACTION: Bert and fantasai solve this issue

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-129
   dbaron explains the issue
   The way url() is defined in the tokenizer, if something starts to
     match url() but doesn't end
   Then the tokenizer has to go back and retokenize as something else,
   which is not what anyone does.
   dbaron: And we have prose that contradicts this, at least for the
           URL case
   <dbaron> I think
   Bert doesn't want to change the grammar
   Others don't want to change implementations
   dbaron: What the spec says is that given
     p { color: red; }
     h1 { color: red; }
   implementations should treat /* as an invalid selector
   <Bert> Currently, "/*" is two DELIMs, we can still use it for
          something. After Zack's change, "/*" becomes reserved.
   <dbaron> Bert, we can't use it for something, since it starts a comment
   <dbaron> Bert, if we used it, we wouldn't be able to have comments
            anywhere later in the style sheet
   Peter: I think it's extremely dangerous to use /* as a delimiter for
          anything other than comments
   Bert: The grammar is the most stable part of the spec, we should not
         touch that
   ChrisL: If the grammar is stable, but a portion of it has not been
           implemented and nobody wants to implement it, then it may be
           stable but it's wrong
   dbaron: We also have prose that contradicts the grammar very clearly
   <dbaron> "User agents must close all open constructs (for example:
            blocks, parentheses, brackets, rules, strings, and comments)
            at the end of the style sheet. For example: "
   fantasai: Prose trumps grammar. I think we should fix the grammar.
   <plinss> http://lists.w3.org/Archives/Public/www-style/2009Jun/att-0164/unterm-css.html
   * fantasai thinks that's a very clever testcase
   <dbaron> I think we've already fixed Firefox on the trunk
   Firefox backtracks the middle two, but not the first and the last
   Sylvain: We backtrack the first and last, but not the middle two
   <hyatt> lol
   * ChrisL sees the basis for another conditional hack
   <plinss> Safari does not backtrack for any
   <sgalineau> IE7 did not backtrack anywhere
   <oyvinds> 9.64 backtracks the last three, but my internal build none
   Daniel: We should fix this
   <dbaron> I guess I have a fix to fix the backtracking in my own tree
            that's not checked in yet.
   <dbaron> I'll have to figure out which patch that is. :-)
   Brad: No sense in keeping it inconsistent among UAs
   <sgalineau> Opera 10 Beta is same as 9.64
   Daniel: I'm happy with the proposal
   Bert doesn't have a problem with the proposal itself, just doesn't
        want to change the grammar
   Straw Poll to accept proposal
   Daniel: yes
   Bert: No, but won't block
   Brad: fix it, don't care how
   Sylvain: change it
   <hyatt> yup
   Alex, Arron: change
   fantasai: in favor
   <hyatt> in favor yes
   dbaron: in favor
   Peter: yes
   <ChrisL> fix as proposed
   <dbaron> Ah, yes, I've had this patch to rewrite url() parsing in my
            tree for ages that I should really do something about...
   dsinger: whatever hyatt says :)
   Daniel: Vast majority for yes.
   RESOLVED: Proposal accepted for CSS 2.1 issue 129

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-130
   dbaron: I think this is as intended
   fantasai: No, it's a problem. The example lists keywords that don't
             exist. So the example is inconsistent with the normative prose
   Sylvain: We're just reserving them for future use
   fantasai: But if we want to do that, we have to do it normatively, not
             in an example
   Bert: We edited the spec to include those keywords because we noticed
         they're defined in later specs, but not listed
   dbaron: I don't think it should be an example, it should just be that
           list (because for font-family, it's exhaustive)
   * dsinger why don't we recommend quoting font names?
   * dsinger like always
   * fantasai too late
   fantasai asks about font shorthand
   <dbaron> font shorthand requires size and family, and only lh and
            family after size, because the syntax for family is so broad
   ChrisL: Making the list normative is good, but should probably also
           call those keywords out explicitly
   <fantasai> I suggest removing those keywords from the example list,
              removing 'e.g.', and adding a sentence that says "'initial'
              and 'default' are reserved as keywords for future use and
              must also be quoted"
   RESOLVED: Proposal accepted with "when used as font names" appended

   * dsinger can we reserve a form that cannot possibly be (part of) a
       font-name, for future keywords?
   <dsinger> and if a font with that name is desired, they must be
             quoted. yes.
   * Bert to dsinger: we would probably have to use a functional notation
       foo() in that case...

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-133
   dbaron: this is only one out of many issues for table heights/widths
           and we wanted to postpone them
   * glazou already needed aspirin before the call and the topics
       discussed did not help :-)
   fantasai: If it's not defined, we should say it's not defined
   fantasai: we don't say that row-group heights are undefined, just
             tables and rows
   Bert: Add a sentence in 17.5.3 saying that height is undefined for
         row groups
   RESOLVED: Accepted, Bert to word and edit

   <glazou> http://wiki.csswg.org/spec/css2.1#issue-134
   Brad: Is there any reason why we can't use percentage offsets on relpos
          children of an auto-height block?
   dbaron: It's probably ok, though I'm a little concerned if there's
           overflow set... though I guess it's not a problem even then,
           just weird behavior
   Brad: Is it going to break anything if people implement it this way?
   fantasai: Apparently IE6 did it, so probably not
   Brad: unless they're doing two things and assuming IE does it but
         others don't
   Bert: I don't see why it can't work
   <hyatt> seems fine
   RESOLVED: Close no change
   * oyvinds notes that hyatt mentioned a cyclic situation related to
       showing of scrollbars in that thread, might need to specify what
       happens at least?

Meeting closed.
Received on Wednesday, 5 August 2009 19:07:05 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:38 UTC