It is sort of wordy, and not as terse and elegant as other parts of
HTML. Because it isn't flagged by browsers or validators as a frank
error, it's probably not on anyone's radar who isn't also worried
deeply about fussing with the DOM.
Every time I try to do the magical sortable list stuff in Rails, I'm
usually reminded by the fact that my tables won't persist their sort
order that I need to go back and add it! That's one case where the
following makes so very much sense:
<table class="list-table">
<thead>
<tr>
<th>Name</th>
<th>Intro</th>
<th>Icon</th>
<th>Banner</th>
<th> </th>
</tr>
</thead>
<tbody id="sort_list">
<% for category in @categories %>
<tr id="id_<%= category.id %>">
<td>
<span class="handle"></span>
<%=h category.name %>
</td>
<td><%=h category.intro %></td>
<td><%=h category.icon_file_name %></td>
<td><%=h category.banner_file_name %></td>
<td style="white-space: nowrap;"><%= link_to "Show", category %> | <
%= link_to "Edit", edit_category_path(category) %> | <%= link_to
"Destroy", category, :confirm => 'Are you sure?', :method => :delete
%></td>
</tr>
<% end %>
</tbody>
</table>
<%= sortable_element 'sort_list',
:url => { :controller => :categories, :action => :sort },
:handle => 'handle',
:tag => 'tr',
:complete => visual_effect(:highlight, 'sort_list')
%>
Your sort will be on the scope of the element parent (for tr, that's
the tbody), and by setting that ID where it is, there's no further
ambiguity about getting the order of elements to pass back to the
server.
So if you added tbody to your local version of the scaffold templates,
then you could get this sort of thing for free -- every table you
generated in scaffolding would already have that extra layer of
function for you to extend.
Walter
On Feb 16, 2011, at 1:13 PM, Jeffrey Lee wrote:
Also makes me wonder why Rails doesn't include the elements in the
layout pages it generates. Seems like a bad idea to allow browsers
to insert their own stuff that isn't in the markup you provide.
___________________________
Jeffrey Lee
http://www.jeffreyalanlee.com
[email protected]
On Feb 16, 2011, at 9:38 , T.J. Crowder wrote:
Hi,
For some reason never learned about the tbody element. When did
that get added to the spec
Proposed in 1996, standardized in HTML 4.01 in 1999.[1] It's a cool
element, because amongst other things, you can have more than one of
them. So if you have a table with rows you want to replace and other
rows you don't, you can put them in separate TBODYs and group them
that way.
AFAIK, it's always been optional (officially optional) in the
*markup*
(it certainly is in HTML5), but that's in the markup; in standards
mode, browsers have been inserting it in the DOM for you for years.
For example: http://jsbin.com/urito5 If you run that on IE6, IE7,
IE8,
Chrome, Firefox, or Opera, they'll all say the only child element of
the TABLE element is a TBODY, although there's no TBODY in the
markup.
Interestingly, HTML5 seems to allow TR to be a direct child of TABLE,
even in the DOM[2]. That surprises me, I thought it was just in the
list of elements that an engine was meant to infer.[3] I'm probably
just misreading the spec. I always explicitly include TBODY if
there's
any chance I'm going to need to manipulate the DOM at the table
level,
just so I know where I am even on "edge" browsers.
1: http://www.w3.org/TR/html4/struct/tables.html#edef-TBODY
2: http://www.w3.org/TR/html5/tabular-data.html#the-table-element
3: http://www.w3.org/TR/html5/syntax.html#optional-tags
Best,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
On Feb 16, 4:37 pm, Jeffrey Lee <[email protected]> wrote:
That will teach me to rely on google and random discussions
online. :) I was suspicious that the <div> was in an awkward
location, but hadn't come up with a good way to replace just the
body of the table. For some reason never learned about the tbody
element. When did that get added to the spec, or has that always
been there and just not used by hacks like me? Granted the last
time I spent any energy on creating and editing web pages before
this year was in the late 90's.
___________________________
Jeffrey Leehttp://www.jeffreyalanlee.com
[email protected]
On Feb 16, 2011, at 8:28 , Walter Lee Davis wrote:
Not in my memory of HTML, which begins in 1997. It's certainly
possible to put that into a browser and see something. Browsers
are designed to ignore or coerce invalid code as best they can,
to preserve the intent where possible. But there's a mile of
difference between the JavaScript DOM interpreter and the
browser's HTML display engine.
JavaScript doesn't even receive the HTML as written in code from
the browser when it's constructing its starting DOM tree, it uses
the output of the browser's first pass at munging the input code
stream into shape. This is why you can see a big difference
between Firebug and view source, for example.
So whenever you are interacting directly with the DOM, as you do
in Prototype Element#update or anything else that inserts
elements into the DOM, you are relied on to insert something that
makes sense in the context where it will be added. If you don't,
you get an error or you get ignored.
One other example of this, directly related to tables: It's
perfectly valid code to write <table id="foo"><tr><td>Something</
td></tr></table>, but it's more correct to write <table
id="foo"><tbody><tr><td>Something</td></tr></tbody></table>. Most
browsers will silently add that missing intermediate element when
the page loads.
So if you wanted to get a handle on your first row, and you used $
('foo').childElements()[0] (totally made-up example) then you
might actually get a reference to the tbody -- the element you
didn't actually code!
Now you're probably smarter than that, and you'd write $
('foo').down('tr') and get what you wanted, but that's just an
example to make the point that the code you wrote isn't even
guaranteed to be the code you're going to be talking to when you
start messing with the DOM.
Walter
On Feb 16, 2011, at 10:15 AM, Jeffrey Lee wrote:
Shows how outdated my HTML is. Thanks for the pointer. Its
funny, when I was googling around apparently once upon a time it
was at least tolerated, if not officially acceptable, to have
<div> as a child of table.
___________________________
Jeffrey Lee
http://www.jeffreyalanlee.com
[email protected]
On Feb 15, 2011, at 23:20 , T.J. Crowder wrote:
Hi,
That HTML is invalid. You can't have a `div` as a child of
`table`:
http://www.w3.org/TR/html5/tabular-data.html#the-table-element
If you want to subdivide a table like that, you probably want
`thead`
(for your headers) and one or more `tbody` elements:
<table>
<thead>
<tr>
<th>Item</th>
<th>Transaction Type</th>
<th>Quantity</th>
<th>Amount</th>
<th>Transaction comments</th>
</tr>
</thead>
<tbody id = "transList">
<tr>
<<bunch of table data>>
</tr>
<tr>
<<bunch of table data>>
</tr><tr>
<<bunch of table data>>
</tr>
</tbody>
</table>
...and then your update will have to be valid `tbody` content
(e.g.,
rows).
Example:
http://jsbin.com/evuxe3
HTH,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
On Feb 15, 10:59 pm, Jeff <[email protected]> wrote:
This is a rails generated webpage. I've created a table
definition as
follows:
<table>
<tr>
<th>Item</th>
<th>Transaction Type</th>
<th>Quantity</th>
<th>Amount</th>
<th>Transaction comments</th>
</tr>
<div id = "transList">
<tr>
<<bunch of table data>>
</tr><tr>
<<bunch of table data>>
</tr><tr>
<<bunch of table data>>
</tr>
</div>
</table>
If I execute a $('transList').update('Test') or frankly any
other text
or html, the existing table data remains, and the updated text
is
placed above the entire table. However, if I do a view -
>source,
this new data doesn't show up in the page source at all, only
the old
table data.
I'm having this problem in both Safari and Firefox. Any
suggestions?
--
You received this message because you are subscribed to the
Google Groups "Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group athttp://groups.google.com/group/prototype-scriptaculous?hl=en
.
--
You received this message because you are subscribed to the
Google Groups "Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group athttp://groups.google.com/group/prototype-scriptaculous?hl=en
.
--
You received this message because you are subscribed to the
Google Groups "Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group athttp://groups.google.com/group/prototype-scriptaculous?hl=en
.
--
You received this message because you are subscribed to the Google
Groups "Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en
.
--
You received this message because you are subscribed to the Google
Groups "Prototype & script.aculo.us" group.
To post to this group, send email to [email protected]
.
To unsubscribe from this group, send email to [email protected]
.
For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en
.
--
You received this message because you are subscribed to the Google Groups "Prototype
& script.aculo.us" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
