[CSSWG] Minutes and Resolutions 2011-06-15

Summary:

   - Considering last week of July for F2F in Seattle
   - There will be some kind of internal W3C telecon about Unicode normalization
   - RESOLVED: use idents for flow names in CSS Regions
   - Disagreement on whether CSS Regions should use the 'content' property
     or have separate 'flow-from' property that overloads 'content: normal'.
   - RESOLVED: Content selection is a UI issue, not in css3-regions
   - RESOLVED: No change to event propagation model due to regions
   - RESOLVED: Publish update of CSS Ruby once outstanding edits are folded in
   - ACTION everyone: Review CSS3 Writing Modes and report any issues that
                      should be addressed before LCWD is published.

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

Present:
   César Acebal
   David Baron
   John Daggett
   Arron Eicholz
   Elika Etemad
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Hĺkon Wium Lie
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   David Singer
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/06/15-css-irc
Scribe: fantasai

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

   glazou: New agenda items: CSS3 Lists from Tab, item from Alex on CSS3 Regions
   jdaggett: August F2F
   sylvaing: Normalization and Namespaces
   sylvaing: Charter schedule
   Vincent: Review agreements on CSS Regions
   Vincent: Chris asked to talk about FX charter

F2F Scheduling
--------------

   glazou: Already in June, so we need to decide about that quickly.
   glazou: First, where?
   Vincent: I'd suggested Seattle following the SVGWG meeting
   Vincent: So we can have a day overlapping with SVGWG
   <ChrisL> svg is 25-29
   Vincent: That's week of July 25th
   jdaggett: So you're suggesting week after that?
   Vincent: Yes
   Vincent: The week of August 1st
   glazou: I can't
   <ChrisL> I can't do week of Aug 1 either
   Steve: Could also do earlier
   <ChrisL> Before is much easier for me
   <ChrisL> overlap is not so great for me
   glazou: Could meet at the same time
   ?: Some ppl are in both groups
   glazou: So first suggestion is 29-31st of July?
   Vincent: 28-29
   Vincent: Have one day of conflict
   <glazou> 28-30
   sylvaing: Or we could be before with no overlap
   sylvaing: Overlap is interesting model, but weird if there are ppl in both.
   sylvaing: Ppl interested can just stay an extra day
   <ChrisL> vincent and tab and I are in both
   <dsinger_> Svg is 25-29 inclusive?
   Vincent is coming back on the 24th
   John: The weekend before will be pretty crazy
   John: It's Blue Angels and they'll close I-90
   <Zakim> +bradk; got it
   <dsinger_> The week before is mpeg Torino...
   fantasai: Seems a bit too early, given we want to span gap between June
             and November, and this is in July
   glazou: Yeah, probably too early. Not enough agenda items.
   sylvaing: Reason for another meeting is we have a lot of work, so not
             worried about that.
   dbaron: I do think we want a little more of a gap though
   September is bad for jdaggett and someone else
   glazou can't do August at all
   Steve can't do most of August
   Steve: I could do just before Labor Day, i.e. late august
   howcome can't do late august
   Steve: So the advantage of the July dates are they don't seem to have
          conflict, except for Blue Angels
   <smfr> the blue angels are a troupe of display jet planes
   <dsinger> The navy's flying aerobatics team
   <plinss> http://www.blueangels.navy.mil/
   sylvaing explains the problem with the Blue Angels and the closing of the
            bridges over the lake
   howcome suggests meeting on the East Coast
   glazou suggests meeting in Europe
   glazou: We're in Santa Clara for TPAC anyway
   glazou: It seems August is not practical for many people
   glazou: Only possibility is the end of the last week of July
   <alexmog1> late july-august is best weather in seattle
   jdaggett: Are there people with explicit conflicts?
   glazou: I need to be back in Europe on the 31st of July
   glazou: back to 28-29-30 of July
   ChrisL: That's 2 days of overlap with SVG
   discussion of conflicts
   -> offline

CSS Namespaces
--------------

   ChrisL: Discussed internally this week, and I pointed out how unfair it was
           when CSS was being penalized wrt this when it applies to everything
   ChrisL: So in the end what we decided was it would be good to have a short
           meeting with a few people
   ChrisL: Me, Ishida, one of the chairs, Addison Philips
   ChrisL: To discuss the issues
   ChrisL: and get i18n to withdraw on that point
   fantasai: What about dbaron's suggestion?
   ChrisL: ....
   <dbaron> (though it's hard to be know that *that* won't have performance
             implications without trying it)
   ChrisL: It's okay to make it the author's responsibility
   ChrisL: I'll set up a meeting next week sometime
   ChrisL: I think authoring in early normalization is better
   fantasai clarifies what dbaron's proposal actually was, i.e. normalizing
            at decoding time
   glazou: Most stylesheet authors and Web authors don't know what normalization
           means
   sylvaing: They shouldn't have to know about it
   glazou: This already harms FTP clients due to filesystem naming issues
   glazou: Even if we add content normalization only we still need to add tests
   glazou: There are 2 different late normalizations -- parse time and
           comparison time
   sylvaing: Either way the specs are held up ?
   glazou: I'm pushing for another solution. I'm pushing to release CSS
           Namespaces now
   glazou: And then have a separate spec dealing with normalization
   sylvaing: It sounds like it's a Web platform issue, no reason to hold up
             this spec as opposed to others
   glazou: So Chris, we're waiting for invitation and possible times

   sylvaing: Are we waiting for specs or waiting for that meeting?
   * fantasai thinks dbaron's solution makes the most sense of everything
              said so far

CSS Regions
-----------

   strings vs identifiers
   Alex: we had discussed at the F2F that strings were better than identifiers,
         but wasn't clear how this was the resolution
   fantasai: There was no official resolution in the minutes
   Alex: We have something similar with counters, and it seems to work okay
         for counters. Is there a reason to come up with something different
         for regions or can we use the same solution?
   smfr: We use idents in animations, too
   glazou: Yes, we usually use idents for this case
   glazou: Also I don't like allowing spaces in names
   * ChrisL ideographic space is your friend :)
   Alex: With strings you'd have to say whether null string is a flow, whether
         ? is a flow, etc.
   glazou: Is there any reason why you need a string, Vincent?
   Vincent: No, that was just where the discussion landed at the F2F.
   Vincent: plinss was in favor of strings
   plinss: We have many cases where we use idents here
   plinss: But we've also had cases where we've painted ourselves into a corner.
           It's safer to have a different syntax for user-named things, and
           strings are a good way to do that.
   fantasai: where have we painted ourselves in a corner before?
   plinss: font names
   fantasai: Those are not CSS-internal identifiers
   plinss: Still have the problem that we can't ever add another keyword to
           those property names because you'll have conflicts
   plinss: If you want to add a keyword, you have to define it now and we're
           stuck with that set forever
   glazou: or you can use a functional notation
   plinss: that was proposed, too, but kindof cumbersome
   Alex: idents are the easiest to use, ..., and we don't have a really good
         reason to not use idents
   plinss: We explicitly didn't resolve on this at the F2F
   plinss: we were just tossing ideas around, so I don't really care one way
           or the other
   plinss: I don't like inconsistency with other properties, but I also don't
           like the extensibility problem
   glazou: Do we need to resolve on this now, or can we add a note to the
           document and resolve later?
   Steve: Make a decision as to how the text should be written now
   John: I'd rather make the decision now.
   glazou: Ok, straw poll
   <dsinger> we can surely reserve names/idents of a specific form for CSS use
             (i.e. user region names cannot start with 'CSS')
   glazou: Two options: 1. String 2. Identifier
   JohnJansen: ident
   glazou: ident
   plinss: strings
   Arron: ident
   Alex: ident
   sylvaing: ident
   Vincent: abstain
   Chris: abstain
   Stearns: strings
   jdaggett: ident
   howcome: I'd like to hear what Bert thinks
   Steve: don't care
   César: abstain
   dbaron: ident
   smfr: ident
   Koji: abstain
   Brad: abstain
   hober: ident
   dweck: ident
   dsinger: defer to simon
   fantasai: ident
   glazou: I think identifiers clearly win here
   11 for ident, 2 for strings
   RESOLVED: use idents for flow names

   <vhardy> http://lists.w3.org/Archives/Public/www-style/2011Jun/0336.html
   Vincent: These were my notes on the meeting, wanted to confirm
   Vincent: First item was to have flow-into and flow-from properties,
            which is different from the current draft
   Vincent: Wanted to confirm if I should make that change
   fantasai: Why can't we use content property?
   Vincent: plinss wanted a separate property
   fantasai: If you specify both flow-from and content property, which one wins?
   plinss: content property overrides, you can use the contents keyword
           to get the normal content
   fantasai: so flow-from affects calculation of 'normal'?
   <stearns> I'm concerned with how 'normal' is getting overloaded
   Alex: You can also use flow-from: none to get normal content
   Alex: I like how flow overrides content property, much easier to handle.
         Otherwise have to look at two properties .. order
   fantasai: I'm concerned about the cascade implications
   fantasai: What's the benefit of having two properties? I see a lot of
             reasons to use content and /not/ two properties. I don't see
             the benefit of a new property.
   plinss: I like having separate properties because to me they are separate
           concepts
   glazou: Taking this discussion offline

   Vincent: Agreed that content selection was a UI issue, not mentioned in spec
   RESOLVED: Content selection is a UI issue, not in css3-regions

   Vincent: discussed whether event propagation model should be model,
            agreement that it should not be changed
   RESOLVED: No change to event propagation model due to regions

   Vincent: next one was to make section on DOM events model informative
   Vincent: I think that's a simple one

   Vincent: Next one was on CSSOM View
   Vincent: Confirmed that the current proposal was good
   Vincent: Agreed to add event on changes to regionOverflow and flowRanges
   No objections

   Vincent: I also had an action item to ...
   ACTION Vincent: Regions spec. editors to specify a model for breaking
                   flow content across areas that accounts for regions,
                   columns and pages. Build on paged media and propose behavior
                   for nested flows breaks.
   <trackbot> Created ACTION-330

Publishing Specs
----------------

   CSS Exclusions
   glazou: Going to have a call with Vincent on that on Friday
   Vincent: Since Alex will be editor, I'll sync up with him

   Topic: CSS3 Images
   fantasai: discussion on gradient keywords needs to either revert or settle

   glazou: please review the DOM ? Events linked from the wiki for next week

   Topic: CSS3 Ruby
   fantasai: basically, I think we should publish with those edits I mentioned
   fantasai's message:
     We really need to pull the css3-ruby spec from CR, so I was wondering if we could
     get a WG resolution to publish an updated WD providing that
       1. All of the marked edits are actually folded into the draft instead of marked
          as changes. (They're mostly editorial, obviously correct, and distract from
          the actual issues.)
       2. The 'bopomofo'/'right' value is renamed 'inter-character' per WG resolution
            http://www.w3.org/blog/CSS/2011/03/15/resolutions_152
     Then hopefully Richard can find the time to make these edits and push the updates
   Koji: Can we use display: none to make the old text go away?
   fantasai: Why would we do that? We should just update the text.
   RESOLVED: Publish update of CSS Ruby with changes mentioned above.

   glazou: Tab asked to publish CSS3 Lists, defer to next week

Charter
-------

   ChrisL: CSSWG and SVGWG charters talk about FX charter, but say
           different things
   ChrisL: We should make sure the charters align on the deliverables etc.
   ChrisL: SVGWG draft charter was published, and the SVGWG charter was extended
   ChrisL says something about a temporary charter extension
   ChrisL: So let's discuss the FX task force stuff soon

CSS3 Conditional Rules
----------------------

   dbaron: Close to FPWD, but not quite there yet
   dbaron: I discussed what it was at the F2F
   dbaron resummarizes
   <dbaron> http://dev.w3.org/csswg/css3-conditional/
   glazou: I've shown your document to a few web authors, and they are really excited

CSS3 Writing Modes
------------------

   fantasai: I would like to publish LCWD of CSS3 Writing Modes next week
             to get wider review, so if anyone has issues they want addressed
             before LC publication they should report them this week.
   ACTION everyone: Review css3-writing-modes and report any issues that
                    should be addressed before LC

Received on Wednesday, 15 June 2011 22:11:34 UTC