Re: Image-dislay status media query for reducing reflows

Emrah BASKAYA wrote:
> That is why user agents must be *told to* disable embedded image sizes  
> or  adapt to alt property text size as a rule when the user turns off 
> images,  as in small images, alt tag is no longer readable, and that is 
> probably  why those forums do not give embedded size info, to make sure 
> buttons are  readable when images are turned off on user side.

Firstly, it's the alt *attribute*, not tag or property.  Secondly when 
the image is not loaded and the fallback content is displayed instead, 
it's not a replaced element and the 'height' and 'width' properties do 
not apply to non-replaced inline elements.

> I think the html specs  must make it obligatory for UA's to expand the image 
> size to the Alt tag,  if the embedded image size is smaller than the alt 
> tag -and- images are  turned off on user side.

They do in standards mode, when the images are not loaded for whatever 
reason; though, IIRC, they don't always do so in quirks mode.

> (This is a bit different from images not being able to be loaded, when
> the images are turned on, the UA should use images embedded size whether
> it can load it or not)

Why?  The reason for not loading the image is irrelevant to the question 
how to render the content.

> I guess this is an issue with  the html spec indeed but may be fixed by a 
> CSS property? Here is my shot  at it: (example)
> 
> @media screen and (image-display: off) {
> img { width: <element-width> | auto | embedded; height: <element-width> 
> |  auto | embedded;}
> }

One problem with that, though I'm sure there are many more, is that it 
only takes the users preference for loading images into account, rather 
than any other reason for the image not loading, such as a network 
error, unsupported image format, ad blockers, etc.

A better solution would be to define a :fallback pseudo-class where the 
elements fallback content, as defined by the markup language's 
semantics, is rendered.  i.e.  the alt attribute, the content of the 
object element in (X)HTML 4.01/1.x or the content of elements with a src 
attribute in XHTML 2.  It could not, however, apply to any element that 
has only been stylisically replaced using the 'content' property in the 
style sheet for the many reasons discussed in a previous thread on 
:load-fail, etc. a few months ago.

:fallback would be useful in many cases.  For example, an image with a 
partially transparent background may be used in a document and, for 
obvious reasons, it would probably not be desirable for the element to 
have an opaque background colour.  However, when the fallback content is 
rendered it may be desirable to provide a solid background colour to 
make the text more readable.

This could be done with :fallback like this:

object, img { background-color: transparent; }
object:fallback, img:fallback { background-color: white; color: black; }

Another example: Consider an XHTML 2 table like this:
<table src="weather-graph.png" ...>
   ...
</table>

When the graph is loaded, no border may be desirable and the height and 
width may be set for the image.  However, when the graph is not loaded, 
it may be desirable to add a border to the table and leave the height 
and width as auto.

table { border: none; height: 200px; width: 300px; }
table:fallback { border: 1px solid black; height: auto; width: auto; }

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Friday, 1 July 2005 15:33:51 UTC