- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Jun 2009 23:36:36 -0700
- 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 UTC