How to increase margins of containers for pending floats ? #4052
Comments
|
Doesn't establishing the new Block Formatting Context (either by explicit setting |
|
None of the 10 proposed solutions are what I expect. All of them still leaves the float going "inside" the block (that they cover). What is sufficient is that, when increasing automatically the margins due to external floats still needing space, the minimum width for the new container will be respected; otherwise a vertical clear will occur along each successive floats pending vertically until there's space, or all floats have been cleared. When such clear will occur, this will just increase the top margin of the new container, but the border, background, and content of the new container will be also moved vertically. As this leaves some space above the container, some of the pending floats may be placed there instead of stacking vertically. The renderer could automatically select the floats that best match that empty space. The block formatting context does not help here. And as I said the typical usage is for illustrations added in Wikpedia articles: there's no easy way to place them in the article, including when their vertical height is variable, and even ajustable (e.g. my collapsing/expanding a floatting infobox). As well we cannot predict the effective rendering display width, the article being read on narrow smartphones or large desktops. It's a common problem in articles: it's difficult to find the appropriate place where to include these floatting illustration. So finally we use too many "clears" and space is wasted on all screens. Note that the situation is simpler when all floatting illustrations or lateral notes will go to a dedicated and cumfortable lateral margin, but this is only used for output printed on paper with known page sizes. Floats were initially intended for lateral ilustrations, and this is still the majority of use of them in Wikipedia articles (also with lateral infoboxes, or floatting TOC's which are collapsible). But finally we have to group all the floatting illustrations and boxes at top, an not in the relevant sections they should illustrate, so that they can stack correctly, and then we can remove all clears: this works well for dektop screen rendering but not so well for small mobile displays (notably those held in portrait mode), and that was the reason for creating another layout for the mobile version of the wikis. |
This doesn't seem right, see https://www.w3.org/TR/CSS22/visuren.html#floats
So please clarify why "The block formatting context does not help here". An example with code would be useful. |
|
Your reference does not apply: the floats effectively cover the content (notably their background and border; only the inline content of the content will wrap around the float, but not any block container in the content, which are not affected at all by the presence of floats that are superposed to them.
As well the floats will cover the horizontal rules in the content (that may then be visible through the floats, inside them, if these floats are not completely opaque)
The contents around floats cannot be properly aligned (e.g. bulleted lists will not have their bullets properly set in their right margin, but will be "glued" to the float, leaving the text content of the list item aligned vertically with the margin of the previous paragraph, instead of being indented).
Left and right margins in the content flowing around floats are never respected.
I need to make a "graphic" to present the problem because you don't
understand.
```
|<----------PAGE WIDTH------------------->|
| : : |
|< MARGIN >:< CONTENT BOX >:<MARGIN>|
| : TEXT HERE... : |
| +-------+ ...TEXT HERE: |
| | INNER +-------------| |
| | LEFT | INNER | |
| | FLOAT | CONTENT BOX| |
| +-------+ | |
| : | | |
| : +-------------+ |
| : : |
```
Here I want to be able to size the new inner box according to the position
of the inner float. I don't want the inner content box to flow "around it"
(not even below it, it must remain to the right of it so that all left
floats will be in the left margin of the inner box, which remains
rectangular. Its width is then autojusted (reduced) as long as its
"min-width" is kept.
But if this is not the case, the inner box will "clear" vertically to go to
just below the float, and then will use the full width of the parent
content box:
```
|<----------PAGE WIDTH------------------->|
| : : |
|< MARGIN >:< CONTENT BOX >:<MARGIN>|
| : TEXT HERE... : |
| +-------+ ...TEXT HERE: |
| | INNER | | |
| | LEFT | cleared | |
| | FLOAT | | |
| +-------+-------------+ |
| | INNER CONTENT BOX | |
| +---------------------+ |
| : : |
```
This makes easy to insert floats any where before, and ensures that the
innerbox will never "wrap" around them (e.g. with their border or
background).
All I need is a way to specify that the inner box will not overlap any
float (left floats can continue flowing to the left as long they fit in the
left margin of the inner box). So I need a way to specify that the
left-margin inner box will never include any space used by the float, and
that the inner box will remain either completely to the right of left
float, or fully below it.
Visually, this creates the minimum "clear" space, and we don't have to
depend on the presence of absence of any prior float.
And the inner contenet box will still have a suitable minimum width, that
can be increased if needed to cover the whole width of the parent content
box. We don't need to size the inner content box, and we don't have to know
which margin to use (which would be useless if there are in fact no floats
before).
What I describe is just a way, a flag, to specify the left margin of the
inner box, in such a way that its margin will be increased (if possible) to
avoid the floats (but at the same time this would reduce the width of the
content-box for the inner box, that's why we need a "min-width" also for
the inner content box.
And simple way to specify it would be that the inner box would not just say
"margin-left:2em", but "margin-left:2em+0.5em", the "+" indicating that it
may be increased by the presence of prior left float (with ANY width). The
"0.5em" is optional: it allows setting an additional margin for the content
box, used only if there's a left-float, and that extra 0.5em will collapse
with the right margin of the float, the margin between both being the
higher value of the two
* so if the inner float has a "right-margin:0" the gap separating them
horizontally will be 0.5em = max(0, 0.5em)
* if the inner float has a "right-margin: 1em", the gap separating them
horizontally will be 1em = max(1em, 0.5em)
* Generally the floats have a small horizontal margin on their internal
side, and a 0 margin on their external side to align them with the parent's
content box.
As well for the "margin-right" with right floats.
Now floats can be present or absent, and can have any width if they are
present: the inner box will autoadapt its margin, but will clear
conditionally if their min-width cannot be satisfied.
We never have to reserve some arbitrary margin for the inner box when we
don't know if there will be floats before (and these floats may
appear/disappear: imagine that the float is vertically collapsible (like
the TOC in a wiki page if it has been placed in a left-float).
Note: my "graphics" between ```triples marks``` do not appear with monospace font here (markdown is not honoured).
Copy paste these two into an external text editor using monospace font.
The message was correctly rendered in the original mail (which was formatted as HTML, not with markdown used here after it was converted by GuitHub). And I don't see how to enable it again when reediting this message from GitHub)
|
|
Note that the main use for this feature is when the inner box has a
distinct background and borders (because they remain sized and aligned
according to the parent's content-box), so these backgrounds and borders
will appear "under" (partially masked) or worse "through" the float (when
the float is transparent or semi-transparent: the content of the float
itself becomes unreadable, polluted by the content in fact placed after it).
Note also that when this feature is enabled and the computed
min-width+borders for the inner box does not fit in the remaining space not
already occupied by floats, then the inner box will clear automatically
below the float.
That inner box is still not a float by itself, it may have its own inner
floats.
And the inner box which has been automatically "cleared down" will have to
respect and collapse its top margin with the bottom margin of the left
float.
As well the shortcut notation for margins can still be used for the
innerbox:
margin: 0.5em 2em+0.5em;
means that there's:
- a top margin of 0.5em with any prior content in the parent box, or with
any prior left or right float below which the inner box was placed.
- a bottom margin of 0.5erm with any further content in the parent box, or
with any further left or right float which may follow the inner box
- a minimum left or right margin of 2em (where floats may be placed), but
if there are floats positioned inside the parent's content-box, ouside
these margins, then the inner box will have an extra left of right margin
of 0.5em in addition to the floats' border+margin
The value "+0.5em" may be written "+0" when only the floats margins matter
(generally floats define their own margins with the content placed round
them) or with their "relative" parent top and bottom content box) or just
"+"
With a single value for the margins of the inner box:
margin: 2px+0.5em;
Here the inner box just defines 2px of margins on all sides, but in case of
floats present, these margins are extended to 0.5em with these floats to
the left, right, top or bottom.
|
|
@verdy-p I wonder if this case could be solved with grid layout instead of floats. You could define a column on the left where you position the content that would have gone to the floats, and the next column would take up the "Inner Content Box" content. The left column's width could fall to zero if there is no content for it, and the start edge of the right column's content would always adjust to the left column's maximum width. |
@verdy-p IMO that seems perfectly doable with a BFC root. Example Instead of your |
|
No, I don't want the grid layout, because the floats have sizes completely independant of the inner box I want to place and completely unpredictable: these floats are generated externally and there's not even any way to know when they exist. A typical usage is when the inner box shows a notication box or an horizontal navbox that should be completely opaque and not being covered by any prior floats. And the presence of these floats must not cause the inner boxes to have their content size expanded vertically. Finaly note: the inner box may also have their own floats: but because the margins was expanded, they can continue to be aligned vertically with the prior floats (i.e. outside the inner box, unless the inner box is a new "relative" parent for containing these inner floats. In the inner box, the inline content can still wrap around the inner floats when needed, for example when the inner floats are larger than the prior floats). As well the inner floats will fit below prior floats, stacking vertically as necessary, they won't cause additional "clears" of the contents of the inner box. This proposal is consistant with simple formatting of articles with illustrations or lateral notes placed in floats. |
|
note that your example with BFC is not consistant: you've broken the two parts of the "TEXT HERE... TEXT HERE", but this is the SAME inline content flowing around the prior float. As well the inner box may contain their own floats (that will also align vertically normally with the prior float), stacking vertically normally. And this rectangle is were we can also place bulleted lists (for now this never works, the list items are incorrectly aligned because the bullet margin collapses into where the prior float are placed: they are aligned to the margin of the parent box, and not aligned with the margin of the prior floats where "normal" text flows. Text indentation in the content also does not work (it is broken by the presence of prior floats: we should be able to isolate them within inner boxes where the margins are increased). So the inner box can be:
|
Irrelevant, that's outside the inner box BFC root
This was not in your graphics, but also irrelevant
OK, that's the real reason that prevents you from using a BFC root. You should have said this from the beginning instead of insisting that BFC roots don't work. It seems what you need is a feature that prevents block boxes from overlapping floats (as if they were BFC roots) but without establishing an independent formatting context, to avoid containing inner floats. To me this seems more reasonable than Though it would be kind of circular if the size of this container could be reduced by inner floats, since inner floats could be sized with percentages relatively to this container. So it seems complicated. |
|
Now the example modified shows other problems caused by incorrect margins (for bulletted items in the inner box). You can see that only item 3 is correctly positioned in the inner box, but items 1 and 2 are not relative to a normal float: these items need to be embedded as well (individually or the full "ul" list) within their own inner box, to be correctly positioned relative to prior floats. That's one of the many quirks we see. But your proposal using BFC roots is almost usable. So there's no way for inner floats to align with outer floats: they will all take all their space in the inner box (which is opposed to the fact that we want to avoid the inner box to clear down, as much as possible because it has insufficient width. But putting the inner floats completely inside the inner box then makes non-sense, they should still flow like outer floats. Is there an alternative to "display:flow-root", so that it will apply to the box itself and its normal content flow, except its floats content which will continue to use the margins inherited from the parent? I proposed the augmented margin values because it was in fact not changing the formatting context, and the inherited margins were still there: all that is needed is to specify alternate margins in case of presence of floats, and that will replace the normal margin for the normal content (text, for bullet/numbered lists, or indented text, like for BFC "display:flow-root"), but will not affect the placement of floats in that content, that will cointinue to use the inherited margins. So may be a "display:flow-content-only" ?? "display:flow-except-floats" ?? (I'm concerned by the placement of the green-colored inner float, which should not be inside the inner box but just below the existing magenta outer float that already created the necessary margin for it and that will still use the inherited margins of the yellow outer box, the same margins used by the prior magenta outer float.) And how to resolve the existing bug for list items and indented text? (see the bullets incorrectly placed) And because the BFC solution forces ALL the content of the inner box to be on the right of the prior float, we can't use it to place bulleted items, or individual paragraphs or other blocks. We need another solution: the BFC establishes a new context that applies to only clearly delimited boxes (with background, borders) We still need to find a way to correctly position the hr rulers so that they will also not be overlapped by prior floats, but will use their own BFC context. For now I see no simple solution, except what I propose with augmented margin values, that replace normal margins when there's a float beside the block. If changing the syntax of "margin: values" is too complicate, may be be can have a separate "margin-with-float: values" for any content box, and that will apply individually to all its child blocks (including list items or "dd" items in definition lists for their bullet/number/indentation margin) in presence of a prior float taking space in the content box, except child floats and positioned elements, that are still rendered within the margins of their nearest "relative" or "absolute" ancestor context. If there are no longer any floats taking space in the content-margins, the standard "margin: values" will still apply to all children, except floats also using the margins of the inherited relative or absolute content. |
|
Note that when playing with ways to solve the problems for the placement of bullets and their margin, I discovered a probable bug in my browser: when the list item has a "opacity:1" (the default), the bullet is drawn over the float that covers it (so it appears as plain black, the default foreground colon); but when "opacity:" has any other value<1, it is drawn under the floats that covers it (because that float is maggenta, the bullet appears as dark magento with "opacity:0.8" |
|
Also my question is more general:
|
It's impossible to define a correct left or right margin for a container, when there are conditional floats pending (on the left or right) and defined outside the new container.
We should be able to increase the margin to take into account the maximum width and margins specified by any pending floats (as they can exist even outside the container itself).
If the computed "minimum width" of the container cannot fit in these increased margins, then it will "clear" vertically automatically after the first float (still pending on the left or right of the container, not necessarily all the same width) that leaves enough space for putting the content.
In frequent cases, (e.g. with floatting illustration images or lateral navboxes used in Wikipedia articles), it is impossible to predict where these floats will end, and
So I suggest "margin-keep: floats/float-left/float-right" (possibly also "float-begin/float-end" to take into account Bidi and notably direction of the parent, independantly of the directionality of the container itself and of its content children).
Or alternatively:
Note as well that floats attached one side may also exceed their "relative parent" content width. and we should be able to limit their default width (unless this width is already their minimum width, in which case they will still overflow their "relative parent", which may then have to either "hide" the excess or use automatic horizontal scroll to allow seeing the float completely on a interactive output, or to render their excess on separate pages with a printed or non-interactive output with static page width).
All this is needed to correctly adapt also to various output devices (notably narrow screens on smartphones, where it is also essential to not "waste" the horizontal space available, whose usage should be maximized, otherwise the output is just hard to read and navigate with excessive vertical scroll and line breaks occuring too often when margins are too high with the conventional solutions).
This suggestion is independant of "margin-trim:" for the layout of content children of the container itself.
The text was updated successfully, but these errors were encountered: