Re: [uf-discuss] Re: hCalendar for events in a table format

[Benjamin Hawkes-Lewis]

Toby A Inkster wrote:


table
  thead
tr
  th id=id_fn axis=fnFull name/th
  th id=id_role axis=roleRole/th
  th id=id_adrspan class=localityLondon/span Address/th
/tr
  /thead
  tbody
tr class=vcard
  td headers=id_fnElizabeth Windsor/td
  td headers=id_roleQueen/td
  td headers=id_adr class=adr
span class=street-addressBuckingham Palace/span
  /td
/tr
tr class=vcard
  td headers=id_fnGordon Brown/td
  td headers=id_rolePrime Minister/td
  td headers=id_adr class=adr
span class=street-address10 Downing Street/span
  /td
/tr
  /tbody
/table


AFAICT this is a double misuse of the, admittedly confusingly specified, 
HTML 4.01 AXIS attribute:


1) You're using it for machine-readable identifiers ('fn') as though it 
were CLASS. But it's actually intended for being rendered directly as 
human-readable information:


http://www.w3.org/TR/html4/struct/tables.html#multi-dimension

And that's precisely what JAWS does, for instance:

http://www.freedomscientific.com/fs_products/Surfs_Up/Tables.htm

2) The content of AXIS (e.g. a formatted name) is in the cell on which 
it is set and the cell then acts as a header for other cells referencing 
it by ID. The AXIS itself is not inherited by cells to which a TH is a 
header. In one of the examples from the spec:


TH id=a6 axis=locationSan Jose/TH

San Jose /is/ a location not a label for locations.

--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

RE: [uf-discuss] Re: Putting microformats on the BBC iPlayer

[[EMAIL PROTECTED]]

Hi,

JAWS/IE6 will read out abbr. Jon Gibbins has published a useful article
about screenreaders and abbr, which specifically mentions the
misconception that abbr doesn't work in JAWS.
http://dotjay.co.uk/2008/feb/screen-readers-and-abbreviations

To avoid using abbr, you could publish the ISO date directly on the page,
then hide the element containing the date with display:none?

Cheers
Jim

Original Message:
-
From: Toby A Inkster [EMAIL PROTECTED]
Date: Tue, 4 Mar 2008 15:53:12 +
To: microformats-discuss@microformats.org
Subject: [uf-discuss] Re: Putting microformats on the BBC iPlayer


Adam Craven - Four Shapes wrote:

 Does anyone have suggestions how this can be worked around whilst still
 keeping relatively good screen reader support?

You mentioned hiding the ABBR with CSS as a solution, but IE6 (which 
plenty of screen readers hook into) ignores the ABBR element entirely and 
will not apply styling to it. (It's not even in the DOM tree.) So that 
technique may prove to be of limited utility.


mail2web.com – Enhanced email for the mobile individual based on Microsoft®
Exchange - http://link.mail2web.com/Personal/EnhancedEmail



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Re: hCalendar for events in a table format

[Toby A Inkster]

Brian Suda wrote:

 i haven't tested your example, but X2V does support the header/id.

Really? As I say, I only had a quick skim of the code on 
hg.microformats.org, and don't really know much XSLT anyway, so I may well 
have missed it. I also think I was explicitly looking for the word axis 
when I was skimming, so may have missed it because of...

 So your example of:
th id=id_fn axis=fnFull name/th
 would need to become:
 th id=id_fnspan class=fnFull name/span/th
 Axis is not used and the class=fn needs to be a child of the id
 being referenced.

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. 

The example I provided will be correctly parsed as hCard according to 
these guidelines.

 To see a working example, you can visit:
 http://www.sixnationskickoff.com/
 it is hCalendar items, but it is pretty easy to figure out how to use
 hCard instead.

Not a particularly useful example: the table headers don't contain any 
microformat classes. Also, what's up with the extra uid classes for each 
event?

-- 
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, 15:22.]

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

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: hCalendar for events in a table format

[Brian Suda]

2008/3/5, Toby A Inkster [EMAIL PROTECTED]:
 That would be contrary to Tantek's guidelines on the Wiki:

--- correct, then we should further discuss this on the dev-list and
correct the wiki as needed.

  | 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.



-- 
brian suda
http://suda.co.uk
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] Re: Putting microformats on the BBC iPlayer

[Toby A Inkster]

Alasdair King wrote:

 This is clearly a contentious statement. However, the fact that this
 able, technical and motivated forum has been unable to come up with a
 agreed accessible format in eighteen months strongly suggests it isn't
 going to be able to do so with current assistive technology: better,
 build it and they will come.

In my opinion this is a misrepresentation of the status quo. 

The reason that no consensus has been agreed for an accessible alternative 
to the ABBR pattern is not that no accessible alternatives exist; it is 
not that no alternatives have been suggested; and nor is it a lack of 
assistive technology support for the suggestions. It is simply that none 
of the proposed alternative patterns have been rubber-stamped by the 
powers that be.

For example, the following:

span title=Monday 3 March 2008 (data:2008-03-03)
class=dtstartstarted two days ago/span

Is perfectly accessible in all tested screen readers (the read the human-
readable started two days ago) and seems to present no problems for any 
other assistive technology. It is trivial to implement -- simply find all 
elements (not just SPAN) with title attributes that match the regular 
expression:

/^.*data\:(.*)[\]\}\)]?$/

and take the matching sub-expression (.*) to be the value of the property.

It doesn't interfere with the existing ABBR design pattern (which is, 
occasionally, used in an accessible manner, such as abbr class=country-
name title=JapanJP/abbr in hCard) so can be used in conjunction with 
it as appropriate; and is highly unlikely to match any false positives on 
existing web pages.

There have been other good suggestions too (though none I think as good as 
the one shown above) -- it is not suggestions that we lack, but the 
inertia to make one or more of them official and widely implemented. It 
does not bode well for the accessibility of Microformats that one of the 
main providers of said inertia has just been banned from the process for 
18 months.

For my part, I've implemented this data: prefix in Cognition http://
buzzword.org.uk/cognition/ and plan on using it when I add hAtom support 
to demiblog http://demiblog.org/. (hCalendar was previously rolled back 
out of demiblog due to accessibility concerns. hCard, XFN and rel-tag are 
currently used though.)

-- 
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, 17:46.]

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

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: Putting microformats on the BBC iPlayer

[Michael Smethurst]

On 4/3/08 16:42, Andy Mabbett [EMAIL PROTECTED] wrote:

 as I've pointed out before, the imminent release of Firefox
 3, with native support for microformats, will see a significant leap in
 public awareness of microformats.

Is this still true? My understanding was that native uf support would not be
shipped in FF3


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: hCalendar for events in a table format

[Tantek Çelik]

On 3/5/08 2:17 AM, Brian Suda [EMAIL PROTECTED] wrote:

 2008/3/5, Toby A Inkster [EMAIL PROTECTED]:
 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/hcalendar-brainstorming#Tabular_event_calendars

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Putting microformats on the BBC iPlayer

[Michael Smethurst]

Hi Adam

We've had the same problems with http://bbc.co.uk/programmes. For now we've
stuck with the standard abbr design pattern but as Mr Mabbett helpfully
pointed out our use has potential accessibility issues and definite semantic
nastiness.

See here:
http://www.bbc.co.uk/programmes/formats/animation

We've spoken to the bbc accessibility and semantic html working groups. The
accessibility people said there were no accessibility problems which in the
light of discussions here and elsewhere surprises me. I'm still chasing to
get a definite answer and some proper testing

The conversation is currently in the hands of the UXD cluster

I've been pushing to get full coverage testing and an update to the BBC
accessibility standards to say either:

- you may use microformats
- you may use the abbreviation design pattern

Or conversely

- you may use microformats
- you must not use the abbreviation design pattern

[And similar for rdf-a]

Would be good if you could also raise these questions with Nick Holmes and
cc Frances Berriman and me. Ta






On 4/3/08 13:26, Adam Craven - Four Shapes [EMAIL PROTECTED]
wrote:

 Hi fellers,
 
 We're working on the next version of the BBC iPlayer and would love to
 put some microformats in there.
 
 Below is what I've gotten so far. In this particular instance there's
 a single box (206x115) with an image attached. When hovered over,
 using JavaScript, the idea is to retrieve the last 7 days of shows for
 that particular program. I've opted to use the vevent pattern as it's
 the most widely supported currently - this is open to change in the
 future.
 
 I have a concern though. At the moment the spec's datatime pattern is
 abbr. Unfortunately screen readers are going to mangle this, which
 is unacceptable naturally, so I've reverted to hiding the abbr with
 {display:none} (this will cover the majority of screen readers) and
 filled the field with with extra text, date;
 
 h4abbr class=dtstart dtstamp title=2008-03-04T00:00:00ZDate:/
 abbrMon 8pm - Radio 2/h4
 
 That way the information can still be parsed. I understand this is an
 incorrect implementation, but currently unsure how to work around this.
 
 Does anyone have suggestions how this can be worked around whilst
 still keeping relatively good screen reader support?
 
 
 
 li class=programme
 div class=feature
 a id=uid-9121211 href=#9121211 class=image uid url
 img src=img/_dev/206x115.jpg width=206 height=115
 alt=206x115 /
 /a
 div class=details
 a class=play-tv href=#9121211
 spanPlay TV/span
 /a
 h3 id=summary-9121211 class=summary
 a href=#9121211Two pints of Juergen and a .../a
 /h3
 /div
 /div
 ul
 li class=vevent featured
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 li class=vevent
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 li class=vevent
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 /ul
 
 
 /li
 /li 
 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss


http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal 
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on 
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Putting microformats on the BBC iPlayer

[Michael Smethurst]

Whoops that wasn't meant to go out to the world

But whilst I'm here I probably should point out that /most/ bbc
services/channels/networks now have uf-ed schedules

http://www.bbc.co.uk/radio1/programmes/schedules
http://www.bbc.co.uk/radio4/programmes/schedules/fm
http://www.bbc.co.uk/bbcone/programmes/schedules/oxford
http://www.bbc.co.uk/cbeebies/programmes/schedules

I'll leave you to guess the rest of the urls

For the moment some schedules are still missing (fivelive, bbc parliament,
local radio etc) but they'll be along soon. They're also not properly linked
into the site but over time will replace existing bbc schedules currently
provided by:

http://www.bbc.co.uk/whatson/

Should also note that all of the below still applies. We're looking for
clarification on the accessibility / semantic validity of these pages. And
we'll let you know if/when we get it ;-)





On 5/3/08 12:21, Michael Smethurst [EMAIL PROTECTED] wrote:

 Hi Adam
 
 We've had the same problems with http://bbc.co.uk/programmes. For now we've
 stuck with the standard abbr design pattern but as Mr Mabbett helpfully
 pointed out our use has potential accessibility issues and definite semantic
 nastiness.
 
 See here:
 http://www.bbc.co.uk/programmes/formats/animation
 
 We've spoken to the bbc accessibility and semantic html working groups. The
 accessibility people said there were no accessibility problems which in the
 light of discussions here and elsewhere surprises me. I'm still chasing to
 get a definite answer and some proper testing
 
 The conversation is currently in the hands of the UXD cluster
 
 I've been pushing to get full coverage testing and an update to the BBC
 accessibility standards to say either:
 
 - you may use microformats
 - you may use the abbreviation design pattern
 
 Or conversely
 
 - you may use microformats
 - you must not use the abbreviation design pattern
 
 [And similar for rdf-a]
 
 Would be good if you could also raise these questions with Nick Holmes and
 cc Frances Berriman and me. Ta
 
 
 
 
 
 
 On 4/3/08 13:26, Adam Craven - Four Shapes [EMAIL PROTECTED]
 wrote:
 
 Hi fellers,
 
 We're working on the next version of the BBC iPlayer and would love to
 put some microformats in there.
 
 Below is what I've gotten so far. In this particular instance there's
 a single box (206x115) with an image attached. When hovered over,
 using JavaScript, the idea is to retrieve the last 7 days of shows for
 that particular program. I've opted to use the vevent pattern as it's
 the most widely supported currently - this is open to change in the
 future.
 
 I have a concern though. At the moment the spec's datatime pattern is
 abbr. Unfortunately screen readers are going to mangle this, which
 is unacceptable naturally, so I've reverted to hiding the abbr with
 {display:none} (this will cover the majority of screen readers) and
 filled the field with with extra text, date;
 
 h4abbr class=dtstart dtstamp title=2008-03-04T00:00:00ZDate:/
 abbrMon 8pm - Radio 2/h4
 
 That way the information can still be parsed. I understand this is an
 incorrect implementation, but currently unsure how to work around this.
 
 Does anyone have suggestions how this can be worked around whilst
 still keeping relatively good screen reader support?
 
 
 
 li class=programme
 div class=feature
 a id=uid-9121211 href=#9121211 class=image uid url
 img src=img/_dev/206x115.jpg width=206 height=115
 alt=206x115 /
 /a
 div class=details
 a class=play-tv href=#9121211
 spanPlay TV/span
 /a
 h3 id=summary-9121211 class=summary
 a href=#9121211Two pints of Juergen and a .../a
 /h3
 /div
 /div
 ul
 li class=vevent featured
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 li class=vevent
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 li class=vevent
 a href=#summary-9121211 class=include/a
 a href=#uid-9121211 class=include/a
 h4abbr class=dtstart dtstamp
 title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
 div class=description
 pShort description of episode lies here. It can be up-to 90
 characters long./p
 pExpires in 3 days/p
 /div
 pa href=#downbabyMore episodes /a/p
 /li
 /ul
 
 
 /li
 /li 
 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss
 
 
 http://www.bbc.co.uk/
 This e-mail (and any attachments) is confidential and 

Re: [uf-discuss] Re: Putting microformats on the BBC iPlayer

[Scott Reynen]

On Mar 5, 2008, at 4:57 AM, Toby A Inkster wrote:


For example, the following:

span title=Monday 3 March 2008 (data:2008-03-03)
class=dtstartstarted two days ago/span

Is perfectly accessible in all tested screen readers (the read the  
human-
readable started two days ago) and seems to present no problems  
for any

other assistive technology.



I think the problem is that seems to.  The original abbr pattern  
seemed to present no problems, but then it did have problems with real  
screen readers in deployment.  So the progress is slow here because  
it's difficult to get access to such testing, and such testing is very  
important.  See:


http://www.w3.org/WAI/eval/users.html

To avoid repeating the same mistake, we shouldn't rubber stamp any  
potential solution without first testing with real world screen reader  
users.  Lacking volunteers coming forward to offer such testing, as  
they have with the include pattern, perhaps we should look into how  
much it would cost to pay for the testing and see if we can't raise  
funds to get it done.


Peace,
Scott

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: hCalendar for events in a table format

[Tantek Çelik]

On 3/5/08 5:02 AM, Toby A Inkster [EMAIL PROTECTED] wrote:

 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.

Speaking from the experience of working on a browser rendering engine which
*did* have to handle colspan and rowspan, I can certainly state that
requiring a microformats parser to perform a table layout (effectively what
it takes to support colspan and rowspan) would *drastically* raise the
effort necessary and would introduce numerous opportunities for subtle bugs
and incompatibilities.

I think it would be reasonable to adopt a design principle of *not*
requiring microformat parsers to perform a table layout, even if it can be
used to make inferring semantics easier.


 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?

Yes, very much so too far in that direction.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

[uf-discuss] IE8 + hAtom = hSlice

[Dimitri Glazkov]

Hi all,

It looks like Microsoft is adopting microformats, if not in a rather
awkward way:

http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#webslices

On one hand, I am thrilled to see hAtom implemented in such an elegant
manner, on the other hand, I am puzzled about the 'hslice' nonsense.
But hey, I'll take this over some proprietary XML markup any day.

:DG
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Putting microformats on the BBC iPlayer

[Adam Craven - Four Shapes]

Thanks everyone for the responses.

We especially resonated with the pushing the use of them now in their  
full format, not quite accessible as they can be. Ultimately  
microformats are standards-based and there to support accessibility  
rather than hinder. It's about time screen readers had a reason to  
move quicker.


In firefox 3, microformats should be in http://wiki.mozilla.org/Firefox3/Product_Requirements_Document 
 (CON-008a). However nothing appears in the latest beta.


Having spoke with others internally, the consensus was to use the abbr  
tag for the time being, and all the caveats that it brings.


Adam



On 5 Mar 2008, at 12:47, Michael Smethurst wrote:


Whoops that wasn't meant to go out to the world

But whilst I'm here I probably should point out that /most/ bbc
services/channels/networks now have uf-ed schedules

http://www.bbc.co.uk/radio1/programmes/schedules
http://www.bbc.co.uk/radio4/programmes/schedules/fm
http://www.bbc.co.uk/bbcone/programmes/schedules/oxford
http://www.bbc.co.uk/cbeebies/programmes/schedules

I'll leave you to guess the rest of the urls

For the moment some schedules are still missing (fivelive, bbc  
parliament,
local radio etc) but they'll be along soon. They're also not  
properly linked
into the site but over time will replace existing bbc schedules  
currently

provided by:

http://www.bbc.co.uk/whatson/

Should also note that all of the below still applies. We're looking  
for
clarification on the accessibility / semantic validity of these  
pages. And

we'll let you know if/when we get it ;-)





On 5/3/08 12:21, Michael Smethurst [EMAIL PROTECTED]  
wrote:



Hi Adam

We've had the same problems with http://bbc.co.uk/programmes. For  
now we've
stuck with the standard abbr design pattern but as Mr Mabbett  
helpfully
pointed out our use has potential accessibility issues and definite  
semantic

nastiness.

See here:
http://www.bbc.co.uk/programmes/formats/animation

We've spoken to the bbc accessibility and semantic html working  
groups. The
accessibility people said there were no accessibility problems  
which in the
light of discussions here and elsewhere surprises me. I'm still  
chasing to

get a definite answer and some proper testing

The conversation is currently in the hands of the UXD cluster

I've been pushing to get full coverage testing and an update to the  
BBC

accessibility standards to say either:

- you may use microformats
- you may use the abbreviation design pattern

Or conversely

- you may use microformats
- you must not use the abbreviation design pattern

[And similar for rdf-a]

Would be good if you could also raise these questions with Nick  
Holmes and

cc Frances Berriman and me. Ta






On 4/3/08 13:26, Adam Craven - Four Shapes [EMAIL PROTECTED] 


wrote:


Hi fellers,

We're working on the next version of the BBC iPlayer and would  
love to

put some microformats in there.

Below is what I've gotten so far. In this particular instance  
there's

a single box (206x115) with an image attached. When hovered over,
using JavaScript, the idea is to retrieve the last 7 days of shows  
for
that particular program. I've opted to use the vevent pattern as  
it's

the most widely supported currently - this is open to change in the
future.

I have a concern though. At the moment the spec's datatime pattern  
is

abbr. Unfortunately screen readers are going to mangle this, which
is unacceptable naturally, so I've reverted to hiding the abbr with
{display:none} (this will cover the majority of screen readers) and
filled the field with with extra text, date;

h4abbr class=dtstart dtstamp  
title=2008-03-04T00:00:00ZDate:/

abbrMon 8pm - Radio 2/h4

That way the information can still be parsed. I understand this is  
an
incorrect implementation, but currently unsure how to work around  
this.


Does anyone have suggestions how this can be worked around whilst
still keeping relatively good screen reader support?



li class=programme
div class=feature
a id=uid-9121211 href=#9121211 class=image uid url
img src=img/_dev/206x115.jpg width=206 height=115
alt=206x115 /
/a
div class=details
a class=play-tv href=#9121211
spanPlay TV/span
/a
h3 id=summary-9121211 class=summary
a href=#9121211Two pints of Juergen and a .../a
/h3
/div
/div
ul
li class=vevent featured
a href=#summary-9121211 class=include/a
a href=#uid-9121211 class=include/a
h4abbr class=dtstart dtstamp
title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
div class=description
pShort description of episode lies here. It can be up-to 90
characters long./p
pExpires in 3 days/p
/div
pa href=#downbabyMore episodes /a/p
/li
li class=vevent
a href=#summary-9121211 class=include/a
a href=#uid-9121211 class=include/a
h4abbr class=dtstart dtstamp
title=2008-03-04T00:00:00ZDate:/abbrMon 8pm - Radio 2/h4
div class=description
pShort description of episode lies here. It can be up-to 90
characters long./p
pExpires in 3 days/p
/div
pa href=#downbabyMore episodes /a/p
/li
li 

Re: [uf-discuss] Reflections on community time, rules, guidelines, and banning Andy

[Ernest Prabhakar]

Hi Ryan,

On Mar 4, 2008, at 10:08 AM, Ryan King wrote:
The how-to-play and mailing-lists pages have been updated with  
annotations
documenting which of the rules have been created directly due to one  
or

more of Andy's actions (wiki edits and/or emails).

As time permits, the admins will both hyperlink each of those  
annotations

to the specific email in the archives or edit in the wiki history that
caused it, as well as annotate any remaining rules with their causes  
as

well.  We believe this will help provide better transparency and
accountability.


Thanks for taking the time to explain and document your actions  
clearly. I'm sure this was a difficult decision, but I appreciate the  
hard work all of the admins have put in to do this as fairly as  
possible.


Sincerely,
Ernest Prabhakar

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] IE8 + hAtom = hSlice

[Ryan King]

On Mar 5, 2008, at 7:28 AM, Dimitri Glazkov wrote:

It looks like Microsoft is adopting microformats, if not in a rather
awkward way:

http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#webslices

On one hand, I am thrilled to see hAtom implemented in such an elegant
manner, on the other hand, I am puzzled about the 'hslice' nonsense.
But hey, I'll take this over some proprietary XML markup any day.


Yeah, I find it strange that they say that they're using hAtom, but  
then go and mint a new term. Why not just use hAtom and be done with  
it? Would it be too much to ask for this feature to work with *already  
deployed content on the web*?


/rant

Come on, microsoft, you're so close to getting it right here!

-ryan
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] IE8 + hAtom = hSlice

[André Luís]

Well, it seems it would be pretty seamless to have the content work
both as a webslice and hatom, no?

div class=hentry hslice
...
/div

One could argue that this way only the intended hAtom's will be usable
as hSlices... but I'd expect it to have a wider audience from boot if
they allowed hAtom as spec'ed...

--
André Luís

On Wed, Mar 5, 2008 at 3:28 PM, Dimitri Glazkov
[EMAIL PROTECTED] wrote:
 Hi all,

  It looks like Microsoft is adopting microformats, if not in a rather
  awkward way:

  
 http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#webslices

  On one hand, I am thrilled to see hAtom implemented in such an elegant
  manner, on the other hand, I am puzzled about the 'hslice' nonsense.
  But hey, I'll take this over some proprietary XML markup any day.

  :DG
  ___
  microformats-discuss mailing list
  microformats-discuss@microformats.org
  http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] IE8 + hAtom = hSlice

[David Janes]

On Wed, Mar 5, 2008 at 1:40 PM, Ryan King [EMAIL PROTECTED] wrote:

 On Mar 5, 2008, at 7:28 AM, Dimitri Glazkov wrote:
  It looks like Microsoft is adopting microformats, if not in a rather
  awkward way:
 
  http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#webslices
 
  On one hand, I am thrilled to see hAtom implemented in such an elegant
  manner, on the other hand, I am puzzled about the 'hslice' nonsense.
  But hey, I'll take this over some proprietary XML markup any day.

 Yeah, I find it strange that they say that they're using hAtom, but
 then go and mint a new term. Why not just use hAtom and be done with
 it? Would it be too much to ask for this feature to work with *already
 deployed content on the web*?

 /rant

 Come on, microsoft, you're so close to getting it right here!

 -ryan


Yes, it's very odd. I think they may have done this because they
(maybe) wanted to

- avoid making people think that the slice was a weblog
- avoid having to use the required elements in hAtom [1]
- encapsulate the idea of _one_ thing that's being updated

This second one is probably a bigger issue, as I don't know any
reasonable way of getting rid of updated/created and still have a
complaint Atom document. Maybe make it be the current datetime? I
think this is where the webslice differs from a feed -- it's one thing
that's continually being updated, rather than a feed where _new_
things are appearing all the time.

The whitepapers can be read here [2]. Note the interesting way of
subscribing to a feed (which can only have a single entry, btw):

a rel=feedurl ref=auction.microsoft.com/item.xmlSubscribe to WebSlice/a

I don't see ref in HTML 4.01 [3] - something in a new spec or is it
broken HTML? If it was part of a standard I could see uses for it,
such as encoding IDs.

It would have been nice if MS engaged us here, so we could have banged
around some ideas (or flew me to Redmond for consultants ;-) My
thought would be to do something like this:

div class=hfeed hentry... the webslice ... /div

Regards, etc...

[1] which reminds me to get our notes from SGFooCamp for hAtom 0.2 up...
[2] 
http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapersReleaseId=567
[3] http://www.w3.org/TR/html4/struct/links.html#edef-A

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onaswarm.com
http://www.onamine.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] Re: hCalendar for events in a table format

[Jason Karns]

On Wed, Mar 5, 2008 at 1:45 PM, Ryan King [EMAIL PROTECTED] wrote:
 On Mar 5, 2008, at 7:30 AM, Tantek Çelik wrote:
  On 3/5/08 5:02 AM, Toby A Inkster [EMAIL PROTECTED] wrote:
 
  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.
 
  Speaking from the experience of working on a browser rendering
  engine which
  *did* have to handle colspan and rowspan, I can certainly state that
  requiring a microformats parser to perform a table layout
  (effectively what
  it takes to support colspan and rowspan) would *drastically* raise the
  effort necessary and would introduce numerous opportunities for
  subtle bugs
  and incompatibilities.

 Though I don't disagree with you that requiring table layout is too
 much, I just wanted to point out that the current HTML5 draft includes
 a more fully specified algorithm for determining table headers:

   
 http://www.whatwg.org/specs/web-apps/current-work/#header-and-data-cell-semantics

 -ryan

 ___
 microformats-discuss mailing list
 microformats-discuss@microformats.org
 http://microformats.org/mailman/listinfo/microformats-discuss


I am a little worried about dropping support for hCalendar in table
markup.  If the most semantic markup for a given hCalendar is in a
table, then to use hCalendar authors would be required to use
less-semantic markup.  I think we can all agree this is not a desired
side effect of using microformats.  We would then have the table-based
markup situation of the 90's, only reversed. (using alternative markup
such as divs and spans where tables *should* be used).

~Jason

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Re: [uf-discuss] IE8 + hAtom = hSlice

[David Janes]

I've posted my initial thoughts:
http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2008-03-05-/

-- 
David Janes
Founder, BlogMatrix
http://www.blogmatrix.com
http://www.onaswarm.com
http://www.onamine.com
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss