-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dom-repeat doesn't work in tables in IE #1567
Comments
Thanks! This is a known limitation and on our near-term roadmap. |
Any plans when this is going to be resolved/worked-around? |
+1 👍 We really need this too. |
👍 |
Don't know polymer, but isn't that you just need small wrapping code like jQuery/jqlite does? |
BTW: couldn't dom-repeat be implemented in such a way it could be applied to any tag, e.g.:
This would not only fix this issue but also made the final DOM simpler, i.e. there would be no extra I understand that ability to apply dom-repeat to any tag may not be a good idea performance-wise but maybe this could be resolved by additional declaration? Sth like:
Then Polymer would need to check the I guess this could be applied to |
Production ready, except we don't support tables on IE. What are you guys smoking??? Workaround: http://www.dummies.com/how-to/content/using-the-div-tag-to-create-tables.html |
@mazswojejzony I don't think that would be possible, because you can't have an element extend multiple other. You would need multiple like Also there would be two incompatible ways. You can extend the repeated element, as in your example <ol>
<li is="dom-repeat" items="...">
<span>{{item}}</span>
</li>
</ol> But you can also extend the container and repeat the Light DOM <ol is="dom-repeat" items="...">
<li>
<span>{{item}}</span>
</li>
</ol> I personally prefer the latter, and granted there would be constant grind of proponents of either way. Current solution is unambiguous, albeit verbose |
You can use a grid CSS system for really nice and responsive tables using a list or series of lists with the animated lists and the layout vertical and horizontal attributes. The add-on of flex and a wrap make for a nice table that is hyper responsive. When we manage to get our early instantiations to do a bit of nice sorting, and maybe a tad of math y'all can have at it. Tables can be awesome and we have used them for everything from adding number lines and word breaks in raw text (we had to use a canvas to calculate with px distances and a buffer to create a word, sentence and paragraph model, but we got it working well after a few weeks) to adjustable height photo sets (also a colossal pain to build). Despite our past work with tables, however, our team finds the utility of Dom repeat so overwhelming that finding a work around here seems like it will be long term easier. The issue related to the table and the native select from HTML is that they do not support a template tag and this do not play nice with the ever useful Dom repeat. A work around here, which we just came up with last night--for selects but it would work with tables as well--takes advantage of the shared elements in neon animation, an infinite list, and the select on a content tag. With the three elements together and some careful binding, setting, mapping... Well, we hope not only to be able to create native selects and tables, but elements that will be dynamic and "set-table" with no more than the placement of a set of firebase locations. (And then only the final names of the addresses.). It's kinda cool to play around and combine stuff. I am fairly new to this venue, And the world of the bleeding edge but as standard six comes into its final form, a lot will change in the way people build business and personal apps. I find that being out in front of the curve--well, it's called the bleeding edge for a reason. So far, it bleeding hasn't been awful. Maybe a scrape or a scratch. But lots of fun--getting the chance to actually make things that were sort of impossible to make 4 years ago. That's my take anyway. Sure it would be awesome if folks did all my work for me, but I have never found that the usual course of things regardless of what folks might be paid. Be patient. I feel--I know an awful thing to do on github--the folks are working their butts off to give us something cool. All I can offer them is thanks. Sent from my iPhone
|
@tpluscode I do not see how those two examples you shown are incompatible. They are simply different: the first one repeats only the By the way, looks like a similar work-around for dom-repeat usage in
More info here: https://www.polymer-project.org/0.5/resources/faq.html#option-tr Sadly a similar hack is not available in 1.0 which forces devs to manually build repeated DOM items using imperative JS code. @jfrazzano When I have a table on a page I want to use the |
@mazswojejzony I don't think you read carefully. In my second example I meant that the But more importantly I think that there is no way to create an element which extends many. You cannot define an element as Polymer({
is: 'my-dom-repeat',
extends: [ 'li', 'tr', 'td' ]
}) It is not a limitation of Polymer but the underlying custom element API. There may have been a polyfill in 0.5 but as you see it did only work for |
👍 |
1 similar comment
+1 |
@tpluscode Indeed, I misunderstood your example. I guess I also did not express myself clearly: I was not suggesting it should be possible to define elements which extend many elements. The idea with Anyway, I am not saying this is the best solution to resolve the issue. Just my 2 cents added to the discussion. :-) |
As a former http://knockoutjs.com/ user I like your suggestion, but there is a big limitation. Content inside <ul is="dom-repeat" items="{{images}}">
<li>
<img src="{{item.url}}" />
</li>
</ul> Would cause an http request to |
<ul is="dom-repeat" items="{{images}}">
<li>
<img src$="{{item.url}}" />
</li>
</ul> Should work without the request |
As @zoechi mentioned the |
But then again the I concur with @miyconst. Even Finally I think that this discussion drifted away from the actual problem or rendering tables, which to my best knowledge is due to a bug in IE parser |
The If you have a complex custom element, which does something when attached, then you can't put such element inside any |
Can you please elaborate on the 'HTML is still resolved by browser'? Yes, the whole discussion started due to a bug in IE parser. :-) |
@mazswojejzony it means that, unlike 'normal' markup, HTML code inside |
@tpluscode Now that makes sense. I guess I am learning WC backwards through Polymer usage. I thought Let's hope IE team is going to fix this bug soon. |
@kevinpschaaf do you have any updates to indicate when we can expect the fix or at least what's the plan and when the work on this may start? I see it's one of three items with the 'on roadmap' label. |
@zoechi oh... So, no chance. Thanks |
@olofweb I guess they were hoping for Microsoft to fix this eventually instead of implementing an expensive workaround (they had one in Polymer 0.5 but removed it later) |
@kevinpschaaf @azakus @sorvell |
+1 |
Just got burned by this incompatibility with IE11 in our app. One viable workaround is to convert your |
Yeah, in our case we put the body of the table on a template and we use templatizr to render the table using JavaScript and then append the content |
There's a solid solution out there in vaadin-grid as well if you want some
more advanced table functionality.
…On Thu, Sep 14, 2017, 4:11 PM Jaime Vega ***@***.***> wrote:
Yeah, in our case we put the body of the table on a template and we use
templatizr to render the table using JavaScript and then append the content
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1567 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABpRr2ikm0Z2JwEMyjRytBWMw_giF2_fks5siZaNgaJpZM4EgqBb>
.
|
The root cause of the issue is that dom-repeat inside <table> does not work in IE11: Polymer/polymer#1567. And at the moment the order-details component has a dom-repeat inside a <template> (introduced by the PR https://github.com/vaadin/bakery-app-starter-polymer/pull/156). Fix: replace the table elements with divs having table-like CSS display property values. Jira: BFF-348
* fix the 'order details' component layout in IE11 The root cause of the issue is that dom-repeat inside <table> does not work in IE11: Polymer/polymer#1567. And at the moment the order-details component has a dom-repeat inside a <template> (introduced by the PR https://github.com/vaadin/bakery-app-starter-polymer/pull/156). Fix: replace the table elements with divs having table-like CSS display property values. Jira: BFF-348
with Polymer2, Templatizr is no longer available (unless I load the Polymer1 with BehaviorMixin), what should be the recommended work-around. Vaadin-grid is very heavy and full of features. https://www.polymer-project.org/2.0/docs/api/mixins/Polymer.TemplateStamp does not seem to work like Templatizr because you cannot pass the context for stamping any template with any data object. Thanks |
@jhuesos I'm pretty sure the code your looking for is in Polymer.Templatize. The API is slightly different, but it should give you the same capabilities as the Polymer.Templatizer. |
I think this would be solved with webcomponents/template#39 |
Okay, so a bit disappointing news: the IE11 parser is even more strict than I imagined. While the above PR does fix the assignment to My assumption is that it does work with imperative case, so maybe we can design an imperative API for |
All right, another update: I was able to fix the actual template parsing by putting it in a property instead. This does fix the parsing, however, it then breaks because IE11 boots the |
It is so pending since so long, can this this be expected to be closed in coming days? |
@hussain21j what about pushing MS to fully implement the spec instead? ;-) |
Microsoft might fix the issue in Edge, but they will not provide a fix for
IE11 since that browser only received security fixes. So since Polymer
officially supports IE11 then the only solution is to find a workaround.
…On Thu, Jun 7, 2018, 16:19 Günter Zöchbauer ***@***.***> wrote:
@hussain21j <https://github.com/hussain21j> what about pushing MS to
fully implement the spec instead? ;-)
The problem is that they are pruning <template> tags inside tables which
polymer needs.
Sure there are always ways to hack around such issues but the underlying
issue is IE/Edge
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1567 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUumRts1pP8ZxUQAq0QrlXLAlHXXL_Fks5t6TZhgaJpZM4EgqBb>
.
|
... or wait until IE11 falls out of supported browsers ;p |
In the meantime the awesome team over at Vaadin has a great table rendering element: https://www.webcomponents.org/element/vaadin/vaadin-grid that gets around the issue. There are numerous other elements out there as well. You can get around it yourself by dropping use of |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed after being marked stale. If you're still facing this problem with the above solution, please comment and we'll reopen! |
Using a repeat element inside of a table doesn't repeat the elements in IE. (Only tested on IE 11)
Example: http://plnkr.co/edit/oXyYMs2TLBLeEaxMzH2K?p=preview
The text was updated successfully, but these errors were encountered: