W3C home > Mailing lists > Public > www-style@w3.org > March 2013

[CSSWG] Minutes 2013-03-13

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 Mar 2013 21:03:13 -0700
Message-ID: <51429D81.8030802@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Discussed WDs that were published but not announced.
   - RESOLVED: Add Simon Pieters as editor to CSSOM, CSSOM-View
   - RESOLVED: September F2F is 9-11 in France, either Sophia or Paris
   - RESOLVED: Reset min-width/min-height to zero for Flex Items
   - RESOLVED: Call the page box's containing block a page container
   - Discussed cycle formed by :root { font-size: 1vw } @page { width: 50em }
     and what to do to break it.
   - Florian queried for interest in addressing Device Adaptation issues

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

Present:
   Glenn Adams
   Rossen Atanassov
   David Baron
   Bert Bos
   Tantek Çelik
   Jim Dovey
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   Dael Jackson
   John Jansen
   Brad Kemper
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Nick Van den Bleeken
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2013/03/13-css-irc
<glazou> http://lockerz.com/s/286935518
Scribe: fantasai

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

   glazou: Sorry for sending agenda really late. Blocked by snowstorm in Paris.
   glazou: So agenda is somewhat random.
   glazou: Please, if any other items, say so

Outstanding Publications and Announcements
------------------------------------------

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0284.html
   glazou: First on agenda is wrt specs that are WDs moving along REC track
   glazou: "Outstanding Publications"
   fantasai: [summarizes email]

   krit: Does the announcement need to be on a blog post?
   glazou: IIRC we resolved on that a year and a half ago
   glazou: One of the editors should write a blog post on the CSSWG blog
   glazou: and post on twitter wrt updated WD/etc.
   SimonSapin: How do you publish on the blog?
   glazou: WordPress with W3C credentials
   glazou: If you can't log in, ask Coralie Mercier
   http://wiki.csswg.org/spec/publish
   <Bert> (Or ask me, but in principle all WG members have write access
           to the blog automatically.)
   fantasai: The idea is to post to www-style/blog to let people know that
             there's an update, and to say what's changed/what you'd like
             feedback on especially.

   fantasai: On topic of publications, has telecon for css3-conditional
             CR been scheduled?
   Bert: Working on that today.

Editorship
----------

   glazou: Next item, adding Simon Pieters to CSSOM
   glenn: Shane hasn't been able to contribute
   glenn: I suggest that Simon could take over primary editorship on
          CSSOM-View spec
   glenn: and could assist with CSSOM as well, depending how much energy
          he can put in, can make more progress
   RESOLVED: Add Simon Pieters as editor to CSSOM, CSSOM-View
   <SimonSapin> Simon Pieters is sometimes zcorpan on IRC


September F2F
-------------

   SteveZ: The website currently lists week of Sept 9-13
   SteveZ: Those are fine with me, but have a conflicting meeting the next
           week, was hoping to lock down dates for that week
   glazou: I have PM from Peter, he's fine with 9-13 but would prefer
           beginning of the week
   SteveZ: Fine with me

   SteveZ: 2nd question is where. Talking about France
   SteveZ: Document conference in Florence 10-13
   SteveZ: Hard to do both in same week
   glazou: Unfortunately missing members in the room at this time
   SteveZ: Don't know who was planning to go to that conference.
   Bert: I added that to the calendar, in case ppl were interested in sharing.
   Bert: ACM Document Engineering: layout, process, etc.
   Bert: Very interesting
   [discussion on conference scheduling]
   Bert: Don't think there will be a lot of overlap, but might be interesting.
         Not important enough to reschedule our own meeting.
   glazou: So let's say for time being 9-10. Where?
   fantasai: Paris and Zurich were volunteered
   SteveZ: And Sophia
   <tantek> for Paris we were considering Mozilla hosting
   dbaron: New Mozilla office in Paris opens soon, but not open yet.
           Might be easier to assess once it's open
   <tantek> Paris Mozilla office should be open by start of next month
   glazou: Everyone ok with 9-11 Sept in France?
   RESOLVED: September F2F is 9-11 in France, either Sophia or Paris

   <florian> I won't know my availability then for quite a while, so I
             can't comment either way
   <tantek> glazou - I have a meeting in the 8th in the UK
   <tantek> would F2F 10-12 be ok?
   <dbaron> I think there was also an offer from Google to host in Zürich
   glazou: (to tantek) Take the EuroStar. No problem.
   <tantek> ok

Flexbox
-------

   glazou: agenda item wrt Flexbox
   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0296.html
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/0364.html
   glazou: wrt reverting Flexbox to use zero as min-width
   glazou: Has anyone reviewed the proposal?
   dbaron: Fine with it
   Rossen: Yes, agreed
   glazou: Other opinions?
   Anton: Why did we add it in the first place
   dbaron: What we lose by changing it, we get back when we add min-content
           and other keywords for heights
   dbaron: Temporary loss, ability to have flexbox that doesn't go down
           below its intrinsic size
   <dbaron> get it back with the min-content etc. keywords
   fantasai: We were triggering it by default because shrinking by default.
   fantasai: Thought it was good to have a minimum for some common cases
             like toolbars.
   Rossen: once we have min-content, then all other keywords, we get
           everything back.
   fantasai: The problem with having it by default is that nested flexboxes
             get complicated and hard to author.
   glazou: Any objections to the proposal?
   RESOLVED: Reset min-width/min-height to zero for Flex Items
   fantasai notes that MSFT's implementation does min-content by default,
            so app authors would have to be aware of that change.
   Rossen: When evaluated internally, thought it was fine to explicitly
           request min-content.

CSS3 Paged Media
----------------

   <glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0219.html
   <fantasai> I think I dreamed that I replied to that...
   SimonSapin explains his email
   fantasai: I think actually that we should keep "page box" as the name
             of the box into which the content is flowed

   SimonSapin: Do we change how MQ work?
   fantasai: There's an open issue on that anyway
   SimonSapin: They're based on outer width of page box
   fantasai: And just need a new term for size given by size property
   SimonSapin: Also might want page-margin boxes to be siblings of page box.
   <BradK> I agree with Simon
   SimonSapin: Would help explain stacking
   fantasai: Wouldn't explain inheritance though.

   fantasai: For the other size... maybe "initial page size"? like
             "initial containing block".
   fantasai: "page base size" or "page basis"
   SimonSapin: But MQ refers to...
   fantasai: We can always update MQ to fix terminology. That's just editorial.

   SimonSapin: Is group ok with making page box sibling of margin boxes?
   fantasai: Don't think it matters how you explain it, as long as behavior
             doesn't change.
   antonp: Think it makes sense.
   <BradK> I like it as sibling

   <BradK> Content-box
   <fantasai> "page container"
   <SimonSapin> page-content box
   <fantasai> no, that would be the content box of the page box
   * fantasai thinks this isn't important to resolve, it's just editorial
   * antonp agrees with fantasai
   RESOLVED: Call the page box's containing block a page container

   SimonSapin: If we have time, could discuss interaction of @page and MQ
   glazou: Might have time today
   glazou: Liam's not on the call, so yes we have time

   SimonSapin: we have an open issue a long time
   SimonSapin: How do viewport units interact with @page
   SimonSapin: ...
   SimonSapin: We discussed @viewport
   SimonSapin: Which changes the default page size, and then applies MQ
   SimonSapin: and affects viewport units
   fantasai: I think for viewport units in these contexts, it makes sense
             to either make them invalid, or have them refer to the default
             page size, like fonts refer to default page size

   <SimonSapin> :root { font-size: 1vw } @page { width: 50em }
   SimonSapin: @page inherits from root element now
   fantasai: This is so that if you set fonts on your document, your margin
             boxes get the same font.
   SimonSapin: So where do we break this cycle?
   SimonSapin: (without breaking some use case)
   SimonSapin: Maybe one way to do that is like @viewport, make a first
               pass applying @page rules
   SimonSapin: viewport units are based on some default
   SimonSapin: Then we have base page size, whatever the name,
   SimonSapin: which is used for MQ when we apply everything again
   SimonSapin: It works nicely with @viewport
   SimonSapin: But for @page rules it's more complicated because we
               generate pages
   SimonSapin: Could get weird cases which don't make sense.
   florian: In general support the idea, but don't know enough about page
            generation
   fantasai: [explains named pages and how, e.g. name of first page can
              depend on 'page' property of first heading in document]
   fantasai: I would be in favor of breaking this cycle earlier somehow
   * glazou +1
   Florian: Need a non-crazy behavior, don't need to go further than that.
   <florian> when all the pages are the same size, do the obvious, when
             not, do something non crazy.

   fantasai: Simon's example there shows two very common use cases
   fantasai: First one is commonly used for slides, or anything else you
             want font size to grow with size of page
   fantasai: Second case is used in Japanese documents, where you want
             the page size to be an exact multiple of the size of the
             main paragraph font.
   florian: Do you want the page size based on the character, or the
            character size based on the page?
   fantasai: The former. You pick a comfortable font size and lay out
             around that.
   koji: Yeah
   fantasai: So we want both of those to work, but don't want them to
             make a cycle.
   <SimonSapin> @page { size: A4; margin: 4em; /* width: auto */ }

   SimonSapin: One option is to have the @page context not inherit from
               the root
   SimonSapin: That does break some use cases, but easiest to work around.
   SimonSapin: Just means that you have to copy your font declarations
               into an @page rule.
   glazou: Maybe the only way we can compromise without adding too much
           overhead.
   * fantasai wonders what AH does
   SimonSapin: Also 'direction' and 'writing-mode' properties can be relevant
   SimonSapin: they determine which is the first page: left or right
   SimonSapin: Another reason it's nice to have inheritance from the root
               element
   florian: I'm wondering if the first page really matters. Whichever
            page it is, all going to be the same. If they're going to be
            different can't be perfect anyway
   * fantasai notes that Japanese documents commonly use multiple sizes
              in the same book. Same margin box size, different page
              content areas

   SimonSapin: So, we don't need to decide anything today about this,
               but please think about it and discuss on mailing list.
   florian: do we have a few concrete options? Or just vague problem area
            where we need ideas.
   SimonSapin: So one proposal is to do like @viewport, do two passes.
   SimonSapin: Other option is to not inherit from the root element.
   fantasai: Whatever we do here should be consistent with @viewport
   fantasai: So my criteria are
               a) break the cycle
               b) don't break use cases, even if some are less convenient
               c) keep @page and @viewport consistent
   florian: Agree with fantasai's statement. Not sure I understand all
            the implications of that.
   <SimonSapin> if we go with not inherit from the root
   glazou: Not sure we're going to close this now
   glazou: Maybe up to you to make a proposal based on discussion we had
           today
   <fantasai> http://wiki.csswg.org/topics
   SimonSapin: I will write up various options by email

Device Adaptation Status
------------------------

   glazou: Anything else?
   florian: Several things on device-adapation spec. Would be nice to tackle,
            but would like to hear from rest of group.
   florian: Think MS has partial implementation. Others?
   florian: Agree with Hċkon most of what was proposed
   glazou: Since you're not working for Opera... is Opera still working on
           this?
   florian: I have don't know what they're doing
   florian: I would guess they'll try to port this to WebKit
   florian: Rune has sent a bunch of mails about this after the announcement,
            so maybe still working on it. Pure speculation.
   glazou: We have 3 editors
   glazou: 3 issues in tracker.
   glazou: Let me ping the editors
   florian: I think at some point I was supposed to co-edit this as well
   florian: Tracked issues are fewer than the mailing list
   glazou: Ok, I will ping the editors and you
   glazou: anything else?

Meeting closed.
Received on Friday, 15 March 2013 04:03:42 GMT

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