10-24-2019, 11:25 AM
(This post was last modified: 10-24-2019, 11:27 AM by Alexandre Machado.)
> - We use the MYGRID == TBLMYGRID.parentNode relation in javascript.
The problem relies on this fact above. You are relying on an implementation detail to make it work.
As I said before, all you need to do is applying your specific style to the 2 elements which have well established IDs (and this didn't change). If there is an intermediate node between your those 2 nodes, that's irrelevant for all meaningful purposes.
Can you please show why it is important to you to have this parent<->child relationship to make it work?
I'll give you a true example of how the internal design shouldn't change anything like that:
Previous version 14.0.x didn't render <thead></thead><tbody></tbody>. This was introduced because some JS grid styling libraries require that. It was introduced transparently and I'm not aware of any customer who had issues with it.
Because they don't rely on the fact that the parent of a <tr> tag was some specific tag. If they had assumed this, it would break, of course, when I introduced a <thead> tag in between.
As I mentioned since my first response:
If you need to interact with 2 tags which are clearly identified by their IDs, use the IDs and not the parent<->child relation ship. It should (and actually is) irrelevant for styling, responsiveness, etc.
The problem relies on this fact above. You are relying on an implementation detail to make it work.
As I said before, all you need to do is applying your specific style to the 2 elements which have well established IDs (and this didn't change). If there is an intermediate node between your those 2 nodes, that's irrelevant for all meaningful purposes.
Can you please show why it is important to you to have this parent<->child relationship to make it work?
I'll give you a true example of how the internal design shouldn't change anything like that:
Previous version 14.0.x didn't render <thead></thead><tbody></tbody>. This was introduced because some JS grid styling libraries require that. It was introduced transparently and I'm not aware of any customer who had issues with it.
Because they don't rely on the fact that the parent of a <tr> tag was some specific tag. If they had assumed this, it would break, of course, when I introduced a <thead> tag in between.
As I mentioned since my first response:
If you need to interact with 2 tags which are clearly identified by their IDs, use the IDs and not the parent<->child relation ship. It should (and actually is) irrelevant for styling, responsiveness, etc.
(10-09-2019, 04:22 PM)brsoft Wrote: Hi Alexandre,
First of all, thank you for correcting the "IE error". We are waiting for the new version.
Secondly, I think we think differently about using IWGrid.
You are right about static rendering. But...
Your example:
<div ID="MYGRID">
<table id="TBLMYGRID">
<--! here goes the grid content -->
</table>
</div>
Other aspects:
- MYGRID has style (border, background, etc.) scaled to external components and TBLMYGRID content.
- TBLMYGRID is transparent, scaled to MYGRID.
- We want a responsive display
- We use the MYGRID == TBLMYGRID.parentNode relation in javascript.
Our well-used javascript functions for years have been disturbed by the appearance of new DIVs. But as I wrote, we have solved this problem.
We don't understand what the new div is good for? Mainly because sometimes it is, sometimes it is not.
If something has no advantage but caused some problems, the end result is negative.
Regards
brsoft
