Dom-repeat doesn't work in tables in IE

[wuxiaoying]

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

[kevinpschaaf]

Thanks! This is a known limitation and on our near-term roadmap.

[mazswojejzony]

Any plans when this is going to be resolved/worked-around?

[mdwragg]

+1 :+1: We really need this too.

[lacolaco]

:+1:

[S-YOU]

Don't know polymer, but isn't that you just need small wrapping code like jQuery/jqlite does?

[mazswojejzony]

BTW: couldn't dom-repeat be implemented in such a way it could be applied to any tag, e.g.:

<li is="dom-repeat" items="...">

This would not only fix this issue but also made the final DOM simpler, i.e. there would be no extra <template> nodes in the DOM.

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:

<template>
  <ol>
    <li is="dom-repeat" items="...">
  </ol>
  <div class="footer" is="dom-if" if="{{showFooter}}">(...)</div>
</template>

<script>
  Polymer({
      is: "my-element",

      extendedElements: ['li', '.footer', 'another css selector'],

      (...)
<script>

Then Polymer would need to check the is attribute of elements matching one of extendedElements selector only.

I guess this could be applied to dom-if and possibly other extensions too.

[craigday]

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

[tpluscode]

@mazswojejzony I don't think that would be possible, because you can't have an element extend multiple other. You would need multiple like li-dom-bind, etc.

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

[jfrazzano]

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

On Sep 18, 2015, at 2:38 AM, Craig Day notifications@github.com wrote:

Production ready, except we don't support tables on IE. What are you guys smoking???

— Reply to this email directly or view it on GitHub.

[mazswojejzony]

@tpluscode I do not see how those two examples you shown are incompatible. They are simply different: the first one repeats only the <li>(...)</li> HTML fragment, the second one repeats a whole <ol>(...)</ol> fragment.

By the way, looks like a similar work-around for dom-repeat usage in <table> and <select> elements exists in Polymer 0.5:

<table>
  <tr template repeat="{{tr in rows}}">
    <td>Hello</td>
  </tr>
</table>

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 <table> tag to build it. That's what this element is for. ;-) Anyway if you can share a link to a live demo of a fluid table built with CSS grid system I'd appreciate that.

[tpluscode]

@mazswojejzony I don't think you read carefully. In my second example I meant that the <li> is repeated and not the entire <ol>. I have seen a repeating template work this way in knockout for example. Thus both examples I showed would produce the same result.

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 <option> and <tr>. And even it was possible, would you include all html elements in the extends array? It simply cannot happen, sadly

[warpech]

:+1:

[miyconst]

+1

[mazswojejzony]

@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 'extendedElements: ['li', '.footer', 'another css selector'] is strictly related to performance implications of being able to add is="dom-repeat" attribute to any DOM element. In other words, without extendedElements Polymer would need to inspect all local (and light?) DOM nodes if they contain is="dom-repeat" (or is="dom-if") attribute and act on it accordingly; with extendedElements only elements matching one of provided CSS selectors would need to be inspected.

Anyway, I am not saying this is the best solution to resolve the issue. Just my 2 cents added to the discussion. :-)

[miyconst]

@mazswojejzony

As a former http://knockoutjs.com/ user I like your suggestion, but there is a big limitation.

Content inside <template> is not resolved by browser, but will be resolved in any other tag. The following code

<ul is="dom-repeat" items="{{images}}">
    <li>
        <img src="{{item.url}}" />
    </li>
</ul>

Would cause an http request to /{{item.url}}.

[zoechi]

<ul is="dom-repeat" items="{{images}}">
    <li>
        <img src$="{{item.url}}" />
    </li>
</ul>

Should work without the request

[mazswojejzony]

@miyconst

As @zoechi mentioned the src$ should do the job. See Annotated attribute binding in Polymer docs: https://www.polymer-project.org/1.0/docs/devguide/data-binding.html#attribute-binding

[tpluscode]

But then again the is="extending-element" syntax comes from the Web Components specification. I don't it's wise to introduce some exceptions, where Polymer interprets native HTML in unorthodox ways :)

I concur with @miyconst. Even src$="" binding "fixes" image being loaded, it is not a valid solution IMO. The <template> tag fits perfectly here, for it defines a part of HTML, which will be used to render each individual item.

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

[miyconst]

@zoechi, @mazswojejzony,

The $ sign solves the particular problem, but the html is still resolved by browser, and I used src instead of src$ to show the problem.

If you have a complex custom element, which does something when attached, then you can't put such element inside any is="dom-repeat" except <template>.

[mazswojejzony]

@miyconst

Can you please elaborate on the 'HTML is still resolved by browser'?

@tpluscode

Yes, the whole discussion started due to a bug in IE parser. :-)

[tpluscode]

@mazswojejzony it means that, unlike 'normal' markup, HTML code inside <template> is parsed but not instantiated immediately by the browser. It stays dormant (the term inert is also used) until its contents are cloned and appended to the page. Polymer calls this stamping. This is important for images but even more so, for scripts. You can have <script> inside a template and it won't run straight away. See this article for an in-depth discussion.

[mazswojejzony]

@tpluscode Now that makes sense. I guess I am learning WC backwards through Polymer usage. I thought <template> was a Polymer thing...

Let's hope IE team is going to fix this bug soon.

[gregorymachon]

@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.

[azogheb]

This would be excellent to see a solution for this if possible

[miyconst]

Here is a temporary workaround for this issue.

Repository: https://github.com/Juicy/juicy-table-repeat Demo: http://juicy.github.io/juicy-table-repeat/index.html

[keskival]

We also need this. The same applies to select-elements, and this is a very commonly used pattern to declaratively populate grids and select boxes.

I know Internet Explorer is not a big priority, but still the fact that a simple repeat-element doesn't work with the newest IE is a bit of a turn off. Especially as this bug has been open for almost a year.

Good work otherwise! I love Polymer and its way of structuring things. WebComponents is definitely the future.

Thanks for the temporary workaround @miyconst ! Although another workaround is needed for the select-elements.

[miyconst]

@keskival you can take a look at juicy-select available here: https://github.com/Juicy/juicy-select

[jay8t6]

+1

Will this be resolved? Or do we have to deal with the workaround option? This seems to be very important as most of the users are still on IE.

[admwx7]

Created an updated JSFiddle using Polymer 1.6, it works fine in IE Edge, but there's still an issue in IE11 (no error messaging though)

https://jsfiddle.net/amurdock/eLe1a2pd/

Anyone have access to IE10 to give it a test?

[daniele-orlando]

+1

[madeleineostoja]

@admwx7 Your JSFiddle doesn't work in Edge for me - what version of Edge did you test it on?

EDIT: nevermind, just upgraded my VM, does indeed work in the latest version of Edge, and considering Edge is evergreen...

[olofweb]

Will this bug be corrected one day? Soon two years that he is known ...

[zoechi]

@olofweb that's an IE bug. <template> is a valid element within <table> but IE strips it anyway. You better complain on the IE bug ;-)

[olofweb]

@zoechi oh... So, no chance. Thanks

[zoechi]

@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)

[btelles]

@kevinpschaaf @azakus @sorvell Wow, this is a pretty big turnoff. 9% of the users on our 4,000qps site still use IE11, so it's no small chunk of users for us (we happen to be an internal client) . That this does not work in IE11 is a huge let-down and is causing days of refactoring for us when we're about to launch our new site.

[Tigerino]

+1

[johnyanarella]

Just got burned by this incompatibility with IE11 in our app.

One viable workaround is to convert your <table>, <tr> and <td> elements to <div> elements with custom table, row and cell classes that use CSS Table (display: table, display: table-row, display: table-cell, etc.). This sidesteps the IE11 <table> parsing issue, allowing use of dom-repeat and dom-if templates to dynamically populate your rows.

[jhuesos]

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

[admwx7]

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 notifications@github.com 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 https://github.com/Polymer/polymer/issues/1567#issuecomment-329610227, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpRr2ikm0Z2JwEMyjRytBWMw_giF2_fks5siZaNgaJpZM4EgqBb .

[jhuesos]

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

[Westbrook]

@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.

[TimvdLippe]

I think this would be solved with https://github.com/webcomponents/template/pull/39

[TimvdLippe]

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 innerHTML, the problematic part is that the IE11 parser throws away all the content. It simply ignores it and at the moment we actually get hold of the template, the nodes are gone. This means that we can never know they were there, unless we can do our logic before the parser kicks in.

My assumption is that it does work with imperative case, so maybe we can design an imperative API for dom-repeat that allows the assignment of the template to get around the IE11 behavior :cry:

[TimvdLippe]

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 <dom-repeat> and <dom-if> from the context. This means that the actual content is simply moved out of the table. This breaks the templates, as they are moved out of context and then consequently breaking the table element creation again /tableflip

[hussain21j]

It is so pending since so long, can this this be expected to be closed in coming days?

[zoechi]

@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

[jhuesos]

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 notifications@github.com wrote:

@hussain21j https://github.com/hussain21j what about pushing MS to fully implement the spec instead? ;-) The problem is that they are pruning