- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 18 Aug 2010 21:29:40 +0200
- To: Toby Inkster <mail@tobyinkster.co.uk>
- Cc: Ivan Herman <ivan@w3.org>, Shane P McCarron <shane@aptest.com>, martin@weborganics.co.uk, W3C RDFa WG <public-rdfa-wg@w3.org>
Toby Inkster, Wed, 18 Aug 2010 17:09:04 +0100: > On Wed, 18 Aug 2010 13:08:37 +0200 > Leif Halvard Silli: >> "hard-coding" >> What, eventually, is the motivation for doing so? > > I wouldn't rule out minting a longdesc-specific predicate, such as > xhv:longdesc in the XHTML vocabulary to cover the purpose rather than > re-using rdfs:seeAlso. I am not sure that a such hard coding would fit together with a possible rel="longdesc." > But I do think the predicate should be hard-coded. First of all, that > allows longdesc to be used alongside the @rel/@resource combination: > > <img src="foo.jpeg" alt="foo" longdesc="foo.html" > rel="cc:license" href="http://example.net/foo-public-license" /> A valid consideration, since one probably wants to place the license directly on the image element - regardless of whether one were using a RDFa vocabulary which somehow permitted placing it somewhere else ... However, it may be a rare use case. If it really was a must to produce a longdesc triple in such a case, then it could be done via @rel="longdesc". <span about="foo.jpeg" rel="longdesc" resource="foo.html"> <img src="foo.jpeg" alt="foo" longdesc="foo.html" rel="cc:license" href="http://example.net/foo-public-license" /> </span> I prefer such a solution. > And secondly, and more importantly, the predicate should be hard-coded > to reflect the established meaning in HTML that longdesc has (which is > somewhat close to rdfs:seeAlso). One wouldn't want @longdesc polluted as > a place to put generic image-related links which aren't links to long > descriptions. e.g. > > <img src="foo.jpeg" alt="foo" > rel="ex:larger" longdesc="foo-big.jpeg" /> Are you speculating that authors will draw a link between "long" and "big"? Or do you just fear general misuse? The example you provide, should not even be valid as HTML. (The HTML5 Validator.nu validator performs URL validity checking - unlike the W3 HTML4 validator. I imagine that a HTML5 Validator possibly could check that the @longdesc only points to valid content.) I understand the motivation. But how real is the danger? What advantage can such a RDFa misuser gain from using @longdesc instead of @resource? One cannot guard oneself against everything. If we reach a stage were that kind of conscious misuse is common, then we may aslo have reached a stage were @longdesc has _also_ gotten a lot of correct use. @longdesc today specifically has the problem that it isn't understood - it isn't understood as a link. Authors fill it with text because they don't know that it is as a link. But any feature that is understood and much used, will also see some misused. >> And an idea to - at some undecided point in the undecided future - >> either globalize @longdesc or mint new, global, attribute with the >> same functionality, is floating in the air. > > That's nice to hear. IIRC ARIA has something to offer in this > department. There is an idea to use some ARIA for it - some seems to think about somehow reusing aria-describedby. Others seems to think about creating a new aria attribute. Globalizing @longdesc is mostly a thought I myself have aired. -- leif halvard silli
Received on Wednesday, 18 August 2010 19:30:19 UTC