-
Notifications
You must be signed in to change notification settings - Fork 27.5k
would be nice for <select> to support ng-size or size="{{expression}}" so we can set the size to the actual size for dynamic multiple selects #1619
Comments
I'm having the same problem. My workaround is to write a custom ngSize directive that 2way-binds to something and update the select.size attribute. |
+1 |
As part of our effort to clean out old issues, this issue is being automatically closed since it has been inactivite for over two months. Please try the newest versions of Angular ( Thanks! |
Same problem here using Angular |
This bug is still present in This is clearly a bug since whatever angular is doing, it's overriding DEFAULT HTML functionality. |
@RavenHursT, would you like to submit a pull request for this feature then? |
so its strange that this works for input, but not select. The docs say that size can only be a non-negative integer http://www.w3.org/TR/html5/forms.html#attr-input-size. I know for a fact that when angular is parsing the attrs in collectDirectives the value of the select size attribute is already 0. This means that we cannot interpolate the value correctly, because we have lost the reference to the original string passed in from the view. Since the directives are collected before the compile functions are even ran, I would think the best solution is to create another directive that we know will not be defaulted by w3 standards. |
Here is a proposed directive ngSize. It only works on SELECT tags as that is all it is needed for. http://jsfiddle.net/joshkurz/DFyWX/2/ |
"If you're not willing to fix it yourself, then you're not allowed to point out that closing an issue when it's a clear bug is not exactly the best way to support a community project" is a pretty lame cop-out. If you're willing to take the time to go through and "clean out" old issues based solely on the frequency of their activity, then you'd think you may be willing to take the time to actually look into the problem when it's been a verifiable bug for over a year now... |
Have y'all tried example: http://plnkr.co/edit/a1xLPGn2YeW0WavH2auD?p=preview Considering you have this feature, can we close this as resolved by cf17c6a ? |
I think there need be better documentation for |
@caitp -- brilliant! Thanks! However, @mlegenhausen is quite right. This is practically undocumented. One would expect it to be documented in the Directives section along with ngApp, ngBind, et al. (If it's not technically a directive, then by all means it should have its own section in the Developers Guide.) |
@caitp Thanks. That worked like a dream. |
@caitp is right in that this issue should probably be closed, but with the proviso that a new issue about better documentation be created. Currently this is documented in one place only: the section entitled "Creating Custom Directives." This is misleading as it implies that |
Where does it say/imply that it's only available when creating directives? |
It's implied because it only appears one section entitled "Creating Custom Directives." It's not using directives, but creating them, which is a natural dichotomy in software toolkits. Many users will skip that section, or will not think to look there when researching this topic. I used Angular quite productively for many months before I created a directive, so I would never think to read that section for a feature that is not limited to creating directives. Plus, more importantly to me, it does not show up on the API page at all, which I would consider an omission. The API page is used as something of a menu of all the ng-* bits that a developer expects to find in Angular. (Whether that's the intention of that page is another matter.) Thus it functions as a reference guide, and as such, if something doesn't appear there, it's effectively undocumented. |
It's true that it's not the best name for the section, because the section is really an overview of what directives are, including how they can be created. A more appropriate place for the ngAttr* stuff might be in the compiler docs, but people never seem to look there. |
I've dipped into the compiler docs, but I think most users would consider the compiler to be an advanced topic. Just the word "compiler" brings back memories of lexical analysis, parsers, and other topics from that one course you needed in order to complete the comp sci graduation requirements. ;-) |
+1 @caitp data-ng-attr-size worked fine. |
+1 |
I've tried 1.0.2 and it seems any expression of the form <select size="{{something}}" which just gets set to size="0". I ended up having to hack around this with jquery which made me feel dirty ;) so wondered if there was a way of just allowing a size expression to be specified (or even defaulting it as the ng-options knows the size).
e.g. something like this...
The text was updated successfully, but these errors were encountered: