I have a control that I am trying to highlight when it is selected. I'm achieving this using padding on a div and some positioning so that it surrounds the control. The problem I'm encountering is that the padding on the highlighter div renders differently in chrome and in firefox. Everything I've read says that they render the same so this shouldn't be a problem.
Chrome:
Firefox:
Here's a fiddle that has the problem on it:
http://jsfiddle.net/5fuGB/1/
.control{
position: absolute;
width: 100px;
height: 20px;
top: 30px;
left: 300px;
z-index: 1;
}
.highlighter{
background-color: orange;
position: absolute;
width: 100%;
height:100%;
left: -2px;
top: -2px;
padding-right: 8px;
padding-bottom: 10px;
z-index: -1;
}
input{
width: 100%;
height: 100%;
}
My Chrome Version:
Version 31.0.1650.63 m on Windows 7
My Firefox Version:
25.0 on Windows 7
Thanks for any help you guys can offer.
I believe the difference you are seeing is a difference which comes from the user agent stylesheet, browsers have their own default stylesheets which they use to render things like input elements. In your case it is probably a difference in the padding applied to the input element. You should specifically set eg: padding: 0px; or padding: 1px; on the input element, and then work out how to get it to look right for an input with the specified fixed padding. This will then override the styles set by the user agent style sheet.
Update
I moved to my Windows PC to have a go at fixing it. One way to fix this using one of the vendor specific prefixes from the answer linked in the comments is to add -moz-padding-end: 6px; to .highlighter to compensate for the differences in padding between browsers.
Here's a jsFiddle which fixes your issue, a footnote tho, I can already tell you that this probably won't fix it on Chrome for OSX, which was also rendering things the Firefox way.
Another way to fix this is by adding -moz-padding-start: 1px; -moz-padding-end: 1px; to input, but doing so somehow changes the bottom padding as well, which makes things look not as pretty in Firefox as with the other fix.
I'd go about it differently. Instead of using an extra div, I'd recommend using a combination of border-color and box-shadow on the input's :focus state to achieve the effect you're going for.
Check out this modified fiddle: http://jsfiddle.net/5fuGB/2/
Just experienced the same issue with my code, and fixed it too. The trick is if you use display: inline-block then line-height makes sense. Try it when debugging your code.
You're doing a little more than what's necessary. To get a highlight around that input you can use :focus
So it would be something like this:
CSS
input {
border: 1px solid white;
}
input:focus {
border: 1px solid orange;
}
That will give the input a white "invisible" border so it doesn't move the input when you click into it. It will simply change the border color to orange to get that highlight effect you're looking for.
EDIT
Just saw your comment. I dont have the rep to comment so I'll just add on to this.
If you aren't using the inputs as actual inputs, then I would just make them divs. Inputs render differently by default so that would mess with consistency across browsers.
I'd also recommend experimenting with those divs within one another and making the most outside div relative.
Outside Div <------ position:relative;
Middle Div <------- position: absolute;
Inner div <-------- position: absolute;
Also, if you need a selected state but don't want or are hindered by inputs then I'd recommend jQuery for modifying the css based on user interaction.
Related
(I've tried searching for this but can't seem to describe it correctly--if this answer exits, please point me in the right direction!)
I'm playing around with some css rules. I wanted to make a specific, secondary 2px-wide border on a pseudo-element appear around nav anchors in the header, which open a modal and blur an absolutely-positioned background image div #bg, which sits as such:
<body>
<div id="#bg"></div>
<header id="global-header">
<nav>...</nav>
</header>
</body>
Since I wanted to transition the blur effect, I added translate3d(0,0,0) to #bg, which smoothed the fps by galvanizing the GPU for hardware accelerated processing of CSS. It worked! ...Until I noticed that the vertical (left & right) borders for the links had inconsistent widths across the nav. They were each set at 2px, but every other one looked 1.5(??)px wide. It took me a minute to narrow down why, which ultimately was because of the translate3d transformation. I took screenshots, but I centered and moved the pseudo-elements with border-left: 2px below the header (the effect persisted), and I removed the background image itself so the effect would be easier to see. Here they are:
Inconsistent 2px calculation (with translate3d(0,0,0) on #bg)
Consistent widths (without translate3d transform on #bg)
And for reference, here's the code for the left-bordered pseudo-elements:
#global-header nav ul li a:before {
content: '';
position: absolute;
display: block;
top: 100%;
left: 50%;
height: 100%;
width: 0;
border-left: 2px solid gray;
background-color: transparent;
}
I know that translate3d creates as well as solves a possible host of issues from my searches--but why is this happening? Does it have anything to do with "subpixel calculations"? And why would these calculations render inconsistently throughout the page with hardware acceleration, on something I would assume is hard to mess up?
Edit: So, even without translate3d, the problem-lines flicker to a smaller width when the blur transitions (seen in the code from screenshots) are triggered, and I can reproduce the original issue without translate3d if I add backface-visibility: hidden to the pseudo-element itself. This could hint at general pixel rounding issues, with specific properties as triggers only being a symptom.
After further fiddling, answering my own question: This is not caused caused by hardware acceleration, which was my revised suspicion. Though the use of these effects showcased the problem in my particular case, I was able to recreate a version of my issue without them.
By removing transform3d from the #bg element:
#bg {
.
.
.
/* transform: translate3d(0,0,0); */
}
And, without the backface-visibility property as well, I added some width to the pseudo-element in order to see what these borders would normally look like:
#global-header nav ul li a:before {
content: '';
position: absolute;
display: block;
/* top: 100%; */
/* left: 50%; */
height: 72px;
width: 1px;
border: 2px solid black;
/* backface-visibility: hidden; */
/* border-left: 2px solid black; */
background-color: transparent;
/* transition: height .2s ease; */
}
Duh: I should have expected the result, since earlier I had tried to use the element itself (by making it 1-2px wide and coloring it) instead of border-left, which at the time seemed to fix the issue. Of course, when I did it this time using the above css, the base problem reappeared.
Though I still don't know why the aforementioned properties showcased the problem with border-left as well, addressing this might be too sporadic/situation-dependent to field here, and likely still has more to do with browser rendering than anything else.
Anyway, my question was why transform3d caused this effect, and the answer is, at least in this case, it didn't--it just made it more obvious.
Firstly, I didn't think this styling would be possible in Chrome/Firefox but surprisingly it worked! However it doesn't display the same in Internet Explorer (What's new huh?).
As it worked in Chrome/Firefox/Safari/Opera I thought it might at least work in the latest versions of Internet Explorer but I get the same issue from IE11 down. I've not tested in EDGE yet.
Here's a CodePen showing the mark-up/CSS: http://codepen.io/moy/pen/yewbBx
Basically I have a pretty standard table but a row which is 'selected' is slightly wider than the rest. I achieved this using the :before pseudo class for the first and last <td> of a selected row, a bit like this:
tr.selected td {
background-color: #brown-lightest;
position: relative;
}
tr.selected td:first-child:before,
tr.selected td:last-child:before {
background: #brown-lightest;
content: "";
display: block;
height: 100%;
position: absolute;
left: -5px;
top: 0;
width: 5px;
}
tr.selected td:last-child:before {
left: auto;
right: -5px;
}
Occasionally it 'looks' like it works but it seems like the content of both the first and last <td> both need to be the same height for it to work. Even though td:before {height: 100%;} is set, it seems to take the height of the text rather than the <td>. Which is strange before with it being a table layout all the heights in the row should be the same?
I understand this mightn't be possible in IE but I thought I'd see if anyone had an ideas why this might be happening incase it's something other than the simple fact the browser just can't do it.
Thanks in advance!
Honestly, doing it that way is quite the hassal. I'd recommend checking out Bootstrap CSS, Why? It's designed specifically to combat it.
However if you want to do it like that, just wrap it with a tag
Example
<span style="color: red; background-color: blue; "><td>RandomData</td></span>
These are just options however, someone else might be better than I with the first and second child marks.
I am trying to style the HTML input range and it works as I expected on webkit browsers but my styling for -moz- browsers doesn't seem to work. I was trying to use pseudo elements before and after on the moz-range-thumb but Firefox doesnt support that maybe? I couldn't find any proper documentation on this. But if someone can help me come up with a solution to this I'd really appreciate it.
This is the moz styling I applied which is the same as for webkit browsers:
input[type=range]::-webkit-slider-thumb:before {
position: absolute;
top: 5px;
left: -2000px;
width: 2000px;
height: 6px;
margin-left: -2px;
background: #666;
content: ' ';
}
JSFiddle
For firefox just added background: #fff; to input style and it rendered exact as chrome. if it doesn't work with you we can check your firefox version.
Perfect explanation of the reason is given here.
:before and :after render inside a container
Pseudo-elements can only be defined (or better said are only supported) on container elements. Because the way they are rendered are within the container itself as a child element. input can not contain other elements hence they're not supported.
As a cross-browser workaround you can use the pseudo-elements on the input's label tag instead. That worked for me.
I'm trying to have a block-level input-append, where the input bar takes up all the space other than the button.
I got this working with a <button> or <span>, but once I switched the tag to an <input>, I started having styling issues again. However, the <input> tag is required.
I've include a Fiddle - HERE
I got it to work by doing this:
.input-append {
display: table;
width: 100%;
}
.add-on {
display: table-cell;
height: auto !important;
}
.input-bar {
display: table-cell;
width: 100%;
border-right-style: None;
}
.well{
padding-right: 58px;
}
I removed the nested selectors as you can't do that in regular CSS. (With Sass and LESS you can though).
I added "height: auto !important" to the ".add-on" selector. Although it's generally regarded not best practice to use "!important".
I added padding-right to the well of 58px which is the width of the GO! button, 39px, plus the well padding of 19px.
Edit: As #nicefinly pointed out, the height of the GO! button was still off. In Chrome I didn't see anything wrong, but in Firefox I could definitely see the height problem.
So, with all of his changes, I would also add that when modifying the well and add-on classes for example, this would change all the places where those standard Bootstrap classes are used and this is probably not want you want.
Instead, I would create separate classes for all of these custom classes so they work in this specific case and elsewhere it works as intended. For example, "add-on-button", "well-with-button", etc.
#CoderDave pointed me in the right direction with his suggestion - JSFiddle of #CoderDave's answer
However, I then noticed that the height was somewhat off. Instead, I set the button height manually - JSFiddle of my workaround
.input-append {
display: table;
width: 100%;
}
.add-on {
display: table-cell;
height: 30px !important;
}
.input-bar {
display: table-cell;
width: 100%;
border-right-style: None;
}
.well{
padding-right: 58px;
}
BUT THEN...
Testing in Chrome gave me strange results (not necessarily in the fiddle, but in my local environment). Therefore, instead of padding, I used the margin-left and margin-right where
margin-left = 17px on the input .add-on
and
margin-right = -55px on the .input-bar
However... After that, I noticed that the z-index was causing the .input-bar to block out the GO! button when the bar was in focus (i.e. I clicked into it).
Therefore, I set z-index
z-index: -1 for the well
z-index: 1 for the .input-bar
z-index: 2 for the .add-on
FINAL JSFIDDLE HERE!
This seems like a pretty hacky solution. If anyone has a better solution, please share.
I'm having a problem with input elements:
Even though in that picture their css is
margin: 0;
padding: 0;
They still have that slight margin I can't get rid of. I had to use a negative margin of -4px to get the button to stay close to the text field.
Also, when doing further styling I end up with a problem between Firefox and Chrome:
submit buttons seem to not have the same height. Setting an height which makes the submit button fit together with the input bar on Chrome breaks it on Firefox and vice-versa. There seems to be no apparent solution.
1px difference between buttons http://gabrielecirulli.com/p/20110702-170721.png
In the image you can see that where in Chrome (right) the button and input field fit perfectly, in Firefox they'll have a height difference of 1px.
Is there a solution to these 2 problems (the persistent margin and the 1px difference)?
EDIT: I've fixed the first problem, it was caused by the fact that the two elements were separated by a newline in the html code.
The second problem persists, though, as you can see here:
by highlighting the shape of the two elements, you can see that in Firefox (left) the button is 2px taller than in Chrome (right)
Try this one: demo fiddle.
HTML:
<span><input type="text" /><input type="submit" /></span>
CSS:
span, input {
margin: 0;
padding: 0;
}
span {
display: inline-block;
border: 1px solid black;
height: 25px;
overflow: hidden;
}
input {
border: none;
height: 100%;
}
input[type="submit"] {
border-left: 1px solid black;
}
Tested on Win7 in IE8, IE9, Opera 11.50, Safari 5.0.5, FF 5.0, Chrome 12.0. Only IE7 fails since it obstinately shows a normal button-like submit input.
Seems to me that your CSS is interfering, somewhere, with your inputs layout.
As you can see here http://jsfiddle.net/F3hfD/1/ what you're asking is doable without any problem.
For your second issue, see How to reset default button style in Firefox 4 +
For a similar issue where I an image used as the button type="submit" and it wasn't exactly the same height as the input adjacent to it, I simply added this to the container of the two said inputs:
padding-bottom:1px;
I had a glyphicon in a span next to input, which was inserting top:1px.
So I set top:0px on span and the issue was fixed.
But actual answer for the thread is totally problem specific and user needs to better understand the elements and css to fix it.