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.
Related
So I read a lot of articles that say that HTML 5 form validation is accessible (things required attribute which will prevent the form from being submitted is a field is left blank), yet when I tested my form on NVDA on Chrome and BackTalk on Android, if I hadn't filled in the input, it focuses back to the input field (which is good!) but both screen readers announce "Please fill in this field" which is useless to the user, since they don't announce the label of the field.
So HTML5 validation alone isn't accessible? Also, can you combine HTML5 validation and custom JS?
Do you have to write custom client site validation in order to make forms accessible?
Short Answer
Yes the standard HTML5 validation is accessible and will pass WCAG2.1 AA, but you can do a lot better with some JavaScript.
Long Answer
If you need to support Internet Explorer 9 or below then you will need to use JavaScript (which according to WebAim survey - section "Browsers" still covers around 3.6% of screen reader users).
Native HTML5 validation is a very good starting point, but there are limitations (you gave one in a comment, some screen readers (NVDA) do not announce the label again, meaning a user has to physically ask for the label to be read via controls).
The other thing is that once you leave a field it doesn't normally tell you you have made a mistake until you have submitted the form (it is meant to but this is not always the case depending on your announce speed, settings and browser).
For example updating aria-invalid is useful for immediate feedback (and provides support for older browsers, while being more robust with 'unusual' screen readers).
Using an aria-live region to provide immediate feedback onblur (or throttled / debounced) is also useful and a better solution.
One other thing is that the native validation is not actually very effective. For example fff#fff shows as a valid email and will allow a form to submit on a type="email" field, same with type="url" it will allow https://fff to be submitted (in Chrome at least).
I could go on with other things such as providing better instructions on how to fix errors (especially for things like phone numbers) but you get the idea.
Basically, use as many native HTML5 features as possible to give a solid grounding and a good fallback for JavaScript errors / people not using JavaScript. Then use CSS and JS to improve the experience for everyone.
Also, can you combine HTML5 validation and custom JS?
You can and you should but be aware that you end up doubling up validation (which isn't a bad thing as I stated for fallback).
The beauty is you can use pseudo selectors in your JavaScript to target fields by type, saving the need for adding unnecessary classes etc.
e.g. document.querySelectorAll('input[type=email]') could be used to select any email input for validation or document.querySelectorAll('input[required]') to find all required fields.
You can also use things like max="100" on slider / numeric inputs to set your validation ranges 'on the fly' and still have a fallback for no JavaScript.
As you can imagine this let's you write a library if you can't find an off the shelf one that is reusable on nearly any form.
In modern browsers the standard of autofill and autocomplete is to completely ignore autocomplete="off" for password fields that are placed in a form. And insert saved passwords, even if it's in a user management page. Although the reason is in the right place, it makes creating a user management page a huge pain.
My team's web application runs with angular 7 and currently only supports chrome. But there's a big possibility that we will need support other browsers like internet explorer, edge, firefox, etc.
I know this is a largely touched subject, and that I can find many questions with answers similar to this question (like this, or this). But every solution I've found so far has at least one big flaw.
What I've tried so far on chrome:
1) Use autocomplete="new-password"
It seems that chrome/chromium developers ignores even this for type="password".
2) Use type="text" autocomplete="new-password" with asterisk font family
This disables chrome from auto-filling the input field and hides the letters. But the big flaw is that the value is still there and can be copy-pasted in a different font family. The input field also loses the security of type="password" and any hacker can easily get the value.
3) Use -webkit-text-security
This is pretty much the same solution as the one before but this isn't even css standard and few browsers support it.
4) Replace value with *
This is the trickiest solution I've tried so far. When input value is changed I call a function in typescript that: Adds the new character to a local string, Change DOM value to * equal to the amount of characters, Return the locally saved value on (blur).
This leaves me with a large amount of problems to deal with including: Erasing any character in the string removes the last character always, In addition to the last problem the first character will always stay the same even if the value is completely erased, Having to know where in the string to remove characters.
This solution is less than ideal.
5) Disable password management for domain in browser settings
This really isn't a solution to the problem as it means that I expect the users to turn off password management for domain. It would also result in not saving the password on the login page as many users may need.
6) Randomise [name] and [autocomplete] values
By one way binding said values to a randomised string based on current time, I can ensure that the password field doesn't match any fields saved by the browser. Although many has reported that this works between all browsers, this doesn't seem to work for me at all when using chrome. For me chrome shows recommended password as long as the input is of type="password".
Solutions I've seen so far:
1) Use two input fields
This seems to me to work the same as my own solution 4). And will probably be just as troublesome to work with.
2) Use jQuery Disable Auto Fill Plugin
This seem to be very close to what I'm looking for but the problem is that it uses jQuery. All I can say is that I've been told that we're not using jQuery and that I probably won't be able to use the plugin directly.
I'm currently looking for a way to implement this using angular and would love any help or directions on this.
If you know of any solution that I haven't mentioned above, please post an answer or drop me a link in comments.
The best solution I've found so far is to use type="text" on password field and use autocomplete="off" on the form and every input field in it.
I won't mark this as an answer however as it still has the great flaw of losing the type="password" security functionality. Text fields also allows spell check which can be disabled with spellcheck="false". But I've read that it's possible to override this with browser settings.
This question will remain unanswered until a better solution is proposed.
I am trying to come up with a good way of displaying Access Key shortcuts on my html5 page.
Some places recommend using the first letter of a link/tab/heading/whatever as the access key, so as to be intuitive. Those places generally recommend that you "subtly" hint to the user that it is an access key by styling it differently to the rest of the heading--that is, to make it underlined, or italic, or bold. This sounds like it would be very ugly, and make people think that it is a bug!
Other places recommend using numbers as access keys, so as not to conflict with browser or device built-in access keys. Those places generally recommend showing access keys after the heading in brackets. This sounds even uglier, and less clear!
Is there a better way of choosing access keys, and how to display them?
Edit:
I really liked #Luke2012's recommendation of using both a letter and a number like:
<input type="search" name="q" accesskey="s 0">
BUT while this works beautifully in IE, it disables ALL of the access keys for the element in firefox or chrome.
You can use both letters and numbers as access keys which make it easier over a range of devices. For example:
<form action="/search">
<label>Search: <input type="search" name="q" accesskey="s 0"></label>
<input type="submit">
</form>
Both s and 0 will trigger the shortcut key.
As far as displaying the shortcuts to a user, what about an information icon that can be hovered (like a tooltip) to explain the shortcut keys. Or a subtle dotted line under the element that will trigger a tooltip when hovered.
There are two options that came to my mind:
A) Some programs, for example the CMS Plone, provide short, automated overviews with a list of the used shortcuts. You could display a link to your users to some "help" page where those are explained.
B) It is very common that accesskeys are underlined when pressing the Alt key. You could mimic such a behavior using JavaScript. You could even read the given accesskey from the the HTML attribute and enclose the first matching character with a span.accesskey or something alike to automate the task of highlighting the the accesskey characters.
If you choose a letter, it seems to me they can be memorized more easily.
How to show them: Use the kbd element.
Where to show them: This depends on your site. Typically, access keys are useful for regular visitors, not for new users. So it might not be necessary to show the keys on every page, as regular users will likely memorize them anyway. Instead, document this feature on a separate page (or as part of a relevant existing page).
If you should use them at all, and in which way you should communicate existing access keys to your users, is probably best discussed at https://ux.stackexchange.com/.
How can I create input type="text" with <select></select> option. In other words I would like to have one field where can I input text, but if I want I could choice option from dropdown list from all values just like with select tag. Is it possible?
If you want to allow free-text typing with suggestions/pre-defined choices then I would encourage you to look at the HTML5 datalist element (see https://developer.mozilla.org/en-US/docs/HTML/Element/datalist) which is designed for precisely this purpose.
As browser support for this is limited to more recent versions of browsers (and not available at all in Safari, iOS or Android) you'll probably want to Polyfill this with something like JQuery UI autocomplete (see http://jqueryui.com/autocomplete/).
Not as a built in html control, no. You would need to create one using an input field and another element (such as a div or list) which contains the dropdown values, with javascript gluing the component parts together. There are plenty of tutorials on how to do this dotted around Google.
I just wondered and wanted to gather together in one place all missing features of our beloved html form elements.
One example could be missing of horizontal scrollbar in a listbox. But I am sure there are a lot of features we would like to see in our form elements by default.
One missing feature per answer please.
Thank you.
Date/Time picker controls, rather than always trying to manipulate a textbox, selects, or some other controls to create them.
Hell, they miss so many features, I wouldn't know where to begin! But here goes:
(Missing in HTML 4, don't know about 5)
Full visual customizability (background colours, borders, and text colours) for all elements (including checkboxes, radio buttons, and select elements)
Native input validation (without needing JS) for text inputs: Numeric only, alphabetic characters only, regular expression
An open enumeration, a "SELECT you can type in" would be handy in some situations.
If pretty much everyone, but not quite, answers the question in one of ten or 15 different ways, you have to either force everyone to type in the answer or have an "other" option with a separate text field.
The lack of intrinsic support for multiple windows (or even just modal dialogs) is ridiculous.
Think of the tens of thousands of programmer-hours wasted on acrobatic manipulation of div elements just to implement a UI that would be trivially easy in a desktop app.
It's somewhat pointless to list what is missing in HTML 4 since so much has been fixed in HTML 5. And then, most of us can't list what is missing from HTML 5 because we are not familiar enough with it yet.