JQuery tbody question - ASP.NET - asp.net

I have a aspx page that looks something like this:
<table runat="server" id="tblTEst">
<tr id="trHeader" runat="server">
</tr>
<tr id="trRow1" runat="server">
</tr>
<tr id="trRow2" runat="server">
</tr>
</table>
When I write my JQuery to say get a count of s, I need to do:
alert($('#' + strTableId).children('tbody').children('tr').length);
My question is when does the TBODY get added? When I do a InnerHTML, I do see the TBODY. I was wondering if this is something ASP.NET does?
EDIT
Thanks for the answers. If it's added by the browser, do I need to worry about testing the code in multiple browsers to ensure compatibility of JQuery? I was under the impression, JQuery is compatible with all browsers and I would'nt have to worry about testing the code on different browsers.

It's neither ASP.Net nor jQuery, it's your browser. jQuery accesses the DOM of your page which is built by your browser based of the HTML code generated by ASP.Net. For tables, when it is not explicity declared, a TBODY element is added to hold "body" rows (TR) of a table.

It's something the browsers do, as part of the process of cleaning up the HTML while building the DOM. The standard specifies that TR elements must occur within a TBODY, THEAD, or TFOOT element, and since you specified none of those, the browser helps you out by adding one for you.
If you wish to ignore this, you can re-write your expression as:
alert($('#' + strTableId).find('tr').length);
...But, you would do well to explicitly wrap your rows in TBODY so as to avoid confusion in the future.

The best thing would be to properly construct your table with a tbody on the server side. Then, you wouldn't have to worry about inconsistencies between browsers.

Related

Table width are different in Outlook then on web browser

I have problem with creating table to create mail with order confirmation.
First row in table are not equal with the next one. On web browser everything is fine with width. I've tried everything and nothing worked. Lines in html:
<td style=\"color: #999999; word-break:break-all; width: 275px;\">
I have tried also something like this:
<td width=\"100%\" style=\"color: #999999;\">
As for the next line and all subsequent tables everything are displayed correctly.
Please help me because I don't have idea what to do.
Outlook uses Word as an email editor. You can read about supported and unsupported HTML elements, attributes, and cascading style sheets properties in the following articles in MSDN:
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)
Yes, thank You very much for your answer but as I can see element
td style
and
td width
are supported in outlook.

JSFiddle simple CSS code not working on localhost

http://jsfiddle.net/TTwtf/
This is some simple CSS that changes the display of a table using a media query. If width is less than a certain amount, it hides the table header, and will make each row of 5 columns display across 3 lines instead (2/2/1) . U can widen and narrow the window in jsfiddle and see it working.
I copy pasted the html into a blank html file.
I copy pasted the css into a blank css file.
I linked both using the following so that the html file looks like:
<link rel="stylesheet" type="text/css" href="jsfiddle.css" />
<table>
<thead>
<tr>
<th class="cell-time">Booking Time</th>
.......
I'm testing it on my localhost in chrome. The table headers disappear however the table cells don't stack above one another like they do on jsfiddle. And I tested jsfiddle using the same chrome browser and it works on jsfiddle.
What am i missing or doing wrong?
Sounds like it's time for the Chrome Debugger tool.
Try right clicking on the browser page where the table headers should be and select Inspect Element. Using the debugging tool, you can then verify that the html and the CSS is as you expect it to be (and experiment with changes until things work as you'd like).

Invalid/Incorrect html syntax - performance

Let's say we have the following html syntax:
<TABLE width=400, height=300>
<TR>
<TD color=Red>SOME TEXT</TD>
</TR>
</TABLE>
as it can be seen, there is no style used, all tags are written using the uppercase letters. This is invalid. I would like to inform it this kind of incorrect HTML syntax has an influence in web performance?
Additionally, in the code I get from the client, lots of HTML controls are build in code-behind and then injected in the aspx.
How is with performance in such a case?
Uppercase elements are valid in HTML. HTML is case insensitive. While XHTML is not - everything should be lower case.
Upper vs lower case should not affect performance. But lots of CSS inline with the HTML might very well affect performance as often an external CSS will more effectively define the style globally instead of each element.
HTML
http://www.w3.org/TR/html4/about.html#h-1.2.1
Element names are written in uppercase letters (e.g., BODY). Attribute names are written in lowercase letters (e.g., lang, onsubmit). Recall that in HTML, element and attribute names are case-insensitive; the convention is meant to encourage readability.
XHTML
http://www.w3.org/TR/xhtml1/#h-4.2
XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags.
The only violation of generic HTML syntax is the comma in <TABLE width=400, height=300>. The comma will probably be taken as part of the attribute value and then ignored. The cost of this error processing is ignorable.
Performance is not an issue here. Basic rendering is.
The height attribute for table is not allowed by HTML specs; though widely supported by browsers, the support is not required (even in HTML5 drafts, which generally require continued support to legacy features) and may be removed in future browsers.
The color attribute for td is not allowed by HTML specs. It is not supported by any browser I know of. So if the intent was to make the text red, it will fail.
The conclusions depend on what you need and can do with the markup. If you cannot adequately change the markup but can inject CSS rules, then you could even fix the non-working non-standard attributes, using e.g.
<style>
[color=Red] { color: red; }
</style>
This would get tedious since you would need e.g. separate rule for each color, and this would not work on some old browsers.
Building HTML controls server-side takes virtually no time at all. In addition, receiving invalid markup will barely affect the rendering time of the browser - however it will affect the display as it will force the client into quirks mode and make a lot of style properties unusable.
Beyond that I'm not sure what exactly you want to know by asking for information on a hypothetical syntax.

XHTML thead, tfoot and tbody importance

Does XHTML have an 'opinion' regarding the use of <thead>, <tfoot> and <tbody>?
Is there a case where they should be used?
Thank you.
They allow you to add semantics to your table, and also allow you to style the head and the foot of the table without introducing redundant classes/ids.
I can't think of a situation where you have to use it, although I know some jQuery plugins use the head & foot to control behaviors.
If your tabular data needs headings and summary rows, use them, if not don't
The thead, tbody, and tfoot elements
in HTML are used to group table rows
into logical sections based on their
content. There are two main reasons
you'd want to do this:
To allow the body to be scrolled independently of the header and/or
footer
To make it easier to apply different style rules to the
different sections of the table.
as stated here What is benefit of <thead>
If you are using tables to make layout then don't use these. If you are showing tabular data then use it.
And if you don't have anything to put in tfoot then don't add this.
You will find some good answers here also What is benefit of <thead>
The only rules, that I'm aware of, is that the thead (if used) must be defined first, and the tfoot (if used) before the tbody (somewhat counter-intuitive, to my mind, but them's the rules).
I think that the purpose of thead is partially for print purposes, allowing columns printed on a second page to have the thead repeated, in order that the data makes more sense.
In theory it could also allow for a scrolling tbody in the case of long tables, with fixed headers:
This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
Source: http://www.w3.org/TR/html401/struct/tables.html#edef-TFOOT
This does not, however, work currently (without using at least two tables, I think).
The largest benefit, though, as #Glenn Slaven notes, seems to be semantic.

GridView thead, tbody, tfoot render order

Is there any way to control the order of which the GridView control renders it's thead, tbody and tfoot child elements?
According to W3C, the correct order is:
thead
tfoot
tbody
The GridView control renders out:
thead
tbody
tfoot
I am extending the GridView control, and I'm using the "first column controls the width of all columns" approach. But if the W3C specifications are not met (thead -> tfoot -> tbody) all hell breaks loose.
I've been reading up on this issue, and it seems that the GridView control has no support for this yet--it's planned though. Even so; I bet there must be some way to counter this sketchy implementation.
Any and all help apreciated.
If you need strict W3C Validation of your HTML (you must have a valid reason), you better not use ASP.net server controls, because you don't have any control on the HTML they generate.
I bet that this little problem is just the tip of the iceberg of the problems that you will find later.
I would imagine that any HTML generated by a Microsoft class will 100% definitely break validation and only work with it's Internet Explorer.
Write your own implementation - or find some Open Source class that will take care of it properly.
This is not yet possible. Although Microsoft is planning this feature for a future release.

Resources