I have somewaht of a strange problem. I am not sure if I am screwing up or if this maybe even is a bug in webkit.
What I am doing is using some more or less complex CSS tricks (:after and content, sibling selector, etc) and custom data-attributes to indicate if the input fields of a form are valid or not.
I have a data attribute "data-valid" on each input field together with an attribute "data-validate", which contains a regular expression. On keyup I run the regular expression against the value of the input and set data-valid accordingly.
I then have a small div next to the input, that is styled using a data-valid sensitive attribute selector. The background will show an ok symbol if the sibling's input data-valid attribute is true and will show a fail symbol if it is set to false.
Because this might be hard to understand, I stitched together this jsfiddle, so you can look at it yourself.
All this works perfectly fine in Firefox 6 and IE9. However, in both Webkit based browsers (Chrome + Safari) this will not work 100% correctly. Allthough the data-valid attribute changes correctly, the styled div will not change it's appearance until I either input additional characters or unfocus the input field. It nearly looks like the Webkit browsers fail to repaint / restyle that particular div.
I really don't know what's going on, I am rather confident, that this should work as I expect it to. I hope someone can come up with some insight or even explaination and maybe a fix/workaround.
Thanks alot!
It's all a bit complicated, so I'm not completely sure, but with selectors like this:
input[data-valid="true"]+div.indicator
I think you're suffering from the same bug as discussed in this question:
CSS attribute selector + descendant gives a bug in Webkit?
#DADU, the owner of that question, has already filed a bug report, but nothing seems to have come of it yet.
I came up with a (clunky) workaround. I noticed, that the indicator div would update if the focus state of it's corresponding input changes. So I added some input.blur().focus() magic to automatically unfocus and refocus the inputs after each keyup event. This isn't very nice, but it works and makes Webkit repaint the sibling divs.
Related
Even though we are shifting the focus to input through the javascript code, the focus is going somewhere else instead of going to the input.
Same issue is observed in w3 aria combobox as well as in link https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-none.html
Expected behaviour:
In voiceover,Focus should move to the input after selecting any suggestion from the dropdown
If you add some code it's easier to answer your question. Without code examples, we are only guessing.
The current version of this pattern is here, and it seems to work a little better: https://www.w3.org/WAI/ARIA/apg/example-index/combobox/combobox-autocomplete-list.html
Otherwise, these are mostly illustrations on how something could work. The code is not meant to be put in production environments as is.
I am probably wasting my time with this question but here goes.
Chrome and Opera do not handle events in option elements IE and Firefox do.
So I am wondering I some knows a workaround other than using onchange in the select element, as I have tried to work with that event and pull errors of null value.
onchange="side_nav(this.getAttibute('id'))"
The code I am using is simple id change that works sweet in anything but option elements in chrome and opera, This is the function.
function side_nav(id)
{
document.getElementById("selectedS").setAttribute("id","");
id.setAttribute("id","selectedS");
}
Like I said it works with this in the option element but only in IE and FireFox
onclick="side_nav(this)"
The function works sweet in buttons and I suspect every other element also, just not the one I am set up to use.
I suspect I will have rewrite the nav panel to fix the problem, but thought I would ask someone else there thoughts.
This is What I believe is the answer. not well written but addresses the issue with an answer.
This is a response to Chrome bug reporting. The actual post
Fist I must say after further evaluation I believe that this is not as much a bug or defect but is in how the browser handles the select and option elements. As I see this the browser sees the option element/tag more as an attribute of the select element rather than than an individual element. The select element/tag is just a multidimensional array in HTML and the option tags become attributes of the select element which is why events do not fire and is also why it is impossible to style the option element/tag. I see now that this is deep in source code and seems to be split up equally between the top four browsers. I'll put the basic select code that I have been working with but it will be of no help as it is just the norm, and as I said, it's not a bug but program design.
Thanks for the response.
I have been trying to change the cursor style to look like a pointer rather than an I beam thing, but it looks like FF does not respect the cursor spec in an input file field. For example, I have made this small fiddle: http://jsfiddle.net/jDZtn/4/ where Id like the cursor to look like a pointer rather than an Ibeam when the user hovers over it. My end plan is to introduce opacity==0 and use a clickable button over it.
I am not sure if this behaviour is a bug or not.
A better solution would be to display:none the file input, and have your button .click() it.
Edit: After some testing, I noticed that safari wouldn't let me .click() the file input since it was set to display:none, so I created this fiddle that seems to work in all browsers. I just hid the file input via positioning/visibility rather than display:none.
Reference: https://developer.mozilla.org/en/Using_files_from_web_applications#Using_hidden_file_input_elements_using_the_click()_method
I'm trying to copy the behavior of Gmail with the checkboxes, selecting a whole range click on one and then shift-clicking another, the checkboxes in between these will change.
However, I'm having a compatibility issue between Firefox and Chrome as clicking the checkboxes works just fine, but clicking the labels somehow it's handled very differently, as Firefox will apparently not trigger the change when shift-clicking.
You can check and test my code here.
Obviously there's a trouble with Firefox and the label, I've tried triggering the checkbox's change(), but it works backwards the behavior of the checkbox, I've tried 'resetting' the label events with preventDefault() and then triggering the change() event and the issue seems to be the same, but now Chrome has this bug (which I think it's somehow the correct way, first homologizing).
The easy way is detecting browsers, but every web developer guru tells us that it's better to identify the problem rather than the browser, so what would be a good fix for this? Also, it doesn't work in IE because it doesn't support indexOf().
Thanks!
For some reason the tag is working differently when highlighting text in Firefox. I think the reason it is failing is because when you hold down shift and click on the label, it doesn't check the box and thus doesn't fire the labeled event.
Check out this: http://jsfiddle.net/xerf/Prxdn/10/
This works both in webkit and FireFox. I changed the labels to span tags. With a bit of CSS, you can fix the padding.
I have a form which I want to use both as a report view and a form. Initially the text inputs (text and textarea) are styled to have no border / background. I also use the following jQuery code to make sure they will reject focus:
$('input[type="text"], textarea').focus(function() {
$(this).blur();
});
This works in Firefox, but it doesn't in Opera (and maybe other webkit browsers). I don't want to use disabled property because then I cannot style the input to be unobtrusive (in the general sense). I can hide the input and display a span or div in its place where the state is view and then swap the visible-hidden property when state changes to form, in fact I'm doing this for selects, radio buttons, and checkboxes. But it'd be less work if I can get it work as is. Any suggestions?
Edit - Removed webkit tag, thank you Fylke.
Why not just use the "readonly" attribute instead of "disabled"? Setting "readonly" to true will not change the way the fields look (meaning that you can do that with CSS), but it prevents modification.
That said, this approach to re-using layout can be problematic when your field values take up more room than allocated on the layout. When they're editable text fields, users generally understand that they can scroll the value around, but that becomes pretty weird when the fields don't look like fields.