I'm trying to make a custom checkbox, so I made something like that : http://jsfiddle.net/wQdUn/2/
The problem is that, on WebKit based browsers, the checkbox is toggled only when clicking on the content of the <span>, not on the box itself, while in Firefox I get the behavior I expect.
So I have two questions:
Which one is the right behavior (i.e. the one conform to specifications)?
How do I get the result I want in both browsers (and others...)?
Thanks.
Not sure about the first question, but if you make the span an inline block too, it'll work as you expect in WebKit browsers. See http://jsfiddle.net/wQdUn/5
For those who come to this topic form google:
Safari 6.0.4(8536.29.13) still got this problem, you need to set inline-block on pseudo-element to make click work.
Chrome switched to Blink as it's rendering engine, so this problem didn't happen on chrome any more(26.0.1410.65).
Related
EDIT: This question has been solved. #jerome.s comment helped me narrow my search, read the edits at the bottom of the question.
I found a problem than only affects Chrome (tested on Chrome, Firefox, Safari, IE9/8/7), but what really is driving me crazy is that it doesnt happen on all sites.
Giving a background to the container of a radio input causes a small white background box to appear on the input, however this background is not being added by any CSS, i created a fiddle using some code i found on twitter bootstrap page:
Fiddle depicting problem: http://jsfiddle.net/DMFca/1/
Alternative code to replicate problem:
<div style="background-color:lightblue">
<input type="radio"/>
</div>
Result of the fiddle on my Chrome (25.0.1364.172 and 26.0.1410.43):
The problem is that the code does not behave the same way in bootstraps site (http://twitter.github.com/bootstrap/base-css.html#forms) after i add a background to any of their forms containing radio inputs. I have some other sites where this problem does not happen.
I have tried disabling all CSS affecting the radio and its closest containers in an attempt to discover the "fix", but it continues behaving differently (correctly) despite no CSS applied to it.
Once all CSS had been disabled i compared the computed styles of the input to my own problematic input and they are exactly the same, leading me to believe that it could be the doctype, some magic meta tag or some strange behavior on the container affecting the input, but no success there either.
This problem can be easily replicated, and i do know of some instances where it doesn't happen (so i assume there is a fix), however i cant find it. The same browser and (apparently) the same code have different results.
PS: I found a bug report for Chromium describing a very similar behavior, but relatively old and supposedly fixed
EDIT: Updated chrome to 26.0.1410.43, problem still exists
EDIT2: Viewing the fiddle outside of the iframe seems to fix it, but my initial issue still exists, will try to replicate the problem again and update the question
EDIT3: After seeing that the iframe was causing its own different bug i focused on trying to figure out what exactly was causing my original problem, i ended up disabling every css rule affecting the radio input and all its parents one by one until i found the culprit:
body {
-webkit-backface-visibility: hidden
}
This "fix" to a bug (Webkit text aliasing gets weird during CSS3 animations) causes my bug.
It looks fine on chrome on mac... Perhaps you could try to set transparent on input elements?
input {background: transparent;}
http://jsfiddle.net/DMFca/2/
Despite the fact that a bug seems to exist when displaying radio inputs inside iframes (as mentioned by jerome.s) my own problem was being caused by a fix to a webkit text aliasing bug:
body {
-webkit-backface-visibility: hidden
}
This "bug fix" can be found here: Webkit text aliasing gets weird during CSS3 animations
Once this line was removed the problem was solved and the behaviour identified in the link above was not detected.
I had that problem once. It was... painful!
My problem was an incorrect overflow: hidden applied in a parent.
Try to move your radio node using Chrome inspector level up per level up to the root, so when you see that its ok it will mean that the problem is located in the parent level you quit last time.
I have a group of radio buttons, and have styled them so that they display:block so that they appear like buttons (have also hidden the radio button itself). This works great in Chrome and Firefox on desktops and on android tablets...but will not work on an iPad.
See it here:
http://jsfiddle.net/WhNRK/
For whatever reason the block element is not 'active' on an iPad and does not set the radio button. If I 'unhide' the radio button you can see that it doesn't get select when clicking the block. However if I click the actual radio button itself, it selects properly and even changes the block element background color as it should!
http://jsfiddle.net/WhNRK/1/
Any idea as to what I'm doing wrong that is causing this to happen? Seems like it should be pretty straightforward functionality, so I'm hoping its just something simple I'm overlooking...
The primary use of the site that this is incorporated within is meant for mobile devices, so definitely need it working on any iOS device (assuming it likely happens on an iPhone as well, just don't have one here with me to test right now).
Thanks for any suggestions you may have!
Fisrt of all, your fiddle does indeed not work on the iphone either, both in safari and chrome.
Curious as i am, i tried to find the solution by playing a bit with your code. In changed the html a bit to make the label a sibling of the input, rather then a parent. Still with no effect on my iphone.
After some googling i found this: http://forums.macrumors.com/showthread.php?t=785632
I tryed the solution and it seems to work, allthough i have no clue why. I guess it is some sort of bug...
You have to add onclick="" to your labels.
I didn't test it on an iPad, but as it is just a big iPhone it should work the same. A working example can be found here: http://jsfiddle.net/WhNRK/15/
I always have a problem when making webpages using input or select boxes in CSS because the focus is mostly making it for FireFox and IE, but for some reason the text inside text boxes/form input objects are usually never properly aligned (line-height).
I'm wondering if there is a common routine for making input boxes look like they do in FireFox and IE, in Safari, because they usually look horrible once you add a touch of CSS to the element. Trying to balance out the line-height on each browser usually never works out perfectly, is there something i'm missing to make the inputs in all browsers look the same once you style it? (mostly talking about the line-height of the inner text inside the input box).
ie. Is using em instead of px a better for cross browser compatibility?
What helps a lot is using some kind of boilerplate starting point, that resets all browsers to the same base CSS (for so far possible). Specifically I've enjoyed HTML5Reset, you could just take the CSS reset file and see if it helps you.
See this link - why are the multiline textboxes draggable?
Is this Firefox bug? It just spoils the design like anything.
Even the same in happening is Stackoverflow's textbox. I am using Firefox 5.0
Thanks in advance:)
Edit:
See these photos of SO itself:
This is a feature that's been included since Firefox 4. However, you can switch it off by including resize: none in the css of the given Textarea(s).
That's something happening since some time now even on Chrome and maybe other browsers too. I think it's to allow a better experience for the users who need to type text in the textarea, so I definitely think it's not a bug.
But it indeed can mess up your website layout. You have to use some CSS to fix it, like
#yourtextarea {
width: /* fixed width here */
height: /* fixed height here */
}
In case the above doesn't work, you may also think about use min-width, max-width, and the height equivalents.
I won't mess up with this anyway, since it's a browser feature and so it's something useful for the users.
Why are the multiline textboxes draggable?
They aren't. Dragging just selects the text inside them. They can be resized though, which is great as it lets users make textboxes bigger so they can see more of their text if they have typed a lot.
Is this Firefox bug?
No, it is a feature. I think Chrome got it first.
I had a go at at this question (this question isn't related at all to his question), and tried to solve it through applying CSS selectors depending on whether the checkboxes had been ticked. The idea I had, was that if there is an element which is :checked, the preceeding submit button should be visible. The resulting CSS I came up with was:
input[type=checkbox]:checked ~ input[type=submit] {
display:block;
}
Now, when the page is loaded, the submit button is hidden, as it should. But, when you check a box, nothing happens (presumably it should?).
If you load the form with one input field with attribute checked, it does have the submit button visible, as it should, but when you untick it, the submit button doesn't hide.
When you clone the the form (with one checkbox ticked) through Javascript (and the whole purpose of this exercise was not to use Javascript), it does do the expected result, i.e. either hides the submit button if no checkboxes were checked, or displays it if a checkbox was ticked.
In other words, that css rule does not take into account changes to the dom, but does take it into account when new elements are put in. Is that working as intended? First I've seen something like that happen with CSS.
Example: http://jsfiddle.net/niklasvh/nn4Qw/
Did I miss something here or isn't it supposed to work as I've described?
Edit tested with firefox, and works fine, so this seems to be an issue with google chrome. Not tried with later versions of IE or Opera.
Your CSS looks correct, but browser support, of course, varies, and where there is support, there will be bugs. Javascript would be much more reliable.
Webkit had problems with siblings and andjacents when combined with pseudoclases. I had some problems with :hover, it's possible that the same thing happens with :checked. It should be fixed in recent nightly chromium builds. If so this bug will some time end in stable chrome version.