- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 15 Aug 2010 13:17:10 +0200
- To: Ivan Herman <ivan@w3.org>
- Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Shane McCarron <shane@aptest.com>, public-rdfa-wg@w3.org
Ivan Herman, Sun, 15 Aug 2010 07:38:50 +0200: > Leif, > > if you formally want @longdesc and @cite to be interpreted in RDFa, I > think for the sake of the discussion in the RDFa WG you should really > give a clear use case for both attributes' usage in terms of RDF > triples. The mail of Shane seems to suggest that this would not > really be a solution for assistive technologies, for example. What diff does it make whether it is useful for assistive technologies or not? That said: while a sighter user looking at some triples might be interested in clicking on the link to 'IMG@src triples', a blind or text browser user might be interested in the img@alt or img@longdesc triples ... The micro format I presented initially - roughly this: <a href="http://example.com/l.htm" rel="longdesc"> <img src="img" alt="text" /> </a> leads to the triple: http://example.com/doc <longdesc> <http://example.com/l.htm> And my initial idea was that doing this <img src="img" alt="text" longdesc='http://example.com/l.htm' /> should lead to the same triple. However, I see that the very image is not part of the triple here. Perhaps my idea of correlation between micro format and triple is to simplistic. For example, when we discuss HTML5 in the HTMLwg, then you will sometimes here people say that if one do <a href=link><img></a>, then the image is a link. However, despite the image being a link, the triple created from the micro format above does not contain a reference to the image ... In the example that you showed - in your first reply in this thread - one would get these triples: http://example.com/doc/i.src <alt> "short description" http://example.com/doc/i.src <longdesc> <http://example.com/longer.html> And these triples perhaps are more meaningful. On the other side, coming back to @cite - what kind of triple would you suggest being generated from using @cite? I think, logically, there should be a triple containing the fragment URI of the <q> or <blockquote> element - if such a thing is possible in RDFa. So for example this: <q id='quote' cite='http://example.com/source#fragment'>Lorem ipsum.</q> should lead to something like this - http://example.com/doc#quote <cite> <http://example.com/source#fragment> So, by analogy, I would say that use of @longdesc on an image <img id='iFrag' src="i.png" alt="text" longdesc='http://example.com/l.htm' /> then should lead to http://example.com/doc#iFrag <longdesc> <http://example.com/l.htm> though this would also be meaningful: http://example.com/doc/i.png <longdesc> <http://example.com/l.htm> > B.t.w., you referred to my reference to object. The reason I referred > to object is as follows. There are a number of attributes in HTML4 > and HTML5 that might be reasonably interpreted in RDFa beyond @rel, > @rev, @href. The original RDFa design decided to give a specific > interpretation (essentially like @href) to @src to give a proper > treatment to <img> (Luckily, the @src attribute covers the > requirement of HTML5's <video> and <audio>.) With the same logic, the > @data attribute of <object> could be interpreted a similar way but it > isn't; I do not remember why it was decided not to do that, but I > suspect the reason was to keep the language more succinct. I agree that it you support @src, then it seems logical to support @data as well. Why don't you? On the other side, OBJECT is a complicated element. In fact, it has many similarities to VIDEO and AUDIO that way: Some object-s may have both a @data and - in a param element - a @src. Or you may find the @src in a 'fallback' element such as EMBED ... For VIDEO and AUDIO, then the element _either_ has a @src, _or_ it has one ore more <source src='*'> elements. (Not so for OBJECT - there is is possible to find both object@data + param+src.) Is fallback and alternative contet a 'problem' for RDFa? I guess that I tend to think in 'constructs' - and expect triples to be generated for microformats, so to speak. Thus I see problems ... E.g I would like to know whether the source@src belongs to a video or an audio element. If a triple is being generated for a @src only, then it is not always clear from the MIME type and - or - file suffix (because not all URIs are semantic - without file suffix ...) whether it is audio or video, for instance. But, OK, I can understand that the 'floodgate' argument may have some validity, still. OTOH, in the case of @data, you could just map it to @src, why not? > That is why I would like to have a very clear use case both for > @longdesc and @cite. And also why you do not add @alt to this list, > although I think it would belong to the same family, so to say. Regarding @alt: In the case of IMG@longdesc, then the long description resource, according to HTML4 relates to @alt - it is a long alternative to IMG@alt. So, in a way, I have included @alt - though perhaps that is to stretch it. In the case of iframe@longdesc and frame@longdesc, then the longdesc resource represents a long alternative to iframe@title and frame@title. OTOH, some would probably say that a longdesc resource for an IMG relates to the image of the src URL and not to the @alt text of the image ... Both are in a way true. Anyway, my view is that when it comes to @alt then you should make sure that RDFa treats IMG@alt the same way that it would have treated <img src=* >alt</img>. So in other words, the @alt should be treated as the content of the IMG element. If we say that @longdesc and @cite are shorthand for - or workaround for - using anchor elements, then I don't think that I in the same go must request that RDFa handles @alt. Though, on the other side: The thing they have in common - and perhaps that is what you meant - is that the @cite URL must be linked to the _content_ of blockquote/q just like the @longdesc URL must be linked to the _content_ of the IMG element = its alt attribute. (Btw, in the HTMLwg there is a debate about what a non-decorative IMG represents - the @src or the @alt.) (Though in the case of @longdesc on an iframe and frame element, then the @longdesc must be linked to the content of their @title attribute - though perhaps that is less obvious ... since the content of an iframe element is not the title attribute ... in that case linking the @longdesc URL to the iframe URL makes more sense. There are a few loose ends in HTML ...) > Thanks > > Ivan Leif
Received on Sunday, 15 August 2010 11:17:47 UTC