audio-info-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(re-ordered the page, tried to move Q&A closer to the actual open issues)
Line 48: Line 48:
hAudio ISSUE #4: {{OpenIssue}}
hAudio ISSUE #4: {{OpenIssue}}


In order to solve the [[audio-info-issues#Historical:_Graphic_buttons_in_rel-patterns|graphic-only buttons in rel-patterns problem]], it was identified that part of the problem dealt with attempting to create relationship quadruples, or incorrect relationship triples. Typically, rel-patterns are created by doing something like the following:
In order to solve the [[audio-info-issues#Historical:_Graphic_buttons_in_rel-patterns|graphic-only buttons in rel-patterns problem]], it was identified that part of the problem dealt with attempting to create relationship quadruples, or incorrect relationship triples.  
 
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).
 
Typically, rel-patterns are created by doing something like the following:


  <a rel="RELATIONSHIP" href="URL">TARGET</a>
  <a rel="RELATIONSHIP" href="URL">TARGET</a>
Line 58: Line 62:
The URL above would be read like so: The URL <code>http://www.people.org/john_f_kennedy.html</code> is related to <code>Robert Kennedy</code> via a relationship of type <code>brother</code>. In other words, John F. Kennedy is Robert Kennedy's brother.
The URL above would be read like so: The URL <code>http://www.people.org/john_f_kennedy.html</code> is related to <code>Robert Kennedy</code> via a relationship of type <code>brother</code>. In other words, John F. Kennedy is Robert Kennedy's brother.


The above rel-pattern is fine, but becomes problematic when images start to be used, thus:
Using rel-pattern as such:


  <a rel="brother" href="/people/john_f_kennedy.html" title="Robert Kennedy">
  <a rel="brother" href="/people/john_f_kennedy.html" title="Robert Kennedy">
Line 69: Line 73:
* the @title attribute on the anchor (A element)
* the @title attribute on the anchor (A element)
* or, not at all.
* or, not at all.
This is because the rel attribute is only concerned with the relationship between the current page and the href. The TITLE of the link is not defined by rel.
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.
How do we present this option to a human being in a non-web-page UI?


===Possible Solutions===
===Possible Solutions===


# Do nothing. The decision should be left up to uF implementors. The market should decide how the information is displayed.
====Do nothing====
# Display whatever a text-only browser would display (in this case, the value in @alt would be displayed).
The decision should be left up to uF implementors. The market should decide how the information is displayed. This is something that does not need to be explicit in the spec, but can be left flexible to developers to implement as they see best and to adapt to their applications and future developments. Forcing someone to use the @alt or @title prevents them from reusing the actual image or using their own graphics because the spec mandated the "correct" use.
# Create a <code>rel-value</code>, or other <code>displayable</code> Microformat class that should specify the text value to be used.
 
====Use the TITLE Attribute====
 
Using @title was proposed in the following post to the mailing list:
 
http://microformats.org/discuss/mail/microformats-new/2007-July/000590.html
 
=====Benefits=====
 
# It POSH-ifies the website.
# It works well with Operator, Firefox 3 and other uF parsers/UIs.
# It adds the accessibility/screen reader problem.
 
=====Drawbacks=====
 
# There are arguments stating that the @alt attribute would be a better choice: http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html
# there are arguments that this is not part of how the rel attribute was designed and it is layering semantics onto the attribute that don't exist in the HTML spec.
 
====New Label Property====
# Create a specific new property that defines the label title, or other <code>displayable</code> Microformat class that should specify the text value to be used.


=Problem: Peeking into child elements=
=Problem: Peeking into child elements=
Line 88: Line 118:


A microformat parser would take the HTML above and automatically parse out the contents of the @alt attribute on all child elements.
A microformat parser would take the HTML above and automatically parse out the contents of the @alt attribute on all child elements.


Another approach would parse out display-able elements based on a pre-defined microformatted relationship such as <code>displayble</code>, like so:
Another approach would parse out display-able elements based on a pre-defined microformatted relationship such as <code>displayble</code>, like so:
Line 100: Line 131:
# The community should decide on a set of attributes and elements that are peek-able (for example: any element that contains an @alt attribute should be peek-able)
# The community should decide on a set of attributes and elements that are peek-able (for example: any element that contains an @alt attribute should be peek-able)
# Only elements that are marked with a class of a specified type, such as <code>displayable</code>, should be used to display the text.
# Only elements that are marked with a class of a specified type, such as <code>displayable</code>, should be used to display the text.
# Display what common text-only browser displays (in the case of Lynx, the value in @alt).
====Benefits====
# Valid HTML requires that the ALT tag is specified anyway, thus we're helping people write proper HTML.
# Because of the item above, this is in-line with what most text-based browsers and screen readers expect.
# There is no danger of @title and @alt both being specified and read by a screen reader.
## ?? what about @title on the 'a' and an @alt on the image?
====Drawbacks====
# 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


= Problem: Summary Property is Missing =
= Problem: Summary Property is Missing =
Line 112: Line 156:


=Historical: Graphic buttons in rel-patterns=
=Historical: Graphic buttons in rel-patterns=
This problem has been split into two parts, per Brian Suda's request. The problems are listed above and refer to this problem statement, namely:
[[audio-info-issues#Problem:_Display_properties_of_rel-patterns|Display properties of rel-patterns]] and [[audio-info-issues#Problem:_Peeking_into_child_elements_to_display_rel-patterns|Peeking into child elements]]
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==
==Affected Parties==


Any site that uses images for links. 'rel-sample', 'rel-enclosure', and 'rel-payment' and wants an additional property to display something besides a URL 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.
Any site that uses images for links. 'rel-sample', 'rel-enclosure', and 'rel-payment' and wants an additional property to display something besides a URL 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).
This problem has been split into two parts, per Brian Suda's request. The problems are listed above and refer to this problem statement, namely:


==Potential Solutions==
[[audio-info-issues#Problem:_Display_properties_of_rel-patterns|Display properties of rel-patterns]] and [[audio-info-issues#Problem:_Peeking_into_child_elements_to_display_rel-patterns|Peeking into child elements]]
 
===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====
 
# It POSH-ifies the website.
# It works well with Operator, Firefox 3 and other uF parsers/UIs.
# It fixes the accessibility/screen reader problem.
 
====Drawbacks====
 
# 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====
 
# Valid HTML requires that the ALT tag is specified anyway, thus we're helping people write proper HTML.
# Because of the item above, this is in-line with what most text-based browsers and screen readers expect.
# There is no danger of @title and @alt both being specified and read by a screen reader.
 
====Drawbacks====
 
# 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====
====History====
Line 193: Line 176:
# Posting stopped due to an End of Thread request: http://microformats.org/discuss/mail/microformats-new/2007-July/000644.html
# Posting stopped due to an End of Thread request: http://microformats.org/discuss/mail/microformats-new/2007-July/000644.html
# The issue and discussion was documented on the wiki.
# The issue and discussion was documented on the wiki.
====Separating the Issues====
There are two actually issues here, which need to be untangled.
*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.
*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.[[User:Brian|brian suda]] 13:11, 2 August 2007 (UTC)

Revision as of 13:52, 8 August 2007

Audio info issues

This page defines the current issues with the hAudio draft specification. Any issues that have not yet been resolved are marked with an open issue! tag.

Contributors

In order of contribution:

Problem: Redundant Property Names

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

image-summary Property

hAudio ISSUE #1: 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

hAudio ISSUE #2: open issue!

audio-title - There is an 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

hAudio ISSUE #3: 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: Display properties of rel-patterns

hAudio ISSUE #4: open issue!

In order to solve the graphic-only buttons in rel-patterns problem, it was identified that part of the problem dealt with attempting to create relationship quadruples, or incorrect relationship triples.

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

Typically, rel-patterns are created by doing something like the following: 

<a rel="RELATIONSHIP" href="URL">TARGET</a>

The final triple that is created can be read thusly: URL is related to TARGET via RELATIONSHIP. 

<a rel="brother" href="/people/john_f_kennedy.html">Robert Kennedy</a>

The URL above would be read like so: The URL http://www.people.org/john_f_kennedy.html is related to Robert Kennedy via a relationship of type brother. In other words, John F. Kennedy is Robert Kennedy's brother.

Using rel-pattern as such: 

<a rel="brother" href="/people/john_f_kennedy.html" title="Robert Kennedy">
  <img src="/images/robert_kennedy.gif" alt="Robert Kennedy" />
</a>

It isn't defined if the displayable value of the relationship "Robert Kennedy" should be used from

  • the @alt attribute on the IMG element
  • the @title attribute on the anchor (A element)
  • or, not at all.

This is because the rel attribute is only concerned with the relationship between the current page and the href. The TITLE of the link is not defined by rel.

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.

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


Possible Solutions

Do nothing

The decision should be left up to uF implementors. The market should decide how the information is displayed. This is something that does not need to be explicit in the spec, but can be left flexible to developers to implement as they see best and to adapt to their applications and future developments. Forcing someone to use the @alt or @title prevents them from reusing the actual image or using their own graphics because the spec mandated the "correct" use.

Use the TITLE Attribute

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

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

Benefits
  1. It POSH-ifies the website.
  2. It works well with Operator, Firefox 3 and other uF parsers/UIs.
  3. It adds 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
  2. there are arguments that this is not part of how the rel attribute was designed and it is layering semantics onto the attribute that don't exist in the HTML spec.

New Label Property

  1. Create a specific new property that defines the label title, or other displayable Microformat class that should specify the text value to be used.

Problem: Peeking into child elements

hAudio ISSUE #5: open issue!

It has been proposed that peeking into child elements that are not labeled with microformatted class names goes against the established publishing practices of microformats. In other words, if there isn't a microformatted class name on the element, we shouldn't be reading/interpreting the contents of the element.

There have been several proposed solutions, one of which automatically peeks at certain sub-elements, such as @alt in IMG: 

<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
  <img src="/images/deed/by.png" alt="Creative Commons Attribution 3.0" />
</a>

A microformat parser would take the HTML above and automatically parse out the contents of the @alt attribute on all child elements.


Another approach would parse out display-able elements based on a pre-defined microformatted relationship such as displayble, like so: 

<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">
  <img rel="displayable" src="/images/deed/by.png" alt="Creative Commons Attribution 3.0" />
</a>

Possible Solutions

  1. Microformats should never peek into child elements when displaying information.
  2. The community should decide on a set of attributes and elements that are peek-able (for example: any element that contains an @alt attribute should be peek-able)
  3. Only elements that are marked with a class of a specified type, such as displayable, should be used to display the text.
  4. Display what common text-only browser displays (in the case of Lynx, the value in @alt).


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.
    1. ?? what about @title on the 'a' and an @alt on the image?

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


Problem: Summary Property is Missing

hAudio ISSUE #6: open issue!

Martin McEvoy did another analysis run of the audio-info-examples data and found that audio descriptions existed for many of the URLs. It has been proposed that audio descriptions should be added to the hAudio Microformat.

Possible Solutions

  • Add audio descriptions to the hAudio specification using SUMMARY
  • Add audio descriptions to the hAudio specification using DESCRIPTION

Historical: Graphic buttons in rel-patterns

Affected Parties

Any site that uses images for links. 'rel-sample', 'rel-enclosure', and 'rel-payment' and wants an additional property to display something besides a URL are affected. Most of the examples also contain images instead of text for samples, downloads and purchase links. This is a demonstrable, widespread problem.

This problem has been split into two parts, per Brian Suda's request. The problems are listed above and refer to this problem statement, namely:

Display properties of rel-patterns and Peeking into child elements

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.
Retrieved from "http://microformats.org/wiki/index.php?title=audio-info-issues&oldid=19629"