Re: Re: hCalendar for events in a table format

On 3/5/08 2:17 AM, "Brian Suda" <brian.sudagmail.com> wrote:

> 2008/3/5, Toby A Inkster <mailtobyinkster.co.uk>:
>> That would be contrary to Tantek's guidelines on
the Wiki:
>>  | If the element is a table data cell <td>,
then:
>>  |
>>  |   1.  parse its "headers" attribute as
a space separated set of local IDs
>>  |
>>  |   2.  find the <td> and <th>
elements referenced by those IDs (call them
>>  |       header cells) and consider them part of
the element being parsed
>>  |       as follows:
>>  |
>>  |         1. Treat the header cells as children of
the element, ordered by
>>  |            the order of ids in its
"headers" attribute, immediately
>>  |            following the last child node (text
or element) or the
>>  |            element. (The basic idea is that the
content from those
>>  |            header cells is used to construct the
VEVENT, but secondary
>>  |            to (AFTER) the content in the data
cell itself, so that the
>>  |            data cell can customize/override part
of the data in the
>>  |            header, e.g. if the header cell
included both start time and
>>  |            location, and the event was being
held at a different
>>  |            location).
>>  |
>>  |         2. Parse the "axis" attribute
of a header cell as a comma-
>>  |            separated list of categories. These
categories must be used
>>  |            in addition to (and before) any class
names on that header
>>  |            cell for determining whether it is a
property of the VEVENT.
>
> 
> --- correct, then we should further discuss this on the
dev-list and
> correct the wiki as needed.
> 

Given Benjamin's message about the "axis"
attribute:

<http://microformats.org/discuss/mail/
microformats-discuss/2008-March/011679
.html>

and the fact that we've never needed to use the axis
attribute in a
realworld tabular event example, nor has that step been
implemented, I've
removed the "Parse the 'axis'..." step.

http://microformats.org/wiki/hcalend
ar-brainstorming#Tabular_event_calendars

Thanks,

Tantek

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Tantek =?ISO-8859-1?B?xw==?=elik wrote:

> and the fact that we've never needed to use the axis
attribute in a
> realworld tabular event example, nor has that step been
implemented,
> I've removed the "Parse the 'axis'..." step.
> 
> http://microformats.org/wiki/hcalend
ar-brainstorming#Tabular_event_calendars

A sensible move, I'd say. Though I've added a note below
your change
stating that yes, it has been implemented -- by me. Though I
plan on
un-implementing it now.

What could be a very handy addition to this parsing
technique would
be to say that when the "headers" attribute is not
present on table
cell X, parsers should:

	1. For each TH element in the same row as X, if it has
	   a scope attribute of "row" then assume that it
is a
	   header for X.

	2. For each TH element in the same column as X, and same
	   TBODY as X, if it has a scope attribute of
"col" then
	   assume that it is a header for X.

	3. For each TH element in the same column as X, if it is
	   within that table's THEAD or TFOOT, and it has a scope
	   attribute of "col" then assume that it is a
header for X.

This would make authoring such tables much simpler. Instead
of:

<table>
 <tr>
  <th>Person</th>
  <th id="eng"><span
class="country-name">England</span></t
h>
  <th id="sco"><span
class="country-name">Scotland</span></
th>
 </tr>
 <tr class="vcard">
  <td class="fn">Gordon Brown</td>
  <td class="adr" headers="eng">
   <span class="street-address">10 Downing
Street</span>
  </td>
  <td class="adr" headers="sco">
   <span class="street-address">318-324 High
Street</span>,
   <span
class="locality">Cowdenbeath</span>
  </td>
 </tr>
 <tr class="vcard">
  <td class="fn">Elizabeth
Windsor</td>
  <td class="adr" headers="eng">
   <span class="street-address">Buckingham
Palace</span>
  </td>
  <td class="adr" headers="sco">
   <span class="street-address">Balmoral
Castle</span>
  </td>
 </tr>
</table>

One could have:

<table>
 <tr>
  <th scope="col">Person</th>
  <th scope="col"><span
class="country-name">England</span></t
h>
  <th scope="col"><span
class="country-name">Scotland</span></
th>
 </tr>
 <tr class="vcard">
  <td class="fn">Gordon Brown</td>
  <td class="adr"><span
class="street-address">10 Downing
Street</span></td>
  <td class="adr">
   <span class="street-address">318-324 High
Street</span>,
   <span
class="locality">Cowdenbeath</span>
  </td>
 </tr>
 <tr class="vcard">
  <td class="fn">Elizabeth
Windsor</td>
  <td class="adr"><span
class="street-address">Buckingham
Palace</span></td>
  <td class="adr"><span
class="street-address">Balmoral
Castle</span></td>
 </tr>
</table>

However, implied headers like this while lowering the
barrier to entry for
authors, would considerably raise the barrier for parsers --
mostly because
of colspan and rowspan, which would be an absolute pain to
handle.

Although microformats' general principle is to place the
burden of effort
onto parsers, implied headers via the scope attribute may
shift the effort
*too* far in that direction. What do others think?

-- 
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 35 days,
18:57.]

                               Bottled Water
          http://tobyinkster.co.uk/blog/2008/02/18/bottled-water/

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss