A little bit of homework on @fullsize

[Shawn Medero]

I think there are a lot of unanswered questions about @fullsize and
the current proposal will be met somewhat skeptically with
implementors of HTML user-agents. It might help first of all to think
of all the possible use cases for the feature. Think in broad terms,
consider how @fullsize would work on the internet & intranet, and ask
yourself if it would impact legacy markup in anyway. It helps to put
on your "archeologist" cap: dig through forums, email lists, bug
databases, etc.

General questions:

1. Are the similar ideas in the wild right now (rhetorical)? Maybe a
microformat that does the same thing? A javascript library? How do
they work, what are the pro & cons. Document your findings.

2. Are their parallels to current or previous features? What gaps does
@fullsize fill in? Consider previous attributes like @lowsrc. What
we're the problems? Netscape 4, IE 4, and IE 5 supported @lowsrc but
more recent browsers aren't really doing anything with it. As far as I
know, @lowsrc never made it into an HTML working draft or
recommendation... why?

After thinking about the above, you might be ready to tackle the
specific implementation questions:

1. What happens when the ratio of the @src and @fullsize image
resources aren't the same? What role does @width and @size play, if
any?

3. How does @fullsize interact with CSS? If @fullsize takes multiple
values, how does that work in CSS?

4. Are the resources in @fullsize pre-fetched? Left up to the user-
agent? End-user?

5. What is the DOM interface for @fullsize? If multiple resources are
allowed how does pushing and popping new ones into the DOM work? How
would DOM Events apply to @fullsize? and so on...

6. What happens when an @fullsize resource request fails? (You can
examine the spec's language for @src for the most part... but consider
what makes @fullsize different)

7. What are the accessibility issues for @fullsize? For instance, do
you need multiple @alt values?

8. As mentioned in IRC (#whatwg), is doing this going to alter the
semantics of <img>?

I don't know the answer to most of the questions, they aren't being
asked with any agenda in mind... but I can tell you that if @fullsize
made it out of the "we have sufficient use-cases & evidence to support
this type of feature" stage, then people are going to ask the nitty
gritty questions.

Keep in mind that @fullsize (a new attribute on <img>) might be the
wrong solution all together -- but, hopefully, in doing the work to
explore @fullsize you'll figure out the potential solutions... there's
usually multiple and they always have pros & cons.

Personally, I think this is an area best left to web authors innovate
in. I'm inclined to think the existing markup pattern (anchor pointing
to a full size image, with a nested image element representing the
thumbnail) is suitable for a user-agent/plugin/javascript library to
do something clever with if they wanted to. Even if implemented, the
user-agents would likely provide a basic UI and I don't think the
experience will be rich enough. (I base that on the *many*
implementations of a thumbnails, galleries, etc on I've used on the
web... they're all very different .. many audiences in mind..)

Cheers,
-s

[Fullsize]

Some excellent points/questions you bring up Shawn.
Here is my attempt to answer some of the questions from my
perspective, and my perspective may not be the correct answer, but
hopefully it can shed some more light onto fullsize :)

----------------------------------------

1. The image ratio really doesn't matter. Fullsize will not be
enlarging the @src image, it will be loading a seperate image, the
@fullsize image. The ratio is irrelevant.
The @width and @height would still apply to the @src image. By nature,
you will want to see the @fullsize image in it's fullsize :) There
would be no reason to view it in a smaller size than the actual file
size, so there is no reason for a @width and @height for the @fullsize
image. Remeber that @fullsize is an attribute of the @img tag, so all
other attributes inside the @img tag apply to the @img, and not
@fullsize.


2. I think CSS support is a 'bonus' that would be warmly welcomed by
web developers, but not necessary. I would opt to have CSS support so
developers can style the pop-up beyond the browser default. I would
imagine this could be done with a pseudo class called ":fullsize". So
you could reference specific @img tags with a present @fullsize
attribute in CSS like:

.foobar:fullsize {
border: ...
box-shadow: ...
background: ...
color: ...
}

This is just an example, and can be re-thought or refined later.


3. I would opt for the @fullsize images to be loaded upon a mouse
click, so there is no extra load times initially for the big images,
and the DOM can be fully loaded and displayed without waiting for the
larger images.


4. You can access the value of @fullsize like this:

document.getElementsByTagName('img')[0].fullsize


5. The @fullsize pop-up appears as normal, but inside the space where
the image should be is an error message, and a button to "reload" the
@fullsize image, essentially letting you "try again".


6. No extra @alt values needed. Again @fullsize is an attribute of the
@img tag. So the @alt attribute describes the @img tag, and the
@fullsize attribute is a "high quality" version of the @imag tag.

7. I don't think so. From my point of view @fullsize actually adds
more description to just what is in the @img tag. Just as @alt
describes an image with text, I think @fullsize can be used to
describe the image in greater pixel detail. As internet connections
get faster, and downloads get faster, I think @fullsize will work
wonders in making HTML that much more "future proof". Because as the
web and computers in general progress we will need to be using higher
resolution images, @fullsize can help fill the gap there by providing
a high res version of every image on the web.
Think how this could benefit a platform like Microsoft Surface. They
can pull the @fullsize image instead of the @src image, to ensure the
photos you see when browsing the web on Microsoft Surface, are high
quality and can be "zoomed into" much further and keep much more
detail.

Thanks again Shawn for the questions!
I would ask that everyone who reads this adds their 2 cents, so we can
progres this idea into a standard :)

Peace,
Drew Wilson

[2elkom...@gmail.com]

www.elkomkompresor.com kompresor, kompresör,
28 Ekim 2008 Salı 00:54:26 UTC+2 tarihinde Shawn Medero yazdı:

[bi...@turhalnakliyat.com]

Evden Eve Nakliyat

14 Ağustos 2012 Salı 22:25:59 UTC+3 tarihinde 2elkom...@gmail.com yazdı:

[bi...@turhalnakliyat.com]

<a href="http://www.turhalnakliyat.com/">istanbul evden eve nakliyat</a>

<a href="http://www.evdenevenakliyatturhal.com/">evden eve nakliyat</a>

28 Ekim 2008 Salı 00:54:26 UTC+2 tarihinde Shawn Medero yazdı:

I think there are a lot of unanswered questions about @fullsize and