Re: content: url() is bad

On Wed, 14 Apr 2004 staffan.mahlen@comhem.se wrote:
>
> When testing with a long alt-text in a broken img, the nowrap of the
> alt-text used by two of three tested browsers suggests to me that the
> img alt-text is not handled as if the image was made non-replaced due to
> its alt-text being used.

This is considered a bug in Opera, as it makes the text unreadable in
cases such as:

   http://ln.hixie.ch/?start=1075242104&count=1
   http://ln.hixie.ch/?start=1081717954&count=1

With images disabled, the above two pages are near-unreadable in Opera
(which flows alt text into an inline-block box) but fine in Mozilla (which
doesn't). (Mozilla's rendering has other issues when images are disabled
but that is another story.)

In any case, if <img> doesn't convince you, try <object>, which is the
same concept.


> I suppose that solution is not workable in this case and you are more
> looking for an object replacement in CSS syntax. To fully work that it
> seems you need to allow selectors on parts of the content value (which
> might get even more interesting when text/html is being referred to...),
> and i am not quite convinced that your single image special-case is a
> good enough compromise. It might be better to "isolate" this issue to
> where it is caused and add new properties/selector for sizing the
> content value, or to special-case the text-only case instead?

Why? What is it about my proposal that doesn't work, in practice?


> The reason i prefer to view the content value as replaced is probably
> that i dislike the concept of having a pseudo-document-fragment in the
> content value

Why? It's no more than is allowed on 'content' in CSS2.


> but also because it seems to create more intuitive results in most sane
> cases. I think allowing too much power into the content value means
> mixing layers, which is what started this thread.

It doesn't mean mixing layers, although it can be used for mixing layers.
The more rope you give authors, the more likely they are to hang
themselves. But given that you need to be giving them the rope (we need
_some_ way of doing image replacement and small content substritution in
the stylesheet), they will always be able to hang themselves. So why make
the simpler cases more complicated?


> > I don't think it's an edge case at all. I think it's a very common case.
> > For example:
> >
> >    h1 { content: url(letter-X) url(letter-Y) url(letter-Z) " Company " url(logo); }
> >
> > ...to get:
> >
> >    [X][Y][Z] Company {(@)}
> >
> > ...or some such.
>
> But since the above does not rescale the contents of the h1, i would
> have thought it was no major issue to consider it "replaced" in a
> sense from the perspective of the h1 element.

I still don't know what you mean by that. If you mean "force 'display' to
'inline-block' when 'content' has a value other than 'contents'", then the
problem is that that breaks cases such as:

   abbr[title] { content: attr(title); }
   img { content: attr(alt); }

...where you _really_ want the wrapping.


> To get the issue i was considering we need something like:
>    h1 {content: "Company " url(logo); height: 50px; width: 50px}
> That is, what does the measurements do to the text if the text is
> considered part of a replaced content value. In your example the
> value of the content should have some form of intrinsic width/height.

The above would, in my version, be identical to:

   <h1>Company <img src="logo"></h1>

   h1 { height: 50px; width: 50px; }

...and could also be done like this:

   h1 { content: "Company "; height: 50px; width: 50px; }
   h1::after { content: url(logo); }


> Could this be compared to the broken image icon combined with alt- texts
> of some browsers?

To get that case with my proposal you would need but say 'display:
inline-block' when declaring the content:

   img { content: url(broken-image-icon) " " attr(alt);
         display: inline-block; border: thin inset; }

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 14 April 2004 06:02:25 UTC