W3C home > Mailing lists > Public > www-style@w3.org > June 2015

[CSSWG] Minutes New York F2F 2015-05-20 Part III: position: fragment

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 20 Jun 2015 08:41:38 -0400
Message-ID: <CADhPm3vTf8q9dHrvFWa2W5h0LPzE8hhXXHmcwVSsBAWh35FmSA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:31 UTC