Is there any way to share <option> tags between different <select> tags?
I have many selects, and all of them have the same exact options.
Since I don't want to populate the DOM with too many duplicates, I changed to using an input with a single datalist to share the options, however this both has issues with events (only fires a change event when unfocused, or the client presses enter), and also allows the client to write anything he wants, which really doesn't suit my case.
I don't think you can do that with straight HTML.
You can use JavaScript to populate all your SELECT tags. The OPTION tags will still appear several times in the DOM, but at least you don't be downloading them from the server.
An old question, but still worth a reply. In my case, I had a table of potentially hundreds of rows of data, with a select element with potentially hundreds of options. Page load times became too long.
My solution was to create 1 select element which is placed over the relevant element when that element gains focus, and focus is then moved to the select element. Result is that the memory footprint is reduced to only one instance of the selection, and only one iteration to populate it. Downside is two user interactions are required to expand the select, one to focus, and another to expand. How to automatically expand html select element in javascript link to ExpandSelect is now defunct. You can find it here https://gist.github.com/adamcoulombe/5390270 but it does seem quite verbose.
As said by zmbq, there doesn't seem to be a way to reuse <option> DOM element inside multiple <select> DOM element.
But you can lighten your DOM, by charging <option> element on the fly when <select> is opened. You can certainly do it manually, but there is also existing js library doing the job, as select2.
Related
I have an html table and I want to be able to hide and show columns dynamically (based on certain values on page load). It could be a large number of columns I need to hide.
I was considering taking the values from the columns that I want to be hidden and putting their values in a data- attribute on the <tr> element to and avoid creating dom elements that aren't being shown in the ui. I need the values somewhere because they are used in click events.
Are there any best practices out there that say it is bad to load columns into a table and hide them with say display: none;, or am I just over thinking it and being anal and should just hide them with css?
I'm unsure of any types of practices particularly for this application. Also based on the information given so far.
The way you are doing it is not the best choice of going about this situation. You are taking data and putting them all in their own elements which not only clusters up HTML with unessessary elements (that are always hidden by CSS) but also can be more taxing then it has to on you and your viewers computer.
When you could be using the data attribute this is a great way to keep the information more consolated, less clutter, well organized, easy to read and manage. Also even when a element has the styling display:none it is still using the computer performance to render all of those elements.
You can read this thread that explains: Read More
I have a simple button that I want to trigger something when pressed. I gave the button an id and created a listener for id.tap. This works fine, but when I put my button inside a template[is=dom-if] it stops working. Is this meant to work like this? How do I solve this?
Elements inside a dom-if don't exist yet when the element is created, so they're not accessible using this.$. Either give the element an on-tap attribute, or use Polymer.dom(this.root).querySelector to find the element.
FYI, the documentation recommends against the liberal use of dom-if.
Since it is generally much faster to hide and show elements rather than destroy and recreate them, conditional templates are only useful to save initial creation cost when the elements being stamped are relatively heavyweight and the conditional may rarely (or never) be true in given usages. Otherwise, liberal use of conditional templates can actually add significant runtime performance overhead.
Usinghidden$=condition might be the best solution.
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.
Is there any way to make select, which allows multiple selections look like ordinary?
Like a drop-down, you know…
<select multiple="multiple"></select>
look like
<select></select>
http://jsfiddle.net/UKf5Y/3/
Well, no. If there were, how would the user use it to select multiple items?
The only way that a multiple selection works is because all of the items are displayed at the same time and they can click-and-drag or click while holding down a modifier key.
If it looked like a drop-down box, how would you navigate to a second item without deselecting the first?
The styling of a select list, as well as many different elements in HTML (notably the input[type='file'] element, is really dependent on the browser. If you're looking to make it visually more appealing / different, you'll really need to use some JavaScript and use an "interface" to your select. Some really nice JavaScript libraries for select lists are jQuery Multiselect, jQuery UI Multiselect and select2, maybe you should look at those.
It's worth noting however that only select2 supports the single/multiple variants, and the styles still do look different, but how else would you be able to see multiple selections at one time? You could design your own solution which did look identical, but I think more than anything this would be misleading.
I inherited an application where display:none was used to control conditional display of input elements based the values of other input elements.
The way this was handled is by running some pretty ugly code to evaluate field values and reset the display property in the during page load. Every time.
Isn't there a better way?
Using display: none in conjunction with JavaScript and CSS is the easiest way of simply showing or hiding DOM elements on the fly. That said, you could manipulate the DOM itself by adding or removing elements rather than simply showing / hiding them (with jQuery, for example).
Maybe your should just redesign the form that uses all the display: none fields or rewrite/refactor the script that does this checking? If the form is too large split it into several pieces - this will help the user too. I personally don't like if the form changes often whenever I am trying to fill in everything.
If you are not showing and hiding elements dynamically as the user interacts with the form, then there's no need to use CSS/Javascript. Just use your server-side language (PHP/JSP/whatever) to not output the hidden fields. You'll use less bandwidth, and the form will work even with Javascript disabled.
Is the idea to reshape the form on every POST or reorder fields before submitting. If the first then the fields shown should be removed on the server-side before page get to the user. If you are talking about changing on the client side before a post (e.g. removing fields which are not relevant based on the input in some fields as the user types), you can use javascript to remove fields from the DOM.
The two things your solution needs are:
The forms must be functional without javascript (even if they feel less slick)
Don't submit fields the user cannot see unless they are input tags with type="hidden". You will only confuse yourself on the backend if you don't know whether a user left a field blank or could not see it because it dynamically had its styling changed by a client-side script.
there is an partial alternate to display:none i.e
use this style in css
opacity:0;
but problem with this is it doesn't appears on canvas but it is still there.
using display:none; completely delete element and creates when u apply attribute display:block;