- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 08 Mar 2009 21:05:56 -0700
- 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 UTC