How to force child element adherence to `flex: nowrap;` CSS directives
I have a couple of d3.js animations on-screen at the same time, each governed by CSS
display: flex; and
flex: nowrap; directives, the only telling difference between the problematic one (which wraps) and other, correctly-displayed (ie non-wrapping) animations being that:
- because it has non-svg header and text input elements, it comprises anchoring
sectionelements. (As I understand, these, being block-level, theoretically occupy the entire available display width, and so have, in the css file, been 'overridden' with the setting
- overflowing svg path elements, whose length has now been physically curtailed so as to match the limits of the containing svg:svg element.
Frustratingly, the animation steadfastly refuses to be governed by the
flex: nowrap; directive.
Is there a general approach to ensuring that flex row nowrap behaviour is determined by what is actually visible on-screen, and not by containing (or sibling) block-level elements such as
div, or wider but
overflow: hidden; child svg
Note: other questions/answers on this topic relate to text, not section, div or svg.
All animations are theoretically governed by the parent
flex-flow: row nowrap; setting.
The associated widths are such as to allow plenty of free space around each.
It would be nice to think the parent
flex-flow: row nowrap;, taken together with the svg:svg element's
overflow: hidden; and the block-level
display: inline; CSS settings would be enough to ensure that no wrapping occurs. I have checked in the inspector, and all dimensions displayed lie within limits required for
flex-flow: row nowrap;.
The only elements in play are
li. In practice, something is leading to unwanted wrapping. My feeling is that the block-level elements are the source of the problem. Can you suggest a strategy to avoid this?
Failing this, are there alternatives I can use as containers for text input elements which are less likely to cause problems?
Once again, the answer arrived during sleep.. :-)
Firstly, use of display: inline; on block-level elements seems not, at least in this situation, have the effect on width claimed by some bloggers (in fact tends to pollute the parent flex context).
This in turn led to a search for alternative inline elements to replace
section. On substituting the inline element
span in place of the block-level elements
section, the desired
nowrap behaviour immediately took effect, but in turn knocked out my (now local) vertical block layout. This was restored using
display:inline-block; on the containing span, so:
originally (somewhat simplified):
---------- header / div--- svg:g -- svg:svg (with overflow:hidden;) \ ---------- user text input area
..which, despite a parent
nowrap directive, was caused to wrap by the div (or other block-level) element.
---------- header / span-- svg:g -- svg:svg (with path extents matching those of svg:svg container) \ ---------- user text input area
..whereby span has the css
display:inline-block; directive set on it and a width specified. Here, the parent flex nowrap directive was adhered to, but locally (ie inside the span) the block layout is applied.