<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Birth of the datagrid element in HTML 5</title>
	<atom:link href="http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 17 May 2012 07:43:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: BertrandLeRoy</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273257</link>
		<dc:creator>BertrandLeRoy</dc:creator>
		<pubDate>Thu, 30 Apr 2009 18:25:57 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273257</guid>
		<description>I&#039;m a little concerned about this list of types.
First, it seems to describe more how the data is rendered than its type. Text, for example, editable or not, is still text. That it is editable is more like state and should probably be settable at the cell level rather than at the column level.
Second, the list of types seems pretty arbitrary: why have progress and meter but no numbers or dates? Should HTML in general be in the business of defining a type system? (otoh the new input types are quite useful)
Finally, it seems to me like there are many ways to implement a data grid and it may be presumptuous from WhatWG to believe they can get it &quot;right&quot; because there are so many ways to get it right or wrong. The current status quo where libraries implement more opinionated grids on top of the existing table semantics doesn&#039;t seem that wrong to me.
What am I missing? Why is this necessary?</description>
		<content:encoded><![CDATA[<p>I&#8217;m a little concerned about this list of types.<br />
First, it seems to describe more how the data is rendered than its type. Text, for example, editable or not, is still text. That it is editable is more like state and should probably be settable at the cell level rather than at the column level.<br />
Second, the list of types seems pretty arbitrary: why have progress and meter but no numbers or dates? Should HTML in general be in the business of defining a type system? (otoh the new input types are quite useful)<br />
Finally, it seems to me like there are many ways to implement a data grid and it may be presumptuous from WhatWG to believe they can get it &#8220;right&#8221; because there are so many ways to get it right or wrong. The current status quo where libraries implement more opinionated grids on top of the existing table semantics doesn&#8217;t seem that wrong to me.<br />
What am I missing? Why is this necessary?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darkimmortal</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273251</link>
		<dc:creator>Darkimmortal</dc:creator>
		<pubDate>Thu, 30 Apr 2009 16:28:35 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273251</guid>
		<description>FINALLY.</description>
		<content:encoded><![CDATA[<p>FINALLY.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chiaroscuro</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273222</link>
		<dc:creator>chiaroscuro</dc:creator>
		<pubDate>Thu, 30 Apr 2009 04:03:17 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273222</guid>
		<description>So this guy didn&#039;t take his CS101 course seriously, what a pity.

&gt; data is structured as a set of rows representing a tree, each row being split into a number of columns

An n-ary tree (a rose tree) is implemented using trivial nested lists. Lists themselves can be viewed as a degenerate case for a tree. If you really need an index-based access, that&#039;s easy with linked lists, too. If you need constant-time index-based access, then you don&#039;t need a tree, perhaps. You can amortize access time by utilising finger trees, though.

&gt; Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices.

If you want to navigate with a focus point, you use a zipper. It&#039;s remarkably simple and leads to code that is easy to understand and maintain.</description>
		<content:encoded><![CDATA[<p>So this guy didn&#8217;t take his CS101 course seriously, what a pity.</p>
<p>&gt; data is structured as a set of rows representing a tree, each row being split into a number of columns</p>
<p>An n-ary tree (a rose tree) is implemented using trivial nested lists. Lists themselves can be viewed as a degenerate case for a tree. If you really need an index-based access, that&#8217;s easy with linked lists, too. If you need constant-time index-based access, then you don&#8217;t need a tree, perhaps. You can amortize access time by utilising finger trees, though.</p>
<p>&gt; Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices.</p>
<p>If you want to navigate with a focus point, you use a zipper. It&#8217;s remarkably simple and leads to code that is easy to understand and maintain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JonathanLeech</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273196</link>
		<dc:creator>JonathanLeech</dc:creator>
		<pubDate>Wed, 29 Apr 2009 15:46:48 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273196</guid>
		<description>I&#039;m wondering why this wasn&#039;t accomplished by enhancing the capabilities of a regular . 

My thoughts: 
1) A less capable  in terms of structure. The equivalent of  is just column labels, which are just Strings. No colspan or rowspan. Nothing corresponding to .

2) Lots of convenience. Standardizing loading data dynamically and sorting is a great thing. Child rows are OK if you&#039;re building trees or hybrid tree-grids, and the equivalent in a  is cumbersome.

3) Columns can be visible or invisible, but not rows. In a , the reverse is true. Rows are easy to hide, columns difficult. It would be nice to extend the &quot;visible&quot; attribute to the datagrid row. This would be useful for &quot;search within results&quot; type scenarios. I call it &quot;filtering&quot; in my applications.

4) I would like to see some thought put towards data export, or even printing, especially considering the dynamic loading data model. Is there a way to get or print all the data, or a flag to indicate that the user isn&#039;t allowed to do that?</description>
		<content:encoded><![CDATA[<p>I&#8217;m wondering why this wasn&#8217;t accomplished by enhancing the capabilities of a regular . </p>
<p>My thoughts:<br />
1) A less capable  in terms of structure. The equivalent of  is just column labels, which are just Strings. No colspan or rowspan. Nothing corresponding to .</p>
<p>2) Lots of convenience. Standardizing loading data dynamically and sorting is a great thing. Child rows are OK if you&#8217;re building trees or hybrid tree-grids, and the equivalent in a  is cumbersome.</p>
<p>3) Columns can be visible or invisible, but not rows. In a , the reverse is true. Rows are easy to hide, columns difficult. It would be nice to extend the &#8220;visible&#8221; attribute to the datagrid row. This would be useful for &#8220;search within results&#8221; type scenarios. I call it &#8220;filtering&#8221; in my applications.</p>
<p>4) I would like to see some thought put towards data export, or even printing, especially considering the dynamic loading data model. Is there a way to get or print all the data, or a flag to indicate that the user isn&#8217;t allowed to do that?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: igstan</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273172</link>
		<dc:creator>igstan</dc:creator>
		<pubDate>Wed, 29 Apr 2009 10:49:38 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273172</guid>
		<description>The most important difference between the table and the datagrid elements, is that the datagrid element will support a specific API (in JavaScript) with which we can do useful things. The API definition is not ready yet, but there would be things like a DataProvider, built-in sorting and some other things for which we normally need external JavaScript libraries. The table element will miss all these.

Those of use that have ever tried a XUL datagrid element should understand the differences. An example of a datagrid element in Firefox is the bookmark list that appears when pressing CTRL+B. If that sort of functionality will be built into the datagrid elements, then that is great news.

Also, I believe it would be much easier to traverse the rows in a datagrid element than in a table. There are complex situation with lots of colspans and rowspans which are very hard to query. In the datagrid element a row may have child rows, whereas in a table a row may have a table with other rows.

I hope the DataProvider will be smart enough so that it knows how to map a JSON structure to a datagrid structure.</description>
		<content:encoded><![CDATA[<p>The most important difference between the table and the datagrid elements, is that the datagrid element will support a specific API (in JavaScript) with which we can do useful things. The API definition is not ready yet, but there would be things like a DataProvider, built-in sorting and some other things for which we normally need external JavaScript libraries. The table element will miss all these.</p>
<p>Those of use that have ever tried a XUL datagrid element should understand the differences. An example of a datagrid element in Firefox is the bookmark list that appears when pressing CTRL+B. If that sort of functionality will be built into the datagrid elements, then that is great news.</p>
<p>Also, I believe it would be much easier to traverse the rows in a datagrid element than in a table. There are complex situation with lots of colspans and rowspans which are very hard to query. In the datagrid element a row may have child rows, whereas in a table a row may have a table with other rows.</p>
<p>I hope the DataProvider will be smart enough so that it knows how to map a JSON structure to a datagrid structure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dzr</title>
		<link>http://ajaxian.com/archives/birth-of-the-datagrid-element-in-html-5/comment-page-1#comment-273169</link>
		<dc:creator>dzr</dc:creator>
		<pubDate>Wed, 29 Apr 2009 10:05:09 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=6710#comment-273169</guid>
		<description>I read this over on the WHATWG blog. The one thing that would help me to understand what this element is actually &lt;em&gt;for&lt;/em&gt; is an example along with a comparison with the table element. As it is it looks like we now have two elements for tabular data. Would anyone care to point to or provide a little more illumination?</description>
		<content:encoded><![CDATA[<p>I read this over on the WHATWG blog. The one thing that would help me to understand what this element is actually <em>for</em> is an example along with a comparison with the table element. As it is it looks like we now have two elements for tabular data. Would anyone care to point to or provide a little more illumination?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

