W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > August 2011

[Bug 12365] Add @fullsize to <img>

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 Aug 2011 19:50:44 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QrEnc-00024Q-KJ@jessica.w3.org>

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #13 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-08-10 19:50:42 UTC ---
(In reply to comment #11)

> Rationale: There are a variety of ways to do this already:
>  <a href="big.jpeg" rel="..."><img src="thumbnail.jpeg" alt="textual
> replacement"></a>

This has the disadvantage that the the image becomes presented as a link - e.g.
in screenreaders - rather than as an image.

>  <img src="thumbnail.jpeg" data-fullsize="big.jpeg" alt="textual replacement">

This could probably work.

>  <figure>
>   <figcaption><a href="big.jpeg" rel="...">caption</a></figcaption>
>   <img src="thumbnail.jpeg" alt="textual replacement">
>  </figure>

I think this has the same 'becomes presented as a link' problem.

>  <object data="thumbnail.jpeg"><object data="big.jpeg">textual
> replacement</object></object>

This seems elegant - though the UA support might not be tip-top.

>  <details>
>   <summary><img src="thumbnail.jpeg" alt="brief textual replacement"></summary>
>   <img src="big.jpeg alt="detailed textual replacement">
>  </details>

This example assumes that the non-sighted needs a longer description of the big
image copy than of the thumbnail copy - I don't think that makes sense. At the
same time, it probably does not make sense to leave the @alt of the big.jpeg
empty - as that would mean that there is a summary description for a
presentational image, or what? May be it could make sense to simply ommit the
@alt of the big.jpeg ?

> (The rel="..." values would be new values.)
> If there's a problem to solve here, we should just pave a cowpath. If there's
> no cowpath to pave, then it probably isn't a problem people are really having.
> As far as I can tell, there's indeed not really a cowpath to pave. (Note that
> just making an element available does not magically mean everyone will use it,
> so if the problem is that people are not using a standard feature to do this,
> merely providing one may not solve the problem.)

When you say 'pave a cowpath' then I assume you mean an *existing* cowpath. The
spec could still point out one or several useful ways to do it - as the usecase
seems common enough!

> If the problem is just that there's nowhere to put script-specific data, that's
> what the new data-*="" attributes are for, so that problem is solved.

I suggest that you add examples for how to do this - one or more scripted
solutions and one or more no-script solutions. The non-scripted solution could
use <figure> and-or  <details>.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 10 August 2011 19:50:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:16 UTC