audio-info-issues: Difference between revisions
(added rel property) |
(Added Sperate Issues section) |
||
Line 43: | Line 43: | ||
Download: | Download: | ||
<a href="http://my.site.com/download/3847293 | <a href="http://my.site.com/download/3847293"> | ||
<img src="/images/cool_download_button.png"/> | <img src="/images/cool_download_button.png"/> | ||
</a> | </a> | ||
Line 114: | Line 114: | ||
# 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:13, 2 August 2007
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
- 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
- Use FN instead
- 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
- or
Possible Solutions
- Use PUBLISHED instead
- 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
- 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
- ALT was proposed on the mailing list: http://microformats.org/discuss/mail/microformats-new/2007-July/000593.html
- 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
- 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
- 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
- A very long argument started on the use/mis-use of ALT: http://microformats.org/discuss/mail/microformats-new/2007-July/000603.html
- 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
- It was asserted that the research completed was not acceptable: http://microformats.org/discuss/mail/microformats-new/2007-July/000635.html
- Things got nasty: http://microformats.org/discuss/mail/microformats-new/2007-July/000637.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.
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.brian suda 13:11, 2 August 2007 (UTC)