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

[CSSWG] Minutes F2F 2009-06-04 Part II: vertical-align ambiguities, Paged Media

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Jun 2009 23:36:36 -0700
Message-ID: <4A388EF4.3080305@inkedblade.net>
To: www-style@w3.org
Vertical-align issue
--------------------

   Steve: I had an action item to come up with more testcases
   ACTION: Steve post testcase to www-style
   Steve loads his testcase into Safari, IE, and Firefox
   Steve: I've got Opera somewhere else...
   Steve: Basically the issue was, if I've got large things that are
          bottom and top aligned, where does the text show up?
   Steve: The arrow points up if it's top-aligned, down if it's bottom-aligned
   Steve: On all of these, they're the same but
   Steve: if I pick up Opera ...
   Steve: What we can tell is, if I have only one object that is top or
          bottom aligned, it makes a difference to these various things

   Testcase 1 shows TEST plus an arrow pointing up
   all browsers align the top of the text aligned to the top of the container
   Testcase 2 shows TEST plus an arrown down
   Safari, IE, and Firefox bottom-align TEST, but Opera top-aligns it
   Testcase 3 shows TEST plus an arrow up followed by an arrow down
   All but Firefox align TEST to the top; Firefox aligns it down
   Testcase 4 shows TEST plus an arrow down followed by an arrow up
   All but Opera align TEST to the bottom; Opera aligns it to the top
   Testcase 5 shows TEST plus a tall arrow up followed by a short arrow down
   TEST is aligned to the top in all but Firefox;
   Firefox shifts TEST down about 1em

   dbaron: It looks like Firefox, whenever it sees something bottom-aligned,
           it pushes the root so that it's bottom-aligned
   dbaron: But it does so only for the height of the things that are
           bottom-aligned
   dbaron: It's pushing the root down to match the bottom-aligned thing,
           assuming there are no top-aligned things

   Testcase 6 shows TEST plus a tall arrow down followed by a short arrow up
   All but Opera aligns to the bottom; Opera aligns to the top
   Testcase 7 shows TEST plus a short arrow up followed by a tall arrow down
   Safari aligns TEST about 1em above the bottom
   IE aligns TEST to the bottom
   Opera aligns TEST to the top
   Firefox aligns TEST to the bottom

   Steve: Opera always aligns to the top
   Steve: IE seems to be aligning to the biggest thing
   Steve: What Safari is doing here seems to be similar to what mozilla
          is doing, except the other way around

   Testcase 8 shows TEST plus a short arrow down followed by a tall arrow up
   Safari aligns TEST about 1em below the top
   IE aligns to the top
   Opera aligns to the top
   Firefox aligns TEST about 1em below the top

   General agreement that IE's behavior seems to make the most sense
   dbaron: So the largest wins, but if there are multiple the same size
           then the first one wins
   concern about randommness when things are close to the same size
   dbaron: You can get into that with fonts that are close to the same size,
           but may or may not be depending on what's available on the system
   ....
   dbaron: Basically these things are all subtrees, when you're using
           top/bottom alignment
   dbaron: non-top/bottom alignment are all linked up into subtrees
   dbaron: When you're doing top/bottom alignement, you're aligning the subtrees
   dbaron: Whichever subtree is tallest, that determines the height of the line
   (dbaron is addressing Alex's concern about whether alignment will affect
    line breaking)
   dbaron: By the time you do top/bottom align, you've already figured out
           the height of the line
   ...
   Steve: You could do what IE does and align to the biggest thing, and
          then if there are multiple always align to the top or always
          align to the bottom
   Steve: Instead of taking the first
   Steve: So the alignment doesn't depend on the order of items
   Bert: ...
   Steve: We had a discussion about where inline blocks should align
   Steve: We went and looked at a bunch of books
   Steve: at Tantek's
   Steve: went to a bookstore
   Steve: Came to the conclusion that the inline block should align its
          bottom line with the baseline
   Steve: I don't know if there's an equivalent thing here, to assume
          bottom.. would that match what designers would expect
   Bert: That might depend on the writing system. Here we might assume
         bottom, but in India not
   Steve: We could ask the design community, but I'm not sure how to
          express the question in a way that they'd understand
   Steve: But there's no obvious choice from what's implemented
   Steve: I think trying to avoid having order matter would be a better solution
   Alex: I'm not sure. You might have seven bottom aligned and one top aligned
   Alex: ...
   Steve: My main reason for concerning myself with ordering is that I suspect
          the behavior will appear to be more random if I take it into account
   * fantasai thinks we should just center it
   Steve: I'm willing to take an action item to write the rules if we can
          decide whether we want it order-specific or not
   Bert: If I'm mixing things,  I don't think I care.
   Alex: IE prefers order dependent alignment :)
   ...
   Steve: The default for images is to baseline-align
   dbaron: I'd like to keep order-dependence because we had three browsers
           that followed it
   correction, only two
   IE7 and below render like Opera
   <anne> yay for Opera!
   dbaron: Then let's do what IE7 and Opera do
   Steve: But it gives the wrong answer when you have one thing that's
          bottom-aligned
   <dbaron> http://lists.w3.org/Archives/Public/www-style/1999Mar/0121.html
   ACTION: Steve write proposals for both order-dependent and order-independent
           vertical-alignment

Paged Media: Paginating content into zero height pages or columns
-----------------------------------------------------------------
Scribe: Anne

   dbaron: don't
   fantasai: what do you do?
   alexmog: you have to avoid inifinite loops
   fantasai: we can say it's undefined
   Arron: don't render them
   fantasai: you need to know when it ends
   alexmog: every pagination engine i worked on forced one character on a page
   alexmog: it would have a boolean somewhere "I've put something on this page"
   alexmog: maybe a border, or some other continuation
   fantasai: if I have a 10px box and put it into 3 zero height columns
   fantasai: what do I get?
   alexmog: I don't think we should define it here
   alexmog: 1px could be considered process
   alexmog: could give up and continue to the next one
   alexmog: we could say that the user agent should make sure there's a finite
            number of pages

image-fit and image-position
----------------------------

   fantasai: SVG didn't like these property names
   fantasai: we have no suggestions
   fantasai: SVGWG wants to merge with preserveAspectRatio
   fantasai: best I came up with was content-fit
   dbaron: what's wrong with image-fit?
   fantasai: doesn't make sense what SVG would use it for
   fantasai: we called it image-fit to make it clear it does not apply
             to non replaced element
   dbaron: if you don't like a name please propose a better name
   ChrisL: I thought a name was proposed
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Mar/0134.html
   anne: that's actually a message from zcorpan and not from the SVG WG
   <shepazu> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
   dbaron: content doesn't sound like something that only applies to images
           or just replaced content
   <shepazu> http://www.w3.org/2009/03/16-svg-minutes.html#item06
   ChrisL: Opera has asked for a new property from CSS to which the SVG
           preserveAspectRatio attribute would match
   ChrisL: however that SVG feature applies to the whole document so
           naming need to take that into account
   dbaron: I prefer fit over content-fit
   SteveZ: the natural thing would be fit-replacement
   dbaron: we don't expose the term replace to authors and I'd like to
           keep it that way
   SteveZ: if that's what it applies to it seems natural to call it that
   ChrisL: with renaming it the values need to change [example not scribed]
   fantasai: people gave feedback that the new keywords are much clearer
   fantasai: these are fill, cover and contain
   SteveZ: how does that map to SVG?
   SteveZ: I think SVG has keywords for things map into a box
   dbaron: fill is the same as slice and cover is the same as meet or is
           it the other way around?
   <fantasai> various suggestions that came in: content-fit + content-position,
              fit-scaling + fit-position, object-fit or object-scale ...
   SteveZ: slice and meet both preserve aspect ratio?
   fantasai: cover is the same as slice, contain is the same as meet,
             and none is the same as fill
   <ChrisL> http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute
   <fantasai> The alignment parts of pAR are a separate property,
              currently called image-fit
   <fantasai> It takes all the value that background-position takes
   ChrisL: I think background-position covers all, yes
   [i.e. covers the same features as SVG]
   fantasai: we can go back to fit and fit-position
   anne: I'd support that
   fantasai: my main problem is that fit is not a shorthand
   anne: we could merge them; i.e. fit: <keyword> <background-position>
   fantasai: fit-position and fit-scale
   anne: why not make it a single property?
   fantasai: position doesn't need to be specified in a lot of cases?
   anne: could make it optional
   SteveZ: what about inheritance? typical reason for splitting properties
   fantasai: both are currently inherited
   dbaron: existing cases where we have a property that is a superstring
           of another is font-size and font-size-adjust, pitch and
           pitch-range and color-interpolation and color-interpolation-filters
   dbaron: plus fill-* and a bunch of stroke-*
   anne: in SVG it's a single attribute and it doesn't seem to be a problem there
   ChrisL: true
   fantasai: would be ok with me; HP prolly has an implementation but they
             are prolly ok with changing it
   <fantasai> Melinda checked with the print implementors before she left
   <dbaron> also speak and speak-*
   SteveZ: one example Melinda was using was generation of comtact sheets
   SteveZ: rather than taking every image I would like to able to put the
           fit piece into the body but separately set the position
   SteveZ: whether that's true or not I don't know
   fantasai: anne said that if we find out there's a reason to split them
             we can split them later
   SteveZ: you might not know what the keyword is
   SteveZ: I don't know; I just tend to distrust pulling things together
   anne: could have fit-type
   fantasai: fit-style!
   <dbaron> We could just have a fit. :-)
   [and there was much rejoicing]
   SteveZ: tentative resolution is to have one property called fit consisting
           of two components
   SOMEWHAT RESOLVED: have one property called fit that pulls together
                      image-fit and image-position

Forced vs. Natural Page Breaks
------------------------------

   difference between forced page breaks and natural page breaks
   howcome: you edited 9.4 which is currently projected
   howcome: I think rule 1 should be simpler
   howcome: that when a forced page break occurs margins are preserved
   howcome: and when natural page break occurs margins are set to zero
   howcome: I'm suggesting a principle where we also preserve margin-bottom
   howcome: it's a simpler principle
   fantasai: then you'd end up with a gap on the next page
   fantasai: e.g. when you have a 6em bottom margin and 3em space we don't
             want a new page
   fantasai: how about we say that the margin is truncated
   howcome: I don't really care but the principle is simpler
   dbaron: if there was a border or background on an ancestor then you
           can tell the difference
   dbaron: the question is how low the background and/or border of the
           parent has to go
   dbaron: if the border needs some sort of visual space you need some
           kind of padding
   howcome: I'm ok leaving this as is
   howcome: shouldn't forced page breaks be discussed in the next section

break-* properties
------------------

   fantasai: I can put those new properties in here
   howcome: that's all I wanted to know
   fantasai: the main concern is that implementations of this module have
             to implement the new names
   howcome: isn't that what we want?
   anne: you could say that some of the values are conditional on the
         multicol draft
   fantasai: multicol can define those
   howcome: fits better here
   howcome: that's it for me
   glazou: anything else?
   [silence]
Received on Wednesday, 17 June 2009 07:48:20 GMT

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