Test of link with image with alt text

From arash.amiri at researchstudio.at Wed Jul 4 05:18:38 2007 From: arash.amiri at researchstudio.at (Arash Amiri) Date: Wed Jul 4 05:19:07 2007 Subject: [uf-new] micorformat for a shopping task Message-ID: <468B901E.5080607@researchstudio.at> Hi! I was wondering if it makes sense to create some microformat for a shopping task. This microformat describes what you want to buy, until when you want to have it (deadline?), and maybe some more things... The reason why I mention this it to find some "portable description" of things you need. For example, you walk passed a supermarket and get reminded that you need some bread. There is probably no format encapsulating this "I need this until then..."-thing. any comments (or is that just out of scope of the idea?) From scott at makedatamakesense.com Wed Jul 4 07:52:36 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Jul 4 07:52:41 2007 Subject: [uf-new] micorformat for a shopping task In-Reply-To: <468B901E.5080607@researchstudio.at> References: <468B901E.5080607@researchstudio.at> Message-ID: <5C5B4EA3-B828-4FC5-8079-0A87C6E68DEC@makedatamakesense.com> On Jul 4, 2007, at 6:18 AM, Arash Amiri wrote: > I was wondering if it makes sense to create some microformat for a > shopping task. This microformat describes what you want to buy, > until when you want to have it (deadline?), and maybe some more > things... > > The reason why I mention this it to find some "portable > description" of things you need. For example, you walk passed a > supermarket and get reminded that you need some bread. There is > probably no format encapsulating this "I need this until then..."- > thing. > > any comments (or is that just out of scope of the idea?) Have you tried applying hListing to this? http://microformats.org/wiki/hlisting -- Scott Reynen MakeDataMakeSense.com From msporny at digitalbazaar.com Sun Jul 8 13:39:33 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Jul 8 13:39:37 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) Message-ID: <46914B85.4040903@digitalbazaar.com> We've gone through and implemented hAudio on Bitmunk.com (one of our service websites). David Lehn, one of our semantic web guys, has also created an hAudio plug-in for Operator. Mike Kaply, author of Operator, said that he will make it available via the Operator download section within the next week or two. To view some hAudio compliant markup, you can go to the following link: http://www.bitmunk.com/view/media/6011098 There are over 850,000 songs that have been marked up on the website. We are in the process of talking our partners, colleagues and competitors into using hAudio to mark up their audio content as well. So, good progress is being made in implementing hAudio. However, we've hit a snag when it comes to usability with hAudio and Operator/Firefox 3. Problem Description: 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:

How do we present this option to a human being in a non-web-page UI? How it relates to the Examples: We (Bitmunk.com) has this problem with 'rel-sample', 'rel-enclosure', and 'rel-payment'. Most of the examples also contain images instead of text for samples, downloads and purchase links. This is a demonstrable, widespread problem. The problem with Operator and screen readers: 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). Proposed solution: We have a fix for Operator that uses the link title text if there is no internal text. This fixes the problem for both Operator menu display, Firefox 3 UI display and for screen readers. Here's how the site author would change the text above: Download:

This approach is beneficial for the following reasons: 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. We need feedback/consensus from the uF community before submitting the patch for inclusion into Operator/Firefox 3. Is there anybody that disagrees with this approach or has a better approach? -- manu From andy at pigsonthewing.org.uk Sun Jul 8 14:10:23 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Jul 8 14:10:30 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: <46914B85.4040903@digitalbazaar.com> References: <46914B85.4040903@digitalbazaar.com> Message-ID: In message <46914B85.4040903@digitalbazaar.com>, Manu Sporny writes >Problem Description: > >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: > >

> > >How do we present this option to a human being in a non-web-page UI? The HTML is invalid, lacking the alt attribute which should fix this problem. -- Andy Mabbett From msporny at digitalbazaar.com Sun Jul 8 14:30:12 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Sun Jul 8 14:30:15 2007 Subject: [uf-new] Mapping the hAudio Microformat to hAudio RDFa Message-ID: <46915764.1070900@digitalbazaar.com> What is the process for mapping the hAudio Microformat to RDFa? The reason that we need to do this is because the hAlbum/hVideo specs that we've been researching internally have some nasty long-term design issues due to the no-namespace/scope-less approach that uFs have adopted. We'd like to make hAudio a standard across "semantic languages". We don't want to go through the same arduous process that everybody had to go through on here concerning hAudio with another community... it would be a waste of everybody's time. The hard work (research, examples and analysis) was accomplished via the Microformats process. Implementing hAudio using the Microformats approach isn't going to work for complicated/nested audio/video/image structures. We have a very large database that we would like to semantic-ify and we would like to do it in a standards-compliant way. How can we propose an RDFa standard for hAudio that is scrutinized and adopted by this community? In other words - Microformats did a good job with the design. We'd like to give people the option to implement using either hAudio uF or hAudio RDFa. -- manu From microformats at kaply.com Mon Jul 9 05:37:49 2007 From: microformats at kaply.com (Mike Kaply) Date: Mon Jul 9 05:37:53 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: References: <46914B85.4040903@digitalbazaar.com> Message-ID: Actually the alt attribute WON'T fix this problem. Because the microformat attribute is on the anchor tag, not the image. Microformats grab the text in the tag. They only grab the image alt text if the microformat class is on the image itself. Here's a different example:

I realize this is a little contrived, but you get the idea. In this case, the fn is empty. Mike Kaply On 7/8/07, Andy Mabbett wrote: > In message <46914B85.4040903@digitalbazaar.com>, Manu Sporny > writes > > >Problem Description: > > > >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: > > > >

> > > > > >How do we present this option to a human being in a non-web-page UI? > > The HTML is invalid, lacking the alt attribute which should fix this > problem. > > -- > Andy Mabbett > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From andy at pigsonthewing.org.uk Mon Jul 9 07:14:12 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Jul 9 07:14:16 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: References: <46914B85.4040903@digitalbazaar.com> Message-ID: <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> On Mon, July 9, 2007 13:37, Mike Kaply wrote: > On 7/8/07, Andy Mabbett wrote: > >> In message <46914B85.4040903@digitalbazaar.com>, Manu Sporny >> writes >>> if we have this: >>> Download: >>> >>>

>>> >>> How do we present this option to a human being in a non-web-page UI? >> The HTML is invalid, lacking the alt attribute which should fix this >> problem. > Actually the alt attribute WON'T fix this problem. Because the > microformat attribute is on the anchor tag, not the image. Microformats > grab the text in the tag. They only grab the image alt text if the > microformat class is on the image itself. Here's a different example: > >

alt="Mike Kaply"> > > I realize this is a little contrived, but you get the idea. > In this case, the fn is empty. My argument is that the fn should /not/ be empty; the "alt" attribute contains the text equivalent of the image. To discount it as you suggest is to ignore the semantics of the mark-up presented to you. -- Andy Mabbett ** via webmail ** From scott at makedatamakesense.com Mon Jul 9 07:37:49 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Jul 9 07:38:02 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> Message-ID: On Jul 9, 2007, at 8:14 AM, Andy Mabbett wrote: >> They only grab the image alt text if the >> microformat class is on the image itself. Here's a different example: >> >>

> alt="Mike Kaply"> >> >> I realize this is a little contrived, but you get the idea. > >> In this case, the fn is empty. > > My argument is that the fn should /not/ be empty; the "alt" attribute > contains the text equivalent of the image. I agree this matches the semantics of the alt attribute; however, I suspect few publishers are currently using this attribute appropriately, so I think we should do more research into the likely ramifications of such a change before making it. -- Scott Reynen MakeDataMakeSense.com From derrick at pallas.us Mon Jul 9 08:42:58 2007 From: derrick at pallas.us (Derrick Lyndon Pallas) Date: Mon Jul 9 08:42:59 2007 Subject: [uf-new] img alt content In-Reply-To: References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> Message-ID: <46925782.3010006@pallas.us> Actually, I can probably be of help here, having written the Alexa Image Search indexer. While I can't divulge too much about what goes into building the index, I'll see if I can find some time to take a look at the usage of img/@alt inside hcard/fn some time this week. Is there anything specific anyone would like me to look for? ~D Scott Reynen wrote: > On Jul 9, 2007, at 8:14 AM, Andy Mabbett wrote: > >>> They only grab the image alt text if the >>> microformat class is on the image itself. Here's a different example: >>> >>>

>> alt="Mike Kaply"> >>> >>> I realize this is a little contrived, but you get the idea. >> >>> In this case, the fn is empty. >> >> My argument is that the fn should /not/ be empty; the "alt" attribute >> contains the text equivalent of the image. > > I agree this matches the semantics of the alt attribute; however, I > suspect few publishers are currently using this attribute > appropriately, so I think we should do more research into the likely > ramifications of such a change before making it. > > -- > Scott Reynen > MakeDataMakeSense.com > > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new From bewest at gmail.com Mon Jul 9 12:34:22 2007 From: bewest at gmail.com (Benjamin West) Date: Mon Jul 9 12:34:24 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: <46914B85.4040903@digitalbazaar.com> References: <46914B85.4040903@digitalbazaar.com> Message-ID: <8ad71be30707091234r17640ce3jcf5bd36d3abe6fb9@mail.gmail.com> One possible solution is to use an image replacement technique. Also, you may choose to send content in a and then hide it when it's unnecessary. -Ben On 7/8/07, Manu Sporny wrote: > We've gone through and implemented hAudio on Bitmunk.com (one of our > service websites). David Lehn, one of our semantic web guys, has also > created an hAudio plug-in for Operator. Mike Kaply, author of Operator, > said that he will make it available via the Operator download section > within the next week or two. To view some hAudio compliant markup, you > can go to the following link: > > http://www.bitmunk.com/view/media/6011098 > > There are over 850,000 songs that have been marked up on the website. We > are in the process of talking our partners, colleagues and competitors > into using hAudio to mark up their audio content as well. So, good > progress is being made in implementing hAudio. > > However, we've hit a snag when it comes to usability with hAudio and > Operator/Firefox 3. > > Problem Description: > > 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: > >

> > > How do we present this option to a human being in a non-web-page UI? > > How it relates to the Examples: > > We (Bitmunk.com) has this problem with 'rel-sample', 'rel-enclosure', > and 'rel-payment'. Most of the examples also contain images instead of > text for samples, downloads and purchase links. This is a demonstrable, > widespread problem. > > The problem with Operator and screen readers: > > 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). > > Proposed solution: > > We have a fix for Operator that uses the link title text if there is no > internal text. This fixes the problem for both Operator menu display, > Firefox 3 UI display and for screen readers. Here's how the site author > would change the text above: > > Download: > href="http://my.site.com/download/MySong.mp3"> >

> > > This approach is beneficial for the following reasons: > > 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. > > We need feedback/consensus from the uF community before submitting the > patch for inclusion into Operator/Firefox 3. Is there anybody that > disagrees with this approach or has a better approach? > > -- manu > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From tantek at cs.stanford.edu Mon Jul 9 12:36:54 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jul 9 12:37:03 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: Message-ID: On 7/9/07 7:37 AM, "Scott Reynen" wrote: > On Jul 9, 2007, at 8:14 AM, Andy Mabbett wrote: > >>> They only grab the image alt text if the >>> microformat class is on the image itself. Here's a different example: >>> >>>

Kaply Mike Kaply On 7/9/07, Andy Mabbett wrote: > On Mon, July 9, 2007 13:37, Mike Kaply wrote: > > On 7/8/07, Andy Mabbett wrote: > > > >> In message <46914B85.4040903@digitalbazaar.com>, Manu Sporny > >> writes > > > >>> if we have this: > > >>> Download: > >>> > >>>

> >>> > > >>> How do we present this option to a human being in a non-web-page UI? > > >> The HTML is invalid, lacking the alt attribute which should fix this > >> problem. > > > Actually the alt attribute WON'T fix this problem. Because the > > microformat attribute is on the anchor tag, not the image. Microformats > > grab the text in the tag. They only grab the image alt text if the > > microformat class is on the image itself. Here's a different example: > > > >

> alt="Mike Kaply"> > > > > I realize this is a little contrived, but you get the idea. > > > In this case, the fn is empty. > > My argument is that the fn should /not/ be empty; the "alt" attribute > contains the text equivalent of the image. To discount it as you suggest > is to ignore the semantics of the mark-up presented to you. > > -- > Andy Mabbett > ** via webmail ** > > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new > From andy at pigsonthewing.org.uk Mon Jul 9 13:51:37 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Mon Jul 9 13:53:18 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> Message-ID: In message , Mike Kaply writes >OK, let's try a different example: > >Michael src="foo.jpg" alt="Aaron"> Kaply Under what circumstances would "Aaron" be appropriate alt text? What would the picture show? -- Andy Mabbett From chris at placenamehere.com Mon Jul 9 16:41:58 2007 From: chris at placenamehere.com (Chris Casciano) Date: Mon Jul 9 16:42:15 2007 Subject: [uf-new] hAudio implemented on Bitmunk (with one snag) In-Reply-To: References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> Message-ID: On Jul 9, 2007, at 4:51 PM, Andy Mabbett wrote: > In message > , Mike > Kaply writes > >> OK, let's try a different example: >> >> Michael > src="foo.jpg" alt="Aaron"> Kaply > > Under what circumstances would "Aaron" be appropriate alt text? > What would the picture show? how about some stylized first letter if styling a whole name doesn't float your boat

ichael Aaron Kaply [i hope this doesn't start turning into a discussion of image replacement methods] Another case I've run across has been one of listing of vendors or associates, some with logos some without...

Company B

So the question becomes are the above two items functionally equivalent or are they not? And if they are functionally different does that mean that my CMS or authoring tool or other templating logic need to be smart enough to move the classes around to different elements depending on the data provided for the entry? -- [ Chris Casciano ] [ chris@placenamehere.com ] [ http://placenamehere.com ] From msporny at digitalbazaar.com Mon Jul 9 19:06:46 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Jul 9 19:06:49 2007 Subject: [uf-new] img alt content In-Reply-To: <46925782.3010006@pallas.us> References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> <46925782.3010006@pallas.us> Message-ID: <4692E9B6.9020905@digitalbazaar.com> Derrick Lyndon Pallas wrote: > Actually, I can probably be of help here, having written the Alexa Image > Search indexer. While I can't divulge too much about what goes into > building the index, I'll see if I can find some time to take a look at > the usage of img/@alt inside hcard/fn some time this week. Is there > anything specific anyone would like me to look for? ~D Derrick, thanks for offering to help. It would be a great help if you could give us the stats on the following: How often is ONLY an image used as the target of a link in hAtom/hReview/hCard/hCalendar? In other words, how often does this happen:

How often is 'alt' defined for those images? How often is 'title' defined for those images? Does the alt/title usually match what the image is depicting? -- manu From msporny at digitalbazaar.com Mon Jul 9 19:30:38 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Jul 9 19:30:41 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> Message-ID: <4692EF4E.60709@digitalbazaar.com> Andy Mabbett wrote: > My argument is that the fn should /not/ be empty; the "alt" attribute > contains the text equivalent of the image. To discount it as you suggest > is to ignore the semantics of the mark-up presented to you. I believe Andy and Scott are referring to Section 13.2 of the HTML 4.01 specification: http://www.w3.org/TR/html4/struct/objects.html#h-13.2 alt %Text; #REQUIRED -- short description -- and Section 13.8 of the HTML 4.01 specification: http://www.w3.org/TR/html4/struct/objects.html#h-13.8 Specifically, the sections that state the following concerning alternate text for images: * Do not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead. * Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output. I think Andy and Scott have the correct approach to this problem. All one must do is view the following in a text-based browser, such as Lynx... or in Firefox/Opera/etc and the answer becomes much clearer: Test of link with image with alt text Here's a link with an image with alt test: Microformat

It! The text that is displayed as a link in Lynx is : "Microformat It!" The text that is displayed as a link in Firefox is: "Microformat It!" Mike, would it be possible to write a parseTagTextFromImages() function that would extract the 'alt' text from images? Therefore, running it over the following HTML: Michael

Kaply Would yield the text "Michael Kaply" for 'fn'. Using this approach would also solve the hAudio problem as well as the problems that have been raised thus far in this thread. -- manu From tantek at cs.stanford.edu Mon Jul 9 19:40:52 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jul 9 19:40:52 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <4692EF4E.60709@digitalbazaar.com> Message-ID: On 7/9/07 7:30 PM, "Manu Sporny" wrote: > Mike, would it be possible to write a parseTagTextFromImages() function > that would extract the 'alt' text from images? Therefore, running it > over the following HTML: > > > Michael

Kaply > > > Would yield the text "Michael Kaply" for 'fn'. Using this approach would > also solve the hAudio problem as well as the problems that have been > raised thus far in this thread. This would be non-compliant with hCard parsing and thus should be AVOIDED. http://microformats.org/wiki/hcard-parsing See the recent FAQ for more details. http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up Thanks, Tantek From msporny at digitalbazaar.com Mon Jul 9 19:51:10 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Mon Jul 9 19:51:15 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: References: Message-ID: <4692F41E.2010503@digitalbazaar.com> Tantek ?elik wrote: > This was deliberately rejected at the creation of hCard to give publishers > more control. > > All too often there is "garbage" (or just extra unwanted text) in alt > attributes for a variety of publisher reasons. Doesn't doing this go against the HTML 4.01 specification? You aren't supposed to have anything in the 'alt' attribute of the image tag that isn't pertinent: http://www.w3.org/TR/html4/struct/objects.html#h-13.8 > I've added this to the hCard FAQ as well: > > http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up The above link states: "In addition all too often there is "garbage" (or just extra unwanted text) in alt attributes for a variety of publisher reasons, and that extraneous text would pollute otherwise clean property values in numerous existing sites." I couldn't find a reference to the analysis that lead to this conclusion? What constitutes "garbage"? What reasons would a publisher have to do this? If they're doing this, aren't they quite blatantly violating the HTML 4.01 and XHTML 1.0 specification? The link stated above also says: "Finally, it is simpler and more predictable for publishers if they know that for images and other such URL related elements (a, object, etc.) that whether they are specifying a URL property (like "email", "photo", "url", etc.) or a text property (like "fn", "nickname", etc.) in either case directly specifying the property on the element is the way to do it." If we were to adopt this approach, I don't see how we could ever get the following chunk of HTML working for hAudio:

Sample, as defined by hAudio is: rel-sample. optional. sample file/stream using rel-design-pattern with 'sample' as the mf-rel-value. Rel-patterns are only available on links... thus the "move the URL property such that it is specified directly" approach doesn't work for any Microformat that uses the rel-design-pattern. -- manu From tantek at cs.stanford.edu Mon Jul 9 20:11:11 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Mon Jul 9 20:11:11 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <4692F41E.2010503@digitalbazaar.com> Message-ID: On 7/9/07 7:51 PM, "Manu Sporny" wrote: > Tantek ?elik wrote: >> This was deliberately rejected at the creation of hCard to give publishers >> more control. >> >> All too often there is "garbage" (or just extra unwanted text) in alt >> attributes for a variety of publisher reasons. > > Doesn't doing this go against the HTML 4.01 specification? You aren't > supposed to have anything in the 'alt' attribute of the image tag that > isn't pertinent: > > http://www.w3.org/TR/html4/struct/objects.html#h-13.8 Many publishers go against many aspects of the HTML 4.01 specification yes, not in the least by publishing invalid content. >> I've added this to the hCard FAQ as well: >> >> http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up > > The above link states: > > "In addition all too often there is "garbage" (or just extra unwanted > text) in alt attributes for a variety of publisher reasons, and that > extraneous text would pollute otherwise clean property values in > numerous existing sites." > > I couldn't find a reference to the analysis that lead to this > conclusion? We didn't capture it at the time unfortunately, and we're being more thorough now. We did actually try it the other way first (including all nested "alternative" content) and found it worked worse across a variety of existing real world sites, not just 1-2 examples but LOTS. > What constitutes "garbage"? In this case things like duplicated text, text for chrome/UI etc. > What reasons would a publisher > have to do this? If they're doing this, aren't they quite blatantly > violating the HTML 4.01 and XHTML 1.0 specification? Not necessarily. > The link stated above also says: > > "Finally, it is simpler and more predictable for publishers if they know > that for images and other such URL related elements (a, object, etc.) > that whether they are specifying a URL property (like "email", "photo", > "url", etc.) or a text property (like "fn", "nickname", etc.) in either > case directly specifying the property on the element is the way to do it." > > If we were to adopt this approach, I don't see how we could ever get the > following chunk of HTML working for hAudio: > > >

> > > Sample, as defined by hAudio is: > > rel-sample. optional. sample file/stream using rel-design-pattern with > 'sample' as the mf-rel-value. > > Rel-patterns are only available on links... thus the "move the URL > property such that it is specified directly" approach doesn't work for > any Microformat that uses the rel-design-pattern. rel does not apply to therefore this is not a problem. Tantek From scott at makedatamakesense.com Mon Jul 9 20:26:39 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Mon Jul 9 20:26:51 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <4692EF4E.60709@digitalbazaar.com> References: <46914B85.4040903@digitalbazaar.com> <18788.80.86.36.97.1183990452.squirrel@www.gradwell.com> <4692EF4E.60709@digitalbazaar.com> Message-ID: On Jul 9, 2007, at 8:30 PM, Manu Sporny wrote: > I think Andy and Scott have the correct approach to this problem. All > one must do is view the following in a text-based browser, such as > Lynx... or in Firefox/Opera/etc and the answer becomes much clearer: Um, that's not really my approach to this problem at all. I suggested more research was required before making any changes, not more hypothetical markup to support a predetermined conclusion. And I suggested more research because I suspect that "red ball" section was included in the HTML spec specifically as a result of many publishers using such alt values, which aren't really content. I prefer to follow the semantics defined in the spec, but I do not think we should do that with complete disregard to how people actually use HTML. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Tue Jul 10 00:10:43 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Jul 10 00:11:58 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: References: <4692EF4E.60709@digitalbazaar.com> Message-ID: In message , Tantek ?elik writes >On 7/9/07 7:30 PM, "Manu Sporny" wrote: > >> Mike, would it be possible to write a parseTagTextFromImages() function >> that would extract the 'alt' text from images? Therefore, running it >> over the following HTML: >> >> >> Michael

Kaply >> >> >> Would yield the text "Michael Kaply" for 'fn'. Using this approach would >> also solve the hAudio problem as well as the problems that have been >> raised thus far in this thread. > >This would be non-compliant with hCard parsing and thus should be >AVOIDED. > > http://microformats.org/wiki/hcard-parsing In other words, the microformat parsing rules are non-compliant with the HTML specification. I think that's something which should be fixed. -- Andy Mabbett From andy at pigsonthewing.org.uk Tue Jul 10 13:16:09 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue Jul 10 13:17:44 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: References: <4692F41E.2010503@digitalbazaar.com> Message-ID: In message , Tantek ?elik writes >On 7/9/07 7:51 PM, "Manu Sporny" wrote: > >> Tantek ?elik wrote: >>> This was deliberately rejected at the creation of hCard to give publishers >>> more control. >>> >>> All too often there is "garbage" (or just extra unwanted text) in alt >>> attributes for a variety of publisher reasons. >> >> Doesn't doing this go against the HTML 4.01 specification? You aren't >> supposed to have anything in the 'alt' attribute of the image tag that >> isn't pertinent: >> >> http://www.w3.org/TR/html4/struct/objects.html#h-13.8 > >Many publishers go against many aspects of the HTML 4.01 specification >yes, not in the least by publishing invalid content. Is the best way to encourage "POSH" to adhere to standards, or to pander to those who break them? >>> I've added this to the hCard FAQ as well: >>> >>> http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up >> >> The above link states: >> >> "In addition all too often there is "garbage" (or just extra unwanted >> text) in alt attributes for a variety of publisher reasons, and that >> extraneous text would pollute otherwise clean property values in >> numerous existing sites." >> >> I couldn't find a reference to the analysis that lead to this >> conclusion? > >We didn't capture it at the time unfortunately, and we're being more >thorough now. We did actually try it the other way first (including >all nested "alternative" content) and found it worked worse across a >variety of existing real world sites, not just 1-2 examples but LOTS. It is indeed unfortunate that such evidence hasn't been captured; especially given your strong advocacy of evidence-based working and a "scientific" process. Someone cynical might think it hypocritical of you to then assert something without providing evidence for it. Perhaps it would be a good idea if you could provide at least a minimum amount of such evidence; preferably with URLs; per: Use real world examples People often invent completely fictitious (and theoretical) examples in order to try to make a point they are trying to make. Microformats themselves are based on studying real world examples and designing for real world examples. Thus arguments based on theoretical examples hold much less weight in microformats discussions and are apt to be ignored. Please avoid posting arguments / questions based solely on theoretical examples. Ask for real world examples If someone discusses or provides arguments based on theoretical examples, ask them to provide a real world example and point them to the above guideline. Use URLs to examples Please provide URLs to real world examples when possible. This helps to validate that such examples truly are "real world" as they are on the public Web, and provides additional context around the example which might be crucial to understanding it or answering questions about it. Ask for URLs to examples When people do not provide a specific URL to a test case or example, then especially as a developer, PLEASE ask them to provide a specific URL (and cite the previous guideline) rather than attempting to work out how an inline snippet of code might work. (which I believe you wrote) to forestall such criticism? >> What constitutes "garbage"? > >In this case things like duplicated text, text for chrome/UI etc. > >> What reasons would a publisher >> have to do this? If they're doing this, aren't they quite blatantly >> violating the HTML 4.01 and XHTML 1.0 specification? > >Not necessarily. Can you give a real world example of someone publishing such "garbage" alt text, pertinent to microformats (and again with URLs as above), which does not violate the HTML specs, please? -- Andy Mabbett From paul_wilkins at xtra.co.nz Tue Jul 10 14:52:26 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue Jul 10 14:52:35 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with onesnag)) References: <4692F41E.2010503@digitalbazaar.com> Message-ID: <003501c7c33c$9b2e10d0$bc08a8c0@nzto22> From: "Andy Mabbett" >>> What reasons would a publisher >>> have to do this? [garbage in alt attributes] >>> If they're doing this, aren't they quite blatantly >>> violating the HTML 4.01 and XHTML 1.0 specification? >> >>Not necessarily. > > Can you give a real world example of someone publishing such "garbage" > alt text, pertinent to microformats (and again with URLs as above), > which does not violate the HTML specs, please? I can. Our website uses feature pages for our cleints to help improve their visibility to the general public through search engines. One of the ways of doing this is to load the page with specific keywords and phrases for our clients. Images for example would have "Copyright CityLife Auckland. Suite at our Auckland hotel accommodation" A google search for "auckland hotel accommodation" results in their feature page being the third result. http://www.google.co.nz/search?q=auckland+hotel+accommodation&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a In terms of the page and ensuring high visibility, this is the right thing to do, but in terms of microformats and providing the information that's required, using this alt information is the wrong thing to do. As far as my boss is concerned, microformats are a tiny blip on our radar and are not worth his time. I believe that he is wrong there, and am steadily massaging our information so that microformats can be applied as easily as possible when the time comes. However, as a business we have a commitment to our clients to provide them the best results that we can. When the time comes, microformats will need to take such issues into account before we apply them, because they must not reduce the effectiveness of our results. Our alt tags will contain whatever they must to maintain their high search engine placements and anything that interferes with that will get fallen by the wayside. -- Paul Wilkins From scott at makedatamakesense.com Tue Jul 10 15:10:14 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Tue Jul 10 15:10:29 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: References: <4692F41E.2010503@digitalbazaar.com> Message-ID: <531BF2FB-496D-4999-B0D0-2F56471684C6@makedatamakesense.com> On Jul 10, 2007, at 2:16 PM, Andy Mabbett wrote: >> Many publishers go against many aspects of the HTML 4.01 >> specification >> yes, not in the least by publishing invalid content. > > Is the best way to encourage "POSH" to adhere to standards, or to > pander > to those who break them? If we had more control of web publishing, I would support pushing complete adherence to HTML specs. But we don't, so we have to balance de jure standards with de facto standards. We treat all alt values as content at the risk of discouraging publishers who use alt values for non-content from using microformats. Whether or not that's a worthwhile trade-off depends on how many publishers we're talking about. > Perhaps it > would be a good idea if you could provide at least a minimum amount of > such evidence; preferably with URLs Indeed, we should collect more examples of how alt is used in practice, because that's a very important factor in deciding how we should treat them. But if we're just collecting such examples with an eye toward supporting pre-determined conclusions, there's really no point. > Can you give a real world example of someone publishing such "garbage" > alt text, pertinent to microformats (and again with URLs as above), > which does not violate the HTML specs, please? While the HTML specs are a very important consideration, they are not the only consideration. While encouraging adherence to HTML, we need to recognize that such adherence is quite rare in practice. How many of us even have perfectly valid websites? Complete adherence to HTML is simply not a practical criteria to apply without concession on today's web. We should push it where we can and choose those battles carefully. -- Scott Reynen MakeDataMakeSense.com From andy at pigsonthewing.org.uk Wed Jul 11 01:07:26 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Jul 11 01:09:00 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with onesnag)) In-Reply-To: <003501c7c33c$9b2e10d0$bc08a8c0@nzto22> References: <4692F41E.2010503@digitalbazaar.com> <003501c7c33c$9b2e10d0$bc08a8c0@nzto22> Message-ID: In message <003501c7c33c$9b2e10d0$bc08a8c0@nzto22>, Paul Wilkins writes >> Can you give a real world example of someone publishing such "garbage" >> alt text, pertinent to microformats (and again with URLs as above), >> which does not violate the HTML specs, please? > >I can. > >Our website uses feature pages for our cleints to help improve their >visibility to the general public through search engines. One of the >ways of doing this is to load the page with specific keywords and >phrases for our clients. > >Images for example would have "Copyright CityLife Auckland. Suite at >our Auckland hotel accommodation" Unless that's the graphical content of the image, which seems unlikely, that's an abuse of the alt attribute; such text should be in the title attribute. It *does* violate the HTML specs. And how is it "pertinent to microformats"? >as a business we have a commitment to our clients to provide them the >best results that we can. What about their responsibility to their customers, some of whom will have a visual disability? -- Andy Mabbett From andy at pigsonthewing.org.uk Wed Jul 11 01:12:56 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed Jul 11 01:17:06 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag)) In-Reply-To: <531BF2FB-496D-4999-B0D0-2F56471684C6@makedatamakesense.com> References: <4692F41E.2010503@digitalbazaar.com> <531BF2FB-496D-4999-B0D0-2F56471684C6@makedatamakesense.com> Message-ID: In message <531BF2FB-496D-4999-B0D0-2F56471684C6@makedatamakesense.com>, Scott Reynen writes >> Can you give a real world example of someone publishing such "garbage" >> alt text, pertinent to microformats (and again with URLs as above), >> which does not violate the HTML specs, please? > >While the HTML specs are a very important consideration, they are not >the only consideration. While encouraging adherence to HTML, we need >to recognize that such adherence is quite rare in practice. How many >of us even have perfectly valid websites? Complete adherence to HTML >is simply not a practical criteria to apply without concession on >today's web. We should push it where we can and choose those battles >carefully. If that's true - which I dispute - then who's going to re-write: The first rule of POSH is that you must validate your POSH. accordingly? -- Andy Mabbett From msporny at digitalbazaar.com Wed Jul 11 07:15:10 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed Jul 11 07:15:14 2007 Subject: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with onesnag)) In-Reply-To: References: <4692F41E.2010503@digitalbazaar.com> <003501c7c33c$9b2e10d0$bc08a8c0@nzto22> Message-ID: <4694E5EE.2060902@digitalbazaar.com> Andy Mabbett wrote: >> Images for example would have "Copyright CityLife Auckland. Suite at >> our Auckland hotel accommodation" > Unless that's the graphical content of the image, which seems > unlikely, that's an abuse of the alt attribute; such text should be in > the title attribute. It *does* violate the HTML specs. And how is it > "pertinent to microformats"? There seems to be two parts to this discussion: 1. HTML specification violation (alt tag mis-use) 2. How the alt attribute is being used in the real-world Andy's line of reasoning is sound regarding the HTML specification violation. I don't think that anybody can state that placing text that does not match the graphical content of an image tag goes against the HTML specification. The second part is how the alt attribute is being used in the real-world. Tantek has asserted that 'alt' is being mis-used on a wide scale on the Interwebs. As Scott has pointed out, the only way to know this is to start gathering real data. I am in the process of writing an image crawler (which will hopefully be done by tonight) to gather these statistics. The crawler will crawl the web for image tags and gather statistics regarding: - How many image tags have 'alt' tags specified. - How many image tags have 'title' tags specified. - How many image tags have both specified. - Whether or not the 'alt' tag matches the image being display (I'll setup a website for all of us to help in analyzing this data) I'm assuming 125,626,329,000 unique images on the web (125,626,329 unique sites on the web - 1000 unique images per site). Statistically, I think we would only need around 385 unique site samples to get a 95% confidence interval with a 5% error rate (somebody correct me if this is wrong). To be safe, I'll collect 100,000 unique image tags , 1 per site to get our initial sample set. Any objections to this method of data collection? -- manu From scott at makedatamakesense.com Wed Jul 11 07:49:25 2007 From: scott at makedatamakesense.com (Scott Reynen) Date: Wed Jul 11 07:49:42 2007 Subject: [uf-new] img alt content In-Reply-To: References: <4692F41E.2010503@digitalbazaar.com> <531BF2FB-496D-4999-B0D0-2F56471684C6@makedatamakesense.com> Message-ID: On Jul 11, 2007, at 2:12 AM, Andy Mabbett wrote: >> Complete adherence to HTML >> is simply not a practical criteria to apply without concession on >> today's web. > > If that's true - which I dispute - then who's going to re-write: > > > > The first rule of POSH is that you must validate your POSH. > > accordingly? Validation and adherence to the HTML spec are not exactly the same thing. All spec-adherent websites are valid, but not all valid sites are spec-adherent. So full adherence to the spec is more work to ask of publishers than simple validation. Ironically, I think the HTML validator actually encourages poor use of the alt attribute because it returns an error on missing alt attributes, but doesn't make any mention that alt should be empty for non-content images. So publishers who leave out alt on non-content images see this error and end up adding alt attributes with exactly the kind of "red ball" values the HTML spec discourages. I completely agree such publishers should be encouraged to stop doing this; I just doubt whether such encouragement should come from the microformats community. I see our goal as a bit more specific than general encouragement of better HTML: making better HTML publishing more appealing by establishing practical benefits. And I think the best way to do this is to focus on areas where better HTML results in maximum practical benefits with minimum cost to publishers. In this case specifically, I suspect the best way to accomplish that goal would not be to encourage everyone publishing non-content alt attributes to change, but rather to encourage everyone publishing content in alt attributes to insert such content as more accessible text, and use style sheets to apply more stylized images, which I think is what Ben was suggesting (see [1]). This solution, I think, makes better HTML more useful without making microformats any more difficult to publish for those who aren't up to spec. [1] http://www.stopdesign.com/articles/replace_text/ -- Scott Reynen MakeDataMakeSense.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://microformats.org/discuss/mail/microformats-new/attachments/20070711/b8948dcf/attachment.html From paul_wilkins at xtra.co.nz Wed Jul 11 17:05:59 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed Jul 11 17:06:02 2007 Subject: Fw: [uf-new] img alt content (was:hAudio implemented on Bitmunk (with onesnag)) Message-ID: <001801c7c418$6d636c40$bc08a8c0@nzto22> From: "Andy Mabbett" >>> What reasons would a publisher >>> have to do this? [garbage in alt attributes] >>> If they're doing this, aren't they quite blatantly >>> violating the HTML 4.01 and XHTML 1.0 specification? >> >>Not necessarily. > > Can you give a real world example of someone publishing such "garbage" > alt text, pertinent to microformats (and again with URLs as above), > which does not violate the HTML specs, please? I can. Our website uses feature pages for our cleints to help improve their visibility to the general public through search engines. One of the ways of doing this is to load the page with specific keywords and phrases for our clients. Images for example would have "Copyright CityLife Auckland. Suite at our Auckland hotel accommodation" A google search for "auckland hotel accommodation" results in their feature page being the third result. http://www.google.co.nz/search?q=auckland+hotel+accommodation&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a In terms of the page and ensuring high visibility, this is the right thing to do, but in terms of microformats and providing the information that's required, using this alt information is the wrong thing to do. As far as my boss is concerned, microformats are a tiny blip on our radar and are not worth his time. I believe that he is wrong there, and am steadily massaging our information so that microformats can be applied as easily as possible when the time comes. However, as a business we have a commitment to our clients to provide them the best results that we can. When the time comes, microformats will need to take such issues into account before we apply them, because they must not reduce the effectiveness of our results. Our alt tags will contain whatever they must to maintain their high search engine placements and anything that interferes with that will get fallen by the wayside. -- Paul Wilkins From regine at regine-heidorn.de Thu Jul 12 04:50:01 2007 From: regine at regine-heidorn.de (Regine Heidorn) Date: Thu Jul 12 04:47:57 2007 Subject: [uf-new] MicroFormats for (Music-)TopLists, htop-list? Message-ID: <946BF4B8-E31D-48D3-9A73-CD4E4EBFC89C@regine-heidorn.de> Hi All, first let me introduce myself: I'm a 35-year-old Webdeveloper living in Berlin, Germany. I care a lot about semantic stuff and CSS, so I feel kind of addicted to that MicroFormat-Thing. I didn't use it a lot up to now though, but there is an idea I would like to materialize. In the last months I cared a lot about Open Music, Music published under cc-licence and netlabels offering that stuff. Since I'm running a blog I got the idea of creating a top-5- list of the tracks I like best from the different labels. To make the thing more communicating I thought it funny to give the netlabels the opportunity to grab my top-lists including the resulting ratings. If more bloggers or community-sites feel like doing this, the labels could establish something like the blogosphere-web2.0-community- BillBoards. So I contacted one of the netlabels, they're quite interested in this idea, so I thought of how to form this idea in the most simple and effective way and stumbled across the microformat-thing. I looked around the blog and the wiki to find out if something would match my idea and what I can see for the moment is the vision of a top-list microformat (for audio), including the haudio-Format and the hreview- format to form something like this:

rechazamos el ahora Christian Dittmann emporio thinner thn 092 cc-by-nc-nd

My thoughts up to this point are: - Did I use the microformats right, did I get the idea properly? - Since it's a top-list the use of

? - How can the rating be included? Does it make sense to work with hreview here? - A top-list can be seen as a review, might it be better to straighten the whole thing out to the hreview thing? So it could also be used for top-lists not regarding audio-tracks. But it also seems logical to use haudio if it's audio-material. So especially for audio- top-lists would it be OK to make that clear by the use of

? - If a top-list is also a review: should it be extended by the hreview-possibilities? Like for example if I write a review about a track like maybe on my blog or somewhere else, it would be semantically interesting to paste this information together with my top-list. Second is: how can those informations be collected by let's say the netlabels? As to now I have the idea of a php-script writing the data in a database and thus creating the netlabel-toplist consisting of the data from participating Blogs, community-sites and whatever. Lots of thoughts, hope one can follow at least ;-) Greez, Regine Heidorn From hkraft at gmail.com Fri Jul 13 02:46:05 2007 From: hkraft at gmail.com (Henrik Kraft) Date: Fri Jul 13 02:46:09 2007 Subject: [uf-new] Microformat for article/document? Message-ID: <68005cb10707130246tfc2929di22fc429950244ea8@mail.gmail.com> Hello Ive been looking but cant seem to find a mf for a document. I think it should contain something like,

Header

Text

Bodytext

Does this makes sense to anyone else or have I misunderstood what the mf should do? /Henrik From davidjanes at blogmatrix.com Fri Jul 13 03:14:19 2007 From: davidjanes at blogmatrix.com (David Janes) Date: Fri Jul 13 03:14:23 2007 Subject: [uf-new] Microformat for article/document? In-Reply-To: <68005cb10707130246tfc2929di22fc429950244ea8@mail.gmail.com> References: <68005cb10707130246tfc2929di22fc429950244ea8@mail.gmail.com> Message-ID: <21e523c20707130314h749c8b19ue782598eb98da9a9@mail.gmail.com> On 7/13/07, Henrik Kraft wrote: > Ive been looking but cant seem to find a mf for a document. > > I think it should contain something like, > >

Header >

Text

Bodytext

H1 and P are pretty good in and of themselves. Another level of granularity can be provided by hAtom, using respectively hentry, entry-title, summary & content. -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://blogmatrix.blogmatrix.com From supercanadian at gmail.com Fri Jul 13 13:42:27 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Fri Jul 13 13:42:32 2007 Subject: [uf-new] Microformat for article/document? In-Reply-To: <68005cb10707130246tfc2929di22fc429950244ea8@mail.gmail.com> References: <68005cb10707130246tfc2929di22fc429950244ea8@mail.gmail.com> Message-ID: <84ce626f0707131342q1e8068fbn270db513b9fc5cbf@mail.gmail.com> Hello Henrik, On 7/13/07, Henrik Kraft wrote: > Hello > Ive been looking but cant seem to find a mf for a document. > > I think it should contain something like, > >

Header >

Text

Bodytext