We have a React Virtualized Table with a header row.
One (or more) of the header cells will contain a drop down Componentallowing you to select values to filter the column by.
We have created the Component, and the ValuePanel has position: absolute; to make it float above the other elements on the page.
We included it in the header and it mostly works, except that the HeaderRow has overflow:none; on it.
<div
class="ReactVirtualized__Table__headerRow table-toplevel-row table-toplevel-header"
role="row"
style="height: 100px;overflow: hidden;padding-right: 17px;width: 1920px;"
>
This "chops off" the bottom of the panel showing the values.
Reading up on overflow: none; and position: absolute; it seems that the ValuePanel must have a (positional) parent outside of the HeaderRow.
This can be achieved by either:
Moving the ValuePanel element so it's no longer an ancestor of the HeaderRow.
Having the nearest ancestor of the ValuePanel element with a position of absolute or relative (i.e. it's positional parent) outside of the HeaderRow.
The problem with 1, is that the Component is supposed to be a self-contained and reusable anywhere, so it shouldn't require part of it's HTML to exist outside of itself ... that violates the "self-contained" bit.
The problems with 2 are that we won't always be able to guarantee where the positional parent is in the hierarchy above the ValuePanel unless the positional parent is inside the Component. And the ValuePanel gets it's width from it's positional parent, so if the positional parent is outside of the Component then the width could well be wrong.
We very much want to avoid having to specify a fixed width for the component and/or the ValuePanel. And we want to keep the Component self-contained.
The thought occurred to remove overflow: none; from the HeaderRow, but it's obviously there for a reason. I haven't tested, but I assume getting rid of that would cause issues with header content that, well, overflows. We could replace it with overflow-y: none;overflow-x: hidden;, but again this seems like it's likely to cause issues under certain circumstances.
I had a search around, but I couldn't find any results for it.
Has anyone achieved this before and can provide some insight? Or otherwise has some ideas/advice?
Slightly longer answer now that I'm back at my computer: Check out react-portal.
It lifts content out of the z-index stack (and so avoids clipping problems) while maintaining the visual position of it (top/left), allowing it to render outside of the clipping rect/box of its parent. It's perfect for things like drop-down menus within List or Table.
Related
I am currently using the following css to display a list of items with a flexbox
section ol li div ul {
display:flex;
flex-direction:row;
flex-wrap: wrap;
gap:7px;
row-gap:0;
list-style-type: none;
}
This satisfies me on all but one problem:
when I have a big item that will not fit entirely on the rest of the line, it will be set at the beginning of a new line, thus possibly making a huge part of the line before unused. I do not wish that (note that for small items, this is exactly what I want).
Initial goal (probably not achievable): I have been thinking on what kind of rule I would like and it would be something like "if more than x% of the line is wasted, then display the item inline instead". This would enable to continue filling the line.
I have currently abandoned on doing that with only html and css and I might consider trying to write such a rule in js later, but not for now (unless somebody has a very nice solution).
Current goal: I have thus decided to manually specify some items (that are "big") that should be inlined (sometimes using media queries, but we can ignore them for now). The idea is to add the following class to those objects.
.inlineitem {
display:inline;
}
Problem: display:inline; within a flex container does not work and I do not wish to change the whole flex container for the other items... Is there a way to achieve what I want ?
Are there situations where an SVG <text> element's dominant-baseline style will be ignored?
I have two <text> labels in two different parts of my SVG. The dominant-baseline: central applied to one works without issue (for example, when I open it up in Chrome's web inspector and change the value, the element moves around as I would expect it to), but it does not seem to affect the other (ex, changing the style's value from the web inspector doesn't change the position of the element).
Is there any reason this could be?
Here is a screenshot of the relevant code:
(I'll post a fiddle demonstrating the problem if I can figure out how to reproduce it)
The culprit was an errant display: inline that the .label was inheriting from its HTML counterpart.
The fix:
svg.label {
display: block;
}
Basically creating a webpage with a dropdown menu I wrote following a tutorial. My page layout consists of 3 separate tables which include 1 for the title/banner, one for the drop down menu and one for the body/content.
The problem I am having first off is that when I scroll over my drop-down menu it drops behind my body/content table. I found a fix for this which was to include z-index:-1. This worked perfectly in IE but after testing it in chrome it prevented links and iframes to be interacted with on the content/body table.
#bodytable {width:1100px;
height:100%;
margin:auto;
position:relative;
top:10px;
z-index:-1;
}
The entire .css code can be found here:
http://pastebin.com/T97JAjQ8
Try giving them each a positive z-index value. Obviously the higher numbes will be "on top" of the other with lesser value. Instaed of giving a table "-1", give it something positive, like 10 and make the dropdown menus "20". You can even set the z-index of the body, to 0 as a baseline.
I haven't confirmed this, but it could be that chrome doesn't like negative z-index values.
Giving Negative z-index makes your element to go under body or wrapper div and hence, prevent them to be interacted because the body element is on the top of that table when you click the event occurs on the body tag not table tag. You have to give positive z-index value. Default stack order of elements is determined the position where the element is defined. For example, your table will be have a larger z-index value if it is defined after menu div. You can fix your problem by changing only the current stack order. By just changing that negative value to positive.
element {
z-index:1;
}
The above code will set the target element to be on top of others beside the current stack order.
I'm considering the use of the <span> tag for grouping a set of arbitrary elements together, but I don't want it to have any visual impact in the structure of the document whatsoever.
I want to use that tag for later manipulating the set of elements within it with JavaScript in some way, such as e.g. detecting whether the mouse entered or left the region, etc.
My question is whether there are cases when the presence of the span tag will disrupt the flow of the document, making the elements within it or the elements around it behave differently from when it's absent.
Of course, I'm aware the presence of an additional node on the DOM can disrupt some CSS selectors which are not expecting the span, and I'm also aware that styling the span can cause the layout to change (e.g. if I added a border I could cause elements to wrap to the next line, etc.). But aside from that, is the span tag neutral? If not, how should I go about figuring in what cases it is not?
Thanks in advance!
-- edit --
I tend to forget that it's wrong to put block-level elements inside inline elements like span, so I can't use span to wrap just everything the way I intended.
So, in case one or more of the elements I'm grouping is block-level, should I use a div instead?
The <span> element is defined to be an inline (text-level) element. Otherwise, it is semantically empty and layout-neutral.
By HTML syntax, the <span> element must not contain block elements, such as <div>. If you violate this, there is no specification of what browsers should no. It sounds pointless to play with that, when you can use the <div> element. It is defined to be a block element, which means that in rendering it by default starts on a new line and any content after it starts on a new line (but no empty lines are generated by this behavior). Otherwise, it is semantically empty and layout-neutral.
Directly of http://www.w3.org/wiki/HTML/Elements/span
The element doesn't mean anything on its own, but can be useful when used together with the global attributes, e.g. class, lang, or dir. It represents its children.
The validator at http://jigsaw.w3.org/css-validator/ says that the value 'text' for 'user-select' is not valid. For a css rule with this code in it:
user-select: text;
the validator says:
text is not a user-select value : text text
Presumably this is because of this behavior, specified at (the outdated) http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select:
This property is not inherited, but it does affect children in the
same way that display: none does, it limits it. That is if an element
is user-select: none, it doesn't matter what the user-select value is
of its children, the element's contents or it's childrens contents
cannot be selected.
Also, I only see the attribute value 'text' specified in that out-of-date css3 doc from w3.org:
http://www.w3.org/TR/2000/WD-css3-userint-20000216#user-select
and not in the latest one: http://www.w3.org/TR/css3-ui/
Additionally, searching 'whatwg.org' yields nothing.
Any ideas if 'user-select: text' is valid css3, and if not, what should be used instead?
This would be used, for example, when overriding 'user-select: none' rules applied to containers of text and ancestor containers.
You are getting this wrong. user-select:text doesn't mean it would select text only. It's default value of user-select property. W3C describe it this way:
The element's contents follow a standard text content selection model.
And Also MDN syas something same:
-moz-none The text of the element and sub-elements cannot be selected,
but selection can be enabled on sub-elements using
-moz-user-select:text .
So I don't think this should prevent selecting images or boxes.
As far as I know user-select:text is useful when you have user-select:none for most or all of your elements and you have a textbox or text area that is kind of output and you want it be selectable for copying and pasting.
It seems if you use -webkit- prefix it works for me. I'm sure it works with -moz- prefix too. Test this fiddle in your browser. I don't know why user-select:text is not working on my Chrome 13 Mac?