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
Related
<nav> typically has <a> elements inside it, but is it required? I have a radio button form whose purpose is akin to navigation. It doesn't navigate to other pages on the Internet, but instead changes the visibility of elements within the body of the HTML document (like a carousel).
Thanks! I've been wrestling with semantic markup tonight!
tl;dr: No, the nav element requires links (but not necessarily a elements).
W3C’s HTML5 defines the nav element like this:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
By default, a radio button doesn’t link to a part within the page. In your case, it changes the visibility of an element on the page. So it’s not appropriate to use the nav element for this purpose (unless, maybe, changing the radio button focuses the changed element; but that behaviour might be bad for usability).
The whole point of semantics, is that when viewed in an entirely different light, it's still readily clear in how to derive meaning and relational context from the content.
A web browser will parse your HTML out of the Dom after every load or change, and construct an opinion based on that about the content. The browser will keep this handy to itself internally in case it needs it later to assist it with difficult judgement calls should it be asked to perform a seemingly complex operation.
For example, someone who has really poor eyesight might enable an accessibility feature on their mobile device that tacks on a variety of different visual styles adding a great deal of visual emphasis to interactible elements they can touch, depending on the type of interaction. This could be something like a bright color coated and outlined overlay on top of elements, perhaps something like cyan for multimedia controls, yellow for form elements, and magenta for navigation points. This feature would have to work on any and all possible content which the browser will ever render, and so what you've got is a hidden under the hood runtime script that the browser is using to dynamically parse what ever it's loaded in order to construct some sort of opinion which it can lean on exorcise what will hopefully be good judgement. So no matter how clear your navigation might seem visually to someone with great eyesight, this is why semantics are such a big deal and why it's so important we continue to make efforts to use them correctly, as here you have a machine alternatively parsing your source code because it has zero comprehension of it's otherwise visual context.
When it comes to accessibility, browsers are much more complex in forming their opinions than just simply parsing the Dom. In a scenario such as this example, and the code you're wanting to write, wrapping your navigation elements in a nav tag should properly assist the browser into making the right call. Even if they're not link tags, the browser is going to take note of any elements inside of a nav tag witch active event listener handles items like click and similar.
As another user mentioned, semantics is all about judgement. There are countless other ways which good semantics play a role into good development, dry code and easier maintainability being my two favorites. There are no hard lines for "can do" and "can't do", but practicing good semantics is still pretty easy to do regardless. Just continually ask yourself these couple of questions about your core content-
• If someone or something tried to use this in ways which I'm not explicitly building in targeted functionality for, do I think it will be able to understand what content is what and the associated intents well enough to be successful at what ever is being attempted?
• If I was to refactor or repurpose any of this later, is there a clear separation of content, logic, and style? Is my content clean, and meaningfully distinguished? Is it so clean and ready, that I can just rip it out and drop it into something new with little or no change? Essentially, how portable is this content? Is it plug and play level portable? And if not, could it be made more portable with better semantics?
Practice developing with proper semantics using those couple of core guidelines, and you'll almost always be perfectly fine.
Just to make sure I've directly addressed your question- Yes. What you've done is "okay", and "semantically legal" 🙂
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
I am trying to disable and hide a checkbox. So the total amount of HTML is small; I can't imagine performance could be an issue.
As far as writing server code goes, the coding work is about the same.
Given these two options, is one better practice than the other? Or does it not matter which I use at all?
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
No, these two options don’t have "exactly the same behavior".
If you hide an element with CSS (display:none), it will still be rendered for
user agents that don’t support CSS (e.g., text browsers), and
user agents that overwrite your CSS (e.g., user style sheets).
So if you don’t need it, don’t include it.
If, for whatever reason, you have to include the element, but it’s not relevant for your document/users (no matter in which presentation), then use the hidden attribute. By using this attribute, you give the information on the HTML level, hence CSS support is not needed/relevant.
You might want to use display:none in addition (this is what many CSS supporting user agents do anyway, but it’s useful for CSS-capable user agents that don’t support the hidden attribute).
You could also use the aria-hidden state in addition, which could be useful for user agents that support WAI-ARIA but not the hidden attribute.
I mean do you need that checkbox? If not then .hide() is just brushing things under the carpet. You are making your HTML cluttered as well as your CSS. However, if it needs to be there then sure, but if you can do without the checkbox then I would not have it in the HTML.
Keep it simple and readable.
The only positive thing I see in hiding it is in the case where you might want to add it back in later as a result of a button being clicked or something else activating it in the page. Otherwise it is just making your code needlessly longer.
For such a tiny scenario the result would be practically the same. But hiding the controls with CSS is IMO not something that you want to make a habit of.
It is always a good idea to make both the code and its output efficient to the point that is practical. So if it's easy for you to not include some controls in the output by adding a little condition everything can be managed tidily, try to do so. Of course this would not extend to the part of your code that receives input, because there you should always be ready to handle any arbitrary data (at least for a public app).
On the other hand, in some cases the code that produces the output is hard to modify; in particular, giving it the capability to determine what to do could involve doing damage in the form of following bad practices: perhaps add a global variable, or else modify/override several functions so that the condition can be transferred through. It's not unreasonable in that case to just add a little CSS in order to again, achieve the solution in a short and localized manner.
It's also interesting to note that in some cases the decision can turn out to be based on hard external factors. For example, a pretty basic mechanism of detecting spambots is to include a field that appears no different in HTML than the others but is made invisible with CSS. In this situation a spambot might fill in the invisible field and thus give itself away.
The confusion point here is this: Why would you ever use display: none instead of simply not render something?
To which the answer is: because you're doing it client side!
"display: none" is better practice when you're doing client side manipulations where the element might need to disappear or reappear without an additional trip to the server. In that case, it is still part of the logical structure of the page and easier to access and manipulate it than remove (and then store in memory in Javascript) and insert it.
However if you're using a server-side heavy framework and always have the liberty of not rendering it, yes, display:none is rather pointless.
Go with "display:none" if the client has to do the work, and manage its relation to the DOM
Go with not rendering it if every time the rendered/not rendered decision changes, the server is generating fresh (and fairly immutable) HTML each time.
I'm not a fan of adding markup to your HTML that cannot be seen and serves no purpose. You didn't provide a single benefit of doing that in your question and so the simple answer is: If you don't need a checkbox to be part of the page, then don't include it in your markup.
I suspect that a hidden checkbox will not add any noticeable time to the download or work by the server. So I agree it's not really a consideration. However, many pages do have extra content (comments, viewstate, etc.) and it can all add up. So anyone with the attitude that they will go ahead and add content that is not needed and never seen by the user, I would expect them to create pages that are noticeably slower overall.
Now, you haven't provided any information about why you might want to include markup that is not needed. Although you said nothing about client script, the one case where I might leave elements in a page that are hidden is when I'm writing client script to remove them. In this case, I may hide() it and leave in the markup. One reason for that is that I could easily show it again if needed.
That's my answer, but I think you'd get a much better answer if you described what considerations you had for including markup on the page that no one will see. Surely, it must offer some benefit that you haven't disclosed or you would have no reason to do it.
On many websites, when typing in a username for example, a dropdown occurs where previous input shows up so the user can easily select something instead of typing. I know you can turn this off in browsers by having the form or input have an attribute of autocomplete="off". The problem is when I want it on, and the input has padding. The dropdown looks horribly off because it has no padding for each item.
Is there any way to style this with only css? I'm aware that you could potentially use a javascript/jQuery workaround to store previous entries in a cookie or something and make your own dropdown. But I don't want to rely on javascript for this.
Nope. Autocomplete is not a part of any standard, and is not part of the DOM. The only way to style is, as you've suggested yourself, by recreating that functionality using JavaScript.
Unfortunately there is no way to style the drop down box itself with CSS, because in this case (when not using javascript/jQuery/mootools/etc.) it is operating system dependent - i.e Windows/Linux/Mas OS visualize it according the visual user settings (i.e scheme).
I have inspected many navigation menus on the internet, and they often use lists instead of a button. What is the reason behind this? Why use the button? Thank you.
Generally lists are used for navigation items in HTML because they are presenting a list of navigation options to the user.
HTML5 offers a bit more semantic precision using menu and nav
There are (at least) two good reasons to use lists. Using lists can help to give an idea of your site's structure which is good in terms of SEO but also if people use either custom CSS or screen readers for accessibility reasons.
The second and slightly related one is that it's rather helpful when it comes to creating stylesheets. You don't need to come up with your own way of nesting elements. Just use lists and go from there. Then you can focus on getting the stylesheet right providing different styles for different hierarchy levels, first, last, odd or even list items.
The semantics of a list make it look more like a grouped section, that's all I can think of.
There is no real (dis)advantage for using list items over other methods of defining a menu.
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.