19 replies [Last post]
Ornette
Offline
Enthusiast
Last seen: 8 years 8 weeks ago
Timezone: GMT+1
Joined: 2006-02-06
Posts: 68
Points: 0

Given the code



we see that for the following doctypes,

1) none at all,
2) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
3) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
4) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
5) <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

Firefox displays an empty image frame for the non-existant image - in common, all invoke browser 'quirks' mode. However, for the following doctypes,

i) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
ii) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Firefox does not display the empty image frame and instead will collapse the space into nothing - in common, all enable 'standards' mode.

With Hugo's suggested CSS declaration: img {display: block;}, Firefox does indeed uphold the explicit dimensions and will not collapse the empty space, however this does not result in the faint grey/dotted border and 'image' icon that one might expect.

The questions I therefore ask are:
Can anyone point me to the relevant sections in the CSS2.1 specification that indicates non-existant images should be collapsed to nothing?
Is there a way to disable this behavior whilst using a 'standards' mode doctype?
Additionally, could one explain why this method should have been affected contrary to the intuitive and expected approach that has been implemented since the conception of the web browser?

- Thanks to http://hsivonen.iki.fi/doctype/ - great excellent reference on the different doctypes available

Tyssen
Tyssen's picture
Offline
Moderator
Brisbane
Last seen: 5 years 1 week ago
Brisbane
Timezone: GMT+10
Joined: 2004-05-01
Posts: 8201
Points: 1386

Maybe I'm missing the point,

Maybe I'm missing the point, but why would you expend time trying to get Firefox to do this rather than just making sure that none of the images are missing?

How to get help
Post a link. If you can't post a link, jsFiddle it.
My blog | My older articles | CSS Reference

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

You won't find anything in

You won't find anything in the CSS specs, were talking about a HTML tag, and as such it's behaviour is not determined by CSS.

What is stated about the empty replaced nature of this tag is that the height and width attributes should be used by UA to reserve the space required for the object while waiting for that data to be received, and is why I and others have always made the point when we see those attrubutes not used that they should be.

I'm not sure why there are these discrepencies between browsers, in Strict mode an img tag object is rendered inline. it would seem that Mozi take that literally and disalow dimensions and that IE have taken a halfway stance on this and render inline but acknowledge the dimension attributes, which also strikes me as perhaps the correct take on things :shrug:.

Mozi weren't happy with the inline nature and the fact that letter descender space would be reserved so they used their 'Almost Strict Mode' to render img tags as display:block as they used to be.

So if you must have the same behaviour as IE then you'll have to use a trans DTD with system Identifier, which should give the results you wish.

As for delving into this any further I doubt that much light will be shed on the matter, although one of the other members might have more information on why this situation exists.

I feel though this is an area where one can waste a lot of energy for no great reason Smile

If space is needed to be reserved then it suggests that the object is in fact block by nature, in which case in strict mode one sets it to 'block' or floats it, personally I doubt I would ever have a problem with this as if inline space isn't going to collapse as the images would likely be in an element that would have formatting and retain it's structure regardless of it's content.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 12 hours 8 min ago
Dallas
Timezone: GMT-5
Joined: 2004-06-25
Posts: 9743
Points: 3822

This is not a css issue.

This is not a css issue. The relevant bit is

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

kk5st wrote: //Curse you

kk5st wrote:

//Curse you English man; using that six hour head start again, but I'm gaining on you.//

cheers,

gary

07.12 VS. 07.13 so if you get up earlier or is that retire later ? by
approx 1 hour you might just pip me to the post, huh I think not.

Rambling now: this issue is one I'm not sure has a sensible conclusion
I appreciate the test case but wonder whether in fact giving the img tag a default inline nature is sane? If one inserts an image amongst a block of text and the image renders then it renders with it's dimensions and will necessarily disrupt the formating of that block of text; if that image fails to render do we really require then that the alt text renders on screen as inline i.e as a neat readable line of text , hmm perhaps so, but given that the img tag was block by nature originally why did it change and was that change really of benefit?

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 7 years 4 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Ornette and Gary, please

Ornette and Gary, please post test cases to a website. It helps greatly to be able to click a link and see exactly what is being described.

Hugo, was the image ever block? Its inline replaced - which means it does have a width and height, just like a textarea, input and object. Only inline non-replaced elements (text) don't have widths and heights. If the image isn't present and the alt text is rendered, presumably it changes from a (potentially) inline replaced element to an inline non-replaced element.

Ornette, what is better?
To show a page with lots of missing image icons and blank space or to cinch up the content and show a clean document? I think there is a pretty strong argument for Firefox's method. A user doesn't need to know the image link is broken or temporarily unavailable.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

It was block Chris, but

It was block Chris, but haven't proof of that as such; with strict it was put into inline mode, Mozi decided to keep 'block' available via 'Almost Standards Mode' as they weren't happy?

Yes it's inline replaced and it gets it dimensions through the object data? or through the width/height attributes which are supposed to convey the required info to reserve the required space (as per the specs) I guess your right Mozi and others are changing it's nature if no image present to non-replaced inline, but is that correct? likely as you point out desirable, but correct? or their own take on things?

IE seems to honour the inline replaced nature and observe the attributes informing it of the space to reserve?

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 7 years 4 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

Hugo wrote:It was block

Hugo wrote:
It was block Chris, but haven't proof of that as such; with strict it was put into inline mode, Mozi decided to keep 'block' available via 'Almost Standards Mode' as they weren't happy?

It was "text level" as opposed to block in HTML 3.2 and a replaced element in CSS 1 Wink

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Chris..S wrote:Hugo wrote:It

Chris..S wrote:
Hugo wrote:
It was block Chris, but haven't proof of that as such; with strict it was put into inline mode, Mozi decided to keep 'block' available via 'Almost Standards Mode' as they weren't happy?

It was "text level" as opposed to block in HTML 3.2 and a replaced element in CSS 1 Wink

Well they should stop refering to it having been frigging 'block level' then!
I don't make things up, well not often , ok sometimes , oh balls. and less of the sarky winks :mad: Smile

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 7 years 4 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

I think its time for that

I think its time for that lunch time pint Laughing out loud

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

Chris..S wrote:I think its

Chris..S wrote:
I think its time for that lunch time pint Laughing out loud

Laughing out loud I think your right , can't sit around waiting for people to send me 'stuff' or ring when they said they would , starting to get that mildly irritated feeling Smile

Pub it is, and the sun is shining so it's The Windmill on the common methinks

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Ornette
Offline
Enthusiast
Last seen: 8 years 8 weeks ago
Timezone: GMT+1
Joined: 2006-02-06
Posts: 68
Points: 0

3 hours this took me...

Hugo -
Thanks for answering and from what you say, its the HTML specs that should be referenced for clarity on this - as you indicated,
HTML 4.01-13.7.1 does indicate that height & width attributes should be used to reserve space.

So it seems that Firefox is not really doing what it should. I appreciate what you say Chris, about lots of missing image icons and blank space vs. a clean document, but that is a matter of context. I can defo see what Gary's testcase points out, but I don't think it is a valid assumption to say that a user doesn't need to know the image link is broken or temporarily unavailable!


Chris -
The description I have read on 'inline-replaced' does seem to be what describes the property of the image element
(reference: http://dbaron.org/css/2000/01/dibm )

- indeed HTML 4.01-13.2 says of the <IMG> tag "it is usually replaced inline by the image ". And so it seems, like you said, that Firefox's approach is to change its nature to 'inline non-replaced' when the image is not available.
(although, infact more correctly, seemingly it actually defines its default status as 'inline non-replaced' changing only to 'inline-replaced' once it has begun to retrive the image!!!!)

In my particular instance, I am not happy with this, and I don't want it doing that. This behavior, which I can see does have benefits, is really something that should be enabled from within the style sheet, if anything
- which, infact, does make this a CSS issue Gary...

As I pointed out, the 'empty image placeholder' is a long time mainstay of browser interface - and thanks again Chris to pointing the "text-level" classification in HTML 3.2 - which clearly states "...when given together with the height, this allows user agents to reserve screen space for the image before the image data has arrived..."


@kk5st / Gary - Quite funny about your preference of Firefox on 'alt' text - as I conversely have just encountered an annoyance with Firefox on this. It has a bizzare restrictive nature on the size of the 'tool tip' that comes up to display it!!! Take another look at your code, and actually add a image to it. That unfeasibly long 'alt text' is severly suppressed by your beloved browser!!!

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

13.7.1 and 13.2 were my

13.7.1 and 13.2 were my references for the reserved space aspect and which keps tugging me towards the thinking that Mozi isn't playing by the rules 100% :shrug:

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Deuce
Deuce's picture
Offline
Guru
Somewhere, USA
Last seen: 2 years 13 weeks ago
Somewhere, USA
Timezone: GMT-5
Joined: 2005-11-20
Posts: 4424
Points: 1843

Why not just make sure you

Why not just make sure you call images that are available?

all ยป http://dictionary.reference.com/browse/all

Google isn't a bunch of guys reading and grading web sites, it's more like a bunch of monkeys sniffing food and putting the good bananas at the top. -Triumph

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 12 hours 8 min ago
Dallas
Timezone: GMT-5
Joined: 2004-06-25
Posts: 9743
Points: 3822

Ornette wrote:@kk5st / Gary

Ornette wrote:
@kk5st / Gary - Quite funny about your preference of Firefox on 'alt' text - as I conversely have just encountered an annoyance with Firefox on this. It has a bizzare (sic) restrictive nature on the size of the 'tool tip' that comes up to display it!!! Take another look at your code, and actually add a image to it. That unfeasibly long 'alt text' is severly (sic) suppressed by your beloved browser!!!

During the short-lived upgrade, I posted an absolutely genius reply, but the undo took it away. Take my word for it, it was massively excellent. Laughing out loud I can't hope to reach that level again in so short a time, so bear with this lesser comment.

If the image is there to be rendered, the alt text is not a player. Its purpose, as stated in

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.

Hugo
Hugo's picture
Offline
Moderator
London
Last seen: 4 years 40 weeks ago
London
Joined: 2004-06-06
Posts: 15668
Points: 2806

As I was going to add to the

As I was going to add to the original highly excellent comment above that was lost but is now resurected; part of the angst on this subject is the behaviour that firefox demonstrates in truncating the tooltip i.e not allowing the text to wrap and at a specified character length simply cutting the text off with a series of elipses, most rude in the opinion of this commentator.

Thinking this through though, one might believe that this is Mozi's attempt at pointing out that a tooltip/title text is not meant as a detailed essay
and if that is required then one should use 'longdesc', a point most true and subtly made then?

Of course if one holds with the adage that 'A picture is worth a thousand words' then a broken image does naturally require a great deal of descriptive text to do that missing image justice, and the timeout on the tooltip display must necessarilly be increased to allow the user time to read that description with comfort, around twenty minutes should suffice.

But the tooltip truncation was mentioned in the revised version of the 'excellent comment' so this semi excellent one is largely redundent.

Before you make your first post it is vital that you READ THE POSTING GUIDELINES!
----------------------------------------------------------------
Please post ALL your code - both CSS & HTML - in [code] tags
Please validate and ensure you have included a full Doctype before posting.
Why validate? Read Me

Chris..S
Chris..S's picture
Offline
Moderator
Last seen: 7 years 4 weeks ago
Timezone: GMT+1
Joined: 2005-02-22
Posts: 6078
Points: 173

You could of course use the

You could of course use the object tag Wink

Didn't one of the (now many) proposed successors to HTML4/XHTML1 suggest doing away with IMG altogether?

Ornette
Offline
Enthusiast
Last seen: 8 years 8 weeks ago
Timezone: GMT+1
Joined: 2006-02-06
Posts: 68
Points: 0

Gary - I posted this thread

Gary - I posted this thread originally in the hope that there was a CSS solution to the issue at hand, the thread was CSS in good faith!!

kkst wrote:
Ornette, to Chris wrote:

Ornette
Offline
Enthusiast
Last seen: 8 years 8 weeks ago
Timezone: GMT+1
Joined: 2006-02-06
Posts: 68
Points: 0

Oop - two posts by

Oop - two posts by mistake.

I will edit this one and take the opportunity to point out never to compose your prose in a browser window!! So many lost revelatority scriptures have occurred on account of this!

If the answer is any more than a quick direct response I will always move to compose it in a text editor/whatever instead.

gary.turner
gary.turner's picture
Offline
Moderator
Dallas
Last seen: 12 hours 8 min ago
Dallas
Timezone: GMT-5
Joined: 2004-06-25
Posts: 9743
Points: 3822

Quote:I see the alt text as

Quote:
I see the alt text as primarily being as a short description of the content of the picture, not exactly as being a direct continuation of the content itself.

I believe that one should not directly assume that the user does not need to know that a image has not been displayed/is not available. I do think though mostly that is a matter of opinion on the web page creators behalf, and also a matter of context. In this context of mine, I want the user to be directly aware if the image was not loaded.
OK, we've got past a couple of faulty assumptions on the rules, and this bit clarifies, to my mind, your intentions.

It is my opinion that the broken image icon is particularly ugly, so I prefer Firefox's rendering of broken images; not that it matters. I don't see an issue when the image is displayed as block (or float). The space for the image/alt text is provided, and is obviously separate from the regular text. I do see your problem where the image is inline with other text. I don't see that happen all that often, if at all, to my memory.

Fortunately, Firefox allows you to style the alt text. You should be able to arrive at an intuitive difference from regular text. Consider the following, with or without the square brackets:
p {
font-size: 1em;
margin: 1.25em 0 0;
}

img {
color: gray;
font-size: .8em;
}
=============


[The home office seen from Oak Street]
We are justly proud of our new headquarters building. We
hope you will pay us a personal visit.


Would not something like that satisfy your requirements?

cheers,

gary

If your web page is as clever as you can make it, it's probably too clever for you to debug or maintain.