W3C home > Mailing lists > Public > www-style@w3.org > November 2008

[CSSWG] Minutes F2F 2008-10-21

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 04 Nov 2008 19:49:23 -0800
Message-ID: <491117C3.1000704@inkedblade.net>
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 
   <fantasai> http://tinyurl.com/5qluy2
   dbaron: the test does not capture the change made in firefox 3 so not
   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


   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
   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
   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
   <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
   <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
   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
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
   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
   fantasai: If we're going to do this, we should definitely put in warnings,
   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
   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
   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
   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
   fantasai?: What about flowing text into the gap
   Peter: If you don't let text flow under it, text should flow under the
   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).
Received on Wednesday, 5 November 2008 03:50:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC