Basically I have a text box with a modifier dropdown. I would like an icon of the current choice to display when chosen. The problem with the current set-up (using UNICODE) is that the icons do not always display, such as on google chrome (unless the specific fonts have been installed).
For example see the Fiddle:
https://jsfiddle.net/q5eLLu2h/
<select class="squareDropdown" id="da" name="da">
<option value="AND">➕ AND</option>
<option value="EXCEPT">➖ EXCEPT</option>
<option value="OR"><b>O</b> OR</option></select>
<input class="textArea" id="d" name="d" placeholder="d" type="text" />
<br>
<br>
<br>
<select class="squareDropdown" id="ca" name="ca">
<option value="OR"><b>O</b> OR</option>
<option value="AND">➕ AND</option>
<option value="EXCEPT">➖ EXCEPT</option>
</select>
<input class="textArea" id="c" name="c" placeholder="c" type="text" />
Does anyone have any advice on what I could do? Either a way to get the unicode icons to display (like through forcing the person to download them?) or a simple way to get pictures or images into a select box, or anything really. Jquery UI is installed, is there anything I can do with it?
Thank you
Options are hard to style.
The basic reason is that they are reaching into the operating system for generation rather than being generated solely by the browser like most other website HTML elements.
This is why file upload form field 'submit' buttons don't follow the same rules as any other submit buttons on a form.
Here is some more detail about limited and inconsistent possibilities and a question that proves <option> can't have any children (this in turn stops the psuedo-elements from working, unfortunately, as psuedo elements are rendered like DOM nodes).
All this means that using an icon font won't work either as you'd need to target just the bit with icon in, which you could only do with extra child elements.
Using JQuery
There are many ways of mimicking select option form fields with various javascript plugins that will give you more control, however, they come with an important caveat. Standard select elements bring with them all the extra usability and accessibility features (such as keyboard focus and operation) javascript plugin writers don't necessarily think about, so use with care.
It's also worth remembering that when you are replacing complex functionality with JQuery you've got quite a lot of overhead in testing / development - select elements do just work in all browsers, without their actual functionality needing testing. This is more considerable if you do pay attention to all the accessibility points.
The MDN article does however judge that this is the best way and lists some good plugins for a solution, which I would use as MDN can be trusted to have considered all the important stuff I mention above.
For the sake of link rot, here are the two of the three they recommend that link to a product still:
UniForm
FormalizeMe
(please note, I haven't tried these, I'm just trusting Mozilla!)
Unicode
You are trying to use unicode in your option tags. This should work, and without forcing a download on the user if you:
Use a font that has the unicode characters you want to use defined.
Ensure that you have the charset in your docs set to utf-8
However, you'll only ever get characters, never styleable icons and you might be stuck with websafe or proprietary fonts.
This jsfiddle here demonstrates with the web-safe font-family: sans-serif and also characters taken from this link with a big list of those that are commonly supported
And finally
For small option sets radio buttons are probably better. The user can immediately see the available options rather than having to open them each time (better learnability, faster cognition); plus, they can make their desired selection, or change their desired selection with just one click each time. The guys over at UX.SE discuss what to use further, raising other points.
All your problems might just disappear if you think about whether <select> is the best option.
Related
Can any browser developer, or anyone who knows why it is so difficult (if not impossible) to style the dropdown list of a <select>, there's any "real explanation" that prevents browsers treat the <select> <option> in a more convenient way.
Every time I see questions like How to modify CSS of a dropdown? in different sites that receive answers like
"It's not possible to style the dropdown list of a html select. But you can build your own dropdown list or use a framework like bootstrap."
or
"If you decide that it's absolutely a good idea to customize a dropdown, then you should use JavaScript".
And I really don't know why, I know now the <select>, I mean the container box, can be styled a little more using
select {
-webkit-appearance: none;
-moz-appearance: none;
appearance: none;
}
And then giving our styles, which is not as simple as all say because we have to do some tricks to make it right, especially with the famous litter arrow.
As time passes we are neglecting such a simple and comfortable as the <select> element and almost all the developers opted to use some of the answers above and at least I still do not know why.
So at least I will be grateful if someone could help me.
Dropdown lists are highly dependent on the system they're running on. Just look what they look(ed) like on iOS:
The <select> element is giving you a uniform way to mark up the functionality of a list of options which can be selected. How that list is represented is entirely up to the browser, and the browser can implement it in the best possible way for the given circumstances. As such it makes no sense to try to "style" it in any way, because you cannot predict how it's going to be presented in the first place.
Usually every operating system a browser runs on has native dropdown lists, and they can look very differently on different systems. The idea is that the <select> element can use the native dropdown list style of the underlying operating system.
It's not that it's "hard" to do, it's that styling a dropdown list makes no sense given the presentation-neutral priorities the <select> element embodies. It is the lowest common denominator of what a dropdown list is across all systems, hence system-specific styling makes no sense.
I´ll just share here the answer I wrote yesterday after reading about selects. As it´s not the same question, I´ll not mark it as duplicated, but anyway is a little wide question to talk about.
About selects:
They are not usual DOM elements, and that makes them behave different from others. It seems the browser generates them outside the DOM model, and then the events like click, or keypress on options do not work.
Also attributes like size will change their behaviour (a size bigger than 1 will make it appear as a list, not a dropdown).
Check this answer:
Check if select is displaying options
As you can see, there is an example with Jquery, then you will be able to style it, or to play with it´s properties. Also there are some useful links and the explanation for them.
Hope this explanation could help to you.
Regards
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/.
This is a "best practices" question. I was perusing the Code Review StackExchage site, and I saw this thread. In it, Joseph Silber makes the suggestion of using bracket notation and eschewing IDs entirely for a form with multiple identically-structured rows of form inputs.
In the books I've read on web design/development, I've never seen this strategy used. Is using bracket notation and wrapping input elements within label tags, as well as not using id tags in form inputs a good idea? Perhaps there something about Javascript/JQuery that makes this approach advantageous?
I wanted to ask Joseph about it directly, but I don't have any reputation on the site yet so I couldn't even comment. However, I'm interested in seeing the community-wide perspective on this, because searching for things like "HTML5 bracket notation" and "HTML5 arraylike notation" isn't turning up anything definitive for me so far.
Here's a summary of the above question with some example code borrowed from the linked question:
Why use this:
<label>Comment:
<input type="text" name="comment[]" width="50" />
</label>
instead of this:
<label for="comment-0">Comment: </label>
<input type="text" id="comment-0" name="comment-0" width="50" />
in a form with multiple rows of the same inputs?
Sticking [] on the end of an input name will cause some server side form processing libraries to present the data as an array. Some other form processors don't need the special syntax. Your choice will largely depend on your desire to be compatible with the former kind vs having more complicated names and not being able to access the elements via dot-notation in JS.
Using child elements instead of for attributes will:
Save you from having to generate unique ids (especially useful if similar forms can appear on a single page)
Limit your styling choices
Be compatible with fewer browsers (I think the only loss is old versions of IE, which is no big loss).
So there are pros and cons there and you have to decide what it right for you.
There are several hidden form fields on my pages that are used for passing data to server side. For debugging purposes, I feel it easier to hide all eligible input fields by just making them all a part of hidden class than setting the type=hidden attribute on each input field.
Whenever I need to debug I could easily modify that class attribute to enter debug mode. Ofcourse both the approaches work in hiding the input fields but I am not sure as to why this approach(hiding via class) isn't much widely used in real life. Can you throw some light on what should be preferred approach ?
<input type="hidden"> won't trigger input validation, auto completion, and other user interaction related events. It's designed to save raw data, without user's direct input.
But a <input type="text">, visually hidden, are still going to be considered as a user interaction component. And on some devices enabled visual aid, it will serve as not hidden, and cannot provide the consistency you expected. That's why it's not preferred to do so.
Eg. a <input type="hidden"> won't auto complete it self, or preserve the inputted data before refreshing a page, or prevent the form from being submitted for a failed type validation can't even be seen.
The CSS approach is bad for usability, and accessibility. Think of someone with CSS disabled (very old mobile phones, people with a screen reader), they won't render your CSS as you might expect, and the input with all of its glory would be displayed to the user.
A hidden input should be used for implied user input, meaning, input that would come from the user, but is implied and does not need to be manually entered.
Your question falls more onto the type="hidden" approach.
I'd recommend using <input type="hidden" /> because it is the standard way of HTML to hold a user's input value. If you use another attribute for type and hide it with css, one problem may arise is that when the css fails to load, the input control will show up.
I think your question is about the best approach for debugging form fields. I recommend keeping them as type='hidden' in your HTML. This is best for you, for your users and for semantic interpretation of the page.
Instead, use a tool like the Chrome Developer Tools to do your debugging. This will let you easily see the values of your hidden fields.
Problem is here. I have simple page with form and not so much other text content. In form I have for example:
<h1>It should be my search result</h1>
<form>
<select name="Months">
<option>January</option>
<option>February</option>
...
<option>December</option>
</select>
</form>
In search results/page keywords I have more months names than other important content, where keywords should be IT SHOULD BE MY SEARCH RESULT only. How I can disable select content from results? Possible?
Repositioning the code (as mentioned in the other answer) does work when you're trying to prioritize content on the markup level. However, it doesn't take care of the keyword density of the month names you want to suppress.
If your page is littered with multiple dropdowns with the same 12 months in them; you could use Javascript to add the dropdowns after the page is done loading. It will suppress it from Google Crawlers while also leaving it in for site visitors. Of course, too much Javascript will be a performance hit.
(Note: on a SEO level, Google doesn't like when you show Google a different page than what would be shown to a site visitor; but I don't think this would hurt you).
If your month names are literally inside the search results content, you could try using server side code (PHP, ASP.NET, etc.) to filter out the month names entirely or replacing them with ellipses; though, may be confusing
It really depends on what your results page would look like. More information would be needed to get a better idea on the best way to tackle it.
Here is an article on 4 ways to hide content from Google
http://www.searchenginejournal.com/4-ways-to-hide-content-from-google-and-googles-reaction/6782/
I would use the option of moving the navigation to the bottom of your code and then reposition it with CSS so that it appears in the location you want. Then from the user's perspective it will appear at the top, and from Google's perspective appear at the bottom.
No guarantee that this would work (it might be viewed as deceiving the bot), but try to split the months into meaningless parts by <wbr>.
<select name="Months">
<option>Ja<wbr>nuary</option>
<option>Fe<wbr>bru<wbr>ary</option>
...
<option>Dece<wbr>mber</option>
</select>