Re: why a different tag for SVG images?

On Thu, 6 Apr 2006, phil-news-nospam@xxxxxxxx wrote:

On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <flavell@xxxxxxxxxxxxxxxxx> wrote:
| On Tue, 4 Apr 2006, phil-news-nospam@xxxxxxxx wrote:
|
|> Why even make a new one? Why not have left <img> to do the same job for
|> all object types, and <object> be an equivalent.
|
| Heavens, no! <img ...> is - and always was - badly designed. Came
| from the house of instant gratification, not from the department of
| fundamentally sound.
|
| The ill-fated HTML/3.0 draft had already recognised that, and tried to
| introduce a <fig...> element to replace it. That, in due course,
| became the W3C part of the <object...> element. Which could have been
| used to define nested variants of an object, falling-back finally to
| properly formatted text (something which the wretched img tag's "alt"
| attribute is incapable of doing).
|
| That is, if the f*up fairy hadn't intervened, and gifted the W3C
| <object> element with the kiss of death from a proprietary vendor,
| making it essentially useless in a general web context.

So go back to <img> and fix it up.

Sorry, there seems to be some kind of misunderstanding here...

One basic step is to specify that whatever content is coming in as
specified in the src= if that content is recognized, render it as
such.

I'm not talking about whatever is at the other end of the src=
reference - but about the IMG element itself:

<!ELEMENT IMG - O EMPTY -- Embedded image -->
<!ATTLIST IMG
%attrs; -- %coreattrs, %i18n, %events --
src %URI; #REQUIRED -- URI of image to embed --
alt %Text; #REQUIRED -- short description --
longdesc %URI; #IMPLIED -- link to long description
(complements alt) --
name CDATA #IMPLIED -- name of image for scripting --
height %Length; #IMPLIED -- override height --
width %Length; #IMPLIED -- override width --
usemap %URI; #IMPLIED -- use client-side image map --
ismap (ismap) #IMPLIED -- use server-side image map --
>

You can't change that (particularly, the EMPTY content model) without
*severe* compatibility issues.

The question of what formats are supported at the far end of src= is a
different matter. Way back, for example, some browsers supported
postscript as an IMG format, but somehow that never became
sufficiently widespread to be useful. And there's no way with
<img...> that you can do anything about that, really - in theory you
could implement content negotiation, but there are enough browsers
which tell lies in their Accept: header when retrieving an <img
src=...> to make that problematic.

You can specify width and height already. Add more specifiers
to the tag if needed.

This is beside the point, I'm afraid. It isn't about adding
*attributes* (we've got enough, or more than enough, of those
already), but about /content/ for the element.

Just make it work with every known type of file
that can be rendered, including HTML itself.

I'm sorry, but it's simply not feasible to mandate all clients to
support all conceivable formats. Some will do more, and some will do
less: that's the way of the world (wide web) - SCNR.

In the absence of well-supported content negotiation (which *can* work
well in some contexts, but here I think in practice it's a lost
cause), I think the nested object approach is the nearest we've got to
a viable solution...

....with the final fallback being a properly marked-up text-mode
content body, which is *far* more useful than the desperate
limitations of an alt attribute value string.

SVG is functionally no different than any image format. It should be
just as acceptable anywhere any other image format is.

Indeed, and (out of the currently available W3C markups) that *should*
be the <object...> markup, with something useful in its element
content - instead of the fundamentally misconceived <img...> markup
with its EMPTY content model. As I've been trying to say already.

Thus, if a .jpg or a .png could be used for a background image, then
there is no reason a .svg cannot be used for the same if the browser
has .svg support active.

Background images are presentation, not content, and, as such, are not
really the business of the HTML authoring group. Whatever conclusion
you or I might agree for those, would not necessarily be relevant to
substantive content, which is the business of HTML.

[...]
| I see what you're getting at, but that isn't how it's been
| defined.

Again, definitions shouldn't stand in the way of flexibility.
Otherwise they are stupid definitions.

And <img...> seems to fit that description!

ttfn
.

Relevant Pages

  • Re: Embedding an image in the html?
    ... with html content will cause the main page's size increase extremely..... ... Microsoft Online Support ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Microsoft MVPs
    ... Because they all use HTML. ... Whether you acknowledge the need for standards ... > more than 90% of the world is still using browsers which either don't ... > care or don't support those recommendations. ...
    (microsoft.public.frontpage.client)
  • Re: Basics... addressing html elements in js
    ... Does forms showed in points 1,2,3 are most supported by different browsers? ... (also with support addresing via id attr and name attr). ... Do you know different ways of addressing elements in html and which is ...
    (comp.lang.javascript)
  • Re: does it really exist any xhtml 2?
    ... good yet -- you're better off sticking with HTML 4.01 Strict. ... we can be confident that browsers will support HTML 4.01 as long as ... validator: http://jigsaw.w3.org/css-validator/ ...
    (comp.infosystems.www.authoring.html)
  • Re: Form Email HTML options
    ... FP2003 support the same features that requires the ... Another option is to not use the FP Form Handler if you want to process form data via email in HTML ... FrontPage Resources, WebCircle, MS KB Quick Links, etc. ... > individuals that "HTML formats are NOT supported by the ...
    (microsoft.public.frontpage.client)