- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 20 Jun 2015 08:41:38 -0400
- To: www-style@w3.org
position: fragment
------------------
- Rossen brought examples of why he believes that
position: fragment (previously position: page) should be a
part of the Positioning spec.
- One of the main use cases that the working group felt needed to
be solved is to make sure a page prints well, even if the
author didn't design for printing.
- The argument against position: fragment was that all the use
cases would be better addressed by the Page Floats spec
because it already has definitions of exclusions and avoidance.
- Page Floats itself, though, is underspecified right now and
therefore it's hard to decide for sure if it would
actually solve the use cases.
- Many people agreed that Page Floats needs to be explained in
terms of CSS primitives, basic concepts, that are generic
that can explain other aspects of CSS layout.
- RESOLVED: Page floats way better defined, less magic, as
potential switches (even if not exposed)
===== FULL MINUTES BELOW ======
Scribe: fantasai
position: fragment
------------------
Rossen: This was a discussion on position: fragment.
Rossen: fantasai pointed out that when I published the FPWD of the
Positioning draft, I left in the position: page feature
that the WG had required to leave out.
Rossen: Going back to this feature, and why it's useful,
Rossen: When we proposed the position: paged value,
Rossen: We didn't have fragmentation spec,
Rossen: We didn't at the time have the notion of
overflow: fragments,
Rossen: and [...]
Rossen: I created one example.
[Shows example of an article about New York]
Rossen: One use case was people trying to either annotate or put
some kind of marking with the content that they have that
flows through some potentially fragments.
[example has first paragraph in one big block across the top,
then a narrow column next to a wide column]
Rossen: Only thing that I added, was to mark some section of the
text,
Rossen: with a marker element.
[Rossen shows a little triangle on top of the word "With" in a
random position in the paragraph]
Rossen: We have two markers that are inline with the text.
Rossen: One of the use cases that we got requested at the time,
Rossen: was that people wanted to, besides having markers inline,
wanted to position those with respect to the fragment that
they happen to be in.
Rossen: If I position the marker left, just with left: 0,
Rossen: Because the top position will be taken from the static
inline position, will be in the same line of text,
Rossen: but shifted to the start of the line.
Rossen: Problem becomes when we try to position the top.
Rossen: position: absolute says that you have to find the nearest
abspos containing block.
Rossen: Since there are no such, it's the initial containing block,
Rossen: which is the first region.
Rossen: So both markers end up overlapping on top of each other.
Rossen: This is why we want to position: relative to the nearest
fragmentainer.
Rossen: Previously we had this name, that I didn't like,
position: page.
Rossen: Prefer it to be called position: fragment.
Rossen: Both markers positioned with respect to their own
fragmentainer.
Rossen: Two markers show up wherever the containing fragmentainer
of the marker is.
Rossen: If I change my template to be a multicolumn, same thing
should apply:
Rossen: Stay in the corresponding column.
[Rossen shows a different article
It has four columns
Title and header spans two of the columns]
Rossen: They used position: fragment for the ads.
Rossen: This is only about positioning, nothing to do with
exclusions.
Rossen: Wanted to resume the discussion about this feature,
Rossen: And pursue a route where we can re-add it to the
positioning spec.
Florian: I completely agree with you on the use cases.
Florian: However, I disagree with you that treating this and
exclusions and collisions as separate topics is a good
idea.
Florian: If you have two markers in the same column, they are
going to overlap with each other.
Florian: This is not very robust.
Florian: It's especially a problem because the author may look in
iPad screen size and it's fine,
Florian: But on a different device, it overlaps.
Florian: Page floats, which are also poorly named, aim to solve
the same problem, while dealing with exclusions and
collisions at the same time.
Florian: Admittedly the page floats spec is not yet very mature,
Florian: But I think it is a better approach to solving these
problems.
Florian: Also works better with column span.
Florian: Spanning 2 columns is reasonably common.
Florian: This feature needs more work, but I think it's a more
promising approach.
Florian: That said, I really agree with the use cases, and we
should solve them.
Florian: So I'm not saying we don't work on this topic,
Florian: Just a question of which approach we take to deal with
that.
fantasai: I'm 100% in support of what Florian said.
Rossen: So you're saying there are no use cases for abspos.
Florian: I'm not saying there are no use case for abspos,
Florian: But there are use cases that you will try to solve with
abspos,
Florian: But would be better solved with page floats.
Florian: More robust, that is, better handled in variable
environments.
Rossen: Page floats is combination of two features, positioning
with respect to fragment, and exclusion.
Florian: Three features: also collision avoidance. That's an
important feature.
Rossen: If we agree that there are use cases and need to have
these as three separate features.
Rossen: Being able to position something wrt fragment, and it not
necessarily being an exclusion,
Rossen: This is a marker, but could easily be a menu.
Rossen: Gets tagged along in the appropriate fragment.
Rossen: Usable without affecting the content,
Rossen: Which is an ebook reader that does this for annotations
and note taking.
Rossen: You want to keep your notes relative to where you took the
notes,
Rossen: And you want to present the menu without destroying the
content.
Rossen: You want to keep it in the fragmentainer it appears in,
Rossen: Not necessarily affecting the content.
<ChrisL> so it is for a popover (that does not cause reflow)
* fantasai points out that two menus ending up on top of each other
is not smart either.
Florian: I would agree that this use case exists.
Florian: But what I'm concerned about is the exclusions and
collision-avoidance being opt-in rather than opt-out.
Florian: By default, you have exclusion and collision-avoidance.
And if you really want to not have those, you turn them
off.
Florian: Otherwise authors will create layouts that work on their
own screens, and don't work on others.
Florian: Absolute positioning is useful and dangerous.
Florian: If we can make a positioning system that is not dangerous
by default, that's better.
dbaron: I worry less about things with exclusions but not
collision-handling, than things that have neither.
dbaron: Since exclusions appear to avoid collisions, but don't.
Florian: I would much rather solve page floats, and have a
property that lets you opt out of exclusions, than the
other way around.
plinss: I want to build page floats out of primitives.
plinss: Explain floating before we add new types of floating.
Florian: Problem if we do it this way is that the simple way of
using it will not be the safe way of using it.
Florian: You will get all the problems authors have with
unanticipated collisions would still be there
<liam> [note from IRC, exclusions/intrusions, floats, spanning &
stacking is one of the hardest problems in layout & it
really does help to view them all together]
...
Florian: In the other example, what happens if both images end up
in the same column ('cuz your screen is taller than you
expected, or whatever).
[Rossen shows an example]
Florian: This example only has one image
...
fantasai: Your menu example is also broken. Say you wanted the
menu at the top of each section. You use position:
fragment to put it there. If on my screen both sections
end up on the same page, because my screen is taller
than yours (e.g. I use portrait and you use landscape),
then the menus will end up both at zero coord in the
same fragmentainer, and thus lay on top of each other.
And one menu is thus unusable.
Rossen: I'm not talking about abspos.
fantasai: Neither am I.
[Rossen tells fantasai that she's complaining about abspos and
he's not talking about abspos]
Rossen: You can fix the problem by using Javascript.
* Bert thinks the problem is that people have a model in mind to
solve a use case and are unable to see that there are other
models, in this case e.g., float or (foot)notes or
transformations with JS or XSLT, instead of abspos.)
johanneswilm: Wrt primitives, I can see the point that page float
is a lot of very complex things, and you would want
something that is simpler and you use JavaScript on
top of that,
johanneswilm: But I don't see how this would help me in doing that.
johanneswilm: I could place the things manually with JS anyway.
Rossen: How would you place things at the top left of the region?
johanneswilm: I would figure out what region I'm in, figure out
what the coordinates are, then I would create a new
region flow for this one element, I then put it in
the place where I need to put the piece of content
that I want to put at the top of this fragment.
johanneswilm: I put it there, maybe make it an exclusion, maybe
change its coordinates to avoid overflow.
Rossen: You would break region chain to make this work.
johanneswilm: It can be done.
Rossen: How would you do it with columns or pages?
johanneswilm: Don't know about the APIs for columns or pages, I'd
use regions.
johanneswilm: I would create a new flow for things I took out of
flow, then place those with javascript.
johanneswilm: Has be done that way today.
johanneswilm: If this does not exist for columns so far, don't see
why you wouldn't just add that to columns.
johanneswilm: Rather than create something new that you can't
actually use in a production environment without a
ton of JS to manage collisions.
<ChrisL> multiple named flows, aka "how FrameMaker did it"
Florian: I agree that you're not creating something totally new,
Florian: But you are addressing a new use case by extending the
reach of abspos to do things it couldn't do before.
Florian: And it would solve these use cases, but not particularly
well, and require JS.
Florian: We have the ability to address these use cases without
these problems,
Florian: So I'm in favor of doing it there.
<astearns> solving a use case with an integrated system that
doesn't require javascript usually results in a dead-
end that cannot be extended to more use cases.
<astearns> we should certainly consider positioning, wrap and
avoidance together, but we should provide primitives
for each separately that are manipulable by javascript
Bert: This use case is the same use case as footnotes.
Bert: You want something at the edge of the region,
Bert: Goes into a special region, if that special region is empty,
it disappears.
Bert: So here you have a region dedicated to an image. If there's
an image you put it there. if not there's no such region.
johanneswilm: For footnotes, you want the footnote on the same
fragmentainer as the marker.
johanneswilm: There's much more complexity in making sure the
markers fit on same page as footnote,
johanneswilm: Footnotes are different than page floats.
leaverou: What I don't understand about this discussion is why we
can't just do ::region { position: relative }
leaverou: That would solve that use case, unless I misunderstood
what the issue is.
dbaron: Two comments.
dbaron: To respond to Lea, one of the issues with making abspos
relative to the first fragment.
leaverou: Didn't suggest that, it's terrible.
dbaron: One of the issues is what happens to pages where the user
prints, but the author didn't think about printing when
they designed the page?
leaverou: Many use cases for positioning, many for page floats.
leaverou: But abspos already exists.
leaverou: Should spec something that does the reasonable thing.
leaverou: All abspos things going to the first fragment makes no
sense.
dbaron: The use case of printing stuff when author wasn't thinking
about printing is probably a significant chunk of the
printing that happens on the Web.
leaverou: Very large segment of printing in the publishing
industry.
leaverou: But few users print web pages.
plinss: Last time I saw stats from HP, over 50% of things coming
out of HP printers was a web page.
dbaron: Second comment I have is in reply to Florian, who said
something about how this wasn't introducing new problems
with abspos
dbaron: One thing it does introduce that's different is problem
fantasai is worried about
dbaron: What happens if author designs it and it works, and then
user's display fragments them differently, resulting in
two things that were on separate pages appearing on the
same page.
dbaron: These are two separate problems.
dbaron: One of my comments is about why abspos associated with
first fragment.
dbaron: And one is about why we want collision-avoidance should be
built in by default.
leaverou: I think page floats should exist and abspos should exist.
Rossen: I didn't say that page floats shouldn't exist.
Florian: Because you are trying to use this mechanism to address
use cases that are better solved with page floats.
Florian: This will solve those cases poorly and get implemented
fast because it's easier
Florian: And then we have these problems, and lose incentives for
implementing page floats
Florian: If we want to try to solve these use cases, we shouldn't
solve them with this.
Florian: Would prefer to solve page floats first.
[argument over whether page floats is relevant to this discussion.
Rossen says they're irrelevant to this discussion. Florian
says that they're relevant because the use cases Rossen is
bringing up as a justification for having this feature at all
are better solved by page floats]
dbaron: I don't think this is a realistic use case.
dbaron: You need to have realistic use cases for people to
understand what you want.
leaverou: Here's a case:
leaverou: In my book, I have code areas that have a page
background.
[leaverou draws a box with some text inside]
leaverou: I wanted when they were broken across pages to have a
zigzag top edge, zigzag bottom edge.
leaverou: I used box-decoration-break: clone.
leaverou: In my use, there can only be two fragments total, so
doesn't scale.
leaverou: Use pseudo elements
leaverou: to hide the zigzag border on the first and last boxes.
<ChrisL> the hiding is a workaround. It would be better to specify
styling of broken edges directly
* fantasai agrees with ChrisL
dbaron: What we want to do for satisfying case of printing ...
dbaron: The behavior you want for printing in order to print ...
dbaron: The problem is we don't have a name for this thing.
dbaron: The goal is we want web pages that were not designed for
printing to print reasonably.
dbaron: The way to handle abspos to solve that goal,
dbaron: is that top is relative to the top fragment, and bottom is
relative to the bottom fragment,
dbaron: so that still works.
<fantasai> Oh, yeah. There's totally buggy abspos printing behavior
out there.
<dbaron> (I *think* Gecko only has the bug fantasai is thinking
about when the bottom is a large enough number to push
something back to an earlier page.)
leaverou: Might want pseudo-elements to target fragments and a
:fragments pseudo-class for elements that are
fragmented, perhaps with an optional an+b parameter for
number of fragments (e.g. :fragments(n+3)).
ChrisL: I would characterize what you did there [in your example]
as a workaround.
ChrisL: If we wanted to solve that use case, we would style top
breaks and bottom breaks differently.
leaverou: Or just target the fragments to style differently, not
targeting the breaks.
Rossen: If you specify top: 0; bottom: 0; top 0 should attach to
the top of the first fragment, and bottom should apply to
the bottom of the last fragment.
Rossen: I'm still not able to work within a single fragment.
Florian: This ties into page floats.
Florian: If you want something attached to the bottom of your
fragmentainer, then you can float it.
Florian: You get additional things with the page floats approach.
Florian: Ability to float to the right or left, next column, avoid
colliding when both at the top of the same fragmentainer,
float left on odd pages, right on even pages.
Florian: We get all of these with page floats.
Florian: On the author side, if they use position: fragment, they
will think they solved the problem when really they
didn't.
Florian: And on the implementer, same thing, they will think they
solved the use cases when really they didn't.
[discussion of use cases]
Florian: Of these markers you have, what happens if they're on the
same page? They'll overlap.
Rossen: Same problem you have with abspos.
Florian: Sure, but the author sees that problem as well.
Florian: In this case, author might not see the problem, but user
sees the problem.
Florian: We should design systems that avoid this problem: where
the author sees the result they want and it breaks on the
user's computer.
Florian: Also, we have opt-in exclusions, but we don't have opt-in
collision-avoidance.
fantasai: Ok, now that we've repeated the argument we had last
time we discussed this, do we have any conclusions?
leaverou: So if by default, abspos are positioned like dbaron
suggested, why can't we just apply position relative to
the fragment?
leaverou: This would be opt-in behavior.
[fantasai explains the issue to leaverou again, but forgets what
she said in order to minute it]
fantasai: So could have e.g. page floats, with a switch that turns
off exclusion and/or collision-avoidance behavior,
fantasai: Which would have the default behavior to avoid overlap,
fantasai: And only has overlap if specifically requested.
Rossen: That seems reasonable to me.
Rossen: Seems smiliar.
Florian: Difference is defaults.
Rossen: ...
Florian: I think you mis-characterized what I'm proposing.
Florian: Idea is to have a switch that applies to page floats, to
turn off exlcusions/avoidance
Florian: Page floats have a definition for exclusions, have a
definition for avoidance.
Florian: You can turn them off, but they exist already.
Florian: But if you have a generic switch, like you're proposing,
have to define how they work for everything.
Florian: I tried to define a generic collision-avoidance property
that works for everything. And that's hard.
Florian: But floats have that already.
Rossen: Because they have a very simple model.
Rossen: Exclusions can apply to other layout models, too, though.
Rossen: Not always bound to page or fragment.
Rossen: Can create templates that have nothing to do with ...
Rossen: I get what you're saying. You want to restrict page floats
so only used on fragmentainers.
Florian: page floats work [on all these things].
<astearns> page floats haven't yet been defined well enough to say
whether they work [on all these things] or not
Rossen: What about on grid?
Rossen: Exclusions work on everything.
Florian: This is also a discussion we had when we discussed
exclusions.
Florian: There were significant negative feedback on exclusions.
Not because of exclusions themselves, but because they
made it more tempting to use abspos in cases where you
would not have used abspos before.
Rossen: Almost everyone uses exclusions on top of grid.
...
<astearns> grid positioning can end up with some of the same
collision problems people see with abspos
johanneswilm: The reason that the page floats spec only talks
about the fragmentation is that we tried to keep it
as simple as possible.
johanneswilm: And we thought there might not be much reason to
doing more than that.
johanneswilm: But no opposition to doing it for more.
Bert: You might want to float something, e.g. a callout, only if
there isn't already one.
Bert: If I have place for two, float both. Otherwise float one,
don't do second one.
Bert: Conditional float or something.
Bert: This seems to be what you'd want to do with your marker.
Bert: Similar to how running headers are done.
Bert: You put current title at the top.
Bert: If two sections start on this page, you don't put the second
one in the running header.
Rossen: What now?
fantasai: There's no consensus, so we don't move forward.
fantasai: I think if you want to bring this up again, you need use
cases for your solution that aren't problematic with
your solution (and better solved with page floats).
fantasai: If there's a use case where the problematic behaviors of
this solutions are strengths for that use case, then
that'd be convincing.
fantasai: But if you only have use cases for which your solution
is problematic, then we'd want a better solution.
plinss: Page floats on its own is violating the extensible web
principles.
plinss: I'd much rather have the primitives to build page floats
than to have page floats.
<astearns> I'd like to have both: page floats built on top of
those primitives
Florian: My reservation with this approach is that primitives are
problematic when using them independently is broken, and
must only be used in combination.
<astearns> and I disagree that using them independently is broken
<astearns> collision avoidance can be scripted
plinss: It's a power tool.
plinss: Can do cool new wonderful things,
plinss: that we don't come up with.
johanneswilm: Is that what the definition is for primitives?
johanneswilm: I think all you need is exclusions, and ability to
position things in Javascript.
Rossen: And C, collision-avoidance if needed.
Rossen: I say yes to all of them.
plinss: Giving them primitives doesn't mean they have to be JS.
plinss: Page floats can be a shorthand for these other properties.
fantasai: ...
Rossen: I can have collision-avoidance in 2 months.
fantasai: Great, bring up your proposal.
dbaron: When you talk about primitives, I'm not sure that the
primitives that we want to describe CSS on top of are also
CSS.
plinss: I think primitives are conceptually CSS. Not necessarily
switches exposed through CSS properties and values.
plinss: Should be conceivable as properties, even if we don't
expose.
dbaron: Yes, and I'm not convinced that absolute positioning is
the primitive we want.
plinss: We all dislike floats, they're weird in their interactions.
plinss: Why are we building on top of floats?
plinss: Want it to be predictable.
Florian: Wrt primitives, I think it would be good to have
exclusions and collisions (which we don't have),
Florian: and they're auto.
Florian: Floats have them, and abspos don't.
Florian: I think we should be careful about the order we add these
in, and we should be careful in defining auto.
Florian: We agree on the end result, but we don't agree on the
path, and don't agree on auto.
Florian: I would rather have page floats, explained through auto
value of these properties, and you can turn it off.
plinss: If the idea is do X before Y then let's not decide on
"don't do Y".
Florian: It's not obvious that what's proposed today is necessary,
if we solve page floats.
Florian: Majority of the use cases discussed here are solved by
page floats.
Florian: If page floats ends up solving all of them, then this
switch doesn't need to exist.
Florian: We're not done exploring page floats, we should do that.
<Bert> The primitives would be things like: position A near B,
position A not before B, position A near the top, position
no more that X things of type A on the same page, position
A at least Y em from B, etc. display A, do not display A
and B in the same region...
<liam> +1 to Bert's examples
fantasai: Ok, so how do we wrap up this discussion?
plinss: Doesn't seem like continuing the discussion is the right
way to go.
plinss: I would like to hear more ways this proposal could move
forward.
Florian: For me, I would like to see that there are use cases that
are *better* solved with this than with page floats.
Florian: Otherwise I am not convinced.
gregwhitworth: If I want to put at the bottom, and not exclude,
then what?
johanneswilm: Turn off exclusions.
plinss: I want page floats explained exactly how it works.
plinss: If all we have is page floats property, but explained very
clearly in terms of the concepts building it up,
plinss: and even don't have switches for these things, but could
add them later,
plinss: Then that's fine.
plinss: I want to see it explained in terms of CSS primitives,
basic concepts, that are generic that can explain other
aspects of CSS layout.
[fantasai, florian, johanneswilm all 100% in favor of this]
Florian: ...
plinss: If we have use cases to have a switch, yes, we add it.
Florian: We don't know whether the switch is useful or not.
Florian: If it is we expose it.
plinss: Rossen, that works for you?
RESOLVED: Page floats way better defined, less magic, as potential
switches (even if not exposed)
johanneswilm: I didn't bring up page floats at this meeting is
exactly because it's not precise enough yet.
Received on Saturday, 20 June 2015 12:42:15 UTC