w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 661 forks source link

[css-page-floats] [css-logical-properties] state of logical directions in relation to floats #220

Open johanneswilm opened 8 years ago

johanneswilm commented 8 years ago

It has been a while so I have been looking at what i could find of communication on this. The following is my understanding of the situation:

Page floats are currently defined as moving only in one direction (inline-start/end or block-start/end). For this reason the direction had to be specified saying whether it should either be the inline or the block direction the float went in.

Through the discussion about this, and various people pointing out how this would be problematic, I came to agree with those critics of the current draft such as @tabatkins, who held that page floats really always need to be two-dimensional: they need to go to one of the four corners of the fragmentainer they are in, and there is not any sense in only having page floats be able to float in two of the possible four corners.

If the spec is changed accordingly, this should no longer be an issue as both directions will need to be specified.

So it can either be A) that we use "float: start start" where the first "start" is the block direction and the second is the inline direction, or B) we can use "float: block-start inline-start" in which case the order doesn't matter. We can also agree a shorthand for solution A, if only one direction is mentioned, that "start" stands for "start start" and "end" stands for "end end". I do not have an opinion on whether A or B is better.

There is one more issue to deal with: What is the stacking direction of the a second and third float? Does it stack in the inline or the block direction? If we use solution A, we can for example ass a new property for that. If we use solution B, we can say that the first direction specified is the principal direction. See also my videos from last winter about this: https://www.youtube.com/watch?v=nXwtsfOMIn8 and https://www.youtube.com/watch?v=zsPUc8iEaHk

It has been a while, so my understanding of the state of the discussion may be somewhat incorrect, but if I'm not mistaken we seemed to be close to a consensus on this. @bradkemper seemed to maintain a more general criticism of defining page floats in terms of exclusions and I think he wanted to possibly write an alternative spec in which he wanted to expand the current inline floats to be able to float in two directions (?), but if I'm not mistaken, the issue of inline-start/end was not part of that disagreement.

You can read the previous discussion about this here: https://lists.w3.org/Archives/Public/www-style/2015Nov/0044.html (admittedly, I did not read all of it).

bradkemper commented 8 years ago

"B" is definitely better, IMO. And "start" meaning the same as "start start" is good too. These all follow general existing syntax patterns of CSS.

bradkemper commented 8 years ago

It wasn't so much that I wanted to write a different spec. It was that I would expect properties with "float" in their name to be based on existing (inline) floats, and I was describing a theoretical spec that was based on how existing (inline) floats could gain a second dimension without changing what the first dimension meant in combination with the second.

I'm perfectly fine with page "floats" being based on exclusions, as long as they are separate from existing floats, and don't mix exclusions into the same property names, or use 'float' as part of the property name. They should have property names and spec terminology that doesn't use the word "float" for anything, other than to point out the ways that floats and exclusions are similar or different. I didn't like the mixing of the two distinct methods of stacking and wrapping elements.

frivoal commented 8 years ago

I'd got for A, with the start -> start start shortcut. This is less verbose with no loss in what can be expressed. Sure, you need to remember which is inline and which is block, but as long as we keep it consistent with the rest of the language, it's not that bad.

johanneswilm commented 8 years ago

@bradkemper: Did you mean "A"? I believe just using "start" for "start start" will work only with "A", right?

johanneswilm commented 8 years ago

@frivoal @bradkemper Are you people then fine with using a new property for the stacking direction? Or how would we specify that? Or should we have something like start start block where the third is the stacking direction?

frivoal commented 8 years ago

There is one more issue to deal with: What is the stacking direction of the a second and third float? Does it stack in the inline or the block direction?

To me this feels like a generalized version of what the clear property solves for inline floats. Having a separate property for that (or extending clear, if we can do that in a way that makes sense) would be fine with me. Additional keywords are probably fine as well. We'd need to look into concrete proposals, but I don't think this has to be a blocking issue for the naming discussion.

bradkemper commented 8 years ago

Yes on "A", except the first one should be for inline direction, second for block. Reasoning: in Latin scripts (which we tend to favor slightly when we have to make these sort of decisions), inline is horizontal. In 2 part values where one is horizontal and the other vertical, the horizontal always comes first.

bradkemper commented 8 years ago

Are you people then fine with using a new property for the stacking direction? Or how would we specify that? Or should we have something like start start block where the third is the stacking direction?

Or, we could have two different properties instead of one main one. So for instance, assuming we replace 'float' with 'wrap-float' to distinguish it from inline floats and to show the stronger connection to exclusions (whose properties all start with 'wrap-'), we would then replace 'wrap-float' with 'wrap-float-inline' and 'wrap-float-block'. Thus, 'wrap-float-inline: start start' would move the element to the start start corner, and stack in the inline direction. Which is to say, if there was already a 'wrap-float-' in that corner, the element would stack up against it in the inline direction.

bradkemper commented 8 years ago

Or even if we kept it to one property ('wrap-float: start start inline' OR 'wrap-float: start start'; wrap-float-direction: inline'), if there was already a 'wrap-float' in that corner, the element would stack up against it in the specified direction.

johanneswilm commented 8 years ago

@bradkemper Ok, but let's keep the question of "wrap" out of this. I said I wouldn't actually mind given this a name other than float, but my understanding is that so far everyone else wanted to keep the "float" name for this. At any rate, let's keep that in a separate discussion (maybe open another ticket if you want to continue to discuss that).

So far, it seems we all agree on using "start start" and "start" as a shortcut. I don't really care whether block or inline comes first. Is everyone fine with @bradkemper's proposal to have the inline direction go first?

bradkemper commented 8 years ago

On Jun 27, 2016, at 9:59 AM, Johannes Wilm notifications@github.com wrote:

but my understanding is that so far everyone else wanted to keep the "float" name for this.

I'll just say that is not what I recall. In the group call we had, I remember there was at least some agreement to move it to a different property. I will continue to object to polluting the 'float' property with exclusions, when it is really a whole different model. But I can do that in a different thread, if you want. It's just that that decision affects a lot of other decisions, so it is not entirely orthogonal.

johanneswilm commented 8 years ago

Check the log. The resolution was to just call it "floats" and to fold regular floats into the page floats spec and call it all "CSS floats"

Start reading here: https://logs.csswg.org/irc.w3.org/css/2015-12-14/#e629436

There was also opposition toward having a second property with very similar functionality there.