473,586 Members | 2,555 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

why a different tag for SVG images?

Why does SVG need a different tag than other images?

IMHO, SVG should be implemented as an image type just like any other image
type, allowing it to work with <img> tags, and ... here is the important
part ... also work with backgrounds in other tags.

I fail to see any wisdom in making SVG different than say PNG (of course
the implementation of the rendering code would obvious be different).

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 4 '06
61 4705
ph************* *@ipal.net wrote:
I do not disagree that <img> could have a flaw. But I do disagree
that any flaw it might have requires a whole new tag to solve it.
I suspect it is more a case of a tag NAME that didn't jive with the
way things were being extended.
Then you haven't understood the problem.
I'll let you tell me about this flaw if you choose to.
The fundamental flaw is that alt content doesn't belong inside a tag, it
doesn't allow it to be marked up. Also, as the img element is currently
defined a UA is required to retrieve the resource referenced by the
'src' attribute before it is able to determine if it is able to do
anything with it.
Then if you
want, you can elaborate on how it could not be fixed without going
to a whole new tag.
<img ...>alt content</img> wouldn't be backward compatible with existing
UAs.
|>|>IMHO, SVG should be implemented as an image type just like any other image
|>|>type, allowing it to work with <img> tags, and ... here is the important
|>|>part ... also work with backgrounds in other tags.
|>|
|>| Backgrounds are not content, hence they should be specified with CSS.
|>| This requires native SVG support in browsers, the browsers that have
|>| native SVG support do not currently support SVG to be specified in CSS.
|>
|>I disagree. It is layered content ... with a limitation on layers.
|
| HTML is a language for marking up content, supplying structure and
| semantics. It has no use for, or concept of "layers". CSS on the other
| hand does.

It could have had layers if they had thought of the need for it back then.
That would be part of structure ... "this over top of that".
There is no such need from a HTML markup perspective. From a content
perspective some image formats can contain layers. You can express a
"this over top of that" structure in SVG itself if required, the HTML
only needs to refer to it as a whole. A UA can extract the layering
structure from the SVG if required.
|>Now we're moving content into CSS.
|
| Who's "we", and what do you mean by "moving content into CSS"?

Some background images are content. But it is apparent that you are
not able to see that.
The problem lies with your incorrect use of language, every layer in a
multiple layer SVG image is a content layer, there is no 'background'
layer. Backgrounds are styling by definition (also in SVG).
| It's difficult and perhaps unfeasible to automatically generate complex
| CSS, but this is due to certain flaws in CSS itself (such as collapsing
| margin behaviour), not it's syntax.

My rant on CSS here is more aimed at the XML-ize-everything proponents.
Personally, I'm not oposed to using whatever format best suits the need.
I assume the creators of CSS chose what they needed. I'm just curious
how it is they managed to resist the XML-ize-everything people. Was CSS
so early in development that it preceeded the XML-ize-everything movement?
You say that you're 'not oposed to using whatever format best suits the
need', but then you suggest that this can't be the reason for CSS's
syntax by assuming that the people who created the language wouldn't
have been able to resist the 'XML-ize-everything movement'.

FYI CSS was devised in 1995.
Do not take the above as a rant against XML. It is not. XML has a major
important place in markup. But there are a lot of uses that XML is being
put to that are just not markup of content. Ironically, SVG happens to be
one of them, IMHO (it's almost all "markup" and virtual devoid of content
if analyzed in XML terms).
That may be the case for the SVG content you've been looking at, it
doesn't reflect what SVG can contain.
But at least SVG is functional and becoming a
wide standard. SVG is usable. And if it were allowed to be used everywhere
any other image format can be used, it would be even more usable.


Imo SVG is a largely useless format, over hyped and widely
misunderstood. There are very few instances where SVG content makes
sense. For almost all images SVG is a hopelessly over complicated
technology with severe drawbacks such as client resource usage, CPU
time, memory usage, bandwidth & diskspace used etc.

--
Spartanicus
Apr 6 '06 #11
On Thu, 6 Apr 2006, ph************* *@ipal.net wrote:
On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <fl*****@physic s.gla.ac.uk> wrote:
| On Tue, 4 Apr 2006, ph************* *@ipal.net 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 misunderstandin g 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
Apr 6 '06 #12
On Thu, 06 Apr 2006 15:19:45 -0400 Harlan Messinger <hm************ *******@comcast .net> wrote:
| ph************* *@ipal.net wrote:
|> On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <fl*****@physic s.gla.ac.uk> wrote:
|> | On Tue, 4 Apr 2006, ph************* *@ipal.net 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.
|
| Why does it bother you if they created a different tag instead? Do you
| have a phobia about typing the word "object"?

It's not an issue so much of what tag, but rather, that when adding a new
image format, it should just work like all the others. The browser should
have a list of mime types, extensions, and maybe even other detection ways,
to decide what type an image is. Then when it gets such an image file
octet stream, it detects the type, invokes the handler for it, and gets
back the displayable pixel array for the image and puts it in place.

Note that this is a simplification. Real implementations of browser can
be more complex, such as many back and forth calls to the handler to show
the image continuously as it is arriving. The handler might be internal,
or a dynamically loaded library module, or a separate process. SVG should
have been added there along with other formats like BMP, GIF, JPEG, PNG,
PNM, and TIFF.

Do that, and SVG and any others would work for background images. It
would not matter whether such images are specified in HTML or CSS or
wherever else.

Actually, you could carry this on further by recognizing HTML itself as
an image format, and invoke the HTML rendering engine itself in a
recursive way (though given browser designs might not be prepared to
handle that without using a 2nd process). Of course rendering HTML in
an 8x8 pixel box might seem silly, but it could be useful in other ways.

Whether <img> or <embed> or <iframe> or <object> is used to define where
and how the images are placed should not matter to the issue of having a
complete set of image format support that leaves nothing out. Different
tags may cause other features to be better handled, such as identification
of objects for DOM manipulation of the images if the handler for that
image includes DOM support.
| By the way, you seem to be operating under the impression that <img>
| can't be used for SVGs by definition. Maybe it's because you're
| confusing several different issues--the limitations of <img>, the uses
| of <object>, etc. The issue with SVGs, if they don't work in <img> tags,
| lies with the browser. There's nothing in the spec that excludes any
| particular graphics format from being included in a document via the
| <img> tag.

I've been told by people that seem to act like they should be in the know
that SVG is incompatible with <img>. I don't know whether that was the
actual decision, or someone's misinterpretati on. I do know that there is
no _technical_ reason for incompatibility , other than for poor framework
design decisions that might exist in a browser implementation.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 10 '06 #13
On Thu, 06 Apr 2006 15:19:46 -0400 Harlan Messinger <hm************ *******@comcast .net> wrote:
| ph************* *@ipal.net wrote:
|> I'm no opposed to CSS. But I am opposed to being required to put content
|> in CSS to get it to work. That's not really CSS's fault, per se. The
|> real fault is that no _other_ way exists. If you want to get pure about
|> it, then you create a DIV section with the background content, and let CSS
|> specify it into the background. But the content itself ... and images ARE
|> content ... neds to be providable outside of the stylesheet. Just because
|> you might design pages where the background is a style (which is equally a
|> valid approach ... for example to give the page the appearance of onion
|> paper) does not mean that someone else can't be designing a page where the
|> background is content.
|
| Why would you put the content somewhere where many users will never see it?

I'm not sure what you are talking about. If you're referring to browsers
that don't support background images, then I could counter refer to browsers
that don't even support images at all. What point are yoy trying to get at?
|> It's all in the perspective of what the content is.
|
| The perspective is that the document is the content. The stylesheet is
| an optional, presentational add-on.

So. Please explain your point.
|> If the background image does little more than give a feel about the page,
|> then I can see that as being part of style. But if it provides information
|> to the viewer, then it is content,
|
| Then it isn't background.

That's the label used for the mechanism of getting the image displayed over
the entire space. Then it was also used for individual table cells. So
that's the term I use. Want to use a different term for it? Suggest one.
| By the way--who told you that there's any definition preventing SVGs
| from being used as background images? There isn't.

Unfortunately, my Usenet reader does not have a good search mechanism, and
Google Groups doesn't have a way to confine searches to a specific thread,
so it won't be easy to find who that was. I think it was here on Usenet,
but it might have been elsewhere.

It's just kind of annoying when one person tells me something, and because
it's in a subject matter I don't know much about (yet), and they seem to
act like they know, and no one follows up to refute them right then, but
then later when they are gone and I'm asking questions based on that info
as if it were true, then now I am told that isn't the way it is. I don't
blame you. It just would have been better to have you and the other person
on at the same time.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 10 '06 #14
On Fri, 7 Apr 2006 00:33:25 +0100 Alan J. Flavell <fl*****@physic s.gla.ac.uk> wrote:

|> So go back to <img> and fix it up.
|
| Sorry, there seems to be some kind of misunderstandin g 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/ |
-----------------------------------------------------------------------------
Apr 10 '06 #15
In article <e1********@new s2.newsguy.com> , ph************* *@ipal.net
wrote:
It's just kind of annoying when one person tells me something, and because
it's in a subject matter I don't know much about (yet), and they seem to
act like they know, and no one follows up to refute them right then, but
then later when they are gone and I'm asking questions based on that info
as if it were true, then now I am told that isn't the way it is. I don't
blame you. It just would have been better to have you and the other person
on at the same time.


Welcome to Usenet. This is how it works. It's up to you to figure the
whole thing out. There are no comfortable immediate answers if you're
not familiar with the poster. There may be valuable disagreement if you
are.
Don't be discouraged. Learn and eventually teach.

leo

--
<http://web0.greatbasin .net/~leo/>
Apr 10 '06 #16
On Thu, 06 Apr 2006 21:28:21 GMT Spartanicus <in*****@invali d.invalid> wrote:
| ph************* *@ipal.net wrote:
|
|>I do not disagree that <img> could have a flaw. But I do disagree
|>that any flaw it might have requires a whole new tag to solve it.
|>I suspect it is more a case of a tag NAME that didn't jive with the
|>way things were being extended.
|
| Then you haven't understood the problem.

Then explain it.
|>I'll let you tell me about this flaw if you choose to.
|
| The fundamental flaw is that alt content doesn't belong inside a tag, it
| doesn't allow it to be marked up. Also, as the img element is currently
| defined a UA is required to retrieve the resource referenced by the
| 'src' attribute before it is able to determine if it is able to do
| anything with it.

The fact that the alt attribute was poorly designed has nothing to do
with saying that GIF and JPEG are allowed and SVG is not. If this means
<img> has to be depricated so be it. Or just depricate alt= and add a
new way to get marked up alt content.

The fact that the UA has to fetch the content to discover if it can
use it or not is also a problem that has nothing to do with allowing
or disallowing one format over another. If the UA gets an <img> in
its document, fetches the data, finds that the mime type says it is
SVG (or if the mime type is absent, the extension at the end of the
URI is what it recognizes as SVG), and if the UA has an impementation
of the SVG format, why should the standard say that SVG should not be
displable?

Could <img> have been fixed up to do what you want of it? I don't
know what all you want of it, so I can't say for sure. But what you
describe so far doesn't sound so hard to do with just extensions to
the existing <img>.

But that's beside the point that as long as <img> is used, there is
really no reason to prohibit use of certain image formats. Just go
ahead and depricate <img> if you need to. Then it's a legacy tag
and probably will be used for years to come, anyway. But there
should be any silly limitations applied to it.
|>Then if you
|>want, you can elaborate on how it could not be fixed without going
|>to a whole new tag.
|
| <img ...>alt content</img> wouldn't be backward compatible with existing
| UAs.

OK, I can see how I would have missed that, as I have never used, and
see hardly ever any need for, alt content. But just because I don't
have a need for something like this, that does not mean others do not.

So we have 2 tags and one allows alt content. Now let's get back to SVG.
A browser has an implementation of the SVG image format. It sees an <img>
tag. It gets the src= data for that. It discovers it is SVG format.
By what reason should a standard say not to display that SVG image?
|>It could have had layers if they had thought of the need for it back then.
|>That would be part of structure ... "this over top of that".
|
| There is no such need from a HTML markup perspective. From a content
| perspective some image formats can contain layers. You can express a
| "this over top of that" structure in SVG itself if required, the HTML
| only needs to refer to it as a whole. A UA can extract the layering
| structure from the SVG if required.

That might work if SVG is allowed to reference instances of HTML
and specify they be rendered over top each other, or at least one
of the layers being HTML.

And this will become a required part of the standard when?
|>|>Now we're moving content into CSS.
|>|
|>| Who's "we", and what do you mean by "moving content into CSS"?
|>
|>Some background images are content. But it is apparent that you are
|>not able to see that.
|
| The problem lies with your incorrect use of language, every layer in a
| multiple layer SVG image is a content layer, there is no 'background'
| layer. Backgrounds are styling by definition (also in SVG).

It is not my incorrect use of the language. It is incorrect use of
the terminology by previous standards that I am referrencing. The
fact that there is/was a background= attribute is the basis of my use
of that term. simply because it (then) was the only means to do any
level of layering.

But it is content, despite what the intended uses were, in instances
where content can only be expressed by using that method.
|>| It's difficult and perhaps unfeasible to automatically generate complex
|>| CSS, but this is due to certain flaws in CSS itself (such as collapsing
|>| margin behaviour), not it's syntax.
|>
|>My rant on CSS here is more aimed at the XML-ize-everything proponents.
|>Personally, I'm not oposed to using whatever format best suits the need.
|>I assume the creators of CSS chose what they needed. I'm just curious
|>how it is they managed to resist the XML-ize-everything people. Was CSS
|>so early in development that it preceeded the XML-ize-everything movement?
|
| You say that you're 'not oposed to using whatever format best suits the
| need', but then you suggest that this can't be the reason for CSS's
| syntax by assuming that the people who created the language wouldn't
| have been able to resist the 'XML-ize-everything movement'.
|
| FYI CSS was devised in 1995.

And CSS has had a long hard rocky road to being workable. How much
of that was CSS's fault I don't really know. I do know that browser
implementations were getting it wrong a lot. But whether that is
ambiguous standards causing it, or just bad browser programming, is
not entirely clear. I'm inclined to lean to the bad programming,
though, because it was the case that past browsers would do some awful
things with apparently valid CSS, such as corrupt their virtual memory
space and crash. That's one reason I avoided CSS for so long, because
implementations of browsers through Netscape 4 made it essentially
unusable. And from Netscape 4 until recent Firefox, the browsers
themselves were terrible (for example way too slow rendering).

So what is the reason SVG is XML based? So it can be a document that
DOM can be used on? That's great. So has anyone considered doing
the same thing with the style itself?
|>Do not take the above as a rant against XML. It is not. XML has a major
|>important place in markup. But there are a lot of uses that XML is being
|>put to that are just not markup of content. Ironically, SVG happens to be
|>one of them, IMHO (it's almost all "markup" and virtual devoid of content
|>if analyzed in XML terms).
|
| That may be the case for the SVG content you've been looking at, it
| doesn't reflect what SVG can contain.

OK.

But basic images, things like simple buttons and stuff, that could be
better done as vector rather than raster, could benefit from some new
file format that is vector based like SVG, but simpler than SVG. I do
have an idea. Maybe I might even implement it some day.
|>But at least SVG is functional and becoming a
|>wide standard. SVG is usable. And if it were allowed to be used everywhere
|>any other image format can be used, it would be even more usable.
|
| Imo SVG is a largely useless format, over hyped and widely
| misunderstood. There are very few instances where SVG content makes
| sense. For almost all images SVG is a hopelessly over complicated
| technology with severe drawbacks such as client resource usage, CPU
| time, memory usage, bandwidth & diskspace used etc.

Then maybe I should pursue my simpler format. It would not be as
complex as SVG. But it would provide basic vector style formatting
of imaging like buttons with color gradients. I guess I can't use
the name "Simple Vector Graphics" though :-)

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 10 '06 #17
On Thu, 06 Apr 2006 15:16:39 -0400 Harlan Messinger <hm************ *******@comcast .net> wrote:
| ph************* *@ipal.net wrote:
|> On Tue, 04 Apr 2006 06:10:36 GMT Spartanicus <in*****@invali d.invalid> wrote:
|> | ph************* *@ipal.net wrote:
|> |>IMHO, SVG should be implemented as an image type just like any other image
|> |>type, allowing it to work with <img> tags, and ... here is the important
|> |>part ... also work with backgrounds in other tags.
|> |
|> | Backgrounds are not content, hence they should be specified with CSS.
|> | This requires native SVG support in browsers, the browsers that have
|> | native SVG support do not currently support SVG to be specified in CSS.
|>
|> I disagree. It is layered content ... with a limitation on layers.
|
| Layered content is handled using position: absolute and the z-index
| property. Background-image is for backgrounds, which shouldn't be used
| for content (unless you don't mind users not seeing your content, but
| then that's a funny sort of content if you don't mind whether or not
| it's seen).

I mind. It's just that without layered content, no other means existed
but background, and I simply had to specify that you don't get to see
all the content unless you use a browser/environment that supports it.
So if you use Lynx on a text console or TTY, you're SOL for that content.
|> And then it becomes immensely complex to have to put a tag name on
|> every table cell and associate it with a specification in CSS that is
|> only useful for that one page.
|
| I'm afraid I can't imagine the scenario you're talking about here.

How would you specify a different image for each cell if you have to put
all the image references in CSS?
|> CSS should be a general template, not
|> something that has to be custom made for each complex page.
|
| It is. Who said it isn't?

If the images have to be specified in CSS, then pages where each page
has different images then needs different CSS.

--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
Apr 10 '06 #18
ph************* *@ipal.net wrote:
| <img ...>alt content</img> wouldn't be backward compatible with existing
| UAs.

OK, I can see how I would have missed that, as I have never used, and
see hardly ever any need for, alt content. But just because I don't
have a need for something like this, that does not mean others do not.
Your content has a need for it, unfortunately you do not seem to realise
this.
So we have 2 tags and one allows alt content.
Both do, one in a fundamentally broken manner, the other in line with
the way most of the rest of HTML works.
Now let's get back to SVG.
A browser has an implementation of the SVG image format. It sees an <img>
tag. It gets the src= data for that. It discovers it is SVG format.
By what reason should a standard say not to display that SVG image?
As you were told before, the specs do not say that this shouldn't work.
I'm not aware of a browser that supports SVG like that, but it's nothing
to do with the specs.

The issue thus has nothing to do with SVG.
|>It could have had layers if they had thought of the need for it back then.
|>That would be part of structure ... "this over top of that".
|
| There is no such need from a HTML markup perspective. From a content
| perspective some image formats can contain layers. You can express a
| "this over top of that" structure in SVG itself if required, the HTML
| only needs to refer to it as a whole. A UA can extract the layering
| structure from the SVG if required.

That might work if SVG is allowed to reference instances of HTML
and specify they be rendered over top each other, or at least one
of the layers being HTML.

And this will become a required part of the standard when?
A mixed namespace document containing both SVG and XHTML can be
referenced from a HTML document. This allows expression of any layer
structure between the XHTML and the SVG content.

But feel free to draw up and submit a use case that demonstrates that
there is a need for expressing a layer structure whereby some layers are
in an SVG referenced by an HTML document, where other layers are in the
HTML document.
|>|>Now we're moving content into CSS.
|>|
|>| Who's "we", and what do you mean by "moving content into CSS"?
|>
|>Some background images are content. But it is apparent that you are
|>not able to see that.
|
| The problem lies with your incorrect use of language, every layer in a
| multiple layer SVG image is a content layer, there is no 'background'
| layer. Backgrounds are styling by definition (also in SVG).

It is not my incorrect use of the language. It is incorrect use of
the terminology by previous standards that I am referrencing. The
fact that there is/was a background= attribute is the basis of my use
of that term. simply because it (then) was the only means to do any
level of layering.
The inclusion of presentational attributes in some versions of HTML does
not mean that these attributes referred to content. Again, backgrounds
are always presentational.
But it is content, despite what the intended uses were, in instances
where content can only be expressed by using that method.
Again, using backgrounds to fake content only demonstrates flawed
authoring, it has no relevance on the status of backgrounds.
| FYI CSS was devised in 1995.

And CSS has had a long hard rocky road to being workable. How much
of that was CSS's fault I don't really know. I do know that browser
implementation s were getting it wrong a lot. But whether that is
ambiguous standards causing it, or just bad browser programming, is
not entirely clear.
It's caused by a lack of a normative comprehensive test case suite,
overly complex standards, implementors cherry picking features and
lastly browser bugs.
I'm inclined to lean to the bad programming,
though, because it was the case that past browsers would do some awful
things with apparently valid CSS, such as corrupt their virtual memory
space and crash. That's one reason I avoided CSS for so long, because
implementation s of browsers through Netscape 4 made it essentially
unusable.
It's been a long time since anyone tried to use NS4 as an argument
against CSS. Way back when NS4 was vaguely relevant the accepted
practice was to hide all CSS from it, this worked fine.
And from Netscape 4 until recent Firefox, the browsers
themselves were terrible (for example way too slow rendering).
No idea what browsers you are referring to. Opera, IE, KHTML based
browsers (Safari, Konqueror) and iCab are fast. Mozilla is only a little
slower than Firefox, for the latter two this is likely only noticeable
on slower hardware (like mine).
But basic images, things like simple buttons and stuff, that could be
better done as vector rather than raster, could benefit from some new
file format that is vector based like SVG, but simpler than SVG. I do
have an idea. Maybe I might even implement it some day.
Form elements like buttons should be drawn by the OS. (Web) Application
specific UI elements generally constitutes poor usability.
| Imo SVG is a largely useless format, over hyped and widely
| misunderstood. There are very few instances where SVG content makes
| sense. For almost all images SVG is a hopelessly over complicated
| technology with severe drawbacks such as client resource usage, CPU
| time, memory usage, bandwidth & diskspace used etc.

Then maybe I should pursue my simpler format. It would not be as
complex as SVG.


Vector content is a solution to a problem that hardly exists.

--
Spartanicus
Apr 10 '06 #19
Spartanicus wrote:

Vector content is a solution to a problem that hardly exists.


You've made this claim several times now, in different ways and in
different places - for example in this thread:
http://makeashorterlink.com/?H13C62FEC

You've said that it's too CPU-intensive to render; hopelessly
over-complicated; and expensive in terms of bandwidth and disk. I don't
see it, and you haven't substantiated these remarks in any of the places
I've read them - in each case, they were just asssertions.

As a format for hand-coding a graphic, I grant that SVG is close to
useless; but that's not how I think it's supposed to be used. SVG
permits a graphic to be represented as structured data that can easily
be stretched, re-purposed, dismantled and reassembled, and perhaps most
importantly marked-up.

Can you please therefore explain why you think adding SVG images to HTML
is such a bad idea? Note: I'm not interested in any deficiencies that
might be exhibited by the Adobe plugin, I'd like to know what substance
there is to your objections *in principle*.

--
Jack.
Apr 10 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
3198
by: Spike | last post by:
Hello! Im going to make a javascript for changing alot of images. But im not sure how to do it., where to start.. Ok, first.. this is the isue. I have 3 images(I call them 1a-3a). when u click on image 1a u change" image x" to image 1a when u click on image 2a u change" image x" to image 2a when u click on image 3a u change" image x" to...
1
4996
by: RugbyTravis | last post by:
I want to have a list that is horizontal and each <li> has different images. I also want them to change on hover. I want the words to be below the images as well. Anyone of you styles gurus have any words of wisdom? Please! :-) Here is what I have so far. <!--styles--> ul#mainNav{ font: bold 80% Verdana;
3
12267
by: src_mag | last post by:
Hello, I'd like to write JavaScript code that refreshes a frame once a second loading a different image each time. Basically, here's what the script would do: 0 sec load img0.gif 1 sec load img1.gif 2 sec load img2.gif 3 sec load img0.gif (back to the first image) 4 sec load img1.gif
4
1961
by: DanielEKFA | last post by:
Hey hey :) Having a lot of problems with this. I'm helping my brother out with this art school web page. He has a big wish to have random images from the web shown in the background, and asked me to help him out. My idea is this: Use the CNN Top Stories RSS feed to harvest keywords, then use a random keyword from this harvest to search...
5
5350
by: Axel | last post by:
An Access 2000 question Hi is is possible to have (as a subform) a continous form with 0..n buttons which have different images in each row. (Personally I would have preferred a button array and assign images in code, much easier with a class module - but unfortunately Access does not support control arrays).
0
5368
by: ghadley_00 | last post by:
MS Access Create form / report with multiple pages using different background images Hi, Would like to have users fill out a multipage form, and then click a print button, which pulls up the info just entered for a particular record and print out multiple pages of forms, each page having a different image as background.
6
1490
by: Kent P. Iler | last post by:
Hi, I am trying to reference images from an images directory immediately off the root level. The problem is that on my dev machine, the url is <machine>/hbmlocal/images, and on the production server, the url is <machine>/images I've tried using the "~" operator along with runat="server", and that works most of the time. However, I have...
6
3486
by: NutsAboutVB | last post by:
Hello, I am a .NET programmer and I have a JPEG image file (from digital camera) of about 109 KB's in size, when I open it and save it (without making any alterations at all, just going to File --> Save) in MS Photo Editor, the file is automatically shrunk in size to 81 KB's. When doing the same thing in MS Paint, the file is shrunk to 54...
0
7839
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8202
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
1
7959
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
8216
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6614
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
5390
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3837
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3865
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2345
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.