Re: why a different tag for SVG images?

On Fri, 7 Apr 2006 00:33:25 +0100 Alan J. Flavell <flavell@xxxxxxxxxxxxxxxxx> wrote:

|> 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.

You can't extend it? Or is the problem that an existing attribute
needs new semantics? Couldn't you just use a new different name
for the redefined attribute and depricate the old one?


| 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 could implement ANY format in which it is possible to code some
handler that can take the format's octet stream and convert it to a
pixel array for the browser to use. It should be quite obvious for
traditional image formats like GIF and JPEG. Then you can add more
simply by coding the conversion code, using the appropriate API, for
other formats like BMP, PNG, TIFF, etc. Then there is no reason you
cannot even go so far as to do this with Postscript, SVG, PDF, and
even HTML itself.


|> 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.

The image content itself? What kind of limitation is there for
that?


|> 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.

I'm not asking to mandate a format. I'm asking that there not be
any defined limitation that would prevent a client from doing so,
as the responses from some people have already indciated exists.

If SVG is NOT a required format, fine. But there should NOT be any
part of the standard that says of a browser implements SVG that it
must not allow its use in all places where images could be used.
Then it becomes an issue of the browser implementation itself, and
then I can take the issue back to the Firefox people in this case.


| 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...

Even if there is no negotiation, if the actual format that arrives is
one the browser does have a handler implemented for, nothing in the
standard should say it should not show that image.


| ...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.

I wouldn't need that fallback if image support is simply allowed to
be universal.

It seems some people are really caught up in arguing whether images
are, or are not content.


|> 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.

Nevertheless, the standard should not say that <img> should show some
formats and must not show others. If you want to move everyone over
to the <object> tag, then fine, depricate <img>. But as long as <img>
is back supported by implementations, there should be no "standards
excuse" for blocking some image formats and not others in <img> or
even in the background= attribute wherever it is implemented (whether
depricated or not).


|> 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.

That may be the idealistic way to think about it, but in the real world,
background images really do sometimes get used as content because no other
means to do that is available for some kinds of content. If you want to
move the specification of a background image to style, then provide a
new means to layer content over content. Ironically, SVG might well be
able to do that for you.

Nevertheless, the point always has been and remains that anywhere an
image can be handled, whether that is in new standard or old standards,
or even in depricated standards that are still implemented for reasons
of compatibility, then any image format that the client as implemneted
should be possible to be used. If the client supports the whole set
of BMP, GIF, JPEG, MPEG, PNG, PNM, SVG, TIFF, there should be nothing
in the standards that says it must not use certain formats. Now it may
not be practical for an implementation to handle things like animation
in background images. But the standards should be neutral on that.


| [...]
|> | 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!

So depricate all of <img>. But saying "Don't use SVG with <img>" is really
just silliness. One might not get all the power SVG is capable of without
using <object>. But SVG is capable of the basics of expressing an image
that <img> and background= are certainly capable of handling.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
.

Relevant Pages

  • Re: What do you make of SilverLight?
    ... Even Adobe abandoned it's SVG viewer. ... gained by MS contraining itself to that format. ... we see that competing standards are ...
    (borland.public.delphi.non-technical)
  • Re: [kde] smb://
    ... follow the RFC for urls which is the way standards are set. ... a format I can't handle, I ask them for it in a format I can. ... application (that costs $$$ to buy, and my time to install) under one OS ... KDE should push for some method of registering URL ...
    (KDE)
  • Re: [opensuse] document incompatibilities
    ... conform to HIS standards will win you no friends in the office. ... closed format recovering something usable in this situation was often ... took up excessive resources when it went wrong. ... environment you are in), its up to YOU to make your software ...
    (SuSE)
  • Re: Database Model - Class, objects and interaction [LONG]
    ... open info exchange format. ... normally find in a standards document. ... form than a standard API :-), but in any case I think the term is ... If there is an ODBC client C, and a database server S with ODBC ...
    (comp.object)
  • Re: Word 2003 XML
    ... So there are many sites That are written that have information Mac users could use, but can't get at it because FronTPage was used to design it, And therefore Only IE users can view it. ... If Microsoft really had made a life's work out of not using any standards, ... group chose the XML format that Microsoft adopted over the open format ...
    (microsoft.public.mac.office.word)
Loading