Options:
Previous day, Next day
- # Session Start: Tue Dec 15 00:00:00 2015
- # Session Ident: #css
- # [00:08] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [00:18] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
- # [00:18] * Joins: Florian (~Florian@public.cloak)
- # [00:34] <TabAtkins> fantasai: Don't do fixup unless it's an emergency, report and let me fix things. No reason to do a lot of work if I can make it work correctly.
- # [00:35] <fantasai> It's slated for publication tomorrow
- # [00:35] <fantasai> so I handed it off to Chris earlier today
- # [00:35] <fantasai> Not sure if he got it
- # [00:35] <fantasai> but I tried
- # [00:35] <TabAtkins> Well, it's approved for publication tomorrow. If you send the contents later, it'll get posted later, whatever.
- # [00:36] <TabAtkins> Linking to ED of 4 instead of the CR of 3 I understand - I kill all refs from earlier versions before I start checking for ED vs TR.
- # [00:36] <fantasai> you'll be on the floats call in half an hour?
- # [00:36] <TabAtkins> Yeah.
- # [00:36] <TabAtkins> We're doing hangouts, right?
- # [00:36] <fantasai> either that or skype, not sure
- # [00:37] <TabAtkins> I can't skype, so it can't be that. ^_^
- # [00:37] <fantasai> kk :)
- # [00:37] * fantasai wonders why that is
- # [00:37] <TabAtkins> ChromeOS is not Skype-friendly.
- # [00:38] <fantasai> huh
- # [00:38] <TabAtkins> By which I mean Skype is not a webapp.
- # [00:38] <fantasai> right
- # [00:38] <Florian> hello
- # [00:38] <TabAtkins> Let me look into the block container thing.
- # [00:39] <fantasai> hi Florian
- # [00:39] <Florian> For the floats call, we can do anything you want, but so far skype was the only thing discussed
- # [00:39] <Florian> either way, people need to share their id.
- # [00:40] <TabAtkins> For hangouts, we just need to create a room and invite people to it.
- # [00:41] <fantasai> send an email so johannes gets it?
- # [00:42] * Joins: bradk (~bradk@public.cloak)
- # [00:43] <bradk> Hello
- # [00:44] <Florian> Alright, I made a hangouts chat. Feel free to join me here whenever you want: https://talkgadget.google.com/hangouts/_/uon22uwibg3jvkeucbdnvxmzgya
- # [00:50] <Florian> I've given the url to Johannes
- # [00:52] <fantasai> okay
- # [00:52] <fantasai> minutes will be in IRC, I guess :)
- # [00:59] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
- # [00:59] * fantasai pokes TabAtkins
- # [00:59] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
- # [00:59] * Joins: dbaron (~dbaron@public.cloak)
- # [01:00] * Joins: johanneswilm (~johannes@public.cloak)
- # [01:00] * Joins: bradk (~bradk@public.cloak)
- # [01:01] <fantasai> dbaron: will you be on the floats call?
- # [01:02] <dbaron> fantasai, yes
- # [01:02] <dbaron> fantasai, assuming I can figure out how to be
- # [01:02] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
- # [01:03] <Florian> dbaron: the link is here: https://talkgadget.google.com/hangouts/_/uon22uwibg3jvkeucbdnvxmzgya
- # [01:03] <Florian> (that's google hangouts)
- # [01:04] <dbaron> lovely that it works with WebRTC in Chrome but requires a plugin in Firefox...
- # [01:05] <fantasai> ScribeNick: fantasai
- # [01:05] <fantasai> johanneswilm: Q1: Should page floats and inline floats use the same property, or are they two different things?
- # [01:06] <fantasai> johanneswilm: Q2: If we need to have both vertical stacking and horizontal stacking floats, which I think we need, what should the syntax be for specifying that.
- # [01:06] <fantasai> johanneswilm: If you're top left, how do you specify that it's stacking horizontally or vertically?
- # [01:06] <fantasai> johanneswilm: Also interested if there's anything else important that nobody has mentioned so far
- # [01:06] <fantasai> Florian: We started discussing this when discussing logical keywords for float
- # [01:06] <fantasai> Florian: I think it was Tab? proposed syntax assuming we'll work out semantics
- # [01:07] <fantasai> Florian: But syntax is not obviously compatible with semantics defined by johannes
- # [01:07] <fantasai> Florian: Not particularly attached to Johanes' proposal, has major advantage of actually being defined, but different could be okay
- # [01:07] <fantasai> Florian: But [...]
- # [01:07] <fantasai> TabAtkins: I just think floating to only two corners is stupid and dumb, we should be able to float to all four corners. Other than that, don't care too much about syntax.
- # [01:08] <fantasai> Florian: 2D Floats aren't exactly 2D, not just a random place on plane
- # [01:08] <fantasai> Florian: 4 corners, but also 4 corners of other page, and collision detection, avoidance, etc.
- # [01:08] <fantasai> Florian: How to split this into multiple axes, not sure
- # [01:08] <fantasai> Florian: We need a plan for how all of this works, not just say "do 4 corners"
- # [01:08] <fantasai> TabAtkins: Current mechanisms for avoidance aren't corner-specific
- # [01:09] <fantasai> TabAtkins: The 4 corners are easy to generalize to. More locations, if end up being useful, more work, but 4 corners are pretty obvious cutpoint
- # [01:09] <fantasai> johanneswilm: With 4 corners, those afaict, only require 2 stacking directions
- # [01:09] <fantasai> johanneswilm: If top left, only stack horizontally or vertically from there
- # [01:09] <fantasai> johanneswilm: But center right, 3 directions from there
- # [01:09] <fantasai> johanneswilm: can stack up, down, to left...
- # [01:09] <fantasai> johanneswilm: Supporting all 4 corners, that's a discussion ..
- # [01:10] <fantasai> johanneswilm: Between brad and I, we came to something that would work
- # [01:10] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
- # [01:10] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
- # [01:10] <fantasai> johanneswilm: Understand that it's preferred to always say block direction first, then inline direction
- # [01:10] <fantasai> johanneswilm: That's fine as long as we have some way to say otherwise
- # [01:10] <fantasai> johanneswilm: Would that be another property? something else?
- # [01:10] <fantasai> TabAtkins: It's okay to have multiple properties work together for layout, but need to be careful wrt computed value dependency
- # [01:11] <fantasai> fantasai: One thing you have to be careful wrt cascading effects
- # [01:11] <fantasai> fantasai: I would want 'float' to be a shorthand for all these properties
- # [01:11] <fantasai> fantasai: And think we should have longhands for all of these things
- # [01:11] <fantasai> fantasai: e.g. float-position for directions
- # [01:11] <fantasai> bradk: ...
- # [01:12] <fantasai> bradk: It seems that most of 2.1 rules don't apply to page floats, has special behavior for stacking / collision avoidance
- # [01:12] <fantasai> bradk: Would prefer if that feature used a different syntax
- # [01:12] <fantasai> bradk: Not muddy water between exclusions and floats
- # [01:12] <fantasai> TabAtkins: What do you want to move to exclusions? What would stay floats?
- # [01:12] <fantasai> bradk: i would reserve float for inline floats
- # [01:13] <fantasai> bradk: unless we want to add a vertical component to floats, too
- # [01:13] * Joins: dauwhe (~dauwhe@public.cloak)
- # [01:13] <fantasai> bradk: On the list, showing ideas for how you could have floats that move up / down in the containing block
- # [01:13] <fantasai> bradk: Johannes has something started that uses exclusions, so let him continue with that
- # [01:13] <fantasai> bradk: Make an exclusion property for that, though
- # [01:13] <fantasai> bradk: Instead of saying float: left; float-reference: page/column; which makes 'float: left' act very differently from other floats
- # [01:14] <fantasai> bradk: Make it something like wrap-stack: right or whatever
- # [01:14] <fantasai> bradk: By default you would just put it in that position in its containing block
- # [01:14] <fantasai> bradk: but if you use wrap-reference, or wrap-stack-reference to move to top of column or page, do that too
- # [01:14] <fantasai> bradk: none of this behavior where you're switching from one model to another
- # [01:14] <fantasai> Florian: Wrt exclusions, question to everybody
- # [01:14] <fantasai> Florian: I think there was, esp from Mozilla, resistance to exclusions in general
- # [01:15] <fantasai> Florian: If I understand correctly not based on exclusions model so much as lack of collision avoidance
- # [01:15] <fantasai> Florian: If this proposal, which turns them on including collision avoidance,
- # [01:15] <fantasai> Florian: reyling on exclusion mechanism here is it okay?
- # [01:15] <fantasai> dbaron: That was one of the2 big problems
- # [01:16] <fantasai> dbaron: The other was that the processing model was weird and slow
- # [01:16] <fantasai> dbaron: It would either produce result that's wrong in all the complicated case
- # [01:16] <fantasai> dbaron: or produce a result that's slow in all the complicated cases
- # [01:16] * fantasai dbaron++
- # [01:16] <fantasai> Florian: In this case, it cannot go into arbitrary spots. Does it make it better
- # [01:16] <fantasai> dbaron: Don't really know what this proposal is
- # [01:16] <fantasai> TabAtkins: page floats
- # [01:17] <fantasai> bradk: It takes wrapping from exclusions, then provides way to start in a corner and stack from there.
- # [01:17] <fantasai> bradk: Is that about right?
- # [01:17] <fantasai> dbaron: i think the problems with other proposal were related to sorts of reordering it could do, and how that would affect placement of other things.
- # [01:17] <fantasai> dbaron: E.g. placing things in a sequence that could be determined without iteration.
- # [01:17] <fantasai> TabAtkins: They are stacked in document order, at least.
- # [01:18] <fantasai> TabAtkins: Only funky bit is that you can intermix top and bottom floats
- # [01:18] <fantasai> TabAtkins: if you alternate between them, ...
- # [01:18] <fantasai> Florian: Remind me, if float to top-left etc. do we look at their widths
- # [01:18] <fantasai> johanneswilm: Right now don't have 2D in it
- # [01:18] <fantasai> johanneswilm: If we do add a 2nd dimension, secondary dimension
- # [01:18] <fantasai> johanneswilm: decides whether move to the leftmost or irghtmost position...
- # [01:19] <fantasai> johanneswilm: Both top left and top right would be on the same page and width of 100...
- # [01:19] <fantasai> Florian: If they have a width of 25%, can have both in the corners?
- # [01:19] <fantasai> johanneswilm: They would move down
- # [01:19] <fantasai> johanneswilm: We don't have this sytnax yet. Have to add it
- # [01:19] <fantasai> johanneswilm: To do 2D floats
- # [01:20] <fantasai> johanneswilm: If yo uhave them being riht top and left top, other way around,
- # [01:20] <fantasai> johanneswilm: so that right/left is prioritized dimension
- # [01:20] <fantasai> johanneswilm: then would be able to put in both corners
- # [01:20] <fantasai> fantasai: but then can't have in all 4 corners
- # [01:20] <fantasai> bradk: if you have both float top left and float top right, separate keyword for which direction, and both floating down, then should both fit
- # [01:20] <fantasai> Florian: Stack down
- # [01:20] <fantasai> johanneswilm: If we discuss all the ways to float, a billion ways to do it and none quite right
- # [01:21] <fantasai> johanneswilm: XSLFO ppl had a giant discussion of it and didn't come to a conclusion
- # [01:21] <fantasai> johanneswilm: Goal here is to ahve something that's simple enough
- # [01:21] <fantasai> johanneswilm: Could have in top right and top left corner, if the prioritized axis is not the top axis
- # [01:21] <fantasai> johanneswilm: then both can go to the top
- # [01:21] <fantasai> johanneswilm: but if you have a third one
- # [01:21] <fantasai> johanneswilm: and you go to the top as well, and enough space, then all three could be at the top of that first fragment
- # [01:22] <fantasai> johanneswilm: But if we disscuss everything gets very complex....
- # [01:22] <fantasai> Florian: I don't think we need to be able to everything right away, but need to be able to extend to where we want eventually
- # [01:22] <fantasai> Florian: So in your model [summarizes]
- # [01:22] <fantasai> Florian: What in your model is incompatible with clear property?
- # [01:22] <fantasai> Florian: If there's room in top right corner, go there, even if something in top lfet already
- # [01:23] <fantasai> Florian: We have clear property..
- # [01:23] <fantasai> johanneswilm: We also have clear here
- # [01:23] <fantasai> johanneswilm: If we add second dimension, say 'clear: left', does that mean nothing can go there?
- # [01:23] <fantasai> johanneswilm: Does that also mean go into next fragment?
- # [01:23] <fantasai> johanneswilm: Reasonable thing to say
- # [01:23] <fantasai> johanneswilm: top left, doesn't just say left, but we cleared for left, so go somewhere else
- # [01:23] <fantasai> johanneswilm: It's a question of how to deal with that.
- # [01:23] <fantasai> johanneswilm: We do use it
- # [01:24] <fantasai> Florian: Your model behaves a bit like having clear by default
- # [01:24] * fantasai agrees with Florian's description, noticed that while reading spec
- # [01:24] <fantasai> ...
- # [01:24] <fantasai> fantasai: what about in all 4 corners
- # [01:25] <fantasai> bradk: If you have 2 things in top left, would stack under each other in top left; ditto top right
- # [01:25] <fantasai> bradk: separate property says whether to stack vertically or horizontally
- # [01:25] <fantasai> bradk: Don't take up whole height/width for each piece
- # [01:25] <fantasai> johanneswilm: If you stack both horzitonal and vertical stacking in same fragment, get complex stacking within each fragment
- # [01:25] <fantasai> johanneswilm: Tried to avoid that by making this simplification
- # [01:26] <fantasai> johanneswilm: Stair type stacking that you mentioned, e.g.
- # [01:26] <fantasai> johanneswilm: I would really like to instead of talkinga bout all these different ways it can be stacked
- # [01:26] <fantasai> johanneswilm: This is a gigantic discussion
- # [01:26] <fantasai> johanneswilm: Other two points, should have clear
- # [01:26] <fantasai> johanneswilm: Is it okay to use a different property for it?
- # [01:26] <fantasai> johanneswilm: we would be okay with it
- # [01:26] <fantasai> johanneswilm: Initially when we talked about it in February
- # [01:27] <fantasai> johanneswilm: Thought about having different property, b/c different from regular inline floats
- # [01:27] <fantasai> johanneswilm: But astearns thought differently
- # [01:27] <fantasai> johanneswilm: So stuck with regular 'float'
- # [01:27] <fantasai> johanneswilm: If there's no opposition to another property name...
- # [01:28] <fantasai> fantasai: I don't think we should have two models for floating that are similar, overlap a bit, but are different in myriad idiosyncratci ways
- # [01:28] <fantasai> bradk: Have that already for exclusions
- # [01:31] <fantasai> fantasai says not to have two different models for floating (positioning aspect + wrapping) that do similar things. Good to have differnet layout models, but need to be significantly different, e.g. floats vs. flex vs. grid
- # [01:31] <fantasai> fantasai: Renaming something just to avoid the conflict doesn't resolve that.
- # [01:31] <fantasai> bradk: [.. scribe missed ..]
- # [01:31] <fantasai> johanneswilm: I understand idea of having page floats without CSS exclusions, but then have to redefine a lot of stuff already in the exclusion spec
- # [01:31] <fantasai> johanneswilm: 3 points brad mentioned from exclusion ..
- # [01:31] <fantasai> johanneswilm: one is scope
- # [01:32] <fantasai> johanneswilm: floats are applied to content afterwards in the document
- # [01:32] <fantasai> johanneswilm: page floats can go up, so can touch content that comes before
- # [01:32] <fantasai> johanneswilm: can't change that aspect, it's a fundamental aspect of page floats
- # [01:32] <fantasai> johanneswilm: positioning is another aspect of the differences
- # [01:32] <fantasai> johanneswilm: it says floats are inner floa, affect the inline box
- # [01:32] <fantasai> johanneswilm: By contrast, exclusions can be positioned using any positioning scheme
- # [01:32] <fantasai> johanneswilm: page floats, if you don' texplain them in terms of exclusions, you still end up somewhere else than this line box that you're in
- # [01:33] <fantasai> johanneswilm: I dont think we get anything in that sense out of it
- # [01:33] <fantasai> johanneswilm: what we can do is copy exclusions spec, add it to page floats spec, and drop anything that wasn't necessary
- # [01:33] <fantasai> johanneswilm: but I don't think we get around having to deal with this
- # [01:33] <fantasai> johanneswilm: but can't get around these things
- # [01:33] <fantasai> bradk: that's just a detail
- # [01:34] <fantasai> bradk: process is 1. move to different line box. 2. just makit behave like left/right floats
- # [01:35] <fantasai> fantasai: What was the third thing?
- # [01:35] <fantasai> johanneswilm: Separation of concerns, making wrapping separate from positioning
- # [01:35] <fantasai> johanneswilm: Because we define positioning in page floats spec, it wouldn't be in the exclusion spec
- # [01:35] <johanneswilm> http://www.w3.org/TR/css3-exclusions/#floats-and-exclusions-differences
- # [01:36] <fantasai> johanneswilm: So we say in page floats how it's positioned, and then rely on exclusions fo rhow the wrpaping happens
- # [01:36] <fantasai> Florian: page floats don't just move to the top of the fragmentatainer
- # [01:36] <fantasai> Florian: Can also escape nested contents, e.g. with multicol in a page
- # [01:36] <fantasai> Florian: You can't change container with regular floats
- # [01:36] <fantasai> bradk: in page floats specthey have property of float-reference
- # [01:36] <fantasai> bradk: and that is what moves it to the top or bottom
- # [01:37] <fantasai> bradk: What I suggest for inline page float model is that you have a property like that or something in between that an defer, where you're specifying which box gets flowed
- # [01:37] <fantasai> bradk: float on the line it's on by default
- # [01:37] <fantasai> bradk: if you say "top left" would go to the top of its containing block
- # [01:37] <fantasai> bradk: Once you set something like "move to nearest column" or "move to column 3 cols away" or "move to last col" would move to different box
- # [01:37] <fantasai> Florian: For deferring, don't see a problem
- # [01:38] <fantasai> Florian: For moving up, how that exclusion would intersect with nested things, not clear
- # [01:38] <fantasai> Florian: The float model doesn't define that
- # [01:38] <fantasai> Florian: You can't move there.
- # [01:38] <fantasai> bradk: That's what the new property would do.
- # [01:38] <fantasai> Florian: Need a model defining how that works, which is what exclusions does
- # [01:39] <fantasai> Florian: ..?
- # [01:39] <fantasai> fantasai: Effects of a 2.1 float are confined to its block formatting context
- # [01:39] <fantasai> Florian: You have a page with 4 columsn in them
- # [01:39] <fantasai> Florian: Float top right, reference to page
- # [01:39] <fantasai> Florian: Width of page is less than 50%
- # [01:39] <fantasai> Florian: I would excpect your float to affect content of rightmost cols but not leftmost ones
- # [01:40] <fantasai> bradk: If you put it across the page, the colum box would move down as a whole
- # [01:40] <fantasai> Florian: Exclusions would give you more generic mechanism
- # [01:40] * fantasai wonders where bradk is
- # [01:40] <fantasai> bradk: if it's the only thing in the top line box, it woudl treat following content as though following it
- # [01:40] <fantasai> bradk: It would wrap around it at that point, because out of flow.
- # [01:40] <fantasai> bradk: Floating within a box that normally ...
- # [01:41] <fantasai> Florian: Multicol below it is a BFC, therefore doesn't intrude
- # [01:41] <fantasai> ...
- # [01:41] <fantasai> Florian: I thikn a float before the multicol wouldn't intrude into multicol, because BFC
- # [01:41] <fantasai> Florian: Having this as one possible option is okay with me
- # [01:41] <fantasai> Florian: Having as only possible option, not so good
- # [01:41] <fantasai> Florian: So don't think 2.1 model is sufficient
- # [01:42] <fantasai> bradk: I have nothing against using exclusions model as long as separate from float model
- # [01:42] <fantasai> bradk: They've already put work into it... getting well-defined
- # [01:42] <fantasai> bradk: not a float anymore once you turn it into an exclusion
- # [01:42] <fantasai> bradk: float-like, but not anythign like what's described in 2.1
- # [01:42] <fantasai> bradk: lots of edge cases different...
- # [01:42] <fantasai> dbaron: 2 points
- # [01:42] <fantasai> dbaron: One is, there are a bunch of reasons for the BFC edge cases
- # [01:43] <fantasai> dbaron: At least for many types of BFCs, it's not clear what an intrusion from th outside would mean
- # [01:43] <fantasai> dbaron: e.g. something with 'overflow', don't want stuff inside to rewrap as you scroll
- # [01:43] <fantasai> dbaron: not meaningful to wrap around something at one scoll position
- # [01:43] <fantasai> dbaron: Another point is,, one of the big complexities of exclusion models
- # [01:43] <fantasai> dbaron: If you have something like a page float, which page is it on?
- # [01:43] <fantasai> dbaron: The rules for that are what gets complicated and slow
- # [01:43] <fantasai> dbaron: Thats one of the difficulties of going backwards
- # [01:44] <fantasai> dbaron: When you go backwards and displace content, you're displacing your "placeholder"
- # [01:44] <fantasai> dbaron: Rules for managing that are important for both quality and performance
- # [01:44] <fantasai> dbaron: And I don't think the Exclusion spec did a good job of that
- # [01:44] <fantasai> TabAtkins: [summarizes Exclusion's 2-pass method]
- # [01:44] <fantasai> Florian: For page floats, moving the anchor point being shifted isn't that important
- # [01:45] <fantasai> Florian: For general case of exclusions it does matter, but here not so much
- # [01:45] <fantasai> dbaron: need to specify used anchor position in an interoperable wya
- # [01:45] <fantasai> dbaron: If you spec "do layout without floats, then put floats and reflow", require 2-pass
- # [01:45] <fantasai> dbaron: In other situation, might be 1-pass in some caes but multi-pass in other cases.
- # [01:46] <fantasai> TabAtkins: Remember, 2-pass is exponential when nested.
- # [01:46] <fantasai> Florian: Do you have a model in mind, dbaron?
- # [01:46] <fantasai> dbaron: single-pass sometimes, e.g. you try to put page float on the same page as the placeholder
- # [01:46] <fantasai> dbaron: If float doesn't move the placeholder, can do kindof single-pass.
- # [01:46] <fantasai> dbaron: Might need to shift lines down, e.g. but don't need to redo layout
- # [01:47] <dbaron> shift lines down or redo a few lines
- # [01:48] <fantasai> [fantasai explains shifting lines]
- # [01:48] <fantasai> dbaron: If it goes to the next page, might need to redo layout
- # [01:48] <fantasai> fantasai: even then, could optimize if the width didn't change.
- # [01:49] <fantasai> johanneswilm: If anchor is being pushed ot next anchor because float has been placed, is that the question?
- # [01:49] <fantasai> johanneswilm: You can see that in one of the videos. that is okay
- # [01:49] * fantasai thought johanneswilm's videos were good
- # [01:49] <fantasai> johanneswilm: If a specific column contains the column at the time the float is placed, and then the anchor gets pushed, the float stays where it is. It's fine. That's why it's different than a footnote. Doesn't need to be on the same page
- # [01:50] * fantasai johanneswilm , paste URLs please?
- # [01:50] <fantasai> Florian: How is that different from what dbaron was saying?
- # [01:51] <fantasai> ...
- # [01:51] <fantasai> Florian: Not sure if Exclusions are the same or different from johanneswilm's model
- # [01:52] <fantasai> TabAtkins: ...
- # [01:52] <fantasai> Florian: Is there a way to avoid relayout?
- # [01:52] <fantasai> TabAtkins: The only way is the avoid wrapping around
- # [01:52] <fantasai> TabAtkins: and require top/bottom float to be full widht of the column
- # [01:52] <fantasai> Florian: johanneswilm's model seems to be minimal thing we could do
- # [01:53] <fantasai> fantasai: ....
- # [01:54] <fantasai> dbaron: Another option that avoids the two-pass thing.
- # [01:54] <fantasai> dbaron: If there is already content on the page, that your page float goes on the next page
- # [01:54] <fantasai> Florian: You always defer
- # [01:54] <fantasai> dbaron: Different authoring model, if you want something near the beginning, put it at the beginning of the article.
- # [01:54] <fantasai> Florian: This is limiting... not sure it's too limiting
- # [01:54] <fantasai> bradk: Need to think about that a bit
- # [01:54] <fantasai> johanneswilm: Was mentioned by Liam
- # [01:55] <fantasai> johanneswilm: If you put all the floats at the very beginning of what you write, then something that puts them in ....
- # [01:55] <fantasai> johanneswilm: Avoid all those problems
- # [01:55] <fantasai> TabAtkins: need to do that for positioning relative to placeholder
- # [01:55] <fantasai> TabAtkins: Or never be relative ot placeholder
- # [01:56] <Florian> https://www.dropbox.com/s/q6ej454sg1h74fb/2015-05-17%2015.52.13.jpg?dl=0
- # [01:56] <fantasai> fantasai: That's a terrible idea. Might work okay for fixed-size pages and small articles
- # [01:56] <fantasai> fantasai: Not going to work fo rillustrating Alice in Wonderland with varying-size screen sizes
- # [01:57] * Joins: bradk (~bradk@public.cloak)
- # [01:57] <fantasai> Florian: [??]
- # [01:57] <fantasai> dbaron: Definitely cases that are hard to do if always going to the next page
- # [01:57] <fantasai> dbaron: Reaonable to want content near its placeholder
- # [01:57] <dbaron> s/near/on the same page as/
- # [01:58] <fantasai> fantasai: I think we should clarify what all the concerns are, because I think we're too early to be aruging over which proposal is better before trying to make th eproposals fit the concerns
- # [01:58] <fantasai> Florian: What's the difference between 'float: top right' and 'float: right top' -- is it only about stacking direction, or is there more to it?
- # [01:59] <fantasai> johanneswilm: Just about stacking direction.
- # [01:59] <fantasai> johanneswilm: I think it's important to be able to specify stacking direction.
- # [01:59] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
- # [01:59] <fantasai> johanneswilm: In this case, can only stack horizontally or vertically...
- # [02:00] <fantasai> Florian: If we go with that model, could have the same behavior set by a separate property
- # [02:00] <fantasai> Florian: rather than implying the secondary direction
- # [02:00] <fantasai> Florian: We could consider sme kind of inline floats as a different container thing
- # [02:00] <fantasai> johanneswilm: Not sure I follow
- # [02:00] <fantasai> Florian: Suppose you have multicol text. do old 'float: left'
- # [02:00] <fantasai> Florian: floats to left of column
- # [02:01] <fantasai> Florian: want to float to left of multicol -- your model currently doesn't allow that
- # [02:01] <fantasai> johanneswilm: That's a discussion we had in February...
- # [02:01] <fantasai> johanneswilm: I felt that of course we need this, need to float to absolute top of current postion, and left/right of current position
- # [02:01] <fantasai> johanneswilm: And we ended up with that being rather complicated.
- # [02:01] <fantasai> johanneswilm: Stacking directions... 3 different posisbilities from there.
- # [02:01] <fantasai> johanneswilm: That's why we went away from that while discussing internally
- # [02:01] <fantasai> I'm not trying to figure out how tha tworks right now,
- # [02:02] <fantasai> but if we do 'float: top left', then the syntax of 'float: left' becomes available for trying to do this in the future
- # [02:02] <fantasai> johanneswilm: Unless we want to say 'float: left' is shortcut for 'float: left top' or something
- # [02:02] <fantasai> johanneswilm: But can say 'float: top' is osmething different from 'float: left right'
- # [02:02] <fantasai> bradk: I think it's time for me to go...
- # [02:03] <fantasai> Florian: Want to add a few things...
- # [02:03] <fantasai> Florian: One other point I wanted to raise..
- # [02:03] <fantasai> Florian: What triggered this entire discussion was Mozilla doing logical 'float' keywords
- # [02:03] <fantasai> Florian: 'float: start' vs 'float: inline-start'
- # [02:04] <fantasai> Florian: We had problem there because ...
- # [02:04] <fantasai> Florian: If we move to model where 'float: start start' and 'top left' are different
- # [02:04] <fantasai> Florian: maybe doing 'float: start' is alright
- # [02:04] * fantasai not sure she got that all correctly
- # [02:04] <fantasai> johanneswilm: I think brad and I came to a resolution on that, yes.
- # [02:04] <fantasai> Florian: If we want the thing I mentioned, 'float: left (not top)', can still be explicit about that, e.g. 'float: start none'
- # [02:04] <fantasai> bradk-
- # [02:05] <fantasai> s/bradk-/-bradk/
- # [02:05] <fantasai> johanneswilm: Put that in a future version, because stacking in 3 directions
- # [02:05] <fantasai> johanneswilm: Much more complex, how that works
- # [02:05] <fantasai> Florian: we will get even more confused once bidi...
- # [02:05] <fantasai> fantasai: Anything else to add?
- # [02:05] <fantasai> TabAtkins: I'm writing an email to the list... for the rest, just need to work on..
- # [02:06] <fantasai> TabAtkins: Working on what options we have for page floats without iterative reflow
- # [02:06] <dbaron> We implemented float:inline-start/inline-end for now
- # [02:06] <fantasai> TabAtkins: If this possibly addresses our uses cases, and what are other ways of optimizing correctness minimizing cost
- # [02:06] <fantasai> Florian: Simple point to start from is [?]? Otherwise unlikely to get implemented.
- # [02:06] <fantasai> Florian: Model needs to have stages, where we can add more complexity over time
- # [02:07] <fantasai> johanneswilm: If not now, then maybe think aobut for later, do we want to have the inline floats defined in this spec or not?
- # [02:07] <fantasai> johanneswilm: Right now kindof doing both...
- # [02:07] <fantasai> johanneswilm: Should probably only do one. Define everything in this spec, or not in this spec at all
- # [02:07] <fantasai> TabAtkins: I'm happy to have it all in
- # [02:07] <fantasai> TabAtkins: More things we move out of 2.1 the btter
- # [02:07] <fantasai> s/btter/better/
- # [02:07] <fantasai> TabAtkins: Regardless of what we do with page floats, I would pull this out. Decent fit conceptually
- # [02:08] <fantasai> johanneswilm: Okay, so just remove disclaimer about inline floats and import all the bits about inline floats
- # [02:08] <fantasai> Florian: Shoudl we call it Page floats?
- # [02:09] <fantasai> fantasai: Just call it Floats.
- # [02:09] <fantasai> johanneswilm: Waiting for list of issues... would try to put that in there.
- # [02:09] <fantasai> johanneswilm: If we do take out the reference to exclusions
- # [02:09] <fantasai> johanneswilm: I have nothing at stake with exclusions, but then ones who were trying to make this about exclusions would be unhappy about that.
- # [02:11] <fantasai> [Florian explains status of exclusions]
- # [02:12] <fantasai> fantasai: I would just call out the differences between exclusions-based vs non-exclusions-based floats as issues, to discuss individually
- # [02:15] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
- # [02:16] <fantasai> Florian: Another issue to write down, to solve eventually, page floats need to interact intelligently with multicol spanning
- # [02:18] <fantasai> johanneswilm: There are other things that will be very difficult to specify correclty, e.g. filling in gaps in float tesselation
- # [02:18] <fantasai> based on size of the floats
- # [02:26] <fantasai> Plan is to fold in 2.1 floats text into page floats spec
- # [02:27] <fantasai> change disclaimer at top to be a warning: look at 2.1, if conflicts follow 2.1 and report conflict to www-style
- # [02:32] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
- # [02:32] * Joins: dbaron (~dbaron@public.cloak)
- # [02:33] * heycam is now known as heycam|away
- # [02:47] <liam> [ yes, filling in gaps, and also the interaction with column spanning, a Hard problem ]
- # [02:56] * Parts: Florian (~Florian@public.cloak) (Leaving...)
- # [02:56] * Joins: Florian (~Florian@public.cloak)
- # [03:14] <johanneswilm> links to videos, as requested:
- # [03:14] <johanneswilm> Example 1 shows placement of top and bottom page flaots with a float-reference set to column.
- # [03:14] <johanneswilm> https://www.youtube.com/watch?v=nXwtsfOMIn8&feature=youtu.be
- # [03:14] <johanneswilm> Example 2 shows placement of top, bottom, right and left page floats in a mutlicol environment:
- # [03:14] <johanneswilm> https://www.youtube.com/watch?v=zsPUc8iEaHk&feature=youtu.be
- # [03:30] * heycam|away is now known as heycam
- # [03:54] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
- # [03:55] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
- # [03:58] * Joins: shepazu_ (schepers@public.cloak)
- # [03:59] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
- # [04:50] * Quits: Rossen_away (~rossen@public.cloak) (Ping timeout: 180 seconds)
- # [04:51] * Joins: Rossen_away (~rossen@public.cloak)
- # [04:51] * Rossen_away is now known as Rossen
- # [05:04] * Joins: dauwhe (~dauwhe@public.cloak)
- # [06:44] * Joins: zcorpan (~zcorpan@public.cloak)
- # [06:44] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [06:44] * Joins: zcorpan_ (~zcorpan@public.cloak)
- # [06:50] * Quits: myles (~Adium@public.cloak) ("Leaving.")
- # [06:56] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
- # [07:02] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
- # [07:11] * heycam is now known as heycam|away
- # [07:37] * Joins: teoli (~teoli@public.cloak)
- # [07:38] * Joins: zcorpan (~zcorpan@public.cloak)
- # [08:21] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [08:24] * Joins: johanneswilm (~johannes@public.cloak)
- # [09:11] * Joins: rego (~rego@public.cloak)
- # [09:32] * Joins: lajava (~javi@public.cloak)
- # [09:45] * Joins: Ms2ger (~Ms2ger@public.cloak)
- # [09:48] * Quits: rniwa (~textual@public.cloak) (Ping timeout: 180 seconds)
- # [10:03] * Joins: antonp (~Thunderbird@public.cloak)
- # [10:25] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
- # [10:26] * Joins: Florian (~Florian@public.cloak)
- # [10:35] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
- # [10:39] * Quits: johanneswilm (~johannes@public.cloak) ("Leaving")
- # [11:35] * Joins: Florian (~Florian@public.cloak)
- # [11:58] * Joins: teoli (~teoli@public.cloak)
- # [12:08] * Quits: rego (~rego@public.cloak) (Ping timeout: 180 seconds)
- # [12:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
- # [12:31] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [12:34] * Joins: Florian (~Florian@public.cloak)
- # [13:18] * Joins: dauwhe (~dauwhe@public.cloak)
- # [13:19] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
- # [14:05] * Joins: plh (plehegar@public.cloak)
- # [14:06] * Joins: Florian_ (~Florian@public.cloak)
- # [14:11] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
- # [14:27] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
- # [14:59] * Joins: sam (osamu@public.cloak)
- # [15:10] * Joins: rego (~rego@public.cloak)
- # [15:19] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
- # [15:21] * shepazu_ is now known as shepazu
- # [15:40] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [15:47] * Joins: teoli (~teoli@public.cloak)
- # [16:09] * Joins: teoli_ (~teoli@public.cloak)
- # [16:16] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
- # [16:16] * Quits: slightlyoff (~sid1768@public.cloak) (Client closed connection)
- # [16:16] * Joins: slightlyoff (~sid1768@public.cloak)
- # [16:41] * Joins: zcorpan (~zcorpan@public.cloak)
- # [17:04] * Quits: rego (~rego@public.cloak) ("Leaving")
- # [17:40] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
- # [17:56] * Quits: sam (osamu@public.cloak) (Ping timeout: 180 seconds)
- # [18:02] * Joins: zcorpan (~zcorpan@public.cloak)
- # [18:05] * Joins: zcorpan_ (~zcorpan@public.cloak)
- # [18:05] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [18:08] * Joins: tantek (~tantek@public.cloak)
- # [18:20] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
- # [18:27] * Joins: zcorpan (~zcorpan@public.cloak)
- # [18:51] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
- # [19:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
- # [19:18] * Joins: liam (liam@public.cloak)
- # [19:24] * Joins: lajava (~javi@public.cloak)
- # [19:43] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
- # [19:59] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
- # [20:00] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
- # [20:06] * Joins: teoli (~teoli@public.cloak)
- # [20:29] * Joins: rniwa (~textual@public.cloak)
- # [20:31] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
- # [21:08] * Quits: tantek (~tantek@public.cloak) (tantek)
- # [21:18] * Joins: zcorpan (~zcorpan@public.cloak)
- # [21:26] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
- # [22:32] * Quits: rniwa (~textual@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
- # [22:32] * Joins: rniwa (~textual@public.cloak)
- # [22:49] * Quits: rniwa (~textual@public.cloak) (Ping timeout: 180 seconds)
- # [22:51] * Joins: dbaron (~dbaron@public.cloak)
- # [23:31] * Joins: myles (~Adium@public.cloak)
- # [23:44] * Joins: teoli (~teoli@public.cloak)
- # [23:44] * Joins: sam (osamu@public.cloak)
- # [23:53] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
- # Session Close: Wed Dec 16 00:00:00 2015
Previous day, Next day
Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn