I need to make a table/table-like component on vue. It displays tabular data. Usually it has 5-30 rows and up to 30 columns. But elements in each cell are pretty heavy to render. Each has a couple of event listener, like #click and #hover, and those call methods that render even more components. They also have a lot of dynamic. It worked very well so far, but now there is a requirement to use this exact component for much larger number of rows, around 200. Obviously, the best way to go about it, is to implement pagination, since rendering so much of those cells would slow down browser immensly. But requirements explicitly says, that UI must not have any arrows to navigate between pages of table. Only acceptable way to go through table is to use scrolling (or infinite-scrolling), like it is all one page. So now i try to implement creating and destroying elements on scroll, when certain parts of table (like every 30th row) coming to view.
My question is, what would be faster to render as a table component?
Should i use a table component, like this?
<table>
<thead>
<tr>
<th v-for="date in dates">
<span>Some dynamic components</span>
</th>
</tr>
</thead>
<tbody>
<tr v-for="name in names">
<th v-for="date in dates">
<span>Some dynamic components</span>
</th>
</tr>
</tbody>
</table>
or this?
<div class="TableLikeComponent">
<div class="TableHeaderLikeComp">
<div v-for="name in names" class="RowLikeComponent">
<span>Some dynamic components</span>
</div>
</div>
<div class="TableBodyLikeComp">
<div v-for="name in names" class="RowLikeComponent">
<div v-for="date in dates" class="ColumnLikeComponent">
<span>Some dynamic components</span>
</div>
</div>
</div>
</div>
or maybe there is even better solution?
Will be grateful for any tips.
As much as I've previously looked into table library solutions, it seems that they all use div instead of native table for performance and customization.
From personal experience, native tables are often not easy to work with, requiring hackier solutions for complex problems that would be easy to achieve with div.
There are many different ways to freeze a header row of an html table, but I need something minimally invasive. I'm working in a large and complex system in which the table html is generated through many layers of back-end coding and it will be non-trivial and risky to change the table structure (lots of complex javascript and css depends on the HTML structure remaining as-is and I don't want to break anything). So I'm looking for a way to freeze my html header rows (2 rows need to be frozen, not just 1) by changing/adding only CSS and/or adding attributes to the table or rows in the table. Here's an accurate example of my table:
<table>
<tbody>
<tr>
<th> </th>
<th id="col0">Option ID</th>
<th id="col1">Description</th>
<th id="col2" title="Sort on Description">Description</th>
</tr>
<tr>
<th> </th>
<td title="Filter on Option ID (Text)">
<input type="text" id="f0">
</td>
<td title="Filter on Description (Text)>
<input type="text" id="f1">
</td>
</tr>
<tr>
<td><input type="radio" name="chk0" id="c_01Q0"></td>
<td>0093005</td>
<td>Local pickup & delivery.</td>
</tr>
<tr>...etc...</tr>
<tr>...etc...</tr>
<tr>...etc...</tr>
<tr>...etc...</tr>
<tr>...etc...</tr>
</tbody>
</table>
As you can see it's nothing exotic. But as I've searched for solutions I have found a lot of examples like this, which require more structural changes to the HTML than I dare make (I'm mainly just worried about having to surround the table by section and div elements -- and it seems like a lot of CSS just to freeze a header row). The 1st two rows both need to be frozen so that when I scroll down, they remain nicely in-place. The first data row (non-frozen) is the row containing 0093005.
A few objectives/desires:
Brevity is more important than elegance. I'm fine with a hack, in this case.
Don't change the HTML structure if at all possible, though adding attributes to existing elements can be done.
Pure CSS additions/changes without touching the HTML would be ideal, but I suspect the HTML will need to be decorated to some extent, and that is ok.
Use of js or jquery is a last resort only, to be avoided if possible.
Many thanks in advance for everyone's time.
I'm using gwt in my web app and I have a html panel which contains a <table>. I've chosen to do this instead of flextable due to some annoying issues when styling it as being unable to do <tbody valign="top">.
I wanted to know if it's possible to wrap a html table
<table>
<thead>
<tr>
<th>Name</th>
<th>Path</th>
<th>Type</th>
</tr>
</thead>
</table>
In a class like Flextable so I can easily control rows and columns through Java?
Something like
Label.wrap("id");
but for tables.
You can also format your data in FlexTable.
You can use flexTable.getRowFormatter(), flexTable.getColumnFormatter() or flexTable.getColumnFormatter().
You can apply alignment, style to rows, columns and cells using above FlexTable attributes.
Please provide a standalone test case if you are facing any problems with FlexTable.
Looking at HTML source code of
http://www.google.com/finance/historical?cid=983582&startdate=Nov+28,+2000&enddate=Nov+27,+2010&num=200
I see that Google never closes td and tr tags. There is no </tr> no </td> in the source.
Why?
<tr class=bb>
<th class="bb lm">Date
<th class="rgt bb">Open
<th class="rgt bb">High
<th class="rgt bb">Low
<th class="rgt bb">Close
<th class="rgt bb rm">Volume
<tr>
<td class="lm">Nov 26, 2010
<td class="rgt">11,183.50
<td class="rgt">11,183.50
<td class="rgt">11,067.17
<td class="rgt">11,092.00
<td class="rgt rm">68,396,121
<tr>
Is it to make it harder to parse it because XML parser won't be able to read it ? I have remarked that &output=csv is not available for indices (this url won't work: http://www.google.com/finance?q=INDEXDJX:.DJI&output=csv) whereas it is available for stock (http://www.google.com/finance/historical?q=NASDAQ:GOOG&output=csv will work) so that to get historical data in csv for indices you have to do the parsing job !
This is HTML4 (and not XML). As pointed out in the W3 specs:
11.2.6 Table cells: The TH and TD elements
…
Start tag: required, End tag: optional
Ditto for tr:
11.2.5 Table rows: The TR element
…
Start tag: required, End tag: optional
I believe the intent is to minimize page size by omitting the end tags. They do various additional optimizations which may actually result in invalid HTML, but are handled by browsers in tagsoup mode.
They do this to save bandwidth. Each byte that comes across the wire is thousands of dollars in Google's book, so why waste extra bytes of data on making readable code. However, they've become less concerned with bandwidth over the past couple years as they've increased their server capacity to God-like proportions, hence the larger logo files (for example, their old logo here is a roughly 8.5kb gif file that looks like crap, and their current one is a 25+kb PNG), so I suspect they'll eventually come up with a more standards compliant and cleaner home page.
According to w3c </TD> and </TR> tags are optional, so the following table is perfectly valid.
<table>
<tr>
<td>google
<td>chrome
</table>
And all browsers I've tested it with render the table fine. I just wanted to ask if this is generally considered safe to use, or if older browsers, which I don't have access to, cause problems. Thanks.
It reduces gzip html size on a page with many tables by a few percent.
This is valid HTML but invalid XHTML.
There's nothing intrinsically wrong with it.
If you look at the source for Google's privacy policy (or any of their other pages), you'll find some much terser HTML.
It does mean that your page will not be usable by an XML parser.
It is safe, since optionality in the standard means that all the browsers (at least the ones which even remotely matter) would have implemented this - and the browser standards compliance usually runs to the opposite side, into trying to work correctly with even invalid HTML as opposed to failing on missing optional tags.
Having said that, I find that omitting such tags makes things harder to read, which may or may not matter to you if the goal is size optimization.
P.S. Also, if you have very large tables, I wonder whether there's any overhead incurred by the browser's HTML parser when dealing with such constructs? I am not sure without benchmarking or really deep thinking about how HTML parser works in detail, but it is something that could possibly be a factor if it happens.
I strongly recommend against doing that, though it is valid in HTML4 (and 5). The bandwidth savings are miniscule when compared to the technical debt you are incurring. Also keep in mind it is not valid in XHTML, so be sure your doctype is set appropriately.
There have been optional tags in HTML since the very beginning — they are a feature inherited from SGML, and so the early browsers must have been able to deal with them. While XHTML moved away from this and required a much more uniform syntax, this doesn’t affect you unless you explicitly tell the browser to parse in XML mode. I’ve never seen a problem when using the standard parsers of HTML 4/5.
Since HTML5 so carefully describes when certain tags are optional, I would read that to imply that someone did lots of testing to make sure that in these cases, most browsers produce the same document tree.
And while the space savings are negligible, I find that leaving off the closing tags of <p>, <li>, <td>, and <tr> simply makes my life easier when I’m working in the markup, and makes me less likely to make an error.
Personally I don't consider it good practice. Looking at the spec it didn't give a whole lot of information. I know it's required for XHTML so I looked up the HTML 5 spec. HTML 5 seems to take the same take on it as HTML 4 which is what you've linked to, but gives a little more information:
A td element's end tag may be omitted if the td element is immediately followed by a td or th element, or if there is no more content in the parent element.
I advise always closing your tags. There's not really too good of a reason not to. Browsers can handle some improperly closed tags, but just to be on the safe side (and it's good programming practice!), close your tags!
Close all tags in HTML for a few reasons:
Not closing tags is tolerated, but it is not correct modern XHTML. It's deprecated much in the same way that HTML style attributes are in favor of CSS
It's more readable for the next guy if you close the tags
Browsers will actually have an easier time parsing your source if it more strictly adheres to the rules, even if that makes the source longer
Certainly if you are using only HTML there is absolutly no problem thats not the case with XHTML nevertheless i don't think you can get that much, also i suggest dont abuse tables remember div are better than tables
It’s Ok with Static Pages not for Dynamic Pages …to debug
You should close your <TR> and <TD>tags if possible, but NOT ALWAYS because in some scenarios it may disturb you. This is because the <TR> and <TD>tags could be styled to display:none while the </TR> tag couldn't. It means that a scenario in which you want to extend / limit your display with media queries, will fail if you use </TR>. Consider the following code:
<style>
#media (max-width : 480px) {
.hidden-class {display:none;}
}
</style>
<table>
<tr>
<td>cell 1</td>
</tr class="hidden-class"> <!-- this will fail! -->
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>
It means that you would write it as:
<table>
<tr>
<td>cell 1</td>
</tr> <!-- this will now close the TR for every screen width, which will destroy your extenstion -->
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>
Which means that the only way to do so is by OMITTING THE in the first place:
<table>
<tr>
<td>cell 1</td>
<tr class="hidden-class">
<td>cell 2</td>
</tr> <!-- this could stay -->
</table>