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

[CSSWG] Minutes TPAC F2F 2013-11-10 Sun IV: CSS2.1, 3-Value <position> Syntax, Zero-height Fragmentainers

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 19 Nov 2013 21:11:37 -0500
Message-ID: <CADhPm3u9TTJPmDOCJ3eXF=x-8LT9OqAET_HV=XpBhVELS0xwNA@mail.gmail.com>
To: www-style@w3.org

  - Bert asked about the progress as he's heard interest in an updated
  - It was decided that the errata needed testing before an update with
         led to further discussion about how to get the errata tested.
  - Bert will create a wiki to list what needs testing and track who is
         doing the tests.

3-Value <position> Syntax

  - Fantasai briefly discussed the idea to create a <position> syntax
         for cases where it's mixed with other types of values.

Zero-height Fragmentainers

  - The group discussed if zero-height fragmentainers should be skipped
         or if there should be a minimum of 1 pixel for the height.
  - RESOLVED: 1px fragmentainer minimum.


ScribeNick: fantasai

  plinss: Who put 2.1 on the agenda?
  Bert: me
  Bert: Do we want to publish the editor's draft as a revised edition?
  Bert: Or solve more issues or what?
  Bert: I've heard people would like to have an update.
  Bert: Errata we decided so far, up to date except for a handful of
  Bert: That's about 1 hour of work.
  Bert: Can I publish or wait?

  fantasai: Do we have tests for all the errata?
  Bert: Don't know.
  ChrisL: I think that's a requirement for PER

  dbaron: Diffs?
  fantasai: Errata include diffs
  dbaron: I wouldn't mind a quick look at the diff-marked version.
  <ChrisLilley> publication will also need a diff-marked version

  dbaron: I think publishing is a good idea.
  dbaron: In addition to tests, I would like week of review to see what
          we're publishing.

  <Bert> -> https://www.w3.org/Style/Group/css2-src/diffs-rec/
         CSS 2.1 diffs
  <ChrisLilley> "The request MUST include a link to a final
                implementation report, or, if there is no such report,
                rationale why the Director should approve the request

  ChrisL: New version definitely better than the old one,
  ChrisL: But we need tests and implementation report.
  plinss: A new implementation report in total, or just for the diffs?
  ChrisL: Just the diffs
  [silence on tests]

  <Bert> -> http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html
         errata for CSS 2.1
  dbaron: Do we have a way of gathering tests for the errata?
  dbaron: plinss, can you propose a way to do that?
  fantasai: I don't think we need anything special, just send a link to
            the test to Bert, he can add it to the errata document.
  ChrisL: It's better to have an automated system.

  dbaron: We'll need an implementation report.
  dbaron: Can we add additional rel=help links to the errata document?
  plinss: Yeah, we can do that, just build a test suite for that.

  plinss: We need to remove tests for things that have changed.
  fantasai: Might want to replace those tests with the new ones.
  dbaron: Hard to find those.
  Bert: Those will be tests that failed, you don't have to look at tests
        that succeeded.
  Liam: We can't assume that will work.

  plinss: So who is going to do this?
  [plinss proposes putting the errata into a hat and letting people
          choose one to work on.]
  SimonSapin: I think the last one is not observable

  <zcorpan> I volunteer to test this errata item: "In 11.1.1 “Overflow:
            the 'overflow' property,” change the definition of 'scroll'
            and 'auto':"

  ACTION: Bert to create wiki page to list tests needed for errata,
          people can sign up to work on them.
  <trackbot> Created ACTION-591 - Create wiki page to list tests needed
             for errata, people can sign up to work on them [on Bert Bos
             - due 2013-11-17].

  SimonSapin: I can do the tests related to tokenization
  SimonSapin: also add
  SimonSapin: I can write up errata text for it
  SimonSapin: "Allow at-rules inside declaration blocks"

3-Value <position> Syntax

  fantasai: Idea was to create a <position> syntax that is not ambiguous
            to parse in cases where it's mixed with other types of
  fantasai: Would have to drop 3-value and 1-value variants.
  fantasai: Question would be, do we want to look into this?
  fantasai: And if so, where would we use it / which existing places
            that take <position> would we want to modify?
  fantasai: Hard to imagine using one-value syntax... except 'center' is
            probably really popular.
  fantasai: Maybe not so interesting if 'center' then becomes invalid.

Zero-height fragmentainers

  Rossen: Issue raised by Alan -- what do we do with zero-height
  Rossen: Do we force progress somehow? Or skip zero-area fragments?

  ChrisL: What would be the practical difference between skipping vs.
  Astearns: As it stands, make at least 1px progress to prevent infinite
  dbaron: Underlying principle of fragmentation, in columns and pages
          certainly, you never want to get into situation where you the
          decide first item on the page/column doesn't fit so push to
          next page... and then make same decision in next column/page.
  dbaron: So for pages/columns, you need to force progress.

  Rossen: Options we came up with are:
  Rossen: A) Have a 1px minimum progress.
  Rossen: i.e. fragmentainer is always assumed to be at least 1px tall,
          so that progress can always be made.
  Rossen: B) Ignore fragmentainers that are zero area.
  Rossen: Meaning, if all fragments are zero-height, such as columns or
          pages, then no layout will take place at all.
  Rossen: Also with this option, if you have a non-homogenous array of
          fragmentainers, then skip zero-height containers, and layout
          only occurs in other containers.
  Rossen: These are only two that we have.

  Bert: Third option would be that if zero-height, must put at least one
  astearns: Sounds like a variation on option 2 where you abort where
            the first zero-height thing, put everything there.
  Bert: If your object is too big for the fragmentainer, it would push
        to next one.
  astearns: Bert's option, if you have flow of 100px tall things, and
            all columns are 50px tall, each column gets one of those
            items (and they overflow).
  astearns: That's choosing not to slice.
  fantasai: For printing though you want to slice, because overflow is
            not visible.

  dbaron: Thinking about it as 1px of height doesn't seem exactly right.
  dbaron: If you're at the top of a fragment and you need to place
          something, might place more than 1px -- might want to put one
          line of text.
  dbaron: In gecko, we have boolean of whether we placed anything yet,
          if not we place the first "thing."
  fantasai: We worded it as fragmentainer is 1px tall, not that it makes
            1px of progress.
  fantasai: We want the behavior to be continuous between zero-height
            and 1px or more.
  fantasai: e.g. one behavior we considered was "if it's zero-height,
            place at least one thing, but if more than that, place
            whatever fits" but that is not continuous.

  Rossen: Another option we considered was to have this as an option,
          where it was and option between 1 and 2, either force progress
          always regardless of area, or you have the behavior inspecting
          fragmentent container chain to see if there is a better place
          to put the content.
  Rossen: That would be more fancy behavior.

  astearns: Might be able to make distinction between situations where
            overflow is basically lost, as in printing, vs. fragmenting
            in a larger layout where you could overflow but overlap
            other content.
  fantasai: Either case risks data loss; in printing, it's guaranteed,
            but if overlapping might also lose content underneath.
  fantasai: I think default behavior should avoid any overflow.
  <astearns> I think the distinction I wanted to make was whether the
             overflow content could be scrolled to or not, not so much
             whether it overlapped anything.
  fantasai: So if you're in a scrolling fragmentainer...

  [astearns clarifies that he's talking about e.g. a region that is a
           fragmentainer placed on a scrollable canvas]
  [fantasai points out that while you can scroll to see the image (or
            whatever) that didn't quite fit, you can't scroll to see the
            paragraph of text that might be underneath now]

  Rossen: What do you do if you have an image into a zero-height page?
  dbaron: Gecko doesn't fragment inline images. For block images, let me
          see ...
  dbaron: If a block image is given a zero page size, it will consume
          1px height on that page.
  Rossen: Which is the behavior we defined in Option A.
  [dbaron notes that this was probably a fix for a hang bug, where the
          point was to make it not hang]
  <SimonSapin> WeasyPrint definitely had such hangs
  Rossen: Note that this a pathological case, but we still have to
          handle it.
  <dbaron> http://hg.mozilla.org/mozilla-central/file/16949049f03d/layout/generic/nsImageFrame.cpp#l860
          is the code I was referring to
  <dbaron> (Interestingly, we only split images when we're paginated, and
           not for multicol in non-paginated displays.)

  Rossen: I think 1px minimum height and guarantee of continuity is
          great for homogenous case.
  Rossen: For the non-homogenous case, option B seems better.
  Rossen: Option C was "don't slice things".
  Bert: So look forward to see if there's a better box.
  fantasai: So what if fragmentainer is not zero, but 1px tall and you
            have a 5px thing, do you look forward for that?
  Rossen: Yes.
  Rossen: But then if you have an image that is 150% tall, it will never
  Bert: You get what you asked for.
  fantasai: You might not have asked for it, might have fragmentainers
             based on viewport height, and have images that happen to be
             taller than my viewport.

  astearns: What convinced me to 1px solution last time was having an
            infinite loop in box-generation code.
  fantasai: So, seems to me that 1px solution is reasonable, simple,
            predictable, and continuous.
  fantasai: Should go with that, and do fancy find-the-fragmentainer-
            that-fits behavior as a different option.
  fantasai: That's not a zero-height fragment container problem, but an
            any-height fragmentainer one.
  Bert: Seems obvious to me that if the item doesn't fit on the left
        page, but fits on the second page, then should go to the second
  [Liam says something about scope and pathological examples]

  plinss: I think we need a general-purpose solution for dealing with
          things that don't fit.
  Liam: You can have constraints like having image or footnote on same
        page as its reference.

  ChrisL: Probably you don't want to print 1px per page.
  dbaron: Then you get into issue of what is the smallest allowable
          page, should it be 100px? 2in?
  dbaron: What if you want to print fortune cookie slips?
  <SimonSapin> Print business cards in CSS. Done that.

  RESOLVED: 1px fragmentainer minimum

  [Content-fitting is separate issue to address in some other spec]
  [asking about other issues?]
  astearns: Why when you have 100px-tall div with 300px of content, do
            you get 3 balanced columns of 100px bits of text?
  fantasai: Oh, you're asking why is overflow content considered content
            for the purpose of filling columns?
  fantasai: I don't know that we explicitly discussed that for columns,
            but print *has* to work that way.
  fantasai: And shouldn't pages/columns be treated the same in how they
            handle fragmentation?
  astearns: I would like that pointed out in the spec.

  ACTION: Rossen and fantasai to note that in the spec
  <trackbot> Created ACTION-592 - And fantasai to note that in the spec
            [on Rossen Atanassov - due 2013-11-17].

[Meeting closed]
Received on Wednesday, 20 November 2013 02:12:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC