- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 19 Nov 2013 21:11:37 -0500
- To: www-style@w3.org
CSS2.1
------
- Bert asked about the progress as he's heard interest in an updated
release.
- 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.
=====FULL MINUTES BELOW======
CSS2.1
------
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
edits.
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>
http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=per-tr
<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
nonetheless."
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
http://lists.w3.org/Archives/Public/www-style/2013May/0783.html
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
values.
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
fragmentainers?
Rossen: Do we force progress somehow? Or skip zero-area fragments?
ChrisL: What would be the practical difference between skipping vs.
not-skipping?
Astearns: As it stands, make at least 1px progress to prevent infinite
loop.
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
thing.
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
fit.
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
page.
[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