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

[CSSWG] Minutes and Resolutions Tokyo F2F Wed AM: Media Queries, Paged Media and Kihon Hanmen

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 08 Mar 2009 21:05:56 -0700
Message-ID: <49B495A4.9000607@inkedblade.net>
To: www-style@w3.org
Summary:

   - RESOLVED: Keep aspect-ratio and device-aspect-ratio in Media Queries,
               no changes to syntax

   - RESOLVED: To fix malformed grammar in Media Queries, anne can choose
               to either define a grammar for MQ or resolve the differences
               with the global grammar

   - Discussion of Kihon Hanmen and what it means (seek "kihon hanmen" below)
   - RESOLVED: 'width' and 'height' apply to the page box, follow rules in
               CSS2.1:10 wrt calculating margins. This behavior is at-risk.
     RATIONALE: Japanese layout requires setting the page area size, then
                using auto margins to position the box on the paper

   - RESOLVED: @page inherits from the root. B/c this was not defined in
               previous CR, conformant implementations may instead use the
               initial value

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

Attendees:
   David Baron
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Chris Lilley
   Håkon Wium Lie
   Anne van Kesteren
   Shinyu Murakami
   Mike Smith
   Steve Zilles

Agenda: http://www.w3.org/Style/Group/2009/Tokyo.html
Meeting: Cascading Style Sheets (CSS) Working Group F2F
Date: 03 March 2009

<RRSAgent> logging to http://www.w3.org/2009/03/04-css-irc

Scribe: Håkon

Media Queries
-------------

   Chris: specific MQ issues?
   Anne: several comments have been made
   Anne: Dean Jackson has proposed changes in aspect-ratio syntax
   <ChrisL> Dan Jackson asked for syntax changes in some queries
   <anne> http://lists.w3.org/Archives/Public/www-style/2008Dec/0019.html
   <anne> http://lists.w3.org/Archives/Public/www-style/2008Oct/0328.html
   howcome: aren't we dropping these
   Anne: they're marked at risk
   Anne: I would be fine dropping the features at risk, and keep orientation
         unchanged
   Anne: the use case for degrees is to have a DOM interface to the orientation
   <ChrisL> portrait or landscape is much more useful
   Steve: is there a square pixel issue involved?
   dbaron: Firefox 3.1 supports aspect-ratio
   Chris: If you're using it for games and things, then you also want to know
          the tilt, the acceleration, etc. Just make another API
   Steve: In that case you'd want landscape/portrait in addition to the orientation angle
   dbaron: the use case for device-* is weak
   dbaron: but we implement both aspect-ratio and device-aspect-ratio
   <ChrisL> I could see a stylesheet that gave 4 columns for a 16:9 landscape
            and 3 for 4:3
   fantasai: one use case is having more columns if the display is wide
   anne: in that case you care about the width
   fantasai: Not if you're doing a presentation that scales to fill the space
   Steve: if I have several images, I could select the right one to fill the
          sceen
   Steve: I thought we went through this in great detail, why are we discussing
          this?
   Anne: apple has proposed a syntax change
   dbaron: given that we support exact matching, we should stick to our
           current syntax
   <ChrisL> yes, trying to match on a float is liable to error
   howcome is skeptical that aspect-ratio is useful
   anne: *device*-aspect-ratio would be useful for videos too
   fantasai: you can use it to select a different video, widescreen vs
             fullscreen
   fantasai: Media queries are used for more than just CSS
   Chris: Mozilla and Opera both implement it
   <ChrisL> common industry use is ratio - 16:9, 16:10, 4:3 not 1.623
   <ChrisL> so we have implementations in firefox, opera and webkit
   RESOLVED: Keep aspect-ratio and device-aspect-ratio, no changes to syntax

   chrisl: any other comments?
   annevk: some editoral comments, some comments on tty
   annevk: we don't clarify what px unit means for tty devices
   annevk: that clarification should possibly go into the Values and Units draft
   <ChrisL> there was one about malformed queries
   <ChrisL> http://lists.w3.org/Archives/Public/www-style/2008Dec/0064.html
   chrisl: is there as disposition of comments?
   annevk: I can add the new issues to the previous disposition of comments
   dbaron: what's the issue with the formal grammar
   <anne> http://www.w3.org/mid/Pine.LNX.4.63.0902242324240.6949@master.abisoft.spb.ru
   howcome: so, it seems we currently can't take all grammars in all CSS specs,
            concatinate them and have something valid comes out
   steve: the formal grammar is only a hint
   jdaggett: there are things that cannot easily be expressed in formal grammars
   Steve: do we say anywhere what the goal of the formal grammars are?
   howcome: HTML5 writes it out in prose
   Mike: by design
   <ChrisL> The spec could state that, due to grammar overrides in the prose,
            the grammar is not sufficient by itself for creating a parser
   <ChrisL> The snapshots could collect together the 2.1 grammar plus the
            patches defined in each module, to give a consistent grammar
   annevk: i agree with the comment that the css grammar is rather hacky
   dbaron: if we think this is important, somebody should sit down and think
           about it
   fantasai: the grammar could be described in a snapshot
   annevk: the alternative is for MQ to define its own grammar, like the CSS
           selectors spec
   Steve: there are selveral pieces to this: all the bits are not meant to go
          into a grammar generator
   Steve: the productions for one specific module is prefixed with an
          identifier specific to the module; if a production is intended
          to replace an existing one, this will be marked
   fantasai: anne can either define a grammar for MQ or resolve the differences
             with the global grammar.
   chrisl: somebody has to sit down and propose a solution
   RESOLVED: anne can choose to either define a grammar for MQ or resolve the
             differences with the global grammar

Namespaces
----------

   <fantasai> I don't think we have anything to discuss with namespaces, just
              need implementation reports
   <fantasai> The test suite went through a very meticulous review process and
              has already been published.

Paged Media
-----------

Scribe: fantasai

   <shinyu> http://lists.w3.org/Archives/Public/www-style/2009Mar/0005.html
   So, its not possible to select the initial containing block and set its size
   (and then set the margins to be auto)
   fantasai: can set the document root element to be a fixed width
<network problems, minuting offline>
   Discussion of kihon hanmen and Japanese layout.
   fantasai summarizes what is meant by "kihon hanmen".
   It refers to three things:
     1. The box that is the equivalent of the page area,
       i.e. the box in which the content is laid out on
       the page.
     2. The settings used to arrive at the size of this
       box, namely:
         - font-size
         - number of columns per page
         - column gap
         - width of column
         - line gap
         - number of lines per page
     3. The grid formed by those settings ...
   Murakami-san writes:
     @page {
       margin: auto;
       width: 40em;
       height: calc(20*16pt);
       font-size: 10pt;
       line-height: 16pt;
     }
   Murakam-san explains that in Japanese layout, you start
   with the kihon hanmen, and then center it within the page,
   or specify one side of the margin and let the other margin
   be auto. Suggests a unit for line-height would be useful.
   fantasai suggests that allowing @page to accept width and
   height should be sufficient. The author (or authoring tool)
   may have to do so some math to get the width and height of
   the kihon hanmen from the settings, but then the margin
   auto positioning should work.

   dbaron suggests the rem unit might be useful here

   Discussion of whether font-size and line-height in @page
   should affect the root element. No, it should not.

   Should @page inherit from the root element?
   Murakami-san writes column-count, writing-mode, and column-width
   into the @page rule. Discussion of page-based templates.

   Chris: So the bit of consensus that I heard was that 'width' and 'height'
          can be used on @page
   Steve: Also inheritance is as before, the :root element is the top of the
          inheritance chain and does not inherit from anything else

   Discussion of copying values between @page and :root
   fantasai does not want inheritance from @page to :root, because that does
     not happen for other media.
   fantasai suggests inheritance from :root to @page

   Lots of discussion about page templates and getting @page templates to match
     up with elements in the tree
   e.g. an Appendix template that matches up with <div class="appendix">

   Proposed resolutions:
   1. Apply width and height to the page box, following rules in CSS2.1:10 wrt
      calculating margins
   2. @page inherits from the root
   3. Synchronization of property values between named page templates and
      content deferred until later
   fantasai explains that because the print industry is relying on css3-page
     for their own standards, we may need to add loopholes that allow
     implementations to be conformant if they don't do the above
   RESOLVED: 'width' and 'height' apply to the page box, follow rules in
             CSS2.1:10 wrt calculating margins. This behavior is at-risk.
   RESOLVED: @page inherits from the root. B/c this was not defined in previous
             CR, conformant implementations may instead use the initial value
   Murakami-san shows an example where different parts of the document have
     different kihon-hanmen
   fantasai writes up an example that uses just the new 'width' resolution and
     named pages to accomplish this use case
   Steve suggests adding fantasai's example to the spec
   Example is:
   <html>
     <style>
   .main { page: main; columns: 2; column-gap: 1em; }
           /* 2*30ch width +gap = 61em; */
   .index { page: index; columns: 3; column-gap: 1em; }
            /* 3*20ch width + gap = 62em; */
   @page { margin: auto; }
   @page main { width: 61em; }
   @page index { with: 62em; }
   </style>
   <div class="main"> ... </div>
   <div class="index"> ... </div>
   </html>
   ACTION: fantasai add this example to the spec

<br type="lunch"/>
Received on Monday, 9 March 2009 04:06:38 GMT

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