Re: [whatwg] image element

[Geoffrey Sneddon]

On 30 Jul 2008, at 08:17, Nicholas Shanks wrote:

So again, I ask for an  element to replace . Benefits  
include:
- As  would cater for video/* MIME types,  would  
cater for

image/*


I don't see how this is a benefit over .


In order of importance to me:

1. It's spelt correctly.
2. It's not an empty element.
3. It's spelt correctly.



Re: 2) — it is, and it has to be for backwards compatibility (it is  
changed to an img element in the tokenizer, though). In terms of 1 and  
3, how about starting with something that is completely wrong, not  
just an abbreviation, such as the Referer header in HTTP? Not that  
that can actually be changed, because things rely upon it…



--
Geoffrey Sneddon

Re: [whatwg] image element

[Smylers]

Nicholas Shanks writes:

> On 30 Jul 2008, at 4:49 am, Ian Hickson wrote:
>
> > I don't see how this is a benefit over .
>
> In order of importance to me:
>
> 1. It's spelt correctly.
> 3. It's spelt correctly.

Having both  and  elements in HTML doing different things
would be confusing.  Many people currently pronounce "img" as "image",
so it would be very hard to distinguish between these elements when
talking about images.

Smylers

Re: [whatwg] image element

[Ian Hickson]

On Wed, 30 Jul 2008, Nicholas Shanks wrote:
> 
> To continue this:
> The video and audio elements are being introduced because they have DOM APIs
> that exceed that of , and we don't want to overload the general
> element with features specific to certain kinds of media. By analogy, images
> could have specific APIs too (dontScale/scaleToFit/stretchToFit,
> nextFrame/previousFrame/startAnimating/stopAnimating). These aren't being
> proposed at present, but overloading object is not something it seems like we
> should be telling people to do.

We have  for this already.


> I would expect, if an analysis was done, that the number of people using
>  as an empty element (thinking they were using img), and the number of
> people using  as was defined in HTML+ are both no higher than
> the background noise of misspelled tags.

0.2%. More common than , , , , , , , 
, etc...


> > I don't see how this is a benefit over .
> 
> In order of importance to me:
> 
> 1. It's spelt correctly.
> 2. It's not an empty element.
> 3. It's spelt correctly.

1 and 3 are non-issues, sorry.

2 is already handled by  when you need it.


> > If you need markup in the fallback, use . (Or, better, 
> > consider exposing the content to everyone and not making it only 
> > available to those who don't see the image.)
> 
> The point of fallback is �help for people who can't see the image� 
> rather than �an explanation of the image suitable for all�. Of course, 
> if you can provide the latter, that's great, and there's no problem. 
> Fallback content could be as simple as "Figure 2", where the surrounding 
> text discusses the image sufficiently that it isn't necessary to see the 
> image, but users still want to know which image element on the page that 
> text was referring to (so they can download it to disk, or whatever).

My point is that the alternative text (the fallback) will often be useful 
for everyone, not just those who can't see the image. But that if you 
really don't want people to see both, you can use  anyway.


> Aye, but  gets me very angry.

With all due respect, this may be more a problem for you than for the 
language. :-)


The spelling of the tag is not a real problem. The lack of rich fallback 
isn't a problem at all, since we have .

I don't really see any issue here.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] image element

[Kristof Zelechovski]

He was the vendor of the prototype implementation so it was impossible to
stop him although TBL did his best.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Shanks
Sent: Wednesday, July 30, 2008 9:17 AM
To: Ian Hickson
Cc: WHAT Working Group Mailing List
Subject: Re: [whatwg] image element

Aye, but  gets me very angry.
I believe this was the worst moment in the history of HTML:
http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html

Why did nobody stop this guy at the time?  We're still cleaning up his  
mess 15 years later :-(

- Nicholas Shanks.

Re: [whatwg] image element

[Nicholas Shanks]

On 30 Jul 2008, at 4:49 am, Ian Hickson wrote:


On Tue, 20 Mar 2007, Nicholas Shanks wrote:


I asked for the resurrection of HTML+'s fallback  
element

last month. The reasons I cited were exactly the same as the reasons
being given now in favour of the  element, however I was told
(paraphrasing) "Why bother, you can just use " and "That  
would

break existing implementations" (though no such implementations were
cited).


To continue this:
The video and audio elements are being introduced because they have  
DOM APIs that exceed that of , and we don't want to overload  
the general element with features specific to certain kinds of media.  
By analogy, images could have specific APIs too (dontScale/scaleToFit/ 
stretchToFit, nextFrame/previousFrame/startAnimating/stopAnimating).  
These aren't being proposed at present, but overloading object is not  
something it seems like we should be telling people to do.


I would expect, if an analysis was done, that the number of people  
using  as an empty element (thinking they were using img), and  
the number of people using  as was defined in HTML+ are  
both no higher than the background noise of misspelled tags. As such,  
I don't believe it would be to any vendor's detriment to change the  
meaning of an opening  tag to not be empty, since the numbers  
of pages rendered incorrectly would stay about the same (just that it  
would be a different set of pages). The action, however, would free up  
the tag for future use.


So again, I ask for an  element to replace . Benefits  
include:
- As  would cater for video/* MIME types,  would  
cater for

image/*


I don't see how this is a benefit over .


In order of importance to me:

1. It's spelt correctly.
2. It's not an empty element.
3. It's spelt correctly.

- The alt and longdesc attributes can be part of the fallback  
content,

allowing markup.


If you need markup in the fallback, use . (Or, better,  
consider
exposing the content to everyone and not making it only available to  
those

who don't see the image.)


The point of fallback is ‘help for people who can't see the image’  
rather than ‘an explanation of the image suitable for all’. Of course,  
if you can provide the latter, that's great, and there's no problem.  
Fallback content could be as simple as "Figure 2", where the  
surrounding text discusses the image sufficiently that it isn't  
necessary to see the image, but users still want to know which image  
element on the page that text was referring to (so they can download  
it to disk, or whatever).



- You don't have to provide a type attribute and match on: object
[type^="image/"]


Seems like "img" handles this too.


Aye, but  gets me very angry.
I believe this was the worst moment in the history of HTML:
http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html

Why did nobody stop this guy at the time?  We're still cleaning up his  
mess 15 years later :-(


— Nicholas Shanks.



smime.p7s
Description: S/MIME cryptographic signature

Re: [whatwg] IMAGE element (was XSLT: HTML 5 --> HTML)

[Anne van Kesteren]

On Fri, 09 Feb 2007 18:43:17 +0100, Nicholas Shanks  
<[EMAIL PROTECTED]> wrote:

I was originally just making an off-the-cuff hostile remark about
IMG, but the more i think about it the more I dislike them pesky and
restrictive alt attributes!


They are, for one, backwards compatible. (Even though originally they  
weren't.) Note that  can't be used anyway. It's parsed like .



--
Anne van Kesteren

[whatwg] IMAGE element (was XSLT: HTML 5 --> HTML)

[Nicholas Shanks]

On 9 Feb 2007, at 15:51, Benjamin Hawkes-Lewis wrote:


Nicholas Shanks wrote:

Yes, like OBJECT, but with a different name. A nicer name than  
IMG. One

with three vowels. One that only accepts image/* content types. One
with a more specific usage that can be controlled independently of
OBJECT through CSS 1/2.


Strictly, you don't really need a second element for independent
selection.

CSS 2:

object[type="image/jpeg"], object[type="image/gif"]


... ad infinitum.

I don't consider that wise, because:

a) you'd have to list every possible image/* combination that exists  
or could be invented in the future

b) you'd have to add a type attribute to the element, which implies
i) you have control over the HTML (in user.css it wouldn't work)
ii) you ‘know’ what content type the server is going to return


Draft CSS 3:

object[type^="image/"]


better (which is why I didn't mention CSS3 originally), but point (b)  
above still applies.



The basic point of replacing  with  rather than replacing  
it with  was (would be) specificity. The image element could  
now be defined as a subtype of the object element for that most  
common usage case of including pictures on a page.


The other thing is that  could be *block level* by default,  
and wouldn't cause the extra line height whitespace problem that  
inline images can cause when misused.  would still be available  
for simple inline images like 
Further benefits: longdescs could be included as a hyperlink at the  
end of the normal fallback text.


Importantly, explicit inclusion in the HTML5 spec would make more  
people aware of the kind of behaviour and benefits that have always  
been available through object but that few people use (myself  
included, I must admit).
I was originally just making an off-the-cuff hostile remark about  
IMG, but the more i think about it the more I dislike them pesky and  
restrictive alt attributes!


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature