- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Nov 2008 19:49:23 -0800
- To: www-style@w3.org
* RRSAgent See http://www.w3.org/2008/10/21-css-irc#T07-28-48
<sylvaing> ScribeNick: sylvaing
CSS2.1 Z-Index Issue
--------------------
<glazou> Topic is z-index in lev2
<glazou> http://wiki.csswg.org/spec/css2.1#issue-60
<glazou> http://dev.moonhenge.net/css21/spec/z-index/
(second URL describes z-index issues)
Hixie: document appears to be a large number of editorial changes;
propose to reject on basis of too many changes; also one
typo + one misunderstanding
Hixie: bottom line, one "'s" should be removed....
Hixie: emailed author to suggest he sends testcase(s) to highlight
actual issues
dbaron: a float can be relatively positioned so 2.10 may be relevant
<dbaron> We could add "non-positioned" in (3) (4) and (5) in the 7-point
list in 9.9.1
<dbaron> and of course change "float's parent's stacking context" to
"float's parent stacking context"
<Hixie> right
<dbaron> in 9.5
plinss: i wonder if there is value in making the editorial changes in a
future revision
glazou: hixie, do you think we should take the changes ?
hixie: changes are always normatively risky
plinss: not sure there is css3 module where this change could be made
plinss: not rejecting comments, but should reject them for CSS21 edits
RESOLVED: two Appendix editorial changes accepted; no CSS21 updates;
Hixie to email proposal author
<arron_> Hixie, Please remind the proposal author to create test cases.
<Hixie> arron_: did that in my first e-mail
Text Layout/Direction module
----------------------------
<glazou> http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0020.html
bert: we need to place this module on the roadmap
fantasai wonders if it needs to be split up
alexmog points out dependency between box model and direction
fantasai, alexmog, bert: line grid will move out of text layout to a
separate module
bert: does name of module remain text layout ?
fantasai: yes, that makes sense
alexmog: deadline to make this happen ?
fantasai, bert, alexmog : first public working draft by end of year
RESOLVED: FPWD of text layout module end of year, alexmog/salonir/fantasai
editors; line grid module moves to new editor's draft
glazou: priority of text layout ?
RESOLVED: goal is CR during charter period
glazou: topic is closed
glazou: we are left with paged media issues we need to address in the
afternoon so melinda can attend
glazou: next topic is attribute selection
glazou: this is about selecting the empty string with an attribute selector
glazou: previous f2f said that the following matches nothing : P[foo$=""]
glazou: but P:not(foo$="") matches everything
glazou: potential for browser hack
glazou: this is true for all attribute selectors; regular = is fine
glazou: this should be invalid
dbaron: I'm not sure this is a good reason to make this invalid
(good reason being second selector was not sensical)
glazou: this is because the empty string is always a substring of any
non-empty string
dbaron, fantasai, glazou discuss previous decisions on the matter and
mozilla changes
glazou proposes that $="", *="" and ^="" never match
<dbaron> FWIW, I said that I thought the discussion was a waste of time --
we were one tiny mozilla change and one tiny spec clarification
away from complete interop, and then we changed the spec to
something drastically different, and now we're discussing changing
it to something else drastically different. I'd prefer whatever
solution ends the discussion the fastest and closes it for sure.
<fantasai> dbaron, what would be the one tiny spec clarification for interop?
<dbaron> fantasai, it would have been saying *="" always matched when the
attribute was present
<fantasai> what about the others?
<dbaron> fantasai, I think it was already clear for the others.
<fantasai> $=?
<fantasai> ~=?
<dbaron> ~= is entirely separate; I think it was clear for $= and ^=
sylvaing, plinss, glazou: empty string could only match an attribute value
set to the empty string
fantasai: today, we have interop between slightly older versions of firefox,
opera and safari
<fantasai> although iirc safari did something weird on one of the cases
<glazou> http://www.disruptive-innovations.com/zoo/css3tests/selectorTest.html#target
glazou: no decision since no consensus
plinss: what do we need to do to come to a decision ?
glazou: we need to test current implementations
alexmog, plinss: we are not far from a decision since no one is opposed to
either decision
plinss: we have consensus that no one has a clue
<fantasai> data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html
lang%3D"en">%0D%0A <head>%0D%0A <title>Test<%2Ftitle>%0D%0A <style type%3D"text%2Fcss">%0D%0A p[title~%3D""] {
text-decoration%3A underline%3B }%0D%0A p[title*%3D""] { color%3A orange%3B }%0D%0A p%3Anot([title~%3D""]) {
border%3A solid blue%3B }%0D%0A p%3Anot([title*%3D""]) { background%3A yellow%3B }%0D%0A <%2Fstyle>%0D%0A
<%2Fhead>%0D%0A <body>%0D%0A <p title%3D"foo">title%3D'foo'%0D%0A <p title%3D"">title%3D''%0D%0A <p>no title%0D%0A
<%2Fbody>%0D%0A<%2Fhtml>%0D%0A
<fantasai> http://tinyurl.com/5qluy2
dbaron: the test does not capture the change made in firefox 3 so not
conclusive
fantasai: logic of the change was that there was interop on ~= so we
made everything else work based on tilde's semantics
dbaron: but it looks like we did not interop on tilde...
<dbaron> (because Safari behaved differently for ~=)
<fantasai> http://pastebin.mozilla.org/558307
no decision on this topic
<fantasai> Alex, peter, and fantasai are looking at the test case results
for FF3, FF trunk, Safari, and Opera and seeing no interop.
But at least FF trunk's behavior is predictable
Variables/Constants
-------------------
fantasai presents CSS variables/constants counter-proposal
<fantasai> http://fantasai.inkedblade.net/style/specs/constants/
the counter-proposal defines parse-time constants
for example, one can separate the layout from the colors across site
pages e.g. a site like launchpad.net
fantasai reviews implementation constraints
fantasai: three type of constants: value constants, styleset constants
and selector constants
defined with @define block
fantasai reviews examples
fantasai: selector constant must be a valid selector but cannot
use comma-separated grouping syntax since the constant may
be part of a selector
fantasai discusses scoping; declarations in-scope from point of declaration
until overriden; not changed, just overriden
fantasai: constants do not cross @import boundaries without a special
@import keyword
discussion of scoping and asynchronous stylesheet parsing
@import keywords are pull, push and sync
glazou: why not allow two keywords so "@import push pull" equivalent to
"@import sync" ?
alexmog: do other languages have this ability to control scope ?
jdaggett_: don't compound docs have this ?
fantasai: I picked a constant expansion character, no personal preference
glazou: if an expanded selector constant is invalid what happens ?
fantasai: if the constant hasn't been declared, it doesn't get expanded;
in this case, the selector is invalid
jdagett: why we need selector constants ?
glazou, plinss: users ask for it
jdaggett: use-case ?
glazou, plinss, fantasai: complex selectors e.g. styling content nested
inside a cell
glazou: I understand why one may prefer immutable constants to variables
but these need to be accessible through CSSOM so the stylesheet
can be re-serialized as it was authored
glazou: you especially want to preserve the rule when the constant turns
out to be invalid
alexmog, fantasai, plinss: you have this problem with invalid CSS anyway
plinss: and comments, etc.
glazou: in an editor manipulating stylesheets, you need to preserve the
@define blocks
glazou: I must be able to edit the @define rule in an editor but how do
I do that if it's gone at parse time ?
glazou: not sure pull/push/sync are useful
dbaron, plinss: for constants, it would make sense for the first constant
definition to 'win'
<dbaron> or would at least solve the problem of (1) define constant C
(2) rule using constant C (3) redefine constant C
(4) use CSSOM to manipulate rule in (2) to use constant C
differently
howcome: don't use the $ sign because the dollar is so weak these days
<dbaron> (discusion of $ or € :-)
fantasai: processing model is parse time, after tokenization
alexmog questions the priority of selector constants
glazou: values is the #1 use-case but selector is also a common request
glazou: making them global means you'd have to parse everything (even
two passes ?)
fantasai reviews name-value table handling depending on @import statement
<dbaron> It seems like this isn't significantly simpler.
fantasai reviews an example in the document
alexmog: first one wins would make global scope confusing as a local
definition could be ignored due to one you cannot see
* Bert is reminded of Gnu make.... how many kinds of assignments can you
come up with?
hakkon: I don't want to have things changing after parse time
glazou: making it parse time only makes it unusable in an editor since I
do not even know there are constants in your stylesheets
hakkon: you'd have to reimplement a parser
* Bert wonders if IDEs for C also rely on the C DOM to edit C files.
(Sorry, that's mean.)
<fantasai> background: #FFDDDD;
<fantasai> background: rgba(100%, 0, 0, 0.5);
<fantasai> background: url(image1.png), url(image2.png);
<fantasai> your editor will only see the middle declaration, the other
two will get lost
<fantasai> the problem with information getting lost in the CSSOM already
exists
howcome: I think it would be a reasonable extention to the CSSOM to allow
access to the strings
howcome: I've got very strong feedback from my developers that they want
this at parse time only
plinss: shouldn't a style attribute be able to refer to a constant ?
glazou: I understand perfectly the users side of this
glazou: but it still seems very hard for implementors
fantasai: there are also use-cases that are not covered
<fantasai> by the variables proposal
fantasai: spec is currently too technical to be presented; it needs examples
and use-cases for a web author audience
dbaron: both proposals - variables and constants - seem like a lot of work
plinss: which one do you prefer ? opera favors a parse-time solution. would
you agree ?
glazou: parse-time solutions are browser-only; harmful to editing tools
plinss: would distinction between parse-time vs. runtime affect your decision?
dbaron: I don't think so
alexmog: agree it's not parse vs. runtime but completeness of the solution.
alexmog: parse-time only is different from everything else we have;
especially one without an object model.
glazou: this is a pragmatic position : do not restrict the feature for
the user, it's an implementor issue
dbaron: the relative priority of this also has to be taken into
consideration; the cost is similar to cal() but I think calc is
higher priority
howcome: this is simple. we shouldn't have an object model
dbaron: i worry about solutions of this kind since we'll have to come
back and change it later
* glazou STRONGLY disagrees with howcome here
dbaron worries about loading consideration (sync cost)
* glazou thinks howcome again thinks browser-only, a W3C disease that
has been plaguing W3C for more than ten years
plinss: other feedback is that if they're defined inside an @media block
they shouldn't propagate outside
fantasai: but i might to have different declarations per media but the
same value
<plinss__> http://www.webmonkey.com/blog/What_s_On_Your_CSS_Wishlist_
<plinss__> <br type="lunch">
Background Shorthand
--------------------
<fantasai> Bert, I can think of two options for the background shorthand:
dropping the slash in background-color (since it's not strictly
necessary, it's there only for clarification)
<fantasai> Bert, or requiring that the non-fallback color be specified in
the shorthand and forbidding background-size from appearing
immediately after the color
<Bert> So in either case, the non-fallback color becomes required.
<fantasai> hm, yeah
* fantasai doesn't have any other brilliant ideas, maybe someone else does
<Bert> It's not necessarily a problem. You may have to use 'transparent'
a bit more often.
<Bert> Dbaron's issue with 2-token look-ahead would only go away if the
slash is removed, so fantasai's first option seems best.
<Bert> Peter is OK with that, he says.
<fantasai> my only concern is readability/understandability of the style
sheet
<fantasai> other than that there is no strong reason for the /
* dbaron wonders if fantasai is in JLTF
* fantasai yes
<plinss__> Having two colors is no less understandable than having a slash
IMO, when I first see the slash I have to wonder what it's for
<plinss__> I actually think it would be more understandable to have the
fallback color as a separate property
<fantasai> no, you really really want it to be reset together with
background-color
<fantasai> imagine I set background-color: transparent;
background-fallback: red;
<fantasai> then later in the cascade I have background-color: white;
<fantasai> That background-color: white must reset the fallback as well
<fantasai> otherwise I get background-color: white; background-fallback: red;
<fantasai> which is totally not what anyone is expecting
<plinss__> ok
<plinss__> although whether or not the later specification of
background-color may still not be seen can still
depend on whether the background-image loads or not.
Does it perhaps make sense to associate the fallback
color with the image rather than the background-color?
<plinss__> if the later rule really wanted a white background,
you'd have to set the background-image to none as well...
<fantasai> hmmm perhaps
<plinss__> which would also preclude the use of the fallback color
<Bert> There is currently only a fallback color for the last image.
<Bert> What syntax could distinguish a fallback color from a normal
color? The slash requires look-ahead. It being the second
color works, but then the color is associated with another
color, not with an image, as plinns said.
<Bert> Two slashes (//) instead of one?
<fantasai> oww
<fantasai> maybe for the background-size, if you must
<dbaron> some implementations treat // as comments, I think
<fantasai> lol
* fantasai wonders if CSSWG has started up again yet, nobody seems to be taking minutes
<glazou> fantasai: not having critical mass here ...
Paged Media
-----------
ScribeNick: dbaron
* dbaron points melinda to the topic, in case she's interested
fantasai: 'em' on font-size on root element
We find "When specified for the root of the document tree (e.g.,
"HTML" in HTML), 'em' and 'ex' refer to the property's initial
value. " in 4.3.2
fantasai: Should margin boxes and page borders and backgrounds be
printed on blank pages?
fantasai: We propose we just print them, but adding :blank that would
let you specify visibility:hidden
fantasai: Technical documents tend to print them, novels tend not to.
(adding in level 4)
Haakon: Should I put in in gcpm?
fantasai: I also have it on the wiki for the level 4 draft.
Haakon: We could make gcpm the level 4 draft.
fantasai: part of it
RESOLVED: It's ok to have everything print even for blank pages, as
long as we have control over it in a future level.
RESOLVED: headers, footers, borders, etc print on blank pages,
add :blank selector later
<fantasai> http://www.savagecreek.net/CSS/Page/css3_paged_media_lc2_issues_list.htm
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Oct/0233.html
(previous was issue 8)
* CWilso hmm. WebApps done, guess I'll wander back up to CSS.
fantasai: Issue 3: We don't define what happens when the width of the
page changes mid-document.
fantasai: Proposal is that each page is laid out as though the ICB is
the same size as the current page, but allow exceptions for
tables and shrink-to-fit elements.
fantasai: ... if they split across pages
Alex and fantasai discuss some possibilities
<glazou> lol
Alex: How important is it to reflow things into irregular-shaped pages,
as opposed to ensuring that a container keeps constant width?
fantasai: If you have that rule, the root element stays the same width
throughout the document.
Alex: I like this rule applied to body but not to a paragraph.
Alex: Things with BFC should have an exception.
Alex: But even without BFC, things can have position:relative, be a
containing block for absolutely positioned elements, etc.
Alex: I'm going to claim no use case for continuous flow of text across
irregular pages.
Peter: Or almost none.
dbaron: I think if you define this for block elements in the normal flow,
then the wacky cases are going to be the cases that don't matter
Haakon and fantasai discuss a bug in Opera.
Hakon: Most often, the margins are going to change, but it's not going
to change the width of the CB -- gutters on opposite sides,
first page having bigger margin at top, etc.
Alex: I could live with a requirement of a non-BFC-element adapting to
changing width, but having softer language until we have an
implementation showing it works.
fantasai: OK, non-BFC, in normal flow, and requirement is a SHOULD.
Alex: multiple bodies would make this easier...
Haakon: Can an element start on one type of page and go to another?
fantasai: Certainly.
(David, Haakon, and Alex discuss DOM, etc.)
RESOLVED: Adopt proposal that page layout on current page assumes ICB
matches current page size and contents lay out accordingly,
restrict requirement to SHOULD and applying for non-BFC
elements in normal flow, all others being undefined
fantasai: Next thing is counters scoping.
fantasai: Melinda and Haakon both want scoping of counter to be shared
between document and page context.
fantasai: So if I have a counter in the document I can print it in the
margin box
fantasai: That's already defined to work, but the reverse doesn't work
currently.
Haakon: Just have one namespace.
dbaron: There's three things you can do with counters. You can use them,
increment them, and reset them
dbaron: Using and incrementing you just need to define the order
dbaron: reset is a problem
fantasai: what would reset on an @page mean? reset at the start of the
document? what about on a named page?
fantasai: reset on the first named page? every named page?
howcome: every named page
fantasai: how is that useful?
peter: footnotes
dbaron talks very fast and very detailed about counters
fantasai, howcome: what if counter-reset on @page doesn't create a scope?
dbaron: This ties into a counter-set property that sets the value
without introducing a new scope
dbaron: I think CSS counters are too limited to do the headers that we want
dbaron: or the headers in html5
BREAK
ScribeNick: fantasai
dbaron: I think that if we a) said that a counter-reset on the page
context didn't make a new scope and
dbaron: b) counter-resets and counter-increments affect all counters
that are in scope at the deepest point in the normal flow at
the page break
dbaron: ...
fantasai: the example in http://dev.w3.org/csswg/css3-page/#page-based-counters
should just work
fantasai summarizes that the page context and document interact as if
the page context were an element within the document at the start
of the page, inside the deepest element in the normal flow that spans
the page break.
fantasai: Would @page { counter-increment: foo; } create a counter scope
at the root?
dbaron: I'd have to check old emails to see if that works
http://www.w3.org/TR/CSS21/generate.html#scope
dbaron: The problem with that was with nested counters
dbaron: I remember what the problem was
dbaron: Say you're using ul, li with the appropriate resets and increments
dbaron: and your ::marker pseudo uses a counters() expression that does
dotted numbering
dbaron: this is all happy as far as incremental rendering goes
dbaron: if after this list, somebody sticks in an <li> that is not in the
<ul> that creates an implied scope on the root element, and you
have to go back and renumber the list items with a zero in front
fantasai: so what if we define any counter-resets and increments in the
page context not to create a scope
fantasai: in the document
fantasai: but all counter-reset and increment declarations create a scope
on the root element
Bert asks about page counter increments
@page { counter-increment: page; }
_@page {counter-increment: foo; }
@page { counter-increment: page 0; }
agreement that it doesn't make sense to put any of this in the margin boxes
@page foo { counter-increment: bar; }
@page { @top-left { content: counter(bar); } }
fantasai: so does bar get created at the root, even if it is never used?
or does the increment get ignored?
<fantasai> my proposal is to only create scopes on the root element for any
counters referenced on the first page of the document
<fantasai> so if I want to increment bar in @page foo, then I need to declare
it otherwise, we have to gather all declarations for @page and
create scopes for any counter-* counters that have been declared
<fantasai> even if that declaration never gets used
ACTION fantasai: propose a solution for allowing counter-properties on
@page that doesn't require going through all the pages
at the beginning to figure out what to reset on the root
ScribeNick: dbaron
fantasai: Should the 'page' property be inherited?
Hakon: No.
fantasai: HP has a bunch of implementations that already inherit it.
fantasai: It was difficult to get these other implementations to not
inherit page-break-inside; we don't want to push it further.
Haakon: I think we fixed things for non-inherited 'page' so that all the
use cases work the same way.
fantasai: One approach is to come up with a solution that lets inherited
work for all use cases, another is to let implementations be
conformant to print profile even if they inherit.
Hakon: [shows css3-gcpm dev.w3.org draft]
Hakon: I think this solution addresses all the use cases.
fantasai: What about existing content?
Hakon: We're making it into a list of properties, which is why we need
it to be not inherited.
Hakon: I think when it's not a list of values, it doesn't matter.
fantasai: Do we want it to be a list?
Hakon: We worked hard to reach this consensus; print implementors are in.
fantasai: The behavior of 'auto' inside an element that has a named page
is different.
Hakon: It may be that this can stay inherited when you only have one value,
but we want to go to multi-value. There has been significant
discussion among vendors.
fantasai: The problem is that most of the time you want the first page of
a series to be special, the middle pages to be uniform, and
maybe the last page to be special.
fantasai: Another proposal that would preserve inheritance of 'page'
would be:
fantasai: In level 4 or gcpm, page becomes a shorthand for page-name
(inherited), page-foo (non-inherited)
fantasai: where page-foo takes value 'auto', 'trigger-first',
'continue-onto-next-page', etc.
Hakon: I'd rather start from the proposal we've discussed for a long time
than a brand new proposal.
fantasai: There's a backwards-compat issue, and an interacting with other
standards orgs issue.
(Note: fantasai has HP hat on)
Hakon: Do you have a code example to show the backwards-compat issue?
fantasai: The content that works differently is
<div style="page:foo"><div style="page:auto"></div></div>
which is probably not very common.
fantasai: The issue HP has is about asking implementations to change.
Hakon: Why don't we take this offline?
Hakon: They'd have to change when they go to the list value.
fantasai, Hakon: We can add loopholes, making implementations conformant
if they do inherited, and warning authors about the case
where there's a difference.
Bert: With the page lists, is an empty page caused by
page-break-before: right counted as one of the pages in the list?
Hakon: Good question.
Bert: I think you strike from the page list even for empty pages.
fantasai: I think you don't.
fantasai: usually the blank page before a chapter heading is considered
part of the previous chapter
Peter: Pages that matter are often ones going straight from device to
printer, not on the Web.
Hakon: Change in gcpm rather than css3-page?
fantasai: We should go with what we ultimately want to do now.
Peter: Hard to do a straw poll given the implementors here, and those
not here.
Hakon: I don't feel like forcing printer manufacturers to change their
hardware.
fantasai: If we're going to do this, we should definitely put in warnings,
etc.
Hakon, fantasai, Peter: Both should be normatively compliant.
Peter: I think I'm ok with that given that the 2 uses may never see each
other.
Haakon: Good, we have consensus.
Peter: Well, provisional, depending on Melinda's reaction.
overflow:scroll in paged media
------------------------------
Alex: (draws)
Alex: For overflow:scroll, should we render scrollbar on paper or drop it?
Alex: With overflow:auto, and something doesn't fit on page, we don't know
if element will fit or not.
Alex: By the second page, we know whether the screen presentation would
have a scrollbar.
David: last page
Alex: In theory, we could go back and re-render previous page.
Alex: Current behavior differs across implementations
Alex: Printing in Firefox never renders a scrollbar for overflow:auto
Alex: Printing in Opera always renders scrollbar for first page, not sure
what it does for last page.
Alex: Printing in Safari does something else.
Jonas: You don't know what size to make the scrollbar thumb.
Alex: There are two things I really don't want:
Alex: (1) I don't want to have to go back to the previous page and
recalculate it.
Alex: (2) I don't want to have a scrollbar on one page and not have
it on one page (thus producing different widths, which has its
own set of problems)
Alex: I favor Firefox behavior; there isn't much use for the scrollbar
on paper.
David: Do we print scrollbars for overflow:scroll?
Alex: Yes, but never for 'auto'.
Alex: I think Safari doesn't paginate the element.
David: Seems like printing scrollbars on paper is a bad idea...
(Hakon and Alex test something in Opera)
Alex: My proposal is that when printing an element with overflow:auto,
it is ok to never print scrollbars.
Hixie: That's already ok.
Alex: It's also ok to print scrollbars if UAs so desire.
Hixie: The spec also says you can use whatever scrolling mechanism you like.
Topic: Do elements with overflow:auto and overflow:scroll split when printed?
Alex: Seems ok to not print.
Peter: Seems good if something that scrolls on screen to print spread out
on paper; but then there's also the argument for print style sheets.
fantasai: Seems like UA should be allowed to act as though it had
height:auto
Peter: How would the UA know what content that's reasonable to do on and
what it's not.
Peter: There is a class of users who want printing to yield a screen grab.
Jonas Sicking: It makes sense to show there is clipped content that would
show on screen...
Peter: Printing a scrollbar does that.
Alex: Now that we have devices that scroll but don't show scrollbars, we
should encourage UAs to produce indications of scroll that aren't
scrollbars.
Peter: That can be UA dependent.
Alex: There's always the option of a print style sheet.
Peter: Would be nice if overflow:auto could degrade into height:auto in
print, but overflow:scroll doesn't.
Peter: but not sure if that really makes sense.
Alex: Use cases for overflow:auto always involve height not 'auto'.
Alex: But rel pos could create scrollbars without height:auto.
Alex: I think we have a consensus that it is not required to make content
that's not visible on screen visible when printing.
Peter: I want the corollary to be that something that has all of its
content visible on screen shouldn't trigger an overflow condition
when printing just because it's near the page boundary.
RESOLVED: It is not required to make content that's not visible on screen
visible when printing.
fantasai: If you have a fixed height element that contains a page break
(either something didn't fit, or forced break) that's not
quite at the bottom of the page, should that gap consume
height of the element?
fantasai draws.
David: Also, do you draw the side borders along where you're skipping?
Alex: And does it count as part of the height of the body for something
abs pos relative to body?
Bert, Peter, David agree that border and height stop 1em above the bottom
of the page (element does not continue into gap)
Jonas: What about one of them being a float: two pieces of text being
uneven?
fantasai?: What about flowing text into the gap
Peter: If you don't let text flow under it, text should flow under the
borders
fantasai: You could choose not to consume height but still draw.
David: Drawing when you're not consuming height is a problem for
background images
David: Drawing backgrounds of some elements but not others also seems
like a problem, especially with float case.
Jonas: I think you should keep drawing borders and background to the bottom.
Jonas: And repeat the part of the background from the break point.
David: That's inconsistent with inlines, where we stop borders and
background before the end of the line.
Jonas: inlines look weird
David: they look weird with borders, fine with backgrounds
Peter: split border isn't weird-- it tells you that it continues on
Peter: I think it's weirder to have background/border continue on in
empty area.
fantasai: So it sounds like we can at least resolve that computed height
isn't consumed.
RESOLVED: Computed height is not consumed by the height between the break
and the bottom of the page.
Alex draws case where there's a float inside a fixed height container,
and the float has an earlier split
David: I think having the float overflow in that case is not as bad as
having the simpler case overflow because we do consume height.
(Note that we didn't resolve whether there's background or border drawn
in the gap.)
fantasai draws another case, which doesn't convince anyone else that
it's another bad case.
Implementations should try to avoid creating overflow when there wouldn't
be overflow when unpaginated (or something like that).
RESOLVED: Implementations should try to avoid creating overflow when
there wouldn't be overflow when unpaginated (or something
like that).
DONE
Received on Wednesday, 5 November 2008 03:50:47 UTC