[CSSWG] Minutes and Resolutions San Diego F2F 2012-08-28 AM I: F2F schedule, CSSOM

Future Meetings
---------------

   - Next meeting is TPAC, Sun-Tues
   - Planning F2F in Tucson for 2013, Februaryish
   - Planning F2F in Tokyo first week of June
   - Planning F2F after that somewhere in Europe sometime Augustish but not August.

CSSOM
-----

   - Status update on CSSOM
   - Discussed serialization of declaration lists, particularly wrt white space
     and indentation

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

Future Meetings
---------------
Scribe: TabAtkins

   dbaron: TPAC is this year, but I think that's all sorted out.
   szilles: Money commitments are there, room hasn't been arranged yet.
   szilles: This is August, it's France, need I say more? :)
   dbaron: We've agreed on months and locations for the next two meetings,
           but not dates yet, and we don't have a location for the third
           meeting.
   Molly: Since you decided Feb for the first meeting, Tucson has some big
          meetings in the middle of Feb which will cause hotel problems.
   Molly: How flexible are you about the date?
   Molly: I'll figure out in the next week what the best dates will be,
          and give you a few choices.
   sylvaing: Early March is fine, but late March is SXSW.
   glazou: I can't do early march.
   szilles: Mar 16-23 is no good for me.
   florian: end of feb or early march is the best for me.
   Molly: I feel that the early Feb is probably the danger zone.
   Molly: I'm going to look at the week starting Feb 4 or 6.
   szilles: The Gem Show is the 14-17.
   Molly: The week before is when the wholesalers are around.
   Molly: People are possibly okay with Sundays, yes?
   [several]: Yeah, that's fine.
   <sylvaing> SxSW is 3/8-3/17 so Interactive should be 3/8-3/11

   dbaron: So, we said we'd meet in Japan in May.
   dbaron: Since then, the AC meeting was announced as June 9-11 in Japan.
   dbaron: So, for the three or four of us going to that, it would be
           awfully convenient to make just one trip there.
   dbaron: The previous week works fine for me.
   jdaggett: The SVGWG said they wanted to colocate in Japan, so if that
             happens, we may need to use the Google office, because the
             Moz office won't take that many people.

   florian: For the third meeting, perhaps Europe.
   florian: I can't speak for Opera at that point, but we can see.
   TabAtkins: I can see what G might be able to do in Europe, too.
   dbaron: We may be able to do London or Paris, as well.  Depends on
           when the construction is done.
   jdaggett: I think we should wait to do dates for when Håkon is here,
             as he often has fall commitments.
   [discussion about being too close to TPAC, maybe hit late August or
    early Sep]
   glazou: I have a conflict in all of August.

CSSOM
-----

   glenn: Update on editing work...
   glenn: I transitioned the format to a preprocessor which I use to generate
          the docs from IDL.
   glenn: So I'm starting to work through the buglist and some of the new
          items appearing on the  mailing list.
   glenn: My current goal is to process all the bugs and get the material
          in place that would allow us to go to a new WD by the end of this
          month.
   glenn: For the items that people asked to discuss here...

   glenn: There was a question about what cssText should return for various
          rules, such as the contents of a @media rule.
   glenn: Should it be pretty-printed or not?
   florian: Right now, all impls break lines and indent things inside of @media.
   <glenn> http://hg.csswg.org/test/file/tip/contributors/gadams/incoming/cssom
   glenn: One thing I'm doing is a link of incoming tests.
   glenn: There are about 130 tests right now, and I'm actively expanding
          those to cover all the interfaces.
   glenn: I'll put one in to test the media behavior you're describing.
   florian: Though, now that we're getting nested @media, the indentation
            is not interop.
   florian: Opera does proper increasing indentation, but Firefox doesn't -
            they're all 2-space in.
   florian: Unfortunately, authors depend on silly details of the
            serialization, so interop is often important here.
   jdaggett: I'm going on the assumption that I can collapse all whitespace,
             and things should serialize the same way (in @font-face).
   jdaggett: So I'm not sure one particular type of whitespace is better
             than another.
   florian: I don't care much about *what* type of formatting is used,
            I just care about something being in the spec so we can do
            it all the same.
   glenn: Will we have exceptions for certain rules, or will this be a
          generic rule for all the parts of CSS?
   florian: Not sure.  It seems easy enough to be consistent, though.
   glenn: Yesterday we were talking about preserving whitespace and comments
          in @supports.
   glenn: in the case of an inline style, should we preserve what they do
          in that case, and pretty-print other places?
   florian: I think we should only do exact preservation in @supports
            condition, and just reserialize otherwise.

   florian: One nuance - when you serialize a single rule, some end it
            with a semicolon, while others end with a semicolon-space.
   jdaggett: If you have a font-family name that's unquote and has an
             escape in the second part of the name, webkit returns a
             quoted version.  It's not identical, but it round-trips.
   florian: It'll take time to nail down the exact details, but I think
            we can put together good general rules for all of these.

   jdaggett: For testing, I want the opposite - I want to test "does
             this parse?" and I get that by looking at the string.
   glazou: Testing is not a target for CSS.

   Molly: If there are differences, it makes it hard for developers to
          deal with it, because they have more to learn and memorize.
          Better to have things be consistent.

   florian: Opera also does the indentation on @keyframes.
   florian: When you nest things, Opera right now does correct pretty-printing.
            I'd like to either agree on that or not do it at all, so
            we're all together.
   florian: Our policy seems to be that at-rules that contain rules are
            indented, while ones that contain descriptors are not.
   glazou: What about groups of selectors? Many authors put newlines
           after commas in selectors.
   florian: No one does anything like that for now - selectors are just
            on one line.
   glazou: Is it naïve to ask for a pretty-printer built in natively?
   [some discussion about it]
   florian: We could just let libraries deal with that for now, and always
            add it in natively if it seems necessary later.
   dbaron: I don't think it's really necessary at all.  This is not
           something that's commonly used.
   glazou: Would you be okay with me and Florian investigating how to
           serialize rules across CSS?
   dbaron: I'm okay with that, with the caveat that the harder part is
           serializing CSS values, which is a separate topic.

   glenn: I hope to finish the value stuff this week.
   glazou: One thing I noticed that is missing a cssText is the Stylesheet
           object.  We should fix that.
   dbaron: One thing I noticed is that some cssText attributes are noted
           as not readonly in the OM, but they're readonly in practice.
   dbaron: Every once in a while, someone will submit a patch making one
           of their setters work.
   florian: Do you know why they might have been made readonly?
   dbaron: A combination of just not bothering to do it, or assuming that
           the spec meant to make things readonly.
   glenn: Do you have any places where you think it should be readonly?
   dbaron: For example, on @media - do authors really want to do this?
   TabAtkins: I think that it's about as useful as innerHTML, which is
              allowed everywhere.
   dbaron: what happens when you set
             mediaRule.cssText = "@keyframes foo { ... }" ???
   dbaron: The spec needs more than the lack of the word "readonly" for
           this to be implementable.
   dbaron: Looks like Firefox only makes it mutable in *one* instance -
           on CSSStyleDeclaration that doesn't come from getComputedStyle.

   glenn: So I don't think I have any other open issues.  If I have any
          questions, I'll bring them up to the group.

   Topic: global CSS object
   glazou: Any issues with that?
   TabAtkins: The last day of discussion in webapps hasn't brought up any
              problems, and people seem positive.  Sounds good - we can
              deal with any changes that prove necessary if problems come
              up later.

   Topic: @font-face OM definition
   glenn: Since John is doing @font-face in Fonts, should I remove those
          definitions from CSSOM?
   jdaggett: I didn't redefine @font-face, I just added @font-features
   glenn: Okay, my mistake.  So should I add some guidance about defining
          new at-rules in OM?
   [several]: YES

   glenn: What about coordinating the constants for new rule types?
   TabAtkins: There's a wiki page about that on the csswg wiki
   http://wiki.csswg.org/spec/cssom-constants
   glenn: Would you mind an informative note pointing to that page?
   TabAtkins: No, that's great.

Received on Wednesday, 29 August 2012 06:34:13 UTC