jQuery hack fails in Opera, alternatives? - javascript

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.

Related

jQuery: sync two text fields without using val()

My question is similar to this or this question.
However all the answers there use jQuery's val function to copy the value between the fields.
I cannot use val since the source input field will be readonly.
Therefore I want to capture the keyboard events on a source input field and based on these populate a target text field. Can it be done?
I was hoping something like this would do it, but it doesn't work.
$(".src").keyup(function(e){
$(".target").trigger(e);
});
Any ideas?
Your question doesn't make much sense. You say:
the source input field will be readonly and thus will only be able to listen to keyboard events.
... but that doens't make much sense. If it's readonly, you cannot focus the field... meaning you cannot give it keyboard events. Regardless, you can always get and set the value of a field, even if it's readonly or disabled. If you don't want to use jQuery's val() - then use plain JS.
$(".src").keyup(function(e){
document.getElementsByClassName('target')[0].value = e.target.value;
});
Update: Now I think I understand your question. Your main goal is that you want to modify the color of the caret by hiding the focused field and writing to another field. Not sure why you want to do this as I assure you your users don't care and you run the risk of interfering with the users experience... and as I type this message I don't even notice the color of the caret in Chrome... buuuut, I have a feeling that you still think that your inputs are more special than others. I feel for your users who try and put the cursor at an earlier point in the input to fix a typo... I digress.
Instead of 2 inputs, create a single input, set it's opacity to 0, and write the entire value to a DIV whenever it changes. This has many benefits:
You get many of the default behaviors of the input without actually needing to see it (eg. cursor on hover on desktop, keyboard navigation, etc).
Your form can still do a vanilla submit without needing to copy values or any other javascript weirdness.
Any other code, validation scripts, etc don't need to change - the input is still getting a value and emitting all events.
https://jsfiddle.net/2sp92bpy/1/

Change cursor style in firefox input file tag

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

Can DIV replace TextArea

As we know can set contenteditable in DIV to allow editable. It can make same like Textarea.
However there's the most big different are the "content copy and paste" to DIV and Textarea.
DIV is allow html/plain but Textarea only serve plain text.
Below are the method to solve those problem:-
Method 1 - Direct using window.clipboardData.getData('Text') ( will prompt for asking permission).
Problem : Mozilla and chrome are not support clipboarddata.
Method 2 - Using flash.
Problem : Flash v.10 has upgraded to new rules which cannot get clipboarddata without user first initialize.
Method 3- Using "onpaste" event. When data paste on div -> Set focus
on hidden textarea -> Get value from hidden textarea and set into div
by using setTimeout -> clear hidden textarea.
Problem : The timing set value to hidden textarea are not consistent.
I have saw google was doing well on this.
For IE , use clipboarddata.
For Mozilla,others (not support html5) - Anyone know how google done it ?
Hint: use iframe designmode ?
For Chrome (support html5) - Just set DIV to Contenteditable="plaintext-only".
The trick that I use for this kind of thing is to have an offscreen <textarea>, which is not visible to the user.
The textarea is focussed and has a keyboard handler that notices whether the user is typing in the textarea. As I detect the user is typing, I grab the value of the textarea and dump it in the div.
This is the basic idea. You'll need a bit more to get the look and feel right:
you can't just hide the textarea with display:none or visibility:hidden because that will generally make it insensitive to typing and events too. So you need to make it really small and position it outside the screen, or stack it behind some other element.
you're going to have to detect whether the textarea blurs and decide if you need to refocus it.
You'll want a click handler on the div so that if people click the div you can focus to the textarea instead so people can start typing again.
The nice thing about this approach is that general keyboard handling, like ctrl+cursor, and cut+paste etc. all work exactly as expected without having to code that yourself - you're just piggybacking on the existing functionality of the textarea.
Here's an example of how this works:
http://js1k.com/2012-love/demo/1168
(A javascript shell)

Why will Webkit not repaint my webpage properly?

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.

Can we make IE7 treat a FILE TYPE=INPUT element as a single control?

When it comes to navigating through an HTML form by hitting the TAB key, Internet Explorer 7 treats an INPUT element with TYPE=FILE as two controls (see MSDN for details). The first time you hit TAB it focusses on the text field, and the second time it focuesses on the Browse button. This is invisible to JavaScript.
The problem is I want to use Ajax Upload or something similar to allow the user to click what looks like a button and see the File chooser appear. This works by placing an invisible file-input element under the mouse. I have managed to change the script to allow you to TAB to the hidden file-input element and for this to trigger a CSS change so the fake button looks like it has focus, the upshot being that, on browsers other than IE7, it looks to the user as if you can tab to the button and activate it as you would expect.
This cannot work on IE7 because the first TAB takes it to the invisible text field; pressing SPACE adds a space to the invisible file name instead of activating the file picker. I have tried adding an event handler for keypress that calls the click event, but when I do this the change event I am depending on seems not to be fired.
I am beginning to think the only accessible solution on IE7 (and, I assume, IE8) will be to replace the whole dialogue with a two part form -- the first part with a (visible) file-input element and Upload button, the second part with all the other form items. This is unfortunate because (a) IE7 get a less slick user experience, and (b) I have to add all sorts of extra server-side code to allow the form to be submitted in two parts.
So I would be interested to know if anyone has a way to make IE7's file-input element behave like a single control, or, alternatively, to allow JavaScript to access both controls of the element (something the DOM was not designed for!).
This a bit complicated to do but here's how:
Create a new button to use as your "fake" input control (you have this as the visible element). This element needs to be a button or a link for it to be able to get tab focus (I suggest button so that it works better on Safari).
Remove the file input from the tabbing order by setting it's .tabIndex to -1. It should now be hidden from sight and tabbing order.
Assign events to the file input so that on activity then the focus is moved back to the fake button, values are copied from it, and so forth.
Assign a click event to the fake button that calls .click on the file input element. This will only work for IE. It will also very likely break in a future release.
For mozilla style browsers you can move the focus from the fake button to the file input on keydown, the keypress event will the occur on the file control and you can then move the focus back to fake button on change. This should also give you del/backspace functionality (clear field).
Clearing the field in IE can only be done by rebuilding a new file input control.
As should be obvious from my other answer, I have managed to build this widget with full keyboard accessibility.
My sincere advice is to drop this pursuit. It is a maintenance nightmare. You are exploiting security holes in the browser to make this work and it is only a matter of time before vendors close something that you rely on.
You could also check out swfupload, as it may provide what you're going for and more.

Categories

Resources