[uf-discuss] Re: DOM scripting as an alternative to include-pattern?

[Steve Robillard]

Michael,

>From a purely accessible stand point what happens to the redundant data and
the understandability/utility of the complete data when JavaScript is
disabled, and does not included the redundant data?

Thanks, 
Steve 

-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Michael
Leikam
Sent: Saturday, June 03, 2006 4:20 PM
To: microformats-discuss at microformats.org
Subject: [uf-discuss] Re: DOM scripting as an alternative to
include-pattern?

Brian,

I realize that supporting DOM manipulations would change how microformat
parsers work.  It's easy to simply pass the page's source code through and
XSL transform, but that doesn't strike me as a reason not to move towards
supporting a more robust way of manipulating the DOM in the future.

The fundamental "problem," which popped up in hResume, seems to me to be
that human readability is at odds with machine comprehension in cases where
data ought to be repeated in order to produce a complete microformat chunk,
but doing so in the source code would create a burden on human writers and
readers.  The same issue exists across all microformats.

I brought up client side parsing not to imply that sever-side parsing is
irrelevant, but to say that there's already a well-known and robust way to
copy precise parts of the DOM and insert them in precide locations.  Web
developers are already familiar with javascript and the DOM spec is well
understood.  I just didn't know if it had been considered as a possible way
to address the "problem" of discontinuity between human and machine
comprehension.


> --- HTML already offers some lesser known semantics that we have 
> employed to help in situations like this. In an HTML table[2] there 
> are several addition attributes such as AXIS, HEADER, and ID [1] all 
> of which microformats parsers can use, similarly to the 
> include-pattern, to include additional data from other parts of the 
> table. This doesn't solve 100% of the mark-up problems, but it gets 
> you alot closer without having you use <object>s

Yeah, those could be useful for my schedule of classes. 
I'd also like to see SCOPE[3] included since it's necessary for ADA
compliance and is complementary to the AXIS attribute. 

However, table markup is the exception rather than the rule for most of my
pages and while it provides a way to pull in table headers, the vevent's
summary field should really be a combination of the course title (which is
outside the
table) and section number (which is header content).  Like you said, it gets
us some of the way, but I think explicit DOM manipulations can get us all
the way.


-ml

[3]
http://www.w3.org/TR/html4/struct/tables.html#adef-scope


> -brian
> 
>  [1] -
>
http://microformats.org/wiki/hcalendar-brainstorming#Tabular_event_calendars
> [2] -
> http://www.w3.org/TR/html4/struct/tables.html#h-11.4.1
> 
> --
> brian suda
> http://suda.co.uk
> 
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss