audio-info-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(dtstart)
m (Added tag image-only content issue)
Line 10: Line 10:
* [[audio-info-proposal#Published Date|published-date]] is a duplicate of the PUBLISHED property found-in [[hatom|hAtom]]. This can be collapsed to a single property name.
* [[audio-info-proposal#Published Date|published-date]] is a duplicate of the PUBLISHED property found-in [[hatom|hAtom]]. This can be collapsed to a single property name.
**or <code>dtstart</code>, from hCalendar (shouldn't the published date be an hCalendar event?) [[User:AndyMabbett|Andy Mabbett]]
**or <code>dtstart</code>, from hCalendar (shouldn't the published date be an hCalendar event?) [[User:AndyMabbett|Andy Mabbett]]
==Problem: Graphic buttons in rel-patterns ==
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 [[audio-info-examples|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.
1. It works well with Operator, Firefox 3 and other uF parsers/UIs.
1. 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.
1. Because of the item above, this is in-line with what most text-based browsers and screen readers expect.
1. 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
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
1. 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
1. 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
1. A very long argument started on the use/mis-use of ALT: http://microformats.org/discuss/mail/microformats-new/2007-July/000603.html
1. 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
1. It was asserted that the research completed was not acceptable: http://microformats.org/discuss/mail/microformats-new/2007-July/000635.html
1. Things got nasty: http://microformats.org/discuss/mail/microformats-new/2007-July/000637.html
1. Posting stopped due to an End of Thread request: http://microformats.org/discuss/mail/microformats-new/2007-July/000644.html
1. The issue and discussion was placed on the wiki

Revision as of 03:32, 2 August 2007

Audio info issues

Redundant property names

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

  • image-summary I can not determine if this is a description of the image, in which case it should NOT be a MUST to use the <img> element, (it shouldn't be a MUST anyway). There are several other formats that already use the PHOTO property, including hCard and hReview. This has potential to collapse and remove image-summary.
  • audio-title There is the on going debate where this should be something else such as FN or SUMMARY
  • 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

Problem: Graphic buttons in rel-patterns

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. 1. It works well with Operator, Firefox 3 and other uF parsers/UIs. 1. 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. 1. Because of the item above, this is in-line with what most text-based browsers and screen readers expect. 1. 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 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 1. 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 1. 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 1. A very long argument started on the use/mis-use of ALT: http://microformats.org/discuss/mail/microformats-new/2007-July/000603.html 1. 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 1. It was asserted that the research completed was not acceptable: http://microformats.org/discuss/mail/microformats-new/2007-July/000635.html 1. Things got nasty: http://microformats.org/discuss/mail/microformats-new/2007-July/000637.html 1. Posting stopped due to an End of Thread request: http://microformats.org/discuss/mail/microformats-new/2007-July/000644.html 1. The issue and discussion was placed on the wiki