Why doesn't IE7- display this CSS properly - css

I set up a search box using divs and floats to create a multiple column layout. My IE 7- clients see a line break between the filter-label and filter-input-controls.
They have corporate policies that won't let them upgrade or use Chrome or FF. I tried using a clearfix and a comment before the doctype. No luck.
jsfiddle here

Consider using LABEL tags and a styled, unordered list, as a container for your form elements. This results in cleaner code and it makes more semantic sense.
See: http://alistapart.com/article/prettyaccessibleforms

It looks to me like your "Deviation Status" span is in a different div than your select, one would expect them to be displayed in different block elements. As I don't see "display:inline(or inline-block);" anywhere in your CSS, it doesn't look like you are accounting for this default behavior..

Looks like your search box is too wide. Try adding a *width: to the containing div. The * is a filter for IE7 and below.
IE7 will need everything spelled out layout wise (width, height, float, etc). If one element is too large, it will break the layout. More modern browsers are more forgiving.

Related

Why is there a vertical gap between adjacent divs when selecting text?

I'm making a rich text editor which is like a clone of Google Docs. For reasons I won't get into here, each line in the text editor is wrapped into its own div container. For example, if there's 3 lines of text, there will be 3 child "line nodes" (rendered as an unstyled div) in the text editor. And within each line node there are inline span elements to control styling such as Bold, Italic, etc.
The issue I'm having is I can't understand why there is an unsightly vertical gap of whitespace between each line when selecting text over multiple lines. I am using Draft.js for this, but from what I can see it shouldn't make a difference; there's no styling or margins applied. I've even tried making every line div and its span elements exactly the same height but the problem persists.
My guess is this is caused by some native browser behaviour. All I really care about though is: can I "fix" it? I mean, I know it's possible because Google Docs doesn't have this spacing issue when selecting text... But then again it uses a completely custom rendering engine with custom cursors too. Thanks for any suggestions
edit: so a temporary workaround I've found (see image below) is to reduce the height of each div and span to a fixed value (in this case, height: 16.4px). But for obvious reasons, this isn't an ideal solution. I'm still looking for a "proper" way to implement whatever styling I want and not have these gaps appear between adjacent divs when selecting text
I believe your talking about line-height in which you can control the space between two elements / texts.
Try it out below:
div {
line-height:100px;
}
<div>Hello World!</div>
<div>How are ya?</div>
Thank you for all the suggestions. Turns out this is quite a challenging issue and there's very little (if anything) that can be done with pure CSS. Only the height attribute of div or span elements appear to have any visible impact on text selection. Inspecting the Google Docs elements reveals they use their own custom selection engine:
Closing this because I at least know how a solution might be implemented now, even if it would be very complex and time-consuming. Thanks again for the suggestions.

Transfer block in table-cell on a new line

I’m writing a template for marking on flex/box. And faced with the problem of emulation of some properties. At the moment, I decide them on JS. What complicates code.
So I decided to try to use the property of table-cell for child elements whose parent has the property display: block. Yes, it’s not right, but it works!
When I’m trying to break the table-cell elements to strings, I ran into a problem. And that’s how I tried to solve them:
If the child blocks table-cell overflow the parent horizontally, then
the following blocks are not transferred to the new line. And it is
logical. Example: Nowrap in link.
If I use the cancel flow, I lose equal to the width of columns for the element to be wrapped to the next line. So, this method only works for IE9+. I’m willing to drop IE7, but not ready to abandon IE8. Example: Wrap nth-of-type in link.
If I use the blocks which separate the table-cell on the line, everything becomes fine! But this complicates the CSS and JS code. Example: Wrap with break elements in link.
Example: http://codepen.io/anon/pen/GmgXmO
What ways to break table-cell can be applied, besides the above described options?
An example of a 12 column layout, fix the problem of calculation of the width percentage: http://codepen.io/anon/pen/PmwRvK
In order to make it clear why I do this.
I will be glad to hear your answers! And excuse me for my bad English.
P.S.: Ignore the strange size of the width in percent. It is calculated
according to the formula:
(100 * element.clientWidth / element.offsetWidth).
The smaller size, so it is more. Funny. This rule is applicable only to
the parent display: block containing the child elements display: table-cell

CSS text-align for other stuff than text (like buttons)

According to W3Schools the property is used to "align text within elements".
When using it in different ways however, like buttons, it also works perfectly. See this JsFiddle
Is it a good idea to use the align-text CSS property in situations like this or is something else a better solution like putting float: right on the button?
I was wondering if this attribute was intended only for text or if the name was just chosen poorly.
(as pointed out by Ray Toal, the answer is in the official W3C spec)
To be more accurate, it is used to align text and inline elements within their parents.
So spans, buttons, elements with display:inline-block and so on will be aligned according to text-align, whereas block-level elements are unaffected (but may inherit the container's text-align and apply it to further descendants).
Your use of text-align is perfectly fine here. Using floats would then need to clear following elements from their effects, etc
Perfectly fine: I wouldn't say that of the HTML code of your example (table, no label, no for/id association)

use inline-block or table-cell for css grid

I'm looking into creating a set of css grid classes for webkit only browsers. Should be simillar to blueprit/bootstrap/compass, however I'd rather not use those because they rely on float positioning.
I'd like something like this:
span-1 {width:10%;display:inline-block}
span-2 {width:20%;display:inline-block}
and so on. Would there be any benefit to using display:table-cell vs inline-block for this? Or is there a better approach?
Actually display: table is really the solution you are probably looking for (because of your target browsers). It was added to browsers so people could get a grid layout without needing to use a table. You don't even need percentages (the number of columns you add will dictate the width of the children elements).
DEMO
The only real caveat comes in when you are doing mobile browsers and want a dynamic layout shift (media tag) to go from a horizontal list to a vertical list. I guess it is not too big of a deal to add you own media tags (and add a class to the wrapper)...
You probably could get display: inline-block working but make sure you use box-sizing: border-box because when you are working with percentages, even a single px off and things start wrapping..

CSS Height Set Dynamically

So I'm inspecting this site: http://www.grittirollo.it/ and it appears that the content that slides out has a fixed height. Is there no way to set this dynamically?
It appears as though the developer measured out how tall each portion of the sliders' box model would be when rendered, and then multiplied it by how many rows there were. From there, he/she set it manually in the CSS.
Elements on a webpage can typically be measured with their scrollHeight JavaScript property (element.scrollHeight) however some browsers don't have this and some browsers do it differently from others. (I believe Firefox's has to be done recursively down the tree of elements and Safari just uses the outermost element.) This should be possible without manually setting the height using JavaScript, you just may have to conditionally code it to work with all the browsers you want to support.
I don't see why it's necessary to set it dynamically. If the stuff is float:left; and they put a <div class="clear"> at the bottom of a hide-able section, you would be able to see the contents of that section when it was un-hidden with JavaScript. You could then adjust the layout with padding and margin to make it look pretty.
Or, they could have also used position:relative; and position:absolute; to layout the hide-able sections. It comes down to preference.

Resources