I'm using some HTML5 form features to progressively enhance the user experience of my web project. One in particular is autofocus, I'm wanting to use this in a modal (lightbox) dialog that allows users to enter tags. Existing tags could be there.
The only browser I have installed that supports autofocus is Chrome 9, however when I test it there it does place the focus on the field, but also automatically selects all existing text in the field. I did not expect or want autoselect, I want autofocus.
Is my expectation wrong or is Chrome wrong?
Chrome decided they were wrong and changed this behaviour in Chrome 36.
I know this because I was wrongly relying on javascript .focus() and html autofocus for also selecting the text. Now it requires a .select() to select and focus in the text field. Good that we can now be specific of what we want :-)
So now Chrome behaves like e.g. Firefox.
Read more about autofocus and html5 here: http://php.quicoto.com/autofocus-in-html5/
If you have a snippet of code we could look at, we might be able to further be of help. It looks fairly simple and painless to implement and says the feature is supported in everything but Fx and IE.
From the HTML5 specification, the focusing steps do not prescribe whether or not text should be selected. User agents are neither required nor forbidden to select the text. Specifically, here is the relevant focusing step:
The user agent may apply relevant platform-specific conventions for focusing widgets.
Note: For example, some platforms select the contents of a text field when that field is focused.
It is supposed to select the text, as input.focus() does this too.
Related
I've got a form with a textbox on it. I have had to apply an input mask on the field as per client's requirements. Client now wants to obscure the input in the manner of a password input field. I've tried setting it as password input but the mask stops working, Is this possible or should I give up now?
I found this:
https://css-tricks.com/snippets/css/password-input-bullet-alternatives/
Which leads to this example:
http://jsfiddle.net/estelle/8WpNg/
using the -webkit-text-security property
Seems to work in Chrome, but not Firefox. Searching a bit further I found this article that seems to discuss a JavaScript solution to making this degrade gracefully across browsers that do not support this feature with CSS: Degrading -webkit-text-security
My question about AngularJs that I can't seem to google my way out of just yet has to do with the way Angular handles forms and form validation.
Ideally I want to make my form cross-browser compatible and use the 'Angular-way' of handling forms. Commonly one would set the novalidate attribute on the form tag because that disables any html5 related form validation the browser wants to do.
But, and this is the thing: does that also mean that Angular handles the way inputs of, say, type="email" and does the browser ignore them? Does Angular guard the fact that the user enters a properly formatted email instead of the browser's implementation of the input type="email" field? And thus does Angular mask the input as well?
I ask because there are several useful types (like email and url) that aren't strictly cross-browser, but I'd really like to make a universal form with Angular's goodies.
The answer depends a bit on what you expect your validation to do. Take the email field as an example. If you look at the quirks documentation you will see the automatic validation for the field type works in most browsers except for IE9 and Sarafi. Bringing angular into the mix doesn't change this at all so your standard validation isn't going to work in all browsers.
That said, Angular actually is binding the value of the field to a variable via model binding. So it doesn't rely on the browser validation entirely but actually provides its own validation. I checked this page, and even on Safari for Mac, the validation works excellently. Even with this in mind, I would still recommend opening the plunker and trying out what fields you need to validate on all browsers you really need to support.
One final thought is that Angular itself is no longer IE8 compatible. Although the team doesn't intend to break IE8, they aren't testing in it any more (See here for details). In other words - if you need really old browser support you are going to have to test that yourself!
I've been developing for some time now...every now and then I find out about more HTML tags, PHP functions etc that I never new I had at my disposal.
Today, I'm talking about the different HTML input types....well, only one and then some link->rel values...
Input type: search?
I have looked in several places and all I get is the obvious answer of what it's purpose is.
I can do fulltext queries just fine by making the field a text type...
so what's the technical difference between the text and search input types? and are there any benefits of using making the input field a search type?
And, I have similar misunderstandings with some of the rel values of the link tag:
Next, prev, search etc...
I can do the same things without using those rels...I can create a 'slideshow' of articles without using next/prev. search, i don't understand at all... I can only find the defeintion of it..'Links to a search tool for the document'...does this mean a tool like that which google provides so your users can search through a document?
I can do these things without using s altogether so I'm guessing the answer to my question is in the fact that I don't use for these tasks and maybe I should? Combine then with AJAX?
Thanks
At the moment, there are no differences between input type='search' and input type='text'. The reason these new HTML input types are put in place is so that functionality can be added later in the future. It's good practice to use type='search' when you are creating a search field, as it could become more useful in the future and it also makes your code more semantic.
There are really some differences are there between "search" and "text"
These two are rendered differently according to the browser. safari, Chrome like browsers adds a cross icon to clear the field more quickly than normal text field.
And in smartphones it changes the normal return button of the soft keyboard into magnifier or search button. which is more user friendly
some browsers will trigger certain applets while user is on a search field
HTML 5 defines a lot of new input types such as date, time, number, email, ... (you find a complete list here) which can be used by modern browsers to provide more functionality such as validation or support for input.
The browser can display a calendar for date inputs. On a touchscreen a different keyboard (containing #) is shown for an input field of type email or phone. For the search attribute an hourglass might be shown.
You should always use the new input types, as they provide more semantic information. An old browser will interpret them as <input type="text" />. A disadvantage is that different browsers display the same field differently and some browsers do not use the tags at all. For input type search a magnifier might be displayed.
Your second question is about link types. Again, this is semantic information mainly for search engines or user agents. The different link types might be displayed in a separate navigation bar.
I'm experimenting with placeholder attribute, but I have noticed that if I focus the field on Chrome the placeholder disappears, in Firefox it disappears only after the first keydown.
I like Firefox behaviour: how can I force Chrome to act the same way?
Thanks a lot
The specification states (emphasis mine)-
User agents should present this hint to the user, after having
stripped line breaks from it, when the element's value is the empty
string or the control is not focused (or both), e.g. by displaying it
inside a blank unfocused control and hiding it otherwise.
This means that browsers may implement either approach you described above. To deviate from the browser default behaviour you would probably have to write a custom JavaScript solution which would have an on keyup event handler and compare the input value with an empty string.
I would personally implement this using a data-placeholder attribute on the input to hold the value.
As it happens though, it would appear that Chrome has changed its default behaviour as with Chrome Canary and Chrome 31 (which is current), the placeholder value remained visible until the user started typing in the JS Fiddle I linked.
This behaviour was only tested on the "desktop" version of the browser, and only on the Windows operating system. It is possible there may be some variation on other platforms, even with the same browser.
Chrome auto-updates, it is in fact relatively hard to prevent this from happening, so it is highly unlikely that many of your users will be using a version as old as Chrome 14 (released September 2011). Generally it is my experience that statistics will show Chrome versions in use being divided between the last three versions, usually mostly the current and previous version (with ratio dependent on the time since the last release).
As a result, it would appear your issue is unlikely to affect many (if any) users.
Please note the following from the specification though-
Note: Use of the placeholder attribute as a replacement for a label
can reduce the accessibility and usability of the control for a range
of users including older users and users with cognitive, mobility,
fine motor skill or vision impairments. While the hint given by the
control's label is shown at all times, the short hint given in the
placeholder attribute is only shown before the user enters a value.
Furthermore, placeholder text may be mistaken for a pre-filled value,
and as commonly implemented the default color of the placeholder text
provides insufficient contrast and the lack of a separate visible
label reduces the size of the hit region available for setting focus
on the control.
Please don't use the placeholder as a replacement for labels, or at the very least have a hidden label for accessibility purposes (as in the Google example you cited).
In the HTML input tag, if the required attribute is set to true, the browser shows a notification to fill up the text box. This notification has different style in different browsers. So is there a way to customize the notification style so that it looks same in all browsers?
tryit in different browsers.
Thank you.
You could try to do so by using JavaScript to override the behaviour but the most likely result is that people would stop using your site as they are used to the behaviour of the browser that they use all the time and be disconcerted to see something else.
The required attribute is a feature of HTML5. You may know that HTML5 is not supported by all the browsers (e.g IE7,IE8). So you need to look for alternative JS solution for this.