W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes Telecon 2012-11-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 14 Nov 2012 12:40:30 -0800
Message-ID: <50A401BE.2000707@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: Lea Verou as co-editor for Backgrounds 4
   - RESOLVED: Add Simon Sapin as co-editor for Paged Media 3
   - Discussed handling of low-priority specs
   - RESOLVED: Add stretch keywords to font shorthand
                 http://lists.w3.org/Archives/Public/www-style/2012Nov/0112.html
   - RESOLVED: Use the Editor's draft version of rules for font selection
               wrt glyphs within a family vs. particular font variant
                 http://lists.w3.org/Archives/Public/www-style/2012Nov/0114.html
   - RESOLVED: Change @font-feature-values syntax to use variant B in
                 http://lists.w3.org/Archives/Public/www-style/2012Sep/0507.html
               with @-sign in front of feature types per
                 http://lists.w3.org/Archives/Public/www-style/2012Oct/0279.html
   - Discussed February F2F logistics: aiming for Feb 5-7 in Tucson, AZ

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

Present:
   Glenn Adams (via IRC)
   Rossen Atanassov
   Tab Atkins (via IRC)
   David Baron
   Ryan Betts
   Bert Bos
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Molly Holzschlag (partial)
   Peter Linss
   Alexis Menard
   Edward O'Connor
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Lea Verou
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/11/14-css-irc
Agenda: http://www.w3.org/mid/50A3AB1D.4090002@disruptive-innovations.com
Scribe: Bert

Agenda
------

   Dirk: new props in compositing affect Backgrounds and borders
   Dirk: Can we move them, or should they stay in Compositing?
   Simon: Adding me as editor for page?
   dbaron: another thread about viewport units and @page rules

F2F Planning
------------

   glazou: I tried to ping molly.
   glazou: No response, so I'm concerned.
   glazou: Should we have a backup venue?
   glazou: She posted something on wiki, but it was subject to sponsoring.
   glazou: So no firm date and location.
   jdaggett: In bay area, than multiple companies can sponsor.
   florian: We considered japan ftf in winter earlier, but concern about
            AC in japan.
   <SimonSapin> +1 for keeping Japan in June
   sylvaing: May be difficult for some
   jdaggett: Jan/feb would be trickier for me [to sponsor in japan]
   jdaggett: prefer spring, but maybe can work on something.
   glazou: So let's look for spare location Bay Area in Feb.

Adding Editors
--------------

   Topic: Adding Lea as co-editor on css4-background
   fantasai: lea has some interest, filing issues on www-style
   fantasai: I thought why not have her co-edit with me.
   fantasai: Good way to get a bit of momentum, even if slow.
   fantasai: It remains a low-priority module, so no pressure on her to move fast.
   fantasai: And I can help Lea along.
   glazou: You mentioned you need ack from Doug?
   lea: Doug agrees.
   RESOLVED: Lea co-editor for Backgrounds 4

   Topic: Simon as co-editor  on css3-page
   Simon: Already started with fantasai's permission.
   Simon: Working on margin box layout algorithms. I'm discussion with
          Murakami-san from Antenna House
   glazou: Objections?

Prioritization / CSS3 Paged Media
---------------------------------

   florian: What was priority for this module? No objection in principle.
   fantasai: Critical for some implementations, but not for browsers.
   fantasai: Important to make progress.
   SteveZ: Counter-example: anything with layout seems important.
   SteveZ: It's part of the center of CSS.
   fantasai: But margin boxes don't interact with other layout models.
   SteveZ: But it should. Why not?
   florian: In any case we need to make progress on it.

   glazou: Is css3-page discussed at IDPF?
   fantasai: Not much, they're using something else.
   glazou: I guess it's important because of e-books.
   glazou: Objections to Simon as co-editor?
   Bert: On the contrary!

   dbaron: Browsers maybe not working on it, but may do so in the future.
   dbaron: May start to interact later, is a danger.
   dbaron: We've had that problem in the past.
   glazou: What does that mean? It should slow down?
   dbaron: Not necessarily. Don't assume it won't need any changes in the
           future once browsers start needing it.
   glazou: That doesn't seem acceptable.
   dbaron: There is a difference between listen and comment and implements;
           and then actually find problems.
   dbaron: We've had this in the past.
   florian: You say that going to PR with only implementations other than
            browsers is problematic?
   SteveZ: So dbaron says: if implemented in a product that doesn't have
           the whole technology stack of a browser, it may not be
           compatible with that stack.
   dbaron: And we have a set of priorities.
   dbaron: We can't comment on everything.
   dbaron: There is too much too comment on.
   glazou: We discussed at ftf. We have 60 docs, too much.
   glazou: Chairs are not dictators.
   glazou: We cannot say trash everything beyond the first 15.
   sylvaing: I don't disagree that it is difficult. But we should have that
             discussion before the poll.
   * jdaggett oh dear, someone brought up a meta-problem

   SteveZ: One way out is to suggest that we set comment deadlines on things.
   SteveZ Low priority items have deadline further in future.
   SteveZ: People like to continue working on things.
   SteveZ: dbaron says there are too many things to comment on. Agree.
   SteveZ: You have to keep working, but don't assume no comments means
           there aren't any.
   * fantasai szilles++
   glazou: We never move documents to next state without asking the members
           first.
   glazou: We have all the sensors to avoid implementations by non-browsrs
           only and to avoid browser problems in the future.
   <jdaggett> I think the conclusion here is that css3-page needs group
              discussion
   <jdaggett> I'm not sure more discussion is needed on this right now
   <krit> seems we left our agenda
   florian: Even if we don't work on a modules, people may come up with
            something and that may be worse. Lesser evil to work on it.
   <jdaggett> wrap... up... discussion...
   glazou: Important discussion, but let's do that later, maybe an hour.

Adding Editors (cont.)
----------------------

   glazou: so back to Simon as co-editor.
   RESOLVED: Simon is co-editor for css3-page.

CSS3 Fonts
----------

   jdaggett: I made a few changes.

   jdaggett: First is 'font-stretch'
   <glazou> http://lists.w3.org/Archives/Public/www-style/2012Nov/0112.html
   jdaggett: I put the keyowrds in the font shorthand.
   jdaggett: Parsing font family names makes this tricky.
   jdaggett: Font size thus always has to be there.
   jdaggett: Other keywords don't conflict.
   jdaggett: Is that Reasonable?
   <dbaron> looks good to me
   * fantasai too
   simon: I see no ambiguities.
   glazou: Me neither.
   RESOLVED: Add stretch keywords to font shorthand

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Nov/0114.html
   jdaggett: In prev WD I made it so that a font-family name existing on a
             system gathers all faces in the family.
   jdaggett: then you choose a specific face.
   jdaggett: All these params choose a specific face.
   jdaggett: Prev WD said look for each character.
   jdaggett: There are some subtle problems with some faces.
   jdaggett: Some lack support for a char.
   jdaggett: So I changed to match the face first and then check for the char.
   jdaggett: When you download, you don't know what's in the faces until
             you download them all.
   jdaggett: So this avoids downloading them all.
   jdaggett: Some font faces have e.g., arabic in normal, but not in italic
             face.
   jdaggett: Not common, but does occur.
   jdaggett: In that case you should fallback to regular face.
   jdaggett: I'd rather introduce exception like that than to have general rules.

   Bert: What exceptions?
   jdaggett: E.g., older Arial has arabic only in regular and not in italic.
   jdaggett: Browsers would automatically use the regular and synthesize the
             italic.
   jdaggett: They're exceptional cases and I'd like the spec to leave wiggle
             room for that.
   <glenn> I guess jdaggett means "synthesize oblique (and pretend its italic)"

   fantasai: Seems fine, but if UA is capable, what is the *better* behavior?
   fantasai: You said practical considerations.
   fantasai: Should we allow both behaviors?
   fantasai: Can UAs deal with them in different ways, take the cost?
   jdaggett: There are all these interactions. E.g., with downloadable fonts.
   jdaggett: Doing style matching for some cases and not for others.
   jdaggett: You may end up with wildly different style, if that is the
            font that has the glyph.
   jdaggett: Particularly on Windows.
   jdaggett: Windows has ways to fold different fonts into a family.
   jdaggett: Would rather stay away from it.
   jdaggett: Previous WD was just something I introduced.
   jdaggett:  I don't think it is better. Solves some cases.
   jdaggett:  Rather leave UAs some wiggle room than have a general rule.
   sylvaing: What's the impact on existing content?
   jdaggett: None.
   jdaggett: When I thought through what the previous rule meant for
             downloadable fonts I thought: no.
   RESOLVED: Wrt issue above: use the Editor's draft version.

   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Sep/0507.html
   <glazou> and http://lists.w3.org/Archives/Public/www-style/2012Oct/0279.html
   jdaggett: Next is syntax issue.
   jdaggett: @font-feature-values rule
   jdaggett: For features only in a certain font.
   jdaggett: What you need is mini-variable syntax, associate name with a
             selector value, only for a given font family.
   glazou: I agree with dbaron to prefer to @ sign.
   <dbaron> glazou said that he prefers Variation B, but with the @ sign

   jdaggett: Some concerns with that.
   jdaggett: With @-signs (variation A in the message) doesn't look like
             property name.
   jdaggett: I prefer that.
   jdaggett: Because it *doesn't* look like something that already exists.
   <SimonSapin> we have property-like descriptors in @font-face and @counter-style
   * glenn doesn't like @ syntax
   <oyvind> @keyframes already has "from" and "to"
   <oyvind> etc.
   <glenn> doesn't think it necessary to make it look different

   fantasai: Other thing is that the values cascade.
   fantasai: That is not clear in the A syntax.
   fantasai: In the B syntax tht is clear.
   jdaggett: It is not a cascade, just some override.
   fantasai: In some cases an @rule obliterates an earlier rule.
             In some cases they combine in some way.
   fantasai: Therefore in the first syntax, it's not clear how they interact.
   fantasai: In 2nd syntax it behaves just like it looks:
   fantasai: very much like selectors.
   fantasai: No specificity, but otherwise the same.
   glazou: We have font descriptors, they are not properties either.
   jdaggett: in @font-face, yes.
   fantasai: No pref either way.
   <glenn> every new sub-syntax requires additional cognitive load for users,
           negatives of which outweigh reuse of existing syntax
   dbaron: No strong pref for A or B, but if B, then with @-sign.
   jdaggett: So we go with B with @-sign?
   <stearns> no strong preference
   <glenn> strong pref against @ syntax
   jdaggett: I'd like A, but don't care that strongly.
   * fantasai has a stronger preference for B
   * leaverou strongly prefers B too
   glazou: readability, coherence with rest of CSS.
   glazou: Seems we have stronger pref for B overall.
   * leaverou B is more consistent with the rest of the language
   RESOLVED: syntax B with an @-sign.
   <glenn> can't we separate adopting 2nd syntax and using @-sign?


   <glenn> jdaggett: suggest you make CSSFontFaceRule in ED a 'partial'
           interface

F2F Planning (cont.)
--------------------

   <dbaron> http://wiki.csswg.org/planning/tucson-2013
   molly: You can follow progress on the wiki.
   molly: We had incredible support from city and from university of Tucson.
   molly: We've been offered a couple of locations.
   molly: We have the univ and the city fighting over who hosts us!
   molly: Constraints in Feb on dates.
   molly: Gem show, rodeo, etc.
   <SimonSapin> is 1 day later possible?
   <SimonSapin> because of fosdem

   molly: Challenge is finding the best political way between univ and city.
   molly: Biosphere 2 is just outside Tucson.
   molly: We have been offered it as a location, with private tour.
   molly: Including apartments with kitchens.
   molly: Beautiful out there.
   molly: We could do a hybrid: 1st day at Univ on sight.
   molly: Mayor wants to provide a welcome and a banquet.
   molly: So which to choose. In town, we would need multiple hotels.
   molly: Not very difficult, everything is around the university.
   molly: Facilities are good
   <jdaggett> i think the question is whether a sponsor is needed or not
   <jdaggett> i.e. a sponsor for the venue
   <dbaron> This sounds like we're going to end up spending a bunch of time
            listening to speeches in exchange for this sponsorship.

   glazou: Dates: some people asked for a day later.
   glazou: So start on Tuesday.
   molly: that would be fine.
   florian: I can't, anyway.
   Molly: Tuscon really wants to be a good host for us.
   molly: Biospehere would be a different model, but it is the Biospehre.
   molly: Can also do a day in town and take a shuttle the next day.
   molly: Money: you have to pay for you own travel and hotel nights.
   molly: But the facilities are donated.
   molly: I also want community involved. I'm looking for banquet sponsor, e.g.
   molly: we have funds coming in, form city, from local groups.
   molly: There has to be a formal photo op, etc.
   glazou: We can thank the city like we did in Lyon:
   glazou: We organize a Meet-up.
   Molly: excellent, I know where to do that.
   glazou: We present our work, my BluGriffon, Mozilla firefox, etc,

   SteveZ: Biosphere: I need to be back on Friday. If we're too far out of
           town, catching a flight on Thu may be difficult.
   Molly: there are shuttles. May have to leave an hour earlier.
   <dbaron> Biosphere looks like it's a 1 hour drive from the Tucson airport
            and a 2 hour drive from the Phoenix airport -- Phoenix may be a
            good option given the connections from it
   SteveZ: Early leaving is OK, as long as I can do it.
   molly: We need somebody to get you there. There is ample time, no stress.
          Not like CDG airport...
   molly: Would be helpful if people could put their needs, concerns on wiki.
   molly: Then I can respond.

   molly: Some kind of outreach event, as glazou suggested, would indeed
          be fabulous.
   molly: My brother is excited. Other people, too.
   molly: We can also do everything on Univ campus and just go visit the
          Biosphere.
   molly: But being there is awesome.
   <jdaggett> +1 for biosphere
   glazou: So one day in town and rest in Biospehereis possible?
   molly: yes.
   SteveZ: Meet-up might have to be *before* the CSS meeting then.
   molly: Another option is two days at Bio and 3rd day in town.
   glazou: People from abroad probabaly have to stay overnight anyway.
   molly: We just need to figure out the days we're in town.
   glazou: Can you deal with this input so far and report back asap?
   florian: Maybe a doodle for the dates?
   glazou: I think molly need firm dates.
   molly: Please, use the wiki. It's easiest for me. Put your dates there, too.
   molly: any special needs.
   glazou: So, if possible, try 5-7, if not possible keep 4-6.

Meeting closed.
Received on Wednesday, 14 November 2012 20:41:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT