audio-info-issues

Audio info issues

Redundant Property Names

The audio info proposal has invented several new properties. These should be condensed, removed and/or discussed further.

image-summary Property

open issue!

image-summary - This is a small graphic image that summarizes the audio piece. It should NOT be a MUST to use the <img> element, (it shouldn't be a MUST anyway) ~BrianSuda. There are several other formats that already use the PHOTO property, including hCard and hReview. This has potential to collapse and remove image-summary.

Possible Solutions

1. Use PHOTO instead.

audio-title Property

open issue!

audio-title - There is the on going debate where this should be something else such as FN or SUMMARY.

Possible Solutions

1. Use FN instead
2. Use SUMMARY instead

published-date Property

open issue!

published-date is a duplicate of the PUBLISHED property found-in hAtom. This can be collapsed to a single property name.

• • or dtstart, from hCalendar (shouldn't the published date be an hCalendar event?) Andy Mabbett

Possible Solutions

1. Use PUBLISHED instead
2. Use DTSTART instead

Problem: Graphic buttons in rel-patterns

open issue!

It is quite often that a site uses an image instead of a text link to present actions. For example: Instead of using the text "Download", they will use a graphic image with a downward-facing arrow.

In other words, if we have this:

Download:

<a href="http://my.site.com/download/3847293">
 <img src="/images/cool_download_button.png"/>
</a>

How do we present this option to a human being in a non-web-page UI?

Affected Parties

Any site that uses images for links. 'rel-sample', 'rel-enclosure', and 'rel-payment' are affected. Most of the examples also contain images instead of text for samples, downloads and purchase links. This is a demonstrable, widespread problem.

If there is no text to display, then how does one place the item into a menu/display for Operator/Firefox? Grabbing the image and placing it in a UI is a difficult argument to make - there are a variety of image sizes that might not do well in the Operator UI (or Firefox 3 UI).

Potential Solutions

Use the TITLE Attribute on the rel-pattern Links

Using @title was proposed in the following post to the mailing list:

http://microformats.org/discuss/mail/microformats-new/2007-July/000590.html

Here is an example markup:

<a rel="rel-enclosure" title="Download My Song"
   href="http://my.site.com/download/MySong.mp3">
 <img src="/images/cool_download_button.png"/>
</a>

Benefits

1. It POSH-ifies the website.
2. It works well with Operator, Firefox 3 and other uF parsers/UIs.
3. It fixes the accessibility/screen reader problem.

Drawbacks

1. There are arguments stating that the @alt attribute would be a better choice: http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html

Use the ALT Attribute on the IMG Elements

Using @alt was proposed in the following post to the mailing list:

http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html

Here is example markup:

<a rel="rel-enclosure" href="http://my.site.com/download/MySong.mp3">
 <img alt="Download My Song" src="/images/cool_download_button.png"/>
</a>

Benefits

1. Valid HTML requires that the ALT tag is specified anyway, thus we're helping people write proper HTML.
2. Because of the item above, this is in-line with what most text-based browsers and screen readers expect.
3. There is no danger of @title and @alt both being specified and read by a screen reader.

Drawbacks

1. The point was raised that ALT tags are not used properly on the web: http://microformats.org/discuss/mail/microformats-new/2007-July/000598.html and http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up

History

1. ALT was proposed on the mailing list: http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html
2. The point was raised that ALT tags are not used properly on the web: http://microformats.org/discuss/mail/microformats-new/2007-July/000598.html
3. Research was started on ALT tag usage on the web: http://microformats.org/discuss/mail/microformats-new/2007-July/000614.html and http://microformats.org/discuss/mail/microformats-new/2007-July/000596.html
4. Analysis on ALT tag usage on the web was reported: http://microformats.org/discuss/mail/microformats-new/2007-July/000624.html and http://microformats.org/discuss/mail/microformats-new/2007-July/000627.html
5. A very long argument started on the use/mis-use of ALT: http://microformats.org/discuss/mail/microformats-new/2007-July/000603.html
6. More research was performed and presented to the list asserting that ALT is not being mis-used on the web: http://microformats.org/discuss/mail/microformats-new/2007-July/000629.html
7. It was asserted that the research completed was not acceptable: http://microformats.org/discuss/mail/microformats-new/2007-July/000635.html
8. Things got nasty: http://microformats.org/discuss/mail/microformats-new/2007-July/000637.html
9. Posting stopped due to an End of Thread request: http://microformats.org/discuss/mail/microformats-new/2007-July/000644.html
10. The issue and discussion was documented on the wiki.

Separating the Issues

There are two actually issues here, which need to be untangled.

1. 1 the yearning to have the rel attribute define 2 different things at once, an @href and a title.

<a href="foo/" rel="rel-value-here">bar</a>

rel has a very specific definition, it can only form a triple based on the href and the rel X is related to Y via rel-value-here

This proposal was to make it do a secondary thing, which it is not semantically designed to do.

X is related to Y via rel-value, and that rel-value has a value of TITLE (@alt or @title).

this should be fixed in 1 of 2 ways... either with a value unto itself, class="rel-value-here-title" because rel-value has a value or TITLE doesn´t make much sense semantically. -or- not at all. Currently, this is how rel-license works. Operator (and other applications) are free to attempt to give a LABEL to that link how they see fit - there is no reason to define this in the spec, let the market define how to do this in the best way.

1. 2, the whole "lets peek inside child elements not directly labeled with microformated properties"

The problem with peeking into child elements is, where does it end? if we do @alt for IMG then we should do @title on abbr as well, ...

I feel that peeking inside child elements is a bad idea. Microformats should only be concerned with elements that are explicitly marked-up as so. XSLT, XPath and RDFa also do NOT "peek inside child elements" so this gives us other technologies that have look into this issue and avoided it as well.

I hope this helps direct any of your further documentation. My suggestion would be to split this into 2 issues and discuss each on separately.brian suda 13:11, 2 August 2007 (UTC)