Bug 12365 - Add @fullsize to <img>
Add @fullsize to <img>
Status: RESOLVED WORKSFORME
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec
unspecified
PC All
: P3 normal
: ---
Assigned To: contributor
HTML WG Bugzilla archive list
http://dev.w3.org/html5/spec/embedded...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-22 20:37 UTC by Leif Halvard Silli
Modified: 2011-12-02 00:49 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leif Halvard Silli 2011-03-22 20:37:24 UTC
Add an attribute named fullsize - or similar to the <img> element.

* Most image gallery solutions offers users to click a small image in order to see a larger version of the image. 
* Many authors seem adds a reference to that <img> inside the <img> element.

Problem: there are no attributes that can provide this function. And as a result, authors have created their own attributes. Or they have misused existing attributes. Typically, they have misused the @longdesc attribute. There are many examples of new and old image gallery scripts in PHP and Javascript which misuse @longdesc for this purpose.

One example is the http://addfullsize.com/. What is unique about the man behind, Drew Wilson, is that he claims to have offered the idea about a @fullsize to HTML5's editor. And he relays on the mentioned web site that our editor asked him to get Web browser vendors to add support before he would add @fullsize to <img>.

However, as authors care so much for validity that they use @longdesc instead, it does not seem neccessary to wait for browser support, anymore than we need to  wait for browser support for @data-x, @data-y, @data-z.

Features: an URL container. Every functionality other than that should be left to scripts.

Benefits: 

@fullsize would offer authors a place to place a link to a larger version of the image.
@fullsize would make authors stop misusing @longdesc for this purpose.

Why not use @data-* instead? Because data-* is intended to "store custom data private to the page or application, for which there are no more appropriate attributes or elements". By adding @fullsize, we create a more appropriate element for a well known issue.
Comment 1 Tab Atkins Jr. 2011-03-22 21:08:40 UTC
If "every functionality [is] left to script", then we aren't actually creating a "more appropriate element" than just letting authors use data-* attributes.
Comment 2 Leif Halvard Silli 2011-03-22 22:03:33 UTC
(In reply to comment #1)
> If "every functionality [is] left to script", then we aren't actually creating
> a "more appropriate element" than just letting authors use data-* attributes.

It depends on what you mean by "appropriate". I was thinking "if the spec says you should use attribute x for feature y", then attribute x is more appropriate. I believe that that is the spirit of the spec text regarding data-*.

That said, I am open to add more to @fullsize than simply @data-fullsize. But I don't think we need to add very much. E.g. @fullsize - unlike @cite - don't need any user interface. It only needs a DOM interface - a DOM interface that it similar to that of @cite.

But if vendors are willing to add more ... Certainly Mr Wilson wanted more. But Wilson also said that the idea, because of that, was dismissed by Ian.
Comment 3 Kornel Lesinski 2011-03-22 22:05:27 UTC
What's expected UA behavior for this?  If UAs aren't supposed to do anything with this, then @data-fullsize is the right solution.

For linking thumbnail to full-size image, IMHO a much better (and hopefully much more popular) design pattern is to use <a href=fullsize><img src=thumbnail></a>. It has much better backwards compatibility and is still easily usable by scripts. 

If explicit association of thumbnail and large image is needed, then perhaps <a rel=fullsize> would be better?
Comment 4 Leif Halvard Silli 2011-03-22 22:26:34 UTC
(In reply to comment #3)
> What's expected UA behavior for this?  If UAs aren't supposed to do anything
> with this, then @data-fullsize is the right solution.

I don't know if you count it as 'do anything', but I'd say that @fullsize should have a DOMString attribute fullsize; 

> For linking thumbnail to full-size image, IMHO a much better (and hopefully
> much more popular) design pattern is to use <a href=fullsize><img
> src=thumbnail></a>. It has much better backwards compatibility and is still
> easily usable by scripts. 
> 
> If explicit association of thumbnail and large image is needed, then perhaps <a
> rel=fullsize> would be better?

The idea of rel=fullsize sounds interesting to. The important issue, then, is to check whether such a thing is what authors ask for. It looks to me as if it isn't enough, given the common misuse of @longdesc for this purpose. (But the use of @longdesc might also be triggered by a desire to be 'valid' - HTML4 did not have a data-* attribute.)
Comment 5 Kornel Lesinski 2011-03-22 22:54:03 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > What's expected UA behavior for this?  If UAs aren't supposed to do anything
> > with this, then @data-fullsize is the right solution.
> 
> I don't know if you count it as 'do anything', but I'd say that @fullsize
> should have a DOMString attribute fullsize; 

I've meant in terms of UI, accessibility or something that affects users. For developers there's element.dataset.fullsize already.
Comment 6 Aryeh Gregor 2011-03-23 22:44:31 UTC
Use-cases for this:

1) Browsers could let the user download the full-size image instead of the thumbnail when they click "Save Image As..." or similar.  (Not too risky if it's a separate context menu option; if the author inadvertently or deliberately specifies something that's not actually a full-size equivalent, the user can figure it out and go back to get the thumbnail.)

2) Browsers could download the full-size image instead of the thumbnail if they're outputting to a high-resolution medium, such as print or an iPhone 4 display.  This use-case is shakier, because a) authors who want to prevent redistribution of their pages could put fake full-size links to prevent users from printing, and browsers would have to implement heuristics to stop this; and b) the full-size image might take up far too much bandwidth to be worth it.

One example of a site that could use this extensively is Wikipedia.  Many articles have pictures, and practically all of those are thumbnails of much higher-res images.  There are probably lots of users who download the low-res version because they don't realize the high-res one exists (although that's just a guess, there's no way to tell).
Comment 7 Leif Halvard Silli 2011-03-23 23:25:21 UTC
(In reply to comment #6)
> Use-cases for this:
> 
>  [...] browsers could let the user download the full-size image instead [of @src image]

> One example of a site that could use this extensively is Wikipedia.

I recall Mark Pilgrim was "looking at your, Wikipedia", for misuse of @longdesc. Did you use @longdesc as you described above?
Comment 8 Leif Halvard Silli 2011-03-24 03:12:57 UTC
(In reply to comment #6)

* we look for attribute with *semantics* as primary effect. 
* the effect should be to express that, when it is used, then @src can be treeated (by users, search engines, browsers themselves etc) as a preview image for the image inside the new @foo attribute.
* The preview image does not need to be a small size preview of a larger image. It could also be for example be a "before" image, and the fullsize attribute could contain the "result" image. (But perhaps this is to stretch its meaning?) But the name of the attribute we are looking for should be one that hints that the current img is merely a preview of the image that this new attribute points to.

* My primary use case is "image galleries". Gallery is a wide term. The thumbnail alike examples of Wikipedia is one example of galleries - I agree!  But in Wikipedia's case, the fullsize (for lack of a better name) image is located at another "page". Whereas often, in javascript image galleries, the fullsize image is displayed in a display area on the same page. I hope, of course, that the attribute could work in both situations.

* Galleries create user expectations: they expect to get a beter - or alternate - quality image when they click the image. Thus they understand that the current image is a preview of some sort. 

* One effect that one could perhaps get could be that the @fullsize images were preloaded so the larger image could be displayed faster.  

    Names, link types, quality:
    ----------------------

*Link types: When it comes to the option of using a link type instead, then we should first look at those link types we already have:

  - 'prefetch' ? <a rel=prefetch href=large><img src=* alt=*></a>
  - 'alternate'? <a rel=alternate href=large><img src=small alt=*></a>

  Of the two, perhaps 'alternate' is best? (But both could be used together!). The problem is its definition: "The keyword creates a hyperlink referencing an alternate representation of the current document.". The image linked to is not meant to be an alternative of the current *document* but an alternative of the current image. (In fact, HTML5 says that all link types defines a relation between the page and the linked resource - and not a relation between that which is inside the link and the linked resource.)

* Perhaps one could also simply use one of these link type names as name of the attribute. E.g. <img src=* prefetch=* alt=*>. Or  <img src=* alternate=* alt=*>   In using the name as an attribute, we are more free in our interpretation of it - the link type names have largely frozen meaning, I think. For instance, it is not common, I think, to use rel="alternate" about simply a larger copy of the same image. (We mean "full size"  and not "more bytes" - it is about quality!)  A word such as "prefetch" is probably far too functional therefore. And @alternat is too dull.

* But 'alternative quality' is still a keywords here: a name which says that the @src is simply another (typically inferior) quality for that which this-new-attribute points to. 

* Name dropping with an eye primarily at 'quality': 

   @aug/@augmented/@augsrc ('augumentative authoring'). 
   @altimg
   @view 
   @viewsrc
   @altview
   @altsize
   @source (a 'large/long' attribute. Plus that small size is often made  by scaling down something big.)

We should probably avoid names which can be interpreted as if the attributes ponts to something that the browser can display instead of the @src. Names such as @view and @viewsrc or @fullview are good because they are active - they hint that they contain stuff that that the user can view if she/he will.

A bad thing with 'fullsize' is that if, like in Wikipedia, ther are several sizes, then the resource inside @fullsize might not actually point to the largest size of the image.

* Question to you: should the presence of the attribute we are discussing make the image into an interactive element? (Probably not.)

Comments/Ideas?
Comment 9 Aryeh Gregor 2011-03-25 02:08:41 UTC
(In reply to comment #7)
> I recall Mark Pilgrim was "looking at your, Wikipedia", for misuse of
> @longdesc. Did you use @longdesc as you described above?

Old versions of MediaWiki used longdesc to point at the image description page (not the larger image version).  That was years ago, though.

(In reply to comment #8)
> * we look for attribute with *semantics* as primary effect. 

Wrong approach.  Start with use-cases, not semantics for the sake of semantics.  Question one is, what features do you want users to have that they don't have now?  Question two is, how do you best achieve that?  Do not try to ask question two until you've gotten question one clearly answered.

> * the effect should be to express that, when it is used, then @src can be
> treeated (by users, search engines, browsers themselves etc) as a preview image
> for the image inside the new @foo attribute.

Not a use-case.  What problem exists that this is solving?  Why would anyone want this, concretely?

> * My primary use case is "image galleries". Gallery is a wide term. The
> thumbnail alike examples of Wikipedia is one example of galleries - I agree! 
> But in Wikipedia's case, the fullsize (for lack of a better name) image is
> located at another "page". Whereas often, in javascript image galleries, the
> fullsize image is displayed in a display area on the same page. I hope, of
> course, that the attribute could work in both situations.

This is not a use-case, because it doesn't describe what the problem is.  You're saying *how* the feature should be used, not *why* anyone would want to use it.  Concretely, in terms of tangible benefits to my users, what would I as an author gain from using this attribute?

> * Galleries create user expectations: they expect to get a beter - or alternate
> - quality image when they click the image. Thus they understand that the
> current image is a preview of some sort. 

If your use-case requires users to click on the images, why does <a> not satisfy the use-case?

> * One effect that one could perhaps get could be that the @fullsize images were
> preloaded so the larger image could be displayed faster.  

Why does rel=prefetch not satisfy this use-case?


If you intend the editor or the Working Group to take your proposal seriously, I strongly suggest you start with the description of a problem, and only then suggest a feature to solve the problem.  The focus needs to be on the problem (use-cases), not the solution.  I gave two good use-cases in comment 6.  Note that both of them focus on specific user-visible benefits that authors cannot easily attain without this new feature.
Comment 10 Leif Halvard Silli 2011-03-26 04:16:36 UTC
(In reply to comment #9)
> (In reply to comment #7)

Aryeh, thanks for helpful, critical remarks.  My main point with this proposal is to attract those authors that would have used @longdesc for such purposes, to use @fullsize instead. As such the usecases should be made clear, I agree.
Comment 11 Ian 'Hixie' Hickson 2011-05-08 03:55:56 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: There are a variety of ways to do this already:

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

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

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

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

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

(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.)

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.
Comment 12 Michael[tm] Smith 2011-08-04 05:01:28 UTC
mass-moved component to LC1
Comment 13 Leif Halvard Silli 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>.
Comment 14 Ian 'Hixie' Hickson 2011-12-02 00:49:48 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: Looks like there's already several data-*="" examples, I don't see why adding another one would be so great here.