Re: Handling of @src (ISSUE-107)

On Sep 10, 2011, at 14:06 , Mark Birbeck wrote:

> Hi Ivan,
> 
> On the implications of change, the only one I can think of would be
> sites adding licensing information about images directly to the <img>
> element. I had thought that Flickr was using this technique but I've
> just checked and it doesn't seem to be the case. So my guess is that
> you're probably safe.
> 

Thanks for checking flickr!

> (And if your question is more about sites that I have deployed, then
> we're not using @src in this way on LevelBusiness so it wouldn't be a
> problem for me.)
> 

Well, that was also my question, so it is good that this would not bother you...

Cheers

Ivan

> All the best,
> 
> Mark
> 
> 
> On Sat, Sep 10, 2011 at 9:24 AM, Ivan Herman <ivan@w3.org> wrote:
>> (Ben, Mark, Jay, you will see below why you were explicitly solicited...)
>> 
>> There is an open ISSUE[1] on the table of the RDFWA WG on RDFa on the exact semantics of @src.
>> 
>> At present, @src behaves like @about. What this means that it is possible to write
>> 
>> <img src="bla" property="prop" content="something"/>
>> 
>> Because the content model of HTML does not allow for any children for <img>, this is the only way to do this without repeating the URI in @src somewhere.
>> 
>> However, it turns out that this behaviour seems to be fairly unnatural to many, users seem to expect that @src behaves like @href, ie, it sets the object. Gregg (and others I believe) have reported that a major source of mistakes in using RDFa is the pattern
>> 
>> <img rel="prop" src="bla"/>
>> 
>> expecting to see something like
>> 
>> <> <prop> <bla> .
>> 
>> which of course will not happen. Put it another way, the design pattern
>> 
>> <div rel="prop"><img src="bla"/></div>
>> 
>> should be used all over the place and people do not really like that...
>> 
>> So the issue recorded in ISSUE-107[1] is to change the behaviour of @src, ie, to make its semantics identical to @href/@resource.
>> 
>> The WG has discussed this on its past telco[2] and, although people agreed that the current design was not optimal, it was not clear how to go ahead. Indeed, a change in RDFa 1.1 would lead to a backward incompatibility. Putting aside the charter issue, the real question is whether this would hurt existing deployment or whether the effect would be minimal. There was a straw poll at the meeting that was not unanimous, but with a majority accepting the change, but it was clear that this is something where we need more feedback. (Hence the explicit addressing of this mail to Jay, Ben, and Mark...)
>> 
>> So, feedbacks please? I think the question we should concentrate on: would such a backward compatible change hurt existing deployments in a really significant manner?
>> 
>> Thanks
>> 
>> Ivan
>> 
>> [1] http://www.w3.org/2010/02/rdfa/track/issues/107
>> [2] http://www.w3.org/2010/02/rdfa/meetings/2011-09-08#src_attribute__2c__ISSUE__2d_107
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>> 
>> 
>> 
>> 
>> 
>> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Saturday, 10 September 2011 13:54:46 UTC