I am styling a drop down in Firefox on Mac OS X, but it is changing the arrow from the standard look to an ugly down arrow. What can I do to keep the standard form element with the nice up and down arrows, rather than the ugly down arrow? I figure that my custom styles are causing it, but I want to be able to identify what causes the browser to switch it.
Here are the styles I'm using...
select {
font: 400 16px/16px "Maven Pro";
margin: 2px 0;
text-transform: capitalize;
padding: 0;
height: auto;
}
That's not the CSS causing the difference. It's actually a browser difference. Form elements are something that you will have a very hard time standardizing across all browsers, except maybe submit buttons, which can be swapped out for images.
You can check around for some javascript plugins, but I wouldn't worry so much to get the safari select. Folks using Firefox / IE are already used to seeing this type of select.
Related
I have an HTML element textarea with defined CSS rule { resize: both }. In FF when the user mouse over the right bottom corner of textarea the cursor changed according to value of property resize, but in Chrome cursor doesn't change.
Please open this example in FF and Chrome to check the difference.
Is it a bug of Google Chrome and can I fix it with CSS on my side?
Update
I reported bug to Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=942017
Update 2
The bug was fixed in Chrome 80.
Actually, there are, or at least were ways in which you could style the resizer and add cursor: se-resize; on hover. Check out this post: Can I style the resize grabber of textarea?
It describes how you can use ::-webkit-resizer to style the resizer:
::-webkit-resizer {
border: 2px solid black;
background: red;
box-shadow: 0 0 5px 5px blue;
outline: 2px solid yellow;
}
Unfortunately it stopped working in Chrome and I couldn't anything similar. (I think it still works in Safari).
But fear not, it's not hard to make a custom handle. Actually, I would encourage you to use a custom one as the default one is too small and hard to hit. Especially with touch. There are actually a lot of sites that use custom handles (or at least automatic resizers based which grows based on the content. Works great on touch too!).
Ie. Stackoverflow uses a custom handle (TextAreaResizer):
GIF of Stackoverflows resize handle
There are also lots of libraries for exactly that purpose, just do a Google search, and you'll find something that works for you :)
This is rendered by browser itself cant be designed using css
I'm styling some select inputs on a page, and it works fine on Windows Chrome. However, on Mac Chrome, the "native" implementation refuses to go away unless I apply -webkit-appearance: none; The problem with this, of course, is that I lose the down arrow that indicates it's a select element, which I would otherwise be able to add back in if inputs were allowed pseudo-elements (they're not).
Specifically, I'm trying to override the border-radius property, but no amount of border-radius: 0!important will override it.
Create or download a small down arrow and then give the following property to you select:
select{-webkit-appearance: none;
background:url(images/downarrow.png) no-repeat;
background-position: 98% 4px; }
I have a list of checkboxes with labels and I am noticing that the spacing looks different in Firefox in comparison to IE.
I have applied the CSS below to try and remove all spacing.
border: 0 none;
margin: 0;
outline: medium none;
padding: 0;
Unfortunately, as you can see from the screen shots below, there still seems to be some extra space between the Firefox checkbox and label.
Firefox:
Internet Explorer
Why does Firefox still show space between the checkbox and label but Internet Explorer has none using the same CSS?
In short, the reason as to why you're seeing this is that such details aren't defined as a standard anywhere, and come down to the 'user-agent stylesheet' - a set of default styles that are applied by the specific browser.
It's something that frustrates plenty of designers/developers, and has led to the development of some kinds of CSS Reset stylesheets. One of the best (in my opinion) is normalize.css, which aims to provide consistent and sensible defaults, smoothing over cross-browser inconsistencies like the one you've described.
I have a TEXTAREA where spacing is very important. I formatted it as follows:
TEXTAREA {
font-family: Tahoma, Arial;
font-size: 8pt;
letter-spacing: 0px;
line-height: 13px;
}
How, if I enter some text, the line height is not correctly applied: The last line of every paragraph (before pessing enter or shift-enter) is one pixel to high:
This problem only occurs in Internet Explorer 9, not in Firefox 7 or Chrome 14 (haven't tested older versions so far).
Is there a way to get rid of thad?
BTW: It does not happen for the last line of the textarea, unless there is a linebreak behind it.
Regards,
Steffen
I know this may not actually help entirely nor be the full answer, but it may be worth while reading up a little on the use of !important declaration within CSS.
http://www.impressivewebs.com/everything-you-need-to-know-about-the-important-css-declaration/
The only reason why this springs to mind is there may be another style/declaration that is applied after which is causing some sort of problem and this will make sure your textarea has the correct styles applied to it.
You may also want to check that any <p> CSS declarations are not causing conflicts/problems with any bottom or top margin's/paddings? Same goes with span or any other styles that could potentially cause some sort of problems.
Like I said, I'm aware this may not help in the slightest but it could be a possibility.
I have had similar problems with the last line in a textarea in IE8. When my textarea had a line-height of less than 18px, the cursor changed the line-height. The reason I bring this up is your line-height of 13px is quite small. You may want to experiment with larger line-heights to see if the problem goes away.
I just went many many rounds with this issue and finally discovered that IE9 is adding extra padding to textareas. Line height, height, etc had no effect. This did the trick:
padding: 0px !important;
The styles:
h2 {
color: #71D0FF;
font-size: 11px;
font-weight: bold;
margin: 0px 0px 5px 0px;
}
a.box {
color: #FFFFFF !important;
cursor: pointer;
display: block;
padding: 10px;
text-align: justify;
}
a.box:hover {
background-color: #0C0C0C;
}
a.box span.down {
display: block;
color: #D04242;
float: right;
font-size: 11px;
margin-left: 5px;
}
a.box span.up {
display: block;
color: #71D013;
float: right;
font-size: 11px;
}
span.noob {
color: #FFA142;
}
span.pro {
color: #A142A1;
}
The HTML (this is basically repeated for each link):
<a href="/library/blaze" class="box">
<span class="down">-0</span>
<span class="up">+0</span>
<h2><span class="noob">NOOB</span> BLAZE</h2>
HAS CREATED 0 MAPS, WON 0 BATTLES, AND LOST 0 MAPS
</a>
What I'm not understanding is why it renders differently in Firefox occasionally. Sometimes it shows up like it's supposed to and sometimes it shows up in this weird format as seen here:
I've never had anything like this happen before, does anyone know what's causing it? Does it even do this for anyone else? Like I stated before, sometimes it loads just fine (exact same HTML, CSS, and everything) and sometimes it doesn't. It seems kind of random. It loads just fine in IE with no weird problems at all.
Interesting. I can definitely reproduce it on FF3.6, actually I'm getting the broken version more often.
I can't get my head around it right now, but looking at it in Firefox, there is something broken with the link. If you open "inspect element" in Firebug, you will notice that the rendered DOM definitely changes between the intact and broken view. Firebug will also add _moz-rs-heading to the link, which is sort of explained here.
The first step should definitely be making the markup W3C valid and checking whether it still occurs.
I am a bit surprised that it doesn't act up more than it does.
You have put a block element (h2) inside an inline element (a). The markup is broken, and different browsers will do different things to try to make the best of it. One thing that can happen is that the browser adds an ending tag for the link before the block element.
Us an inline tag instead of the h2 tag, and use CSS to style it to look the way you want.
I'm having the same problem.
http://www.jameshughbanks.com/
I've narrowed it down to this. It ONLY happens when I put a link around multiple elements (in my case it involves one (or more) block element(s) and one (or more) in-line elements.
It is very odd as in it seems to only affect "every other" "error" you create using the method I described above. It will modify the first and third div output but not the 2nd. (at first it affected the 2nd one only, but I partially fixed the problem (it used to mess up the H2's also, but putting the link around the h2's only removed them from getting the error.
So it comes down to only being able to put a link around 1 block element, I haven't tested the error with more than 1 block element, only the mis-match of a block element and multiple in-line elements.
If anyone has any work-arounds for this issue in firefox please let me know. It does not appear to happen in IE, Opera, or Chrome.
Also for those that think this is bad markup, it is included to be valid in the next revision of html5, and it is the only way (without javascript/etc) to do these types of links. Firefox is obviously coded to show this markup properly but for some reason has some type of bug that makes it render it differently sometimes due to unknown reasons. Regardless it needs to be fixed or a work-around developed, I could make each element its own individual block and probably fix it, but that's a lot of extra unnecessary code.
Works fine for me in Safari, Chrome, and Firefox 3.5.
I've tried refreshing repeatedly. No luck in duplicating your problem. Have you tried clearing your cache?
Inspecting the element in Safari or Web Developer (FF plugin) does not reveal anything unusual either.
Is N00B BLAZE always the one that messes up every time you see an issue or is it random?
For me, sometimes Firefox doesn't properly load CSS, it's usually all of it, not partially like it's happening to you. For me tho it's loading correctly. Have you recently changed it by any chance and didn't allowed to properly refresh?
When I buzzed your site, the problem occurred for me in FF3.6. Using Firebug to peek at the HTML, the problem was that the lines that display incorrectly have an extra <a> wrapped around the text, within the <span>. Maybe some HTML included in your DB where it should only be text?