Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Charles Iliya Krempeaux wrote:


On 5/27/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:


[snip]


I don't think this is a very natural use of the q element. A
thumbnail isn't really like a quote of a prose fragment. Consider
that you would never put a thumbnail in quotation marks.


True... but you don't have to have the q elements put quotes around
the thumbnail.

Please refer to the following to see how to get rid of it...

http://microformats.org/discuss/mail/microformats-discuss/2007-May/009703.html 



This is similar to the problem we have with using abbr for dates.

Some browsers put a border under the abbr element.

We get rid of the bottom border some browser put under the abbr
element (when we use it for dates) with a little extra inline style.

We can do something similar here for the q element used for video 
thumbnails.


Hmm. I think Maciej does have a strong point about interoperability 
here. Removing the quotation punctuation with CSS does not help those 
with user-designated styles or UAs that ignore such CSS: e.g. text 
browsers and screen readers. The question to ask yourself is: if you 
could not remove the quotation punctuation and layout, would you still 
use q and blockquote? If a screen reader read (for example):


quote Dorothy encounters the Lion end quote

That would be rather strange, wouldn't it? As you say above, it is 
True that you would never put a thumbnail in quotation marks. This 
suggests that we should not be using q or blockquote for this.


Maybe it would be better to use something along the lines of:

span class=video-detailsimg class=thumbnail alt=Dorothy 
encounters the Lion src=http://example.com/thumbnail.jpg;citea 
href=http://example.com/thevideo; type=video/quicktimeThe Wizard of 
Ozz/a/cite/span



If you want the full video to be clickable, what you might want is:

a rev=thumbnail href=http://example.com/video;
   img src=http://example.com/thumbnail.jpg;
/a


I'm not sure if the rev attribute is being used correctly in your markup.


Yeah, the HTML4 spec says the rev and rel imply relationships between 
the current document and the href, not the anchor's contents and the href.


http://www.w3.org/TR/html401/struct/links.html#adef-rev

--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Colin Barrett


On May 28, 2007, at 1:49 AM, Benjamin Hawkes-Lewis wrote:

Hmm. I think Maciej does have a strong point about interoperability  
here. Removing the quotation punctuation with CSS does not help  
those with user-designated styles or UAs that ignore such CSS: e.g.  
text browsers and screen readers. The question to ask yourself is:  
if you could not remove the quotation punctuation and layout, would  
you still use q and blockquote? If a screen reader read (for  
example):


quote Dorothy encounters the Lion end quote

That would be rather strange, wouldn't it?


I dunno, I think that might be helpful. It's semantic information that  
it's a portion of a larger document. Using a span tag as you suggest  
provides the UA with zero semantic information. I suspect having alt  
tags that just link to a video which perhaps they don't want to watch  
is annoying to people with screen readers -- although I think I would  
need a bit more data about how screen readers work and how they're  
used to really say anything else.


-Colin
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Keith Alexander

Benjamin Hawkes-Lewis wrote:


Yeah, the HTML4 spec says the rev and rel imply relationships between 
the current document and the href, not the anchor's contents and the 
href.


http://www.w3.org/TR/html401/struct/links.html#adef-rev


I think eRDF's approach is worth noting here - when translated into 
RDF,  rel and rev links relate the current *document* *fragment* to the 
*href.*


It's not quite what the spec says, but I think it's sensible: after all, 
the href can point to a document fragment, so the  rel/rev should also 
be able to relate  to  the current document fragment as well.



Keith



[1] http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml - the 
canonical description of eRDF


[2] http://getsemantic.com/wiki/ERDF - a wiki page about eRDF

--
Keith Alexander
http://semwebdev.keithalexander.co.uk/blog/

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Maciej Stachowiak


On May 27, 2007, at 6:55 PM, Paul Wilkins wrote:


http://www.w3.org/TR/html401/struct/links.html#h-12.1.2

My simplified understanding of the relationship between rel and rev is

With the rel attribute, the relationship that the linked page has  
to this link is foo.
With the rev attribute, the relationship that this link has from  
the linked page is foo.


Actually, I think that's exactly backwards. But that's part of the  
reason rev is so confusing.


Use previous or next as the link values and you'll understand  
what's going on.


link rel=next should point to the logically next document, so  
the linked resource's relationship to the current resource is that it  
is next.


What you describe below seems to reflect the same understanding  
though, so maybe we just disagree on the wording.




From: Patrick H. Lauke [EMAIL PROTECTED]

Charles Iliya Krempeaux wrote:


a rev=thumbnail href=http://example.com/video;
   img src=http://example.com/thumbnail.jpg;
/a


I'm not sure if the rev attribute is being used correctly in  
your markup.


Rev defines the reverse link to the current document, not to  
whatever is encapsulated by the link itself...unless I'm reading  
the spec wrong
This attribute describes the relationship from the current  
document to the anchor specified by the href attribute

http://www.w3.org/TR/html401/struct/links.html#edef-A


A rel link from the video page to the thumbnail would be thumbnail.
So, a rev link on the thumbnail to the video page would also be  
thumbnail.


I've got no problem with using rel and rev values myself, but if  
you're going to use a a custom link-type that's not actually  
defined in http://www.w3.org/TR/html401/types.html#type-links then  
you should use a profile to define what's going on.



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Colin Barrett wrote:


On May 28, 2007, at 1:49 AM, Benjamin Hawkes-Lewis wrote:


[snip]


 If a screen reader read (for example):

quote Dorothy encounters the Lion end quote

That would be rather strange, wouldn't it?


I dunno, I think that might be helpful. It's semantic information that 
it's a portion of a larger document.


This is a tempting argument, but in theory and practice a problematic 
one. q and blockquote are not merely intended to be portions of a 
larger document but to be /quotations/:


http://www.w3.org/TR/html401/struct/text.html#h-9.2.2

I'm not sure that a thumbnail really is a quotation, although it's 
clearly conceptually close to one. When people talk of quotations from 
movies in everyday speech, they are talking about quotations from the 
dialogue not stills, e.g.:


http://www.imdb.com/title/tt0032138/quotes

I don't think quote Dorothy encounters the Lion end quote would be a 
human readable hint that it's a thumbnail from a video. Unless you 
happen to be a microformats guru. ;)



Using a span tag as you suggest provides the UA with zero semantic information.


I'd prefer to provide zero information than potentially misleading 
information. I suppose one could prefix the alt with still: though:


alt=still: Dorothy encounters the Lion

So then you might hear:

graphic still Dorothy encounters the Lion link The Wizard of Oz

A microformat parser could remove everything up to and including the 
first colon to get to the alternative text proper.


I suspect having alt 
tags that just link to a video which perhaps they don't want to watch is 
annoying to people with screen readers -- although I think I would need 
a bit more data about how screen readers work and how they're used to 
really say anything else.


I believe your suspicion is wrong for three reasons:

1. Most screen reader users are not deaf as well as blind, and many 
screen readers still have some sight. So most screen reader users are as 
likely to enjoy watching videos online as you and I. Their big problem 
with sites like YouTube is that it's too hard to /find/ videos, not to 
watch them:


http://www.bbc.co.uk/blogs/access20/2007/05/access_20_interview_mark_prous.shtml

2. Most video formats, include Flash video and Quicktime, can include 
captioning which mainstream screen readers can push to a braille display 
for deafblind users. Videos /should/ include captioning and authors 
should make it clear when they do not: and ideally provide a transcript 
as an alternative. There are now captioning websites that either make it 
easy to add captions to online video or will even caption it for you for 
free on request:


http://www.bbc.co.uk/blogs/access20/2007/05/captioning_video_gets_easier.shtml

3. Even if a video is completely inaccessible for some reason, screen 
reader users may use the alternative text to understand why the author 
is referring to that video, to share the video or thumbnail with sighted 
friends or colleagues, or to demand an accessible alternative. Just 
hiding inaccessible materials would produce confusion.


On an even more basic technical level: leaving out alt would result in 
some screen readers reading the image src attribute. Leaving alt blank 
would result in some screen readers reading the href for any surrounding 
anchor link when alt provides the only text content for the link, e.g.:


a href=http://www.example.com/video;img alt=/a

By default, Window-Eyes would read something like:

link h t t p colon slash slash w w w dot example dot com slash video

Commonly, I think, the user will have reduced the verbosity to strip out 
most punctuation and only have to suffer:


link h t t p w w w example com video

Takeaway: include an alt for all images; and always include an alt with 
actual text if the img is the /sole/ content of the link.


--
Benjamin Hawkes-Lewis

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello Benjamin,

On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:

Charles Iliya Krempeaux wrote:

 On 5/27/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:

[snip]

 I don't think this is a very natural use of the q element. A
 thumbnail isn't really like a quote of a prose fragment. Consider
 that you would never put a thumbnail in quotation marks.

 True... but you don't have to have the q elements put quotes around
 the thumbnail.

 Please refer to the following to see how to get rid of it...

 http://microformats.org/discuss/mail/microformats-discuss/2007-May/009703.html


 This is similar to the problem we have with using abbr for dates.

 Some browsers put a border under the abbr element.

 We get rid of the bottom border some browser put under the abbr
 element (when we use it for dates) with a little extra inline style.

 We can do something similar here for the q element used for video
 thumbnails.

Hmm. I think Maciej does have a strong point about interoperability
here. Removing the quotation punctuation with CSS does not help those
with user-designated styles or UAs that ignore such CSS: e.g. text
browsers and screen readers. The question to ask yourself is: if you
could not remove the quotation punctuation and layout, would you still
use q and blockquote? If a screen reader read (for example):


A text browser can NOT see the graphical thumbnail anyways.  It will
see the alt text of the thumbnail.  And putting the alt text in
quotes seems OK with me.

(It's only the putting the graphical thumbnail in quotes that seems wrong.)

Also... a screen reader is going to read the alt text too (instead
of the graphical thumbnail).  So... in this case too, putting the
alt text in quotes seems just fine.

So... this seems to be a non-issue.


quote Dorothy encounters the Lion end quote

That would be rather strange, wouldn't it? As you say above, it is
True that you would never put a thumbnail in quotation marks. This
suggests that we should not be using q or blockquote for this.


Like I pointed out above, any situation (that you mentioned) that
keeps the quotation marks is actually fine doing it, because it will
also be seeing/reading the alt text... and NOT doing anything with
the graphical thumbnail.

So it's a non-issue.


See ya


Maybe it would be better to use something along the lines of:

span class=video-detailsimg class=thumbnail alt=Dorothy
encounters the Lion src=http://example.com/thumbnail.jpg;citea
href=http://example.com/thevideo; type=video/quicktimeThe Wizard of
Ozz/a/cite/span

 If you want the full video to be clickable, what you might want is:

 a rev=thumbnail href=http://example.com/video;
img src=http://example.com/thumbnail.jpg;
 /a

 I'm not sure if the rev attribute is being used correctly in your markup.

Yeah, the HTML4 spec says the rev and rel imply relationships between
the current document and the href, not the anchor's contents and the href.

http://www.w3.org/TR/html401/struct/links.html#adef-rev

--
Benjamin Hawkes-Lewis



--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello Benjamin,


Most screen reader users are not deaf as well as blind, and many
screen readers still have some sight. So most screen reader users are as
likely to enjoy watching videos online as you and I


Hmmm... that's a good point.  And something I wasn't aware of

Perhaps the alt text could be something like...

 alt=Thumbnail of ...

So, for example, we could have...

 alt=Thumbnail of Tirebiterz episode #12

(Where Tirebiterz is an Internet TV show.)


On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:

Colin Barrett wrote:

 On May 28, 2007, at 1:49 AM, Benjamin Hawkes-Lewis wrote:

[snip]

  If a screen reader read (for example):

 quote Dorothy encounters the Lion end quote

 That would be rather strange, wouldn't it?

 I dunno, I think that might be helpful. It's semantic information that
 it's a portion of a larger document.

This is a tempting argument, but in theory and practice a problematic
one. q and blockquote are not merely intended to be portions of a
larger document but to be /quotations/:


True... but is the abbr element designed for the way Microformats do dates?

It seems like the same problem as that isn't it.

And if we accept that screen readers can adapt to dates with the
abbr element, then why not accept that they can adapt to thumbnails
in a q element?


http://www.w3.org/TR/html401/struct/text.html#h-9.2.2

I'm not sure that a thumbnail really is a quotation, although it's
clearly conceptually close to one. When people talk of quotations from
movies in everyday speech, they are talking about quotations from the
dialogue not stills, e.g.:

http://www.imdb.com/title/tt0032138/quotes

I don't think quote Dorothy encounters the Lion end quote would be a
human readable hint that it's a thumbnail from a video. Unless you
happen to be a microformats guru. ;)


What about what I mentioned above... about using alt text like...

 alt=Thumbnail of Dorothy encountering the Lion

So that would read...

 quote Thumbnail of Dorothy encountering the Lion end quote



 Using a span tag as you suggest provides the UA with zero semantic 
information.

I'd prefer to provide zero information than potentially misleading
information. I suppose one could prefix the alt with still: though:

alt=still: Dorothy encounters the Lion

So then you might hear:

graphic still Dorothy encounters the Lion link The Wizard of Oz

A microformat parser could remove everything up to and including the
first colon to get to the alternative text proper.

 I suspect having alt
 tags that just link to a video which perhaps they don't want to watch is
 annoying to people with screen readers -- although I think I would need
 a bit more data about how screen readers work and how they're used to
 really say anything else.

I believe your suspicion is wrong for three reasons:

1. Most screen reader users are not deaf as well as blind, and many
screen readers still have some sight. So most screen reader users are as
likely to enjoy watching videos online as you and I. Their big problem
with sites like YouTube is that it's too hard to /find/ videos, not to
watch them:

http://www.bbc.co.uk/blogs/access20/2007/05/access_20_interview_mark_prous.shtml

2. Most video formats, include Flash video and Quicktime, can include
captioning which mainstream screen readers can push to a braille display
for deafblind users.


Yeah... I'm actually using a captioning sHTML in a piece of software
that hasn't been made public yet.  (Perhaps I'll describe it on this
list later... and get it reviewed.)


See ya


Videos /should/ include captioning and authors
should make it clear when they do not: and ideally provide a transcript
as an alternative. There are now captioning websites that either make it
easy to add captions to online video or will even caption it for you for
free on request:

http://www.bbc.co.uk/blogs/access20/2007/05/captioning_video_gets_easier.shtml

3. Even if a video is completely inaccessible for some reason, screen
reader users may use the alternative text to understand why the author
is referring to that video, to share the video or thumbnail with sighted
friends or colleagues, or to demand an accessible alternative. Just
hiding inaccessible materials would produce confusion.

On an even more basic technical level: leaving out alt would result in
some screen readers reading the image src attribute. Leaving alt blank
would result in some screen readers reading the href for any surrounding
anchor link when alt provides the only text content for the link, e.g.:

a href=http://www.example.com/video;img alt=/a

By default, Window-Eyes would read something like:

link h t t p colon slash slash w w w dot example dot com slash video

Commonly, I think, the user will have reduced the verbosity to strip out
most punctuation and only have to suffer:

link h t t p w w w example com video

Takeaway: include an alt for all images; and always include an alt with
actual text if the img is the /sole/ content of the link.


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Charles Iliya Krempeaux wrote:


On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:

Charles Iliya Krempeaux wrote:

 On 5/27/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:

[snip]

 I don't think this is a very natural use of the q element. A
 thumbnail isn't really like a quote of a prose fragment. Consider
 that you would never put a thumbnail in quotation marks.

 True... but you don't have to have the q elements put quotes around
 the thumbnail.


[snip]


Hmm. I think Maciej does have a strong point about interoperability
here. Removing the quotation punctuation with CSS does not help those
with user-designated styles or UAs that ignore such CSS: e.g. text
browsers and screen readers. The question to ask yourself is: if you
could not remove the quotation punctuation and layout, would you still
use q and blockquote? If a screen reader read (for example):


A text browser can NOT see the graphical thumbnail anyways.  It will
see the alt text of the thumbnail.  And putting the alt text in
quotes seems OK with me.

(It's only the putting the graphical thumbnail in quotes that seems wrong.)


Ah. Okay, I hadn't understood that's what you were saying. I think 
putting the thumbnail alternative text in quotation punctuation is 
potentially problematic unless the alternative text is actually a 
quotation from the video's dialogue.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello Benjamin,

On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:

Charles Iliya Krempeaux wrote:

 On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:
 Charles Iliya Krempeaux wrote:

  On 5/27/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:

 [snip]

  I don't think this is a very natural use of the q element. A
  thumbnail isn't really like a quote of a prose fragment. Consider
  that you would never put a thumbnail in quotation marks.
 
  True... but you don't have to have the q elements put quotes around
  the thumbnail.

[snip]

 Hmm. I think Maciej does have a strong point about interoperability
 here. Removing the quotation punctuation with CSS does not help those
 with user-designated styles or UAs that ignore such CSS: e.g. text
 browsers and screen readers. The question to ask yourself is: if you
 could not remove the quotation punctuation and layout, would you still
 use q and blockquote? If a screen reader read (for example):

 A text browser can NOT see the graphical thumbnail anyways.  It will
 see the alt text of the thumbnail.  And putting the alt text in
 quotes seems OK with me.

 (It's only the putting the graphical thumbnail in quotes that seems wrong.)

Ah. Okay, I hadn't understood that's what you were saying. I think
putting the thumbnail alternative text in quotation punctuation is
potentially problematic unless the alternative text is actually a
quotation from the video's dialogue.


What if there is no video dialogue?

What if it is a motorcycle race?

What should I put in there then?... an onomatopoeia of the motorcycles?

Something like...

   alt=e..., e..., rrrmm...

:-)

Doesn't really seem useful.


The Thumbnail of... suggestion seems better in that case.


See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Charles Iliya Krempeaux wrote:


Ah. Okay, I hadn't understood that's what you were saying. I think
putting the thumbnail alternative text in quotation punctuation is
potentially problematic unless the alternative text is actually a
quotation from the video's dialogue.


What if there is no video dialogue?


Sorry, it's my fault for being oblique but that was actually my point. 
Not all videos have dialogue and not all dialogue would make the most 
suitable thumbnail alternative text. Hence q is not generally an 
appropriate element for enclosing the thumbnail.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello Benjamin,

On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:

Charles Iliya Krempeaux wrote:

 This is a tempting argument, but in theory and practice a problematic
 one. q and blockquote are not merely intended to be portions of a
 larger document but to be /quotations/:

 True... but is the abbr element designed for the way Microformats do
 dates?

 It seems like the same problem as that isn't it.

 And if we accept that screen readers can adapt to dates with the
 abbr element, then why not accept that they can adapt to thumbnails
 in a q element?

But I /don't/ accept that. IMHO microformats currently abuse abbr and
perhaps (more debatably) title for time and location, violating the
standards-based credos of the movement with poor consequences for
assistive technology which have already been widely discussed on the
list.


Admittantly, I haven't gotten around to reading those threads yet :-(

Was there a consensus about a solution to the problem you are describing?


And even if screen readers can eventually adapt to read ISO dates
and geographical data as anything other than gibberish, their users will
lag behind the times because mainstream screen readers are prohibitively
expensive. On balance, I'd prefer innovators to depart from the HTML
specification by introducing new attributes for new parsers with a
custom DTD than to break HTML documents in existing user agents by
abusing the semantics of old elements. (Not that a custom DTD would be a
great idea either, just the lesser of two evils.)

But at least the misuse of abbr for ISO time and location was useful for
parsers, whereas this misuse (if we agree it is such) of q isn't.


I'd say I'm suggesting it be used in a way the designers of it
probably didn't imagine it would be used.  (It doesn't seem to violate
the HTML specification though.)

Having said that... there isn't a thumbnail cite=... src=...
element... so what else can we do?

I want to add semantics somehow... but don't want to make
non-validating HTML (and just make up a new element... even though I'd
like to).


 I don't think quote Dorothy encounters the Lion end quote would be a
 human readable hint that it's a thumbnail from a video. Unless you
 happen to be a microformats guru. ;)

 What about what I mentioned above... about using alt text like...

  alt=Thumbnail of Dorothy encountering the Lion

 So that would read...

  quote Thumbnail of Dorothy encountering the Lion end quote

Well that's an improvement. But in that case what's actually
communicating the semantic is Thumbnail of, not q. And quote
still confuses the issue.

Also, I think Thumbnail of will prove harder to internationalize than
Still: or Thumbnail:, which would mean parsers would struggle to get
at the alternative text proper.


The img alt attribute doesn't really seem built for i18n.

Isn't i18n usually handled with completely different versions of the
same HTML page.

Which in that case would make the i18n for the sHTML Video
Thumbnailing suggestion I made a non-issue.

(I.e., there would be different version of the alt attribute for
each language supported (in each of those pages)... and it will be a
worded in a way that makes sense.)


But yeah... having quote read out does still seem undesired.

Aren't the aural style sheet or something that can be used to get rid of that?


See ya



 Yeah... I'm actually using a captioning sHTML in a piece of software
 that hasn't been made public yet.  (Perhaps I'll describe it on this
 list later... and get it reviewed.)

Cool.

--
Benjamin Hawkes-Lewis



--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello Benjamin,

Sorry for replying to my own post, but

On 5/28/07, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote:

Hello Benjamin,

On 5/28/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote:
 Charles Iliya Krempeaux wrote:

  This is a tempting argument, but in theory and practice a problematic
  one. q and blockquote are not merely intended to be portions of a
  larger document but to be /quotations/:
 
  True... but is the abbr element designed for the way Microformats do
  dates?
 
  It seems like the same problem as that isn't it.
 
  And if we accept that screen readers can adapt to dates with the
  abbr element, then why not accept that they can adapt to thumbnails
  in a q element?

 But I /don't/ accept that. IMHO microformats currently abuse abbr and
 perhaps (more debatably) title for time and location, violating the
 standards-based credos of the movement with poor consequences for
 assistive technology which have already been widely discussed on the
 list.

Admittantly, I haven't gotten around to reading those threads yet :-(

Was there a consensus about a solution to the problem you are describing?

 And even if screen readers can eventually adapt to read ISO dates
 and geographical data as anything other than gibberish, their users will
 lag behind the times because mainstream screen readers are prohibitively
 expensive. On balance, I'd prefer innovators to depart from the HTML
 specification by introducing new attributes for new parsers with a
 custom DTD than to break HTML documents in existing user agents by
 abusing the semantics of old elements. (Not that a custom DTD would be a
 great idea either, just the lesser of two evils.)

 But at least the misuse of abbr for ISO time and location was useful for
 parsers, whereas this misuse (if we agree it is such) of q isn't.

I'd say I'm suggesting it be used in a way the designers of it
probably didn't imagine it would be used.  (It doesn't seem to violate
the HTML specification though.)

Having said that... there isn't a thumbnail cite=... src=...
element... so what else can we do?

I want to add semantics somehow... but don't want to make
non-validating HTML (and just make up a new element... even though I'd
like to).

  I don't think quote Dorothy encounters the Lion end quote would be a
  human readable hint that it's a thumbnail from a video. Unless you
  happen to be a microformats guru. ;)
 
  What about what I mentioned above... about using alt text like...
 
   alt=Thumbnail of Dorothy encountering the Lion
 
  So that would read...
 
   quote Thumbnail of Dorothy encountering the Lion end quote

 Well that's an improvement. But in that case what's actually
 communicating the semantic is Thumbnail of, not q. And quote
 still confuses the issue.

 Also, I think Thumbnail of will prove harder to internationalize than
 Still: or Thumbnail:, which would mean parsers would struggle to get
 at the alternative text proper.

The img alt attribute doesn't really seem built for i18n.

Isn't i18n usually handled with completely different versions of the
same HTML page.

Which in that case would make the i18n for the sHTML Video
Thumbnailing suggestion I made a non-issue.

(I.e., there would be different version of the alt attribute for
each language supported (in each of those pages)... and it will be a
worded in a way that makes sense.)


But yeah... having quote read out does still seem undesired.

Aren't the aural style sheet or something that can be used to get rid of that?



Shouldn't putting quotes: none none on the q element be enough to
get the screen readers to NOT say quote at the beginning and the
end?

As in...

   q style=quotes: none none;...q


See ya



See ya


  Yeah... I'm actually using a captioning sHTML in a piece of software
  that hasn't been made public yet.  (Perhaps I'll describe it on this
  list later... and get it reviewed.)

 Cool.

 --
 Benjamin Hawkes-Lewis


--
Charles Iliya Krempeaux, B.Sc.

charles @ reptile.ca
supercanadian @ gmail.com

developer weblog: http://ChangeLog.ca/




--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread James O'Donnell


On 28 May 2007, at 22:09, Charles Iliya Krempeaux wrote:




But yeah... having quote read out does still seem undesired.

Aren't the aural style sheet or something that can be used to get  
rid of that?



Shouldn't putting quotes: none none on the q element be enough to
get the screen readers to NOT say quote at the beginning and the
end?

As in...

   q style=quotes: none none;...q


I think that noone has actually implemented aural CSS in any of the  
major screenreaders. Mind you, screenreaders don't generally read out  
quote for the q tag either. Have a look at this:

http://dotjay.co.uk/tests/screen-readers/q-element/

For what it's worth, it seems reasonable to me that a still image, or  
short clip, could be marked up as a quote from a larger film. But the  
original HTML spec only considers quoting excerpts from written   
text, not excerpts from audio or video as well. I don't know if  
there's any practical value in using q like this, since q isn't  
consistently implemented across web browsers.


Jim

Jim O'Donnell
[EMAIL PROTECTED]
http://eatyourgreens.org.uk
http://flickr.com/photos/eatyourgreens



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Charles Iliya Krempeaux

Hello James,

On 5/28/07, James O'Donnell [EMAIL PROTECTED] wrote:


On 28 May 2007, at 22:09, Charles Iliya Krempeaux wrote:



 But yeah... having quote read out does still seem undesired.

 Aren't the aural style sheet or something that can be used to get
 rid of that?


 Shouldn't putting quotes: none none on the q element be enough to
 get the screen readers to NOT say quote at the beginning and the
 end?

 As in...

q style=quotes: none none;...q

I think that noone has actually implemented aural CSS in any of the
major screenreaders. Mind you, screenreaders don't generally read out
quote for the q tag either. Have a look at this:
http://dotjay.co.uk/tests/screen-readers/q-element/

For what it's worth, it seems reasonable to me that a still image, or
short clip, could be marked up as a quote from a larger film. But the
original HTML spec only considers quoting excerpts from written
text, not excerpts from audio or video as well. I don't know if
there's any practical value in using q like this, since q isn't
consistently implemented across web browsers.


It's the cite attribute that gives it value.

It lets me bind a set of thumbnails together (as being from the same
video) while allowing the thumbnails to be all over the place (and
not necessarily in some container element, like a span or something,
which binds them together).

(Did that make sense?  Did I explain that well?  Or would an example help?)


See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Charles Iliya Krempeaux wrote:


But I /don't/ accept that. IMHO microformats currently abuse abbr and
perhaps (more debatably) title for time and location, violating the
standards-based credos of the movement with poor consequences for
assistive technology which have already been widely discussed on the
list.


Admittantly, I haven't gotten around to reading those threads yet :-(

Was there a consensus about a solution to the problem you are describing?


My understanding of the limited consensus would be that the community 
needs to do more accessibility testing of alternative solutions (e.g. 
using span with title instead of abbr with title), since:


1) It's more realistic to fix microformat parsers than upgrade 
everyone's assistive technology.


2) We need to make sure any fix actually has tangible benefits for 
end-users, rather than just looking better from a language lawyer point 
of view.



I'd say I'm suggesting it be used in a way the designers of it
probably didn't imagine it would be used.  (It doesn't seem to violate
the HTML specification though.)


That entirely depends on what we think quotation means. The more I 
think about, the less convinced I am that quotation can stretch to 
mean thumbnail.



Having said that... there isn't a thumbnail cite=... src=...
element... so what else can we do?


Use the cite element instead of the cite attribute. Or to put that in 
the form of a question: what problem does the cite attribute solve that 
the cite element does not?



I want to add semantics somehow... but don't want to make
non-validating HTML (and just make up a new element... even though I'd
like to).


Sure, but there's no point in adding the wrong semantics. ;)


Also, I think Thumbnail of will prove harder to internationalize than
Still: or Thumbnail:, which would mean parsers would struggle to get
at the alternative text proper.


The img alt attribute doesn't really seem built for i18n.

Isn't i18n usually handled with completely different versions of the
same HTML page.

Which in that case would make the i18n for the sHTML Video
Thumbnailing suggestion I made a non-issue.

(I.e., there would be different version of the alt attribute for
each language supported (in each of those pages)... and it will be a
worded in a way that makes sense.)


Sorry, I wasn't talking about about localizing individual documents and 
consuming them as a human reader. For that, any sensible phrasing is 
fine. The problem is with localizing the proposed microformat itself and 
consuming it as a microformat parser. I'm assuming such parsers may want 
to extract both the thumbnail and alternative text for the thumbnail. 
Now, prefixes such as Thumbnail of  and Still:  are only useful if 
you need to communicate that the thumbnail is in fact a thumbnail; that 
is, they are not part of the text alternative proper but additional 
hints to the user sneaked into the alt attribute. So a microformat 
parser will want to drop those phrases to get to the real alternative 
text, Dorothy encounters the Lion. But in order to drop them, it needs 
to be able to recognize them reliably. Separating the prefix from the 
real alt attribute with some very simple punctuation makes the task of 
writing a microformat parser that can deal with alt attributes in 
multiple languages much simpler. Instead of translating thumbnail of  
into every single language, you only need to translate the colon symbol 
into a comparatively small number of equivalents. It's the same reason 
we use a single ISO date format in microformats rather than hundreds of 
more human readable date formats, except in this case still:  is human 
readable. :)



But yeah... having quote read out does still seem undesired.

Aren't the aural style sheet or something that can be used to get rid of 
that?


Short answer: no, not with current technology. :(

Only self-voicing software that has a tiny share in the assistive 
technology market (Emacspeak, Fire Vox, Opera for Windows) supports 
speech styles at all. Safari, Firefox, and Internet Explorer do not 
parse aural CSS and do not expose it to accessibility frameworks for use 
by screen readers; mainstream screen readers do not download the CSS and 
parse it for themselves; and only Orca (which barely counts as 
mainstream) uses CSS internally.


If mainstream screen readers have access to quotation semantics /at 
all/, it's usually in the form of either:


1) Quotation punctuation already (e.g. Orca used with ELinks or Thunder 
used with WebbIE).


2) The abstract notion that a given node is a q or blockquote (e.g. 
Window-Eyes used with Firefox or JAWS used with Internet Explorer).


What they do with this information varies enormously by screen reader, 
screen reader version, and configuration, but has nothing to do with 
author-specified CSS. For a bit more detail (mainly about how they 
handle the poor old q element) see:



Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

James O'Donnell wrote:

Mind you, screenreaders don't generally read out 
quote for the q tag either. Have a look at this:

http://dotjay.co.uk/tests/screen-readers/q-element/


Well, in so far as they have any especially common behaviour for q, 
reading quote at the beginning is it. Of course, whether they do 
anything special for q depends on one's verbosity configuration, but 
then everything with a screen reader does.


What skews everyone's view of q is that JAWS 7.1 (and probably 8 too, 
but I've never been able to find someone with a licenced copy to test 
that) doesn't recognize it as a quotation. But while JAWS is a very 
popular screen reader, it's not as dominant in the screen reader market 
as (say) Internet Explorer is in the browser world.


--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-28 Thread Benjamin Hawkes-Lewis

Charles Iliya Krempeaux wrote:


It's the cite attribute that gives it value.

It lets me bind a set of thumbnails together (as being from the same
video) while allowing the thumbnails to be all over the place (and
not necessarily in some container element, like a span or something,
which binds them together).

(Did that make sense?  Did I explain that well?  Or would an example help?)


Ah, I see your problem. It's not pretty, but until HTML-next comes to 
town how about either of the following hacky solutions:


1. Using cite then trying to hide it

span class=video-stillimg 
src=http://www.example.com/thumbnail.jpg; alt=Still: Dorothy 
encounters the Lionspan class=full-video(cite 
class=full-video(a href=http://www.example.com/video;Wizard of 
Oz/a/cite)/span


with CSS:

@media all {
.full-video {display:none;speak:none;height:0;visibility:hidden;width:0}
}

If the citation is not hidden, it's not the end of the world: it still 
makes sense. Thanks to buggy treatment of display:none, I think 
mainstream screen readers will fail to read it even though they ignore 
speak:none.


http://css-discuss.incutio.com/?page=ScreenreaderVisibility

http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=1165

2. Using object

object class=video-still type=image/jpeg 
data=http://www.example.com/thumbnail.jpg;
param name=full-video value=http://www.example.com/video; 
valuetype=ref/param

Still: Dorothy encounters the Lion.
/object

Both would need some testing though.

--
Benjamin Hawkes-Lewis
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


[uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-27 Thread Charles Iliya Krempeaux

Hello,

This is an RFC -- Request for Comments.  So I'm looking for people's
opinions, comments, and criticisms on all this.


Note... this is NOT a Microformat.  Nor an attempt to define a new
Microformat.  This is about semantic HTML (sHTML) markup.

(Hopefully this isn't too off-topic for this mailing list.  I'm just
looking to tap this group for comments on this.)



BACKGROUND

I'm developing some software for a client that will (among other
things) display video thumbnails within HTML.

I've actually used this form of semantic HTML before.  However, until
this, none of it was publicly released.

(Also, with this software, once it is out there, I won't be in control
of the software... and thus not able to make corrections to the markup
later.)



SEMANTIC HTML

The way I'm planning on marking these up is using a combination of 2
built in HTML elements.

The q element and the img element.

Conceptually, I'm considering a video thumbnail to be analogous to
quoted text.  In other words, I'm conceptually considering video
thumbnails to be a quote of a video.

So, for example, we would have something like...

   q cite=http://example.com/video;img
src=http://example.com/thumbnail.jpg; //q

Or if you want that pretty-printed...

   q cite=http://example.com/thevideo;
   img src=http://example.com/thumbnail.jpg; /
   /q



CITING VIDEO

In this, I make use of the q element's cite attribute to refer to
the video where the thumbnail is taken from.

This cite attribute might refer to a binary video file.  But could
also refer to a blog post or vlog post in which the video is
embedded.

For the purposes of this, I'm considering some (but not all) HTML
pages to be video.  So.. for example, an HTML vlog post is
considered to be video.



TYPES OF THUMBNAILS

Really there are different sources a thumbnail can come from.

A thumbnail can come from a video.  But it could also come from a
(static) image.

So... to distinguish between these different types of thumbnails, I've
added a class-video to the q element.  (I suppose if you have a
thumbnail from a static image you could add class-image... but
anyways)

So, our example from before becomes...

   q class=video cite=http://example.com/video;img
src=http://example.com/thumbnail.jpg; //q

Or if you want that pretty-printed...

   q class=video cite=http://example.com/thevideo;
   img src=http://example.com/thumbnail.jpg; /
   /q



RFC

Comments?  Critisizms?  Opinions?


--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-27 Thread Maciej Stachowiak


On May 27, 2007, at 11:10 AM, Charles Iliya Krempeaux wrote:



TYPES OF THUMBNAILS

Really there are different sources a thumbnail can come from.

A thumbnail can come from a video.  But it could also come from a
(static) image.

So... to distinguish between these different types of thumbnails, I've
added a class-video to the q element.  (I suppose if you have a
thumbnail from a static image you could add class-image... but
anyways)

So, our example from before becomes...

   q class=video cite=http://example.com/video;img
src=http://example.com/thumbnail.jpg; //q

Or if you want that pretty-printed...

   q class=video cite=http://example.com/thevideo;
   img src=http://example.com/thumbnail.jpg; /
   /q



RFC

Comments?  Critisizms?  Opinions?


I don't think this is a very natural use of the q element. A  
thumbnail isn't really like a quote of a prose fragment. Consider  
that you would never put a thumbnail in quotation marks. Also, q  
cite= does not generally result in a clickable hyperlink, and q  
adds rendered quotes in some browsers but not others. If you want the  
full video to be clickable, what you might want is:


a rev=thumbnail href=http://example.com/video;
  img src=http://example.com/thumbnail.jpg;
/a

Or, since rev is confusing and semi-deprecated, you could use  
rel=full-video or something like that; there's no very good  
opposite to thumbnail unfortunately.


Regards,
Maciej



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-27 Thread Charles Iliya Krempeaux

Hello Maciej,

On 5/27/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:


On May 27, 2007, at 11:10 AM, Charles Iliya Krempeaux wrote:


 TYPES OF THUMBNAILS

 Really there are different sources a thumbnail can come from.

 A thumbnail can come from a video.  But it could also come from a
 (static) image.

 So... to distinguish between these different types of thumbnails, I've
 added a class-video to the q element.  (I suppose if you have a
 thumbnail from a static image you could add class-image... but
 anyways)

 So, our example from before becomes...

q class=video cite=http://example.com/video;img
 src=http://example.com/thumbnail.jpg; //q

 Or if you want that pretty-printed...

q class=video cite=http://example.com/thevideo;
img src=http://example.com/thumbnail.jpg; /
/q



 RFC

 Comments?  Critisizms?  Opinions?

I don't think this is a very natural use of the q element. A
thumbnail isn't really like a quote of a prose fragment. Consider
that you would never put a thumbnail in quotation marks.


True... but you don't have to have the q elements put quotes around
the thumbnail.

Please refer to the following to see how to get rid of it...

http://microformats.org/discuss/mail/microformats-discuss/2007-May/009703.html

This is similar to the problem we have with using abbr for dates.

Some browsers put a border under the abbr element.

We get rid of the bottom border some browser put under the abbr
element (when we use it for dates) with a little extra inline style.

We can do something similar here for the q element used for video thumbnails.


Also, q cite= does not generally result in a clickable hyperlink,


It's not suppose to be clickable (in general).

In this bit of sHTML, I'm only tackling the problem of video thumbnailing.

It is true that I often do make it clickable by having code like the
following...

   a href=http://example.com/thevideo;
  q class=video cite=http://example.com/thevideo;
  img src=http://example.com/thumbnail.jpg; alt=... /
  /q
   /a

But this is NOT always the case.  Sometimes I don't want the thumbnail
to be clickable.


and q
adds rendered quotes in some browsers but not others. If you want the
full video to be clickable, what you might want is:

a rev=thumbnail href=http://example.com/video;
   img src=http://example.com/thumbnail.jpg;
/a


I'm not sure if the rev attribute is being used correctly in your markup.



Or, since rev is confusing and semi-deprecated, you could use
rel=full-video or something like that; there's no very good
opposite to thumbnail unfortunately.

Regards,
Maciej




See ya

--
   Charles Iliya Krempeaux, B.Sc.

   charles @ reptile.ca
   supercanadian @ gmail.com

   developer weblog: http://ChangeLog.ca/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-27 Thread Patrick H. Lauke

Charles Iliya Krempeaux wrote:


a rev=thumbnail href=http://example.com/video;
   img src=http://example.com/thumbnail.jpg;
/a


I'm not sure if the rev attribute is being used correctly in your markup.


Rev defines the reverse link to the current document, not to whatever is 
encapsulated by the link itself...unless I'm reading the spec wrong
This attribute describes the relationship from the current document to 
the anchor specified by the href attribute

http://www.w3.org/TR/html401/struct/links.html#edef-A

So, the above would mean the current document as a whole is the 
thumbnail for http://example.com/video; rather than the img is the 
thumbnail for 


So yes, it's a slight misuse (or a case of stretching the semantics, 
if you will) of rev, I'd say.


P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__
Take it to the streets ... join the WaSP Street Team
http://streetteam.webstandards.org/
__
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] RFC: sHTML Video Thumbnailing

2007-05-27 Thread Paul Wilkins

http://www.w3.org/TR/html401/struct/links.html#h-12.1.2

My simplified understanding of the relationship between rel and rev is

With the rel attribute, the relationship that the linked page has to this 
link is foo.
With the rev attribute, the relationship that this link has from the linked 
page is foo.


Use previous or next as the link values and you'll understand what's 
going on.


From: Patrick H. Lauke [EMAIL PROTECTED]

Charles Iliya Krempeaux wrote:


a rev=thumbnail href=http://example.com/video;
   img src=http://example.com/thumbnail.jpg;
/a


I'm not sure if the rev attribute is being used correctly in your 
markup.


Rev defines the reverse link to the current document, not to whatever is 
encapsulated by the link itself...unless I'm reading the spec wrong
This attribute describes the relationship from the current document to 
the anchor specified by the href attribute

http://www.w3.org/TR/html401/struct/links.html#edef-A


A rel link from the video page to the thumbnail would be thumbnail.
So, a rev link on the thumbnail to the video page would also be thumbnail.

I've got no problem with using rel and rev values myself, but if you're 
going to use a a custom link-type that's not actually defined in 
http://www.w3.org/TR/html401/types.html#type-links then you should use a 
profile to define what's going on.


--
Paul Wilkins 


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss