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/ |
----------------------------------------------------------------------------- 61  4623  ph**************@ipal.net wrote: Why does SVG need a different tag than other images?
It doesn't from a spec perspective, in theory all embedded content
should use the <object> element. Due to IE's poor support for embedding
gif, png and jpeg with that element the <img> element is still widely
used.
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.
--
Spartanicus
On Tue, 04 Apr 2006 06:10:36 GMT Spartanicus <in*****@invalid.invalid> wrote:
| ph**************@ipal.net wrote:
|
|>Why does SVG need a different tag than other images?
|
| It doesn't from a spec perspective, in theory all embedded content
| should use the <object> element. Due to IE's poor support for embedding
| gif, png and jpeg with that element the <img> element is still widely
| used.
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.
|>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.
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. CSS should be a general template, not
something that has to be custom made for each complex page. That's
what it was original intended for. What we have today is so bastardized.
It should be possible to let the end user at the client have their own
CSS and it function correctly with any given page. That was the ideal
state when CSS was first being born in the 1990's. Seems someone forgot
all that along the way. Now we're moving content into CSS.
And while on CSS, why wasn't it made with an XML style syntax? If XML is
good enough for just about everything else these days, why not for CSS?
One of the big problems with complex structured sites being dynamically
generated is the complexity of generating 2 simultaneous output streams.
It's bad enough that 2 streams (HTML and CSS) have to be generated (and
usually generated in separate instances, which makes it all that much
harder to keep them in sync when dynamic content is changing at every
second), but normal XML tools cannot be used to generate CSS.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
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.
|>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.
(sorry about the disformatting there - my fault)
I disagree.
It's not a matter of agreeing or disagreeing - it's a consequence of
the way things have been defined.
It is layered content ... with a limitation on layers.
I see what you're getting at, but that isn't how it's been defined.
You'd have to start a whole new development if you wanted to get what
you're describing there. At the moment, I'd say the "separation of
presentation from content" is doing what it says on the tin; some of
us think that's working well, while others feel that it's defeating
their ability to guarantee their attempts at DTP presentation.
It should be possible to let the end user at the client have their
own CSS and it function correctly with any given page. That was the
ideal state when CSS was first being born in the 1990's.
....and we're getting back there, despite all the harm that was done by
HTML/3.2 and proprietary geegaws in the meantime...
Seems someone forgot all that along the way. Now we're moving
content into CSS.
I don't think so. Those who are trying that on are generally rated to
be in error, anyway. (x)HTML is for the content, the stylesheet is
meant for the presentation.
[...snipped questions that I'm not moved to comment on...]
Nobody said at the outset that the stylesheet *had* to be CSS. There
were other possibilities mooted. But CSS is currently what we get to
choose from - whatever your opinion of it may be. ph**************@ipal.net wrote: |>Why does SVG need a different tag than other images?
|
| It doesn't from a spec perspective, in theory all embedded content
| should use the <object> element. Due to IE's poor support for embedding
| gif, png and jpeg with that element the <img> element is still widely
| used.
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.
<img> has a fundamental flaw, <object> solves that.
|>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.
Perhaps you are one of many who is used to abusing background images to
fake content, that however does not make background images 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. CSS should be a general template, not
something that has to be custom made for each complex page. That's
what it was original intended for. What we have today is so bastardized.
It should be possible to let the end user at the client have their own
CSS and it function correctly with any given page. That was the ideal
state when CSS was first being born in the 1990's. Seems someone
forgot all that along the way.
No one "forgot",
1) The one CSS component that allows for true separation of markup code
and styling code is selectors. IE's poor support for CSS selectors is
partially to blame for the more intricate relationship between markup
code and styling code than is needed.
2) CSS2 selectors have limited functionality, modern design requires
more than what can be achieved by using CSS2 selectors, this is the
other reason for the greater relationship between markup code and
styling code.
Now we're moving content into CSS.
Who's "we", and what do you mean by "moving content into CSS"?
And while on CSS, why wasn't it made with an XML style syntax? If XML is
good enough for just about everything else these days, why not for CSS?
One of the big problems with complex structured sites being dynamically
generated is the complexity of generating 2 simultaneous output streams.
It's bad enough that 2 streams (HTML and CSS) have to be generated (and
usually generated in separate instances, which makes it all that much
harder to keep them in sync when dynamic content is changing at every
second), but normal XML tools cannot be used to generate CSS.
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.
--
Spartanicus
On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <fl*****@physics.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.
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. You can specify width and height already. Add more specifiers
to the tag if needed. Just make it work with every known type of file
that can be rendered, including HTML itself.
|> |>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.
|
| (sorry about the disformatting there - my fault)
|
|> I disagree.
|
| It's not a matter of agreeing or disagreeing - it's a consequence of
| the way things have been defined.
It would have been smarter to define things such that in every case of
any content to be rendered anywhere, that every known and supportable
(e.g. renderable) format be accepted.
SVG is functionally no different than any image format. It should be
just as acceptable anywhere any other image format is. It's really not
even about the standard. An implementation should just do this. If
something calls for something else to be rendered in a certain place,
that should just happen if it recognizes the format and has rendering
code (integrated, plugin, dynamic module, etc) available to do so.
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. Definitions should never stand in the way of
that.
|> It is layered content ... with a limitation on layers.
|
| 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.
| You'd have to start a whole new development if you wanted to get what
| you're describing there. At the moment, I'd say the "separation of
| presentation from content" is doing what it says on the tin; some of
| us think that's working well, while others feel that it's defeating
| their ability to guarantee their attempts at DTP presentation.
There's no reason, aside from a few definition addicts standing in the
way, that both goals cannot be accomplished.
|> It should be possible to let the end user at the client have their
|> own CSS and it function correctly with any given page. That was the
|> ideal state when CSS was first being born in the 1990's.
|
| ...and we're getting back there, despite all the harm that was done by
| HTML/3.2 and proprietary geegaws in the meantime...
I don't see HTML/3.2 as a harm. It certainly was a stray branch off in
a wild direction of chaos and disorder. But it was also a learning tool.
We move on while HTML/3.2 can still be supported separately for resons
of compatibility. And when a browser acquires new image format support,
that support should also work even in HTML/3.2 ... accessing renderers
for image formats should be transparent of how the image was requested,
aside from additional meta data or parameters that may be provided from
newer methods.
|> Seems someone forgot all that along the way. Now we're moving
|> content into CSS.
|
| I don't think so. Those who are trying that on are generally rated to
| be in error, anyway. (x)HTML is for the content, the stylesheet is
| meant for the presentation.
|
| [...snipped questions that I'm not moved to comment on...]
|
| Nobody said at the outset that the stylesheet *had* to be CSS. There
| were other possibilities mooted. But CSS is currently what we get to
| choose from - whatever your opinion of it may be.
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. It's all in the perspective of what the content is.
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, absolutely so (and should not be done in
CSS other than to manage the placement of it in a general way for all pages
of that style).
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Tue, 04 Apr 2006 19:25:01 GMT Spartanicus <in*****@invalid.invalid> wrote:
| ph**************@ipal.net wrote:
|
|>|>Why does SVG need a different tag than other images?
|>|
|>| It doesn't from a spec perspective, in theory all embedded content
|>| should use the <object> element. Due to IE's poor support for embedding
|>| gif, png and jpeg with that element the <img> element is still widely
|>| used.
|>
|>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.
|
| <img> has a fundamental flaw, <object> solves that.
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.
I'll let you tell me about this flaw if you choose to. Then if you
want, you can elaborate on how it could not be fixed without going
to a whole new tag.
|>|>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".
| Perhaps you are one of many who is used to abusing background images to
| fake content, that however does not make background images content.
Or I can be one who actually has content overlaying content and have
to use background images because that's the ONLY means provided to do
it in a consistent manner.
I sense you dislike background images.
|>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. CSS should be a general template, not
|>something that has to be custom made for each complex page. That's
|>what it was original intended for. What we have today is so bastardized.
|>
|>It should be possible to let the end user at the client have their own
|>CSS and it function correctly with any given page. That was the ideal
|>state when CSS was first being born in the 1990's. Seems someone
|>forgot all that along the way.
|
| No one "forgot",
|
| 1) The one CSS component that allows for true separation of markup code
| and styling code is selectors. IE's poor support for CSS selectors is
| partially to blame for the more intricate relationship between markup
| code and styling code than is needed.
| 2) CSS2 selectors have limited functionality, modern design requires
| more than what can be achieved by using CSS2 selectors, this is the
| other reason for the greater relationship between markup code and
| styling code.
|
|>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.
|>And while on CSS, why wasn't it made with an XML style syntax? If XML is
|>good enough for just about everything else these days, why not for CSS?
|>One of the big problems with complex structured sites being dynamically
|>generated is the complexity of generating 2 simultaneous output streams.
|>It's bad enough that 2 streams (HTML and CSS) have to be generated (and
|>usually generated in separate instances, which makes it all that much
|>harder to keep them in sync when dynamic content is changing at every
|>second), but normal XML tools cannot be used to generate CSS.
|
| 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?
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). 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.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: On Tue, 04 Apr 2006 06:10:36 GMT Spartanicus <in*****@invalid.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).
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.
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? ph**************@ipal.net wrote: On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <fl*****@physics.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"?
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. 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?
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.
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.
By the way--who told you that there's any definition preventing SVGs
from being used as background images? There isn't. 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
On Thu, 6 Apr 2006, ph**************@ipal.net wrote: On Tue, 4 Apr 2006 20:13:41 +0100 Alan J. Flavell <fl*****@physics.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 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
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*****@physics.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 misinterpretation. 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/ |
-----------------------------------------------------------------------------
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/ |
-----------------------------------------------------------------------------
On Fri, 7 Apr 2006 00:33:25 +0100 Alan J. Flavell <fl*****@physics.gla.ac.uk> 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/ |
-----------------------------------------------------------------------------
In article <e1********@news2.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/>
On Thu, 06 Apr 2006 21:28:21 GMT Spartanicus <in*****@invalid.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/ |
-----------------------------------------------------------------------------
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*****@invalid.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/ |
----------------------------------------------------------------------------- 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
implementations 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
implementations 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
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.
Jack <mr*********@nospam.jackpot.uk.net> 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.
That a vector format requires significantly more CPU resources compared
to a bitmapped resource should be obvious. SVG parsing and rendering
requires significantly more CPU and memory resources. The uncompressing
routines required for bitmapped resources are much easier on the CPU and
memory. This becomes very obvious if you try SVG rendering on a resource
strapped device such as a mobile phone. They handle bitmapped resources
without a noticeable rendering delay, the same cannot be said for SVG.
For the bandwidth & disk space issue I refer to the size of a simple
image of a butterfly:
SVG: http://www.spartanicus.utvinternet.ie/embed.htm#svg 33854 bytes
PNG: http://www.spartanicus.utvinternet.ie/embed.htm#img 6333 bytes
This ratio between the bitmapped and vector images increases
significantly for more complex images.
The PNG image can be blown up to a 678x441 size and still weigh in below
the size of the same image in SVG format:
http://homepage.ntlworld.ie/spartani...rfly_large.png 24148
bytes
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.
Where did I claim otherwise?
SVG
permits a graphic to be represented as structured data that can easily
be stretched,
SVG is useless for the image type most used on the web: photo realistic
images. For the few remaining images, rare cases excepted, there is no
need or real advantage to these images being resizable without a few
artifacts.
re-purposed, dismantled and reassembled
Rarely is that an advantage to a *client*. It _is_ an advantage to the
*author*, but for almost all purposes the same can be achieved by
keeping oversized versions of bitmapped images.
and perhaps most
importantly marked-up.
There are very few cases where a UA like an SE bot could conceivably do
anything useful by parsing and indexing graphic SVG content. For SE's
and for non visual renderers such as speaking browsers for most cases it
is far more preferable to have them index and/or render the textual
alternative for the entire object supplied in the HTML.
--
Spartanicus
Spartanicus wrote: Jack <mr*********@nospam.jackpot.uk.net> 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.
That a vector format requires significantly more CPU resources
compared to a bitmapped resource should be obvious.
It depends what you mean by "significantly". Ten times the CPU resources
is not 'significant', if the original CPU utilisation was (say) 0.1%.
SVG parsing and rendering requires significantly more CPU and memory
resources. The uncompressing routines required for bitmapped
resources are much easier on the CPU and memory.
That would depend on the size of the image (in the case of a compresswed
bitmap), and the complexity of the drawing (in the case of a SVG
graphic). That is, there would appear to be a pay-off calculation there.
This becomes very obvious if you try SVG rendering on a resource
strapped device such as a mobile phone. They handle bitmapped
resources without a noticeable rendering delay, the same cannot be
said for SVG.
I haven't looked into the implementations of SVG on mobile devices, but
if they bear any resemblance to the only desktop implementation I have
experience of (Adobe), then it could be said that there is 'scope for
optimisation'.
For the bandwidth & disk space issue I refer to the size of a simple
image of a butterfly: SVG:
http://www.spartanicus.utvinternet.ie/embed.htm#svg 33854 bytes PNG:
http://www.spartanicus.utvinternet.ie/embed.htm#img 6333 bytes
But that is an extremely complex image, considered as a vector image. It
contains a multitude of paths, nearly all of which are ad-hoc curves.
There are no regular geometric shapes, which is the construct that
vector drawings are best at.
This ratio between the bitmapped and vector images increases
significantly for more complex images.
Of course; but were I to take a representation of a bar-chart, for
example, or perhaps a diagram of a network, it might well have shown the
opposite ratio of storage requirements (depending on what bitmap format
I had chosen to compare with).
Meanwhile, there is no benefit in being able to decompose and re-purpose
a butterfly's wing; but decomposing and re-purposing components of a
network diagram seems to me to be a completely reasonable aim, and one
that might even justify increased network bandwidth, if that was indeed
needed.
The PNG image can be blown up to a 678x441 size and still weigh in
below the size of the same image in SVG format:
http://homepage.ntlworld.ie/spartani...rfly_large.png
24148 bytes
That is not a blown-up representation of the smaller PNG image; it is a
different image. It took 3 seconds between the display of the first
third to full rendition, on my 800MHz system. 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.
Where did I claim otherwise?
SVG permits a graphic to be represented as structured data that can
easily be stretched,
SVG is useless for the image type most used on the web: photo
realistic images. For the few remaining images, rare cases excepted,
there is no need or real advantage to these images being resizable
without a few artifacts.
It may be that 'most' images on the web are actually photos; but a
significant (that word again) proportion are not. re-purposed, dismantled and reassembled
Rarely is that an advantage to a *client*. It _is_ an advantage to
the *author*, but for almost all purposes the same can be achieved by
keeping oversized versions of bitmapped images.
Many people snarf images from the web for re-use in their own materials.
Many more would do so, if images were routinely represented in a way
which made that easier. and perhaps most importantly marked-up.
There are very few cases where a UA like an SE bot could conceivably
do anything useful by parsing and indexing graphic SVG content. For
SE's and for non visual renderers such as speaking browsers for most
cases it is far more preferable to have them index and/or render the
textual alternative for the entire object supplied in the HTML.
I certainly didn't have in mind a search-engine, for example using
markup in an image to improve rankings. I had in mind more interesting
possibilities; for example, an SVG could be marked-up in such a way as
to make possible multiple views of the same diagram, or to allow
captions to be internationalised. Of course, butterflys don't have
captions; but bar-charts and network diagrams do.
I frequently run across technical documents on the web, in which all the
diagrams have been rasterised, because there is no viable alternative.
The result is an image that scales badly, in which the captions cannot
readily be extracted or altered. Rasters are the wrong medium for that
kind of image.
--
Jack. ph**************@ipal.net wrote: 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?
I mean that CSS is optional. If you have material that should be content
in a background image, then any user who has CSS switched off or is
overriding background images with his own stylesheet or is using a
text-based browser won't see your content. Also, if you care about
search engines, then search engines absolutely won't see it.
Jack <mr*********@nospam.jackpot.uk.net> wrote: 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.
That a vector format requires significantly more CPU resources
compared to a bitmapped resource should be obvious.
It depends what you mean by "significantly". Ten times the CPU resources
is not 'significant', if the original CPU utilisation was (say) 0.1%.
Typical for those who only consider a particular rendering platform,
usually their own desktop system. There are other clients that do not
have the luxury of such abundant resources.
SVG parsing and rendering requires significantly more CPU and memory
resources. The uncompressing routines required for bitmapped
resources are much easier on the CPU and memory.
That would depend on the size of the image (in the case of a compresswed
bitmap), and the complexity of the drawing (in the case of a SVG
graphic). That is, there would appear to be a pay-off calculation there.
Other things being equal, SVG will always use considerably more CPU
resources relative to a bitmapped image.
This becomes very obvious if you try SVG rendering on a resource
strapped device such as a mobile phone. They handle bitmapped
resources without a noticeable rendering delay, the same cannot be
said for SVG.
I haven't looked into the implementations of SVG on mobile devices, but
if they bear any resemblance to the only desktop implementation I have
experience of (Adobe), then it could be said that there is 'scope for
optimisation'.
I rarely use the Adobe plugin, my observations are based on the Opera 9
previews and Firefox. Opera is quite fast compared to Firefox, but SVG
rendering is still clearly slower than comparable bitmapped images,
particularly so on resource strapped devices.
For the bandwidth & disk space issue I refer to the size of a simple
image of a butterfly: SVG:
http://www.spartanicus.utvinternet.ie/embed.htm#svg 33854 bytes PNG:
http://www.spartanicus.utvinternet.ie/embed.htm#img 6333 bytes
But that is an extremely complex image, considered as a vector image. It
contains a multitude of paths, nearly all of which are ad-hoc curves.
There are no regular geometric shapes, which is the construct that
vector drawings are best at.
This ratio between the bitmapped and vector images increases
significantly for more complex images.
Of course; but were I to take a representation of a bar-chart, for
example, or perhaps a diagram of a network, it might well have shown the
opposite ratio of storage requirements (depending on what bitmap format
I had chosen to compare with).
Other things being equal, only by using multiple gradients on simple
shapes can I get the size of an SVG image somewhat below that of a
bitmapped representation at a size that can reasonably be expected to be
used on a web page.
The size of images of bar graphs is in my experience at least as good
with bitmaps as with SVG, frequently better.
Meanwhile, there is no benefit in being able to decompose and re-purpose
a butterfly's wing; but decomposing and re-purposing components of a
network diagram seems to me to be a completely reasonable aim, and one
that might even justify increased network bandwidth, if that was indeed
needed.
That type of usage requirement is pretty exotic, it falls well within
the "very few instances" in my claim that "There are very few instances
where SVG content makes sense."
The PNG image can be blown up to a 678x441 size and still weigh in
below the size of the same image in SVG format:
http://homepage.ntlworld.ie/spartani...rfly_large.png
24148 bytes
That is not a blown-up representation of the smaller PNG image; it is a
different image.
To keep the other parameters equal necessary for a fair comparison it is
a screencap of the SVG rendering of the same object displayed at that
same size.
It took 3 seconds between the display of the first
third to full rendition, on my 800MHz system.
Don't know what problems your system has, it doesn't show a noticeable
rendering delay on my PII/266.
SVG is useless for the image type most used on the web: photo
realistic images. For the few remaining images, rare cases excepted,
there is no need or real advantage to these images being resizable
without a few artifacts.
It may be that 'most' images on the web are actually photos; but a
significant (that word again) proportion are not.
That doesn't mean that such images benefit from the ability to zoom or
edit them.
re-purposed, dismantled and reassembled
Rarely is that an advantage to a *client*. It _is_ an advantage to
the *author*, but for almost all purposes the same can be achieved by
keeping oversized versions of bitmapped images.
Many people snarf images from the web for re-use in their own materials.
Many more would do so, if images were routinely represented in a way
which made that easier.
For photo realistic images perhaps, unlikely to be the case for bar
graphs and gradient backgrounds. Plus, unlike your network diagram that
a user needs to edit example, I don't see it as a valid requirement to
facilitate such usage.
and perhaps most importantly marked-up.
There are very few cases where a UA like an SE bot could conceivably
do anything useful by parsing and indexing graphic SVG content. For
SE's and for non visual renderers such as speaking browsers for most
cases it is far more preferable to have them index and/or render the
textual alternative for the entire object supplied in the HTML.
I certainly didn't have in mind a search-engine, for example using
markup in an image to improve rankings. I had in mind more interesting
possibilities; for example, an SVG could be marked-up in such a way as
to make possible multiple views of the same diagram, or to allow
captions to be internationalised. Of course, butterflys don't have
captions; but bar-charts and network diagrams do.
We are in exotic territory again. Also, captions don't need to be part
of the image content, they can be placed below the graphic in the HTML.
I frequently run across technical documents on the web, in which all the
diagrams have been rasterised, because there is no viable alternative.
The result is an image that scales badly, in which the captions cannot
readily be extracted or altered. Rasters are the wrong medium for that
kind of image.
It works fine for most purposes: http://www.pan-europe.utvinternet.ie.../meter_abs.htm
Zooming in the image used there further would not make it work better.
--
Spartanicus ph**************@ipal.net wrote: Why does SVG need a different tag than other images?
If you are talking about the same SVG that I'm thinking (Scalable
Vector Graphics) then the answer is simple: because it is not image. It
can be used as scalable vector graphics in its most primitive form, but
mainly it is a scriptable dynamic graphics context you can include into
your page - or vice versa include your entire page *into it*. It is,
roughly speaking, an open source XML based equivalent of Macromedia
Flash.
When used as static graphics, its effectiveness (as opposed to
conventional graphics format) depends on the same factors as for
regular vector vs. bitmap situations. Sometimes vestor graphics is
utterly uneffective (say your family photo represented in besier curves
will probably simply crash any vector rendered). And sometimes bitmaps
are utterly uneffective in comparison to vector transformations.
Say the butterfly
<http://www.croczilla.com/svg/samples/butterfly/butterfly.svg> takes
30.4Kb of text to describe all needed points and vectors. The same
batterfly in PNG format takes 30.7Kb and in JPG 33.4Kb
But the gradient fill
<http://www.croczilla.com/svg/samples/gradients2/gradients2.svg> takes
only 317 bytes to write all SVG commands, while the PNG equivalent
takes 28.3Kb and JPG 15.7Kb
You go figure :-)
If you still think that SVG is just another format for <img>, you may
try to drag the red points at
<http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml>
Really interesting <img>, is it? :-)
VK wrote: If you still think that SVG is just another format for <img>, you may
try to drag the red points at
<http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml>
Really interesting <img>, is it? :-)
Oh yeh... If you have IE 5.5 or higher, you also may look at the IE's
counterpair: VML (Vector Markup Language).
At this page:
<http://www.geocities.com/schools_ring/archives/VML_SVG.html> click
anywhere on canvas to define lines.
Should it be another extension for poor <img>? ;-)
On Sun, 09 Apr 2006 22:42:36 -0700 Leonard Blaisdell <le*@greatbasin.com> wrote:
| In article <e1********@news2.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.
That's fine. That's the way it has been since I started 20 years ago.
The problem is someone asks me who told me something that was apparently
mis-learned. It's not practical to remember all that. I suppose I could
give them the standard stock answer: google it
I just don't keep a record of who specifically tells me what. I learn
too much each day for that to be practical. I won't start now. If what
I learned is wrong, tell me so, tell me what is right, and let's move on.
If you are seeing a _pattern_ in the same mis-learned things, then maybe
that is worth tracking it down. Say so if that is the case.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Mon, 10 Apr 2006 11:06:14 -0400 Harlan Messinger <hm*******************@comcast.net> wrote:
| ph**************@ipal.net wrote:
|> 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?
|
| I mean that CSS is optional. If you have material that should be content
| in a background image, then any user who has CSS switched off or is
| overriding background images with his own stylesheet or is using a
| text-based browser won't see your content. Also, if you care about
| search engines, then search engines absolutely won't see it.
If they don't override the background image, then they can see mine regardless
of their CSS setting since I do use background= to define it. You seem to be
describing a situation in which it will actually be necessary to do this.
Your thinking is narrow by believing that background images can only be style.
Step out of the box and realize it can be either style or content, depending
on the situation. Then think further to generalize the relationships between
elements of content and you can then see that it's not really "background",
per se, but "content underneath content". Then with that thought, define a
standard way to express that content. One should not have to "flatten" their
content at the source. That is another way to deal with this, though a bad
one. Yet we do see it on many pages where the whole page is one big image
because that was the only way (in some of them) to accomplish it. Generalize
the document model better, and then maybe you can account for all content and
eliminate the need to play games with content that methods intended for style.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Mon, 10 Apr 2006 08:16:54 GMT Spartanicus <in*****@invalid.invalid> wrote:
| 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.
You have the floor to explain further.
|>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.
How is it that a tag that decides whether some content is, or is not,
to be displayed, is consistent with the principle of HTML being just
markup of content? The original principle of HTML was that all of
what is in the document is content, no more, no less, and this is not
changed by tags being present or absent. So having alt content be
placed between tags means it is _the_ content, regardless of what
the tag indicates. So now are you telling me this is changed so
that you can have content that can be decided to be ignored, such
as the alt content if the tag succeeds in displaying the image?
That sounds more like template than content. Maybe what we really
need is a system of client side templates (Javascript is doing lots
of this now in a rather bastardized way).
Actually, things like images should not be done in HTML tags at all.
Images are as much content as a text glyph is. Some content is pure
image and nothing else. Markup should then be added to that hybrid
content. I.e. the image should be part of it before there are any
tags to mark it up.
|>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.
Great. I will go back to the Firefox people and see if they again tell
me they cannot do that because it would be incompatible with standards.
Then I can point them to your post and tell them they are full of it.
| The issue thus has nothing to do with SVG.
Good.
|>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.
I don't see where that is possible with the current state of HTML.
Show me a simple snippet of HTML (if that's all it takes) that will
place some text layered over an image.
| 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.
Cases where background is used, especially in cells, for something more
than just coloring or texture.
| 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.
Either you are mistaken on that view, or you don't see the connection
that "backgrounds" are just a "layer underneath" using a bad method
to accomplish it.
|>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.
|
| 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'd certainly agree with all those.
Don't you think it would be better (after getting over the rough period
of transition following the flag day) to just start all over from scratch
and do it all "right" (whatever that might be)?
|>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.
|
| 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.
I wasn't against the principle of CSS. It was just not practical to
do any serious work with it with a broken browser.
And browsers have been going downhill until Firefox somewhere around
1.0 and at 1.5 I think it has gotten usable to the point I can stop
using both NS3 and NS4.
Now I just wish they would develop their own PDF rendering so I don't
have to deal with Adobe's bloatware.
|
|>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).
Actually I didn't try Safari. IE won't run on my computer (I might
run it if it did), at least not with fancy environment emulation.
Konqueror messed up table structures, meaning I couldn't use it until
there was a good oppotunity to transition off table structures. Never
heard of iCab.
|>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.
You're asking quite of lot of an OS in that one. That would be huge
bloat. As an OS person, I can say that is a very bad idea. OS should
not see user interface at all (once it got itself booted).
|>| 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.
It might not seem so with poor vector solutions like SVG.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Mon, 10 Apr 2006 12:48:27 GMT Spartanicus <in*****@invalid.invalid> wrote:
| That a vector format requires significantly more CPU resources compared
| to a bitmapped resource should be obvious. SVG parsing and rendering
| requires significantly more CPU and memory resources. The uncompressing
| routines required for bitmapped resources are much easier on the CPU and
| memory. This becomes very obvious if you try SVG rendering on a resource
| strapped device such as a mobile phone. They handle bitmapped resources
| without a noticeable rendering delay, the same cannot be said for SVG.
I noticed as I scrolled Firefox 1.5.0.1 up and down as the butterfly in
the page below crossed the bottom edge of the view that Firefox slowed
down a lot on the SVG image coming up, whereas on the PNG it did not.
But I suspect this is due to it re-rendering the SVG one each time, and
not the PNG (where reender in this case is a reference to uncompressing
the raster bits).
| For the bandwidth & disk space issue I refer to the size of a simple
| image of a butterfly:
| SVG: http://www.spartanicus.utvinternet.ie/embed.htm#svg 33854 bytes
| PNG: http://www.spartanicus.utvinternet.ie/embed.htm#img 6333 bytes
That was a lot of numerics in that SVG. You might have done better by
doing a rasterized run length encoding.
| This ratio between the bitmapped and vector images increases
| significantly for more complex images.
And peaks at pure noise, I'm sure.
No one is saying SVG or any vector method is best for everything. I was
working on the design of my smaller vector format last night, and focusing
on making it better suited for the less complex images that I think vector
methods should be used for.
| SVG is useless for the image type most used on the web: photo realistic
| images. For the few remaining images, rare cases excepted, there is no
| need or real advantage to these images being resizable without a few
| artifacts.
I think the butterfly is definitely a case where SVG and any vector format
should be avoided unless there is a specific need to make objects of the
image that can be DOM manipulated. But this SVG code wouldn't be any good
for that.
| Rarely is that an advantage to a *client*. It _is_ an advantage to the
| *author*, but for almost all purposes the same can be achieved by
| keeping oversized versions of bitmapped images.
I once proposed (not to the standards people, it wasn't a real proposal,
just something to inspire thought) attributes for the <img> tag (which
you could in theory now do in the <object> tag) to override colors in
the GIF color maps. In CSS might even be better. The idea is to make
images that have shape, but give them color separately ... as a style.
There are advantages to having images that can be scaled and colored at
will, without keeping a zillion copies around or generating them on the
fly with CGI (I've done that, too).
Ideally vector images should be drawn in GPUs, anyway.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
In article <e1********@news2.newsguy.com>, ph**************@ipal.net
wrote: If you are seeing a _pattern_ in the same mis-learned things, then maybe
that is worth tracking it down. Say so if that is the case.
Your point of view is forceful but I'm seeing a pattern in which you
argue a point that isn't supported by WWW recommendations, current
browsers, or most members of this group.
On the other hand, I don't know where else you might argue the point on
Usenet that was more appropriate. Or what good it will do you.
Perhaps <news:comp.infosystems.www.authoring.images>, but I see that
you're already there.
leo
--
<http://web0.greatbasin.net/~leo/>
On Mon, 10 Apr 2006 15:30:03 +0100 Jack <mr*********@nospam.jackpot.uk.net> wrote:
| It may be that 'most' images on the web are actually photos; but a
| significant (that word again) proportion are not.
I would expect to see more instances of things like network diagrams
built on the fly from router configurations, modified on the fly by
interface states to show troubled links. Years ago I wrote C code to
generate them in GIF. Operators loved them. But we ended up not able
to deploy them for the whole network because of the GIF transfer times.
I don't know just how much better at it SVG would be right now. But
it has potential. Or maybe the smaller vector format I'm designing
(more for bar and pie charts) would be adequate. Initially it will
have to be done server-side, and send down a PNG or GIF.
|> the *author*, but for almost all purposes the same can be achieved by
|> keeping oversized versions of bitmapped images.
|
| Many people snarf images from the web for re-use in their own materials.
| Many more would do so, if images were routinely represented in a way
| which made that easier.
You mean like: http://phil.ipal.org/green_butterfly_vector.svg
:-)
| I certainly didn't have in mind a search-engine, for example using
| markup in an image to improve rankings. I had in mind more interesting
| possibilities; for example, an SVG could be marked-up in such a way as
| to make possible multiple views of the same diagram, or to allow
| captions to be internationalised. Of course, butterflys don't have
| captions; but bar-charts and network diagrams do.
|
| I frequently run across technical documents on the web, in which all the
| diagrams have been rasterised, because there is no viable alternative.
| The result is an image that scales badly, in which the captions cannot
| readily be extracted or altered. Rasters are the wrong medium for that
| kind of image.
Like Cisco documentation in HTML.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: |>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.
You have the floor to explain further.
http://www.w3.org/TR/html4/struct/objects.html#h-13.2
http://www.w3.org/TR/html4/struct/objects.html#h-13.8
|>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.
How is it that a tag that decides whether some content is, or is not,
to be displayed, is consistent with the principle of HTML being just
markup of content? The original principle of HTML was that all of
what is in the document is content, no more, no less, and this is not
changed by tags being present or absent. So having alt content be
placed between tags means it is _the_ content, regardless of what
the tag indicates. So now are you telling me this is changed so
that you can have content that can be decided to be ignored, such
as the alt content if the tag succeeds in displaying the image?
What's between an object tag pair _is_ the element's content and called
such, only textual content specified with the alt attribute is referred
to as "alt content". Use of the object element indicates that there are
other preferred content representations that can replace the element's
content depending on the client capabilities.
Actually, things like images should not be done in HTML tags at all.
Images are as much content as a text glyph is. Some content is pure
image and nothing else.
Some images are content, they should be referenced in the markup with
fall back textual alternative, other (non background) images are
decorative, they should be inserted as generated content by CSS, then
there are images used as backgrounds, these should be coded as such in
CSS.
|>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.
Great. I will go back to the Firefox people and see if they again tell
me they cannot do that because it would be incompatible with standards.
Then I can point them to your post and tell them they are full of it.
It would be silly for implementors to add functionality to an old
element that is universally acknowledged as fundamentally broken whilst
the sought functionality is available by using the provided and widely
supported replacement element.
|>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.
I don't see where that is possible with the current state of HTML.
Show me a simple snippet of HTML (if that's all it takes) that will
place some text layered over an image.
I'd need an example of the various bits of content, the relationship
between them, and the need for expressing that relationship as a layered
structure.
| 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.
Cases where background is used, especially in cells, for something more
than just coloring or texture.
I note that you continue with your refusal to accept that backgrounds
are not content, various people have shown you the error of your
thinking. There's no point in continuing this part of the discussion
until you accept this basic fact.
|>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.
|
| 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'd certainly agree with all those.
Don't you think it would be better (after getting over the rough period
of transition following the flag day) to just start all over from scratch
and do it all "right" (whatever that might be)?
CSS has a few fundamental problems, non complete support and
implementation differences are currently a major issue. The first could
be solved by new versions of the spec, the latter by new and better
browsers. Both will take time, starting from scratch would take far
longer.
| 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).
Actually I didn't try Safari.
Mac only.
Konqueror messed up table structures, meaning I couldn't use it until
there was a good oppotunity to transition off table structures.
Blame your code.
Never heard of iCab.
Mac only.
|>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.
You're asking quite of lot of an OS in that one. That would be huge
bloat.
Not at all, Macs have this and don't allow styling of these elements.
Most other OSs at least have a system wide specific styling for UI
elements such as form elements that most applications use to draw such
UI elements.
| Vector content is a solution to a problem that hardly exists.
It might not seem so with poor vector solutions like SVG.
There is very little need for a vector based format. Thus the quality of
a particular method doesn't come into it.
--
Spartanicus
On Mon, 10 Apr 2006 16:12:37 GMT Spartanicus <in*****@invalid.invalid> wrote:
| Other things being equal, SVG will always use considerably more CPU
| resources relative to a bitmapped image.
I won't argue that specific point. But I will dismiss it by saying
that where SVG or other vector image formats are used properly, that
extra CPU resource will be made up for by less use of other resources.
For example someone that has poor vision might have their fonts scaled
way up. Doing the same with diagrammatic images would definitely be
worth it. That's why the "S" means Scalable instead of Slow.
| I rarely use the Adobe plugin, my observations are based on the Opera 9
| previews and Firefox. Opera is quite fast compared to Firefox, but SVG
| rendering is still clearly slower than comparable bitmapped images,
| particularly so on resource strapped devices.
I think this is partly because Firefox has approached it wrong.
For example, right click on your PNG butterfly and then do the same
for the SVG butterfly. See a difference.
Next, open up a small window of some other application (for example xmag).
Scroll down your butterfly page so both the PNG and SVG versions appear.
Move the extra window around. Move it across the PNG image. Move it
across the SVG image. I'm seeing major slowdown on the SVG. If I open
the SVG image in a window all by itself (directly on the SVG URL) then
I get that slow effect through the entire Firefox window. It seems they
are re-rendering the SVG image for every X expose event, rather than
caching the bit map result of rendering once. Of course there are times
when re-rendering is needed. If a DOM property in the SVG DOM space is
changed, then re-render it soon (there should be a method for that image
class to do so). But Firefox is doing it wrong by re-rendering for every
X expose event.
|>Of course; but were I to take a representation of a bar-chart, for
|>example, or perhaps a diagram of a network, it might well have shown the
|>opposite ratio of storage requirements (depending on what bitmap format
|>I had chosen to compare with).
|
| Other things being equal, only by using multiple gradients on simple
| shapes can I get the size of an SVG image somewhat below that of a
| bitmapped representation at a size that can reasonably be expected to be
| used on a web page.
|
| The size of images of bar graphs is in my experience at least as good
| with bitmaps as with SVG, frequently better.
But how well do the bar graph raster scale up?
|>Meanwhile, there is no benefit in being able to decompose and re-purpose
|>a butterfly's wing; but decomposing and re-purposing components of a
|>network diagram seems to me to be a completely reasonable aim, and one
|>that might even justify increased network bandwidth, if that was indeed
|>needed.
|
| That type of usage requirement is pretty exotic, it falls well within
| the "very few instances" in my claim that "There are very few instances
| where SVG content makes sense."
You are a butterfly collector, not a network administrator/engineer.
|>It took 3 seconds between the display of the first
|>third to full rendition, on my 800MHz system.
|
| Don't know what problems your system has, it doesn't show a noticeable
| rendering delay on my PII/266.
Try it over a dialup modem.
|>> SVG is useless for the image type most used on the web: photo
|>> realistic images. For the few remaining images, rare cases excepted,
|>> there is no need or real advantage to these images being resizable
|>> without a few artifacts.
|>
|>It may be that 'most' images on the web are actually photos; but a
|>significant (that word again) proportion are not.
|
| That doesn't mean that such images benefit from the ability to zoom or
| edit them.
They can benefit from the ability to scale them to keep up with the scaling
being done with the page in general, such as fonts. They can benefit from
the ability to specify element sizes in units other than pixels for display
or printing on various media.
|>>> re-purposed, dismantled and reassembled
|>>
|>> Rarely is that an advantage to a *client*. It _is_ an advantage to
|>> the *author*, but for almost all purposes the same can be achieved by
|>> keeping oversized versions of bitmapped images.
|>
|>Many people snarf images from the web for re-use in their own materials.
|>Many more would do so, if images were routinely represented in a way
|>which made that easier.
|
| For photo realistic images perhaps, unlikely to be the case for bar
| graphs and gradient backgrounds. Plus, unlike your network diagram that
| a user needs to edit example, I don't see it as a valid requirement to
| facilitate such usage.
Maybe I need to print the network diagram. I don't want it to become
blocky when I do that on a high resolution laser printer.
|>>> and perhaps most importantly marked-up.
|>>
|>> There are very few cases where a UA like an SE bot could conceivably
|>> do anything useful by parsing and indexing graphic SVG content. For
|>> SE's and for non visual renderers such as speaking browsers for most
|>> cases it is far more preferable to have them index and/or render the
|>> textual alternative for the entire object supplied in the HTML.
|>>
|>I certainly didn't have in mind a search-engine, for example using
|>markup in an image to improve rankings. I had in mind more interesting
|>possibilities; for example, an SVG could be marked-up in such a way as
|>to make possible multiple views of the same diagram, or to allow
|>captions to be internationalised. Of course, butterflys don't have
|>captions; but bar-charts and network diagrams do.
|
| We are in exotic territory again. Also, captions don't need to be part
| of the image content, they can be placed below the graphic in the HTML.
Hover captions in images can be very useful, even for butterflies (to
identify the biological parts, for example, in educational content).
Or hover over connection points in a network diagram to see the MAC and IP
addresses, current link status, etc.
I don't know if any hovering over parts of SVG has even been implemented
or can even be specified. But it's definitely something more easily doable
with SVG than with raster formats.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On 10 Apr 2006 12:37:54 -0700 VK <sc**********@yahoo.com> wrote:
| ph**************@ipal.net wrote:
|> Why does SVG need a different tag than other images?
|
| If you are talking about the same SVG that I'm thinking (Scalable
| Vector Graphics) then the answer is simple: because it is not image. It
| can be used as scalable vector graphics in its most primitive form, but
| mainly it is a scriptable dynamic graphics context you can include into
| your page - or vice versa include your entire page *into it*. It is,
| roughly speaking, an open source XML based equivalent of Macromedia
| Flash.
We're arguing semantics here. But I think that's an argument that needs
to be carried out. SVG is very usable as an image. It can function as
an image. Pass the octet stream received from the HTTP server to the code
that is an implementation for it, and get back a pixel array that can be
given to the GUI subsystem to display on the current page. This can be
with GIF, JPEG, PNG, etc ... so why not SVG.
Even Flash could be done this way. But it also takes over mouse control
so it needs something more. But still, it could at least be displayed
that way, if the implementations generalized things well enough.
| When used as static graphics, its effectiveness (as opposed to
| conventional graphics format) depends on the same factors as for
| regular vector vs. bitmap situations. Sometimes vestor graphics is
| utterly uneffective (say your family photo represented in besier curves
| will probably simply crash any vector rendered). And sometimes bitmaps
| are utterly uneffective in comparison to vector transformations.
|
| Say the butterfly
| <http://www.croczilla.com/svg/samples/butterfly/butterfly.svg> takes
| 30.4Kb of text to describe all needed points and vectors. The same
| batterfly in PNG format takes 30.7Kb and in JPG 33.4Kb
|
| But the gradient fill
| <http://www.croczilla.com/svg/samples/gradients2/gradients2.svg> takes
| only 317 bytes to write all SVG commands, while the PNG equivalent
| takes 28.3Kb and JPG 15.7Kb
|
| You go figure :-)
We don't dismiss PNG from <img> just because there are some cases that
PNG is not optimal for. Why should we do so for SVG?
| If you still think that SVG is just another format for <img>, you may
| try to drag the red points at
| <http://www.croczilla.com/svg/samples/xbl-shapes2/xbl-shapes2.xml>
|
| Really interesting <img>, is it? :-)
Certainly SVG is a lot more than just showing an image. But that should
not rule out doing so.
As it turns out, I'm more recently told that the standards do not rule out
SVG in <img>. Perhaps it is a mis-read or mis-understanding of the standards
on the part of Firefox developers, or maybe it is an excuse given by them
because they have a poor graphical infrastructure that cannot easily handle
SVG in the same way it handles PNG.
I notice that Firefox creates a frame for SVG with <object> but does not do
so for PNG with <object>. That may be telling about how they do internals.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Tue, 11 Apr 2006 21:01:05 -0700 Leonard Blaisdell <le*@greatbasin.com> wrote:
| In article <e1********@news2.newsguy.com>, ph**************@ipal.net
| wrote:
|
|> If you are seeing a _pattern_ in the same mis-learned things, then maybe
|> that is worth tracking it down. Say so if that is the case.
|
| Your point of view is forceful but I'm seeing a pattern in which you
| argue a point that isn't supported by WWW recommendations, current
| browsers, or most members of this group.
There are a lot of points being argued here. A lot of it is just my
particular opinion. Most people have those. And if you don't agree
with me, I might think you are still in some tiny box, but that is your
right, too. If you want to attack one of my opinions, it hs helpful to
identify which it is.
| On the other hand, I don't know where else you might argue the point on
| Usenet that was more appropriate. Or what good it will do you.
| Perhaps <news:comp.infosystems.www.authoring.images>, but I see that
| you're already there.
The tag issue was here because I saw it as a tag issue specifically.
Since I see SVG as usable where PNG is usable, I see no reason it cannot
be referenced by any tag or attribute that can reference PNG, including
<img>, <embed>, <object>, and background= in any tag that supports it.
What I was told by a _supposed_ Firefox developer is that SVG was not
implemented in background= because the standard prohibited it. I then
figured this must also be why it is not supported by <img>. Now I do
not need it in <img> because I could, and will, use <object>. But the
issue I have is how to use an SVG image in a background so I can have
text overlayed on it that isn't a built-in part of that SVG image file.
I assumed the browser developers could generalize their image support
by having some kind of common interface/API to access the selected image
format handler (based on mime type and falling back to extension if no
mime time is available). I guess they just don't generalize things that
well.
So far people here are telling me these things: 1: the standard does not
specifically prohibit use of SVG in <img> ... 2: if an image is used in a
background, then it cannot have content and it must be style ... 3: SVG
is not an image.
To me it remains clear and obvious that 2 and 3 are not true, but are,
instead, a matter of one's perspective on things in the world.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: Pass the octet stream received from the HTTP server to the code
that is an implementation for it, and get back a pixel array that can be
given to the GUI subsystem to display on the current page. This can be
with GIF, JPEG, PNG, etc ... so why not SVG.
Because SVG has nothing to do with the above described mechanics.
Sorry, but you seem to demonstrate some missing knowledge on the
subject. SVG is a set of textual command arranged into XML syntacs. Say
this is a right targeted arrow image:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
"http://www.w3.org/TR/2001/REC-SVG-20050904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.0">
<title>No title</title>
<polygon
points="159,0 209,51 159,100 159,55 103,55 58,101 0,101
50,51 0,0 58,0 103,45 159,45"/>
</svg>
It can be viewed as it is (as am .xml or .svg document) on a browser
with SVG support like Firefox 1.5 or higher or Opera 7.0 or higher.
It can be added directly to the document DOM tree using
document.createElementNS (NS- because as you can see SVG doesn't share
the default "HTML" namespace, it has its own). You don't need any
<object> wrapper for it.
I'm failing to see any sorrelation between *this* and a binary stream
for <img>
If we take your above quoted statement in the most wide sense, then it
gets too general to be usable. With the same effect we could apply it
then to HTML itself and ask <img> to support direct HTML code
insertion.
Because it is too an octet stream from the server (HTML source code in
TCP/IP packets) sent to an implementation for it (HTML parser) to get
back a pixel array (graphics context produced in the browser window).
You have to be careful with semantic - it may bite ;-)
On Wed, 12 Apr 2006 06:48:49 GMT Spartanicus <in*****@invalid.invalid> wrote:
| ph**************@ipal.net wrote:
|
|>|>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.
|>
|>You have the floor to explain further.
|
| http://www.w3.org/TR/html4/struct/objects.html#h-13.2
| http://www.w3.org/TR/html4/struct/objects.html#h-13.8
|
|>|>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.
|>
|>How is it that a tag that decides whether some content is, or is not,
|>to be displayed, is consistent with the principle of HTML being just
|>markup of content? The original principle of HTML was that all of
|>what is in the document is content, no more, no less, and this is not
|>changed by tags being present or absent. So having alt content be
|>placed between tags means it is _the_ content, regardless of what
|>the tag indicates. So now are you telling me this is changed so
|>that you can have content that can be decided to be ignored, such
|>as the alt content if the tag succeeds in displaying the image?
|
| What's between an object tag pair _is_ the element's content and called
| such, only textual content specified with the alt attribute is referred
| to as "alt content". Use of the object element indicates that there are
| other preferred content representations that can replace the element's
| content depending on the client capabilities.
But what if there is no alternate content because the nature of the
content is such that only the image can represent it?
So you must also agree that the original principle of HTML that all
that is not tags is content that must be displayed is wrong.
|>Actually, things like images should not be done in HTML tags at all.
|>Images are as much content as a text glyph is. Some content is pure
|>image and nothing else.
|
| Some images are content, they should be referenced in the markup with
| fall back textual alternative, other (non background) images are
| decorative, they should be inserted as generated content by CSS, then
| there are images used as backgrounds, these should be coded as such in
| CSS.
If the textual alternative makes no sense in a given situation (I'm not
saying all situations are like that, but I know some are), then what?
Just nothing there between the tags (I think that would work)?
What one thinks of as decorations are often changing per page as well.
For example the buttons that provide some site navigation may the one
for the current page grayed out (or some other changed with the same
meaning). That would force each page to have its own separate CSS, and
that then defeats the ability to have one CSS for the whole site.
|>Great. I will go back to the Firefox people and see if they again tell
|>me they cannot do that because it would be incompatible with standards.
|>Then I can point them to your post and tell them they are full of it.
|
| It would be silly for implementors to add functionality to an old
| element that is universally acknowledged as fundamentally broken whilst
| the sought functionality is available by using the provided and widely
| supported replacement element.
The <img> tag was not my interest. It was referenced to be descriptive
of the nature of the problem. If the implementation was well generalized,
then SVG would have just worked without any effort to specifically make
it do so.
Consider for example a browser implementation highly based on dynamically
loadable modules for everything. For images, it would know a specific
directory (or list of them) to look for modules to handle images. The
mime type would be used to construct the filename to look for. So for
PNG we might be accessing "${LIBPATH}/images/png.so" and for SVG we might
be accessing "${LIBPATH}/images/svg+xml.so". Of course there would be
sanity checks when constructing the names to avoid mime type abuse, such
as allowing only one "/" and no "..". Once the dynamic library is loaded,
a common API would be used for each one to pass the image document octet
stream to it, and getting some or all of the image area pixels back.
Some mime types could be recognized as already built in to the executable
file itself and accessed differently (use a function table instead of
calling dlsum() for example). A browser doing that, but has no SVG, can
have the effect by someone writing code and building "svg+xml.so" and
installing it in "${LIBPATH}/images". At that point, it should "just
work" wherever any image works. Firefox obviously didn't to that. I'm
getting the feeling the standards don't rule out this approach, but that
some people here might be confused by it.
| I'd need an example of the various bits of content, the relationship
| between them, and the need for expressing that relationship as a layered
| structure.
Text over images. I don't have anything like that at the moment, but
I have done that before. I'll look around and see if I have some old
stuff left here like that.
Yes, I know it can be done in CSS. But then you have CSS-per-page. Style
should be consistent across pages. But the images are specific to a page.
|>| 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.
|>
|>Cases where background is used, especially in cells, for something more
|>than just coloring or texture.
|
| I note that you continue with your refusal to accept that backgrounds
| are not content, various people have shown you the error of your
| thinking. There's no point in continuing this part of the discussion
| until you accept this basic fact.
It's not about whether backgrounds are content, but rather, about the
use of the mechanism to put an image in the background as a hack to
get the image to show up underneath other content because HTML lacks
any other means to do that.
If you say that an image under other objects is background AND you
say that background cannot be content (and must be style) then I say
that one of those statements is wrong. It may be more practical for
the first one to be wrong. But in practice, calling the 2nd one as
wrong for now allows the use of the background= attribute because
there is no alternative (though SVG might be providing non-standard
ways at some point, though likely in an awkward way).
Whatever it is you believe has been shown to me that would convince me
that use of backgrounds cannot be content, I apparently have read that
with a broader scope of experience and seen that it conflicts with at
least some element of real life. I don't remember a specific statement
in this case, probably because I readily dismiss things that conflict
with real experiences.
| CSS has a few fundamental problems, non complete support and
| implementation differences are currently a major issue. The first could
| be solved by new versions of the spec, the latter by new and better
| browsers. Both will take time, starting from scratch would take far
| longer.
Hopefully the standards people have established pages that describe
these issues so they can point the bad implementors to what they are
doing wrong.
|>| 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).
|>
|>Actually I didn't try Safari.
|
| Mac only.
That would explain it. I'd heard of it, but never know it was Mac only.
|>Konqueror messed up table structures, meaning I couldn't use it until
|>there was a good oppotunity to transition off table structures.
|
| Blame your code.
Code works fine everywhere else, and looks logically correct, in the
contents of the old way tables were used to create effects they were
not intended to do.
While many people refused to build upon what they had in the early days,
and some were just not good enough to figure it out, others, like myself,
used what we had and made things actually work. Of course, as new ways
came along, these hacks were then pointless. But many are still around
for various reasons.
Konqueror came out before Netscape had usable CSS. Because of the latter
issue, I didn't use CSS. I used HTML tables. In fact it was not even
clear that CSS could to what I did with tables (but maybe someone can show
me that it can ... and maybe the latest version of CSS has stuff in it
I had not seen before). Anyway, my table code, despite being complex,
worked correctly in NS3, NS4, NS6, IE3, IE4, IE5, and a version of Opera
I tried at the time. It also works in Firebird 0.6.1 and Firefox 1.0 and
1.5. Konqueror, at the version I tried, failed miserably in several ways.
Maybe it has improved in recent versions, but I have not occaision to try
it to see that. I also cannot try new versions of IE right now, and
certainly not Safari.
I have one web site still using this code in a major way. Feel free to
try it out. The site is destined for a big overhaul in the next month
or 2 or 3 but you can see the old method still there today.
if you want to say how my table code is broken, certainly feel free to.
But saying I should have used CSS doesn't mean the table code is broken.
At the time this was developed, CSS wasn't usable, and the overhaul is
most likely not going to use this effect (the table drop shadows).
The site is http://linuxhomepage.com/
|>Never heard of iCab.
|
| Mac only.
That explains it.
|>|>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.
|>
|>You're asking quite of lot of an OS in that one. That would be huge
|>bloat.
|
| Not at all, Macs have this and don't allow styling of these elements.
| Most other OSs at least have a system wide specific styling for UI
| elements such as form elements that most applications use to draw such
| UI elements.
I think maybe we're talking different understanding of what "OS" is.
|>| Vector content is a solution to a problem that hardly exists.
|>
|>It might not seem so with poor vector solutions like SVG.
|
| There is very little need for a vector based format. Thus the quality of
| a particular method doesn't come into it.
I guess we'll have to agree to disagree. Unfortunately, SVG is a poor
example of making a vector format usable in a great many cases. It has
its uses. I'm dabbling with building one of my own now, which will be
smaller than SVG, and a simpler non-XML syntax. We'll see.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: But what if there is no alternate content because the nature of the
content is such that only the image can represent it?
That's no excuse for not supplying a text alternative, if only to
provide a hook to allow people who have disabled the loading of graphics
to retrieve images selectively.
So you must also agree that the original principle of HTML that all
that is not tags is content that must be displayed is wrong.
It parses, but I can't extract what you are trying to say.
| Some images are content, they should be referenced in the markup with
| fall back textual alternative, other (non background) images are
| decorative, they should be inserted as generated content by CSS, then
| there are images used as backgrounds, these should be coded as such in
| CSS.
If the textual alternative makes no sense in a given situation (I'm not
saying all situations are like that, but I know some are), then what?
I can't comment on "I know some are" if you don't specify the situation.
What one thinks of as decorations are often changing per page as well.
For example the buttons that provide some site navigation may the one
for the current page grayed out (or some other changed with the same
meaning). That would force each page to have its own separate CSS, and
that then defeats the ability to have one CSS for the whole site.
On for example a site wide navbar the text that refers to the active
page shouldn't be linked, this is then used to style it differently.
Removing active page links can be done manually, but it's typically done
by generating a page from a database or template, either locally
resulting in static remote pages, or remotely by generating each page
per request.
| I'd need an example of the various bits of content, the relationship
| between them, and the need for expressing that relationship as a layered
| structure.
Text over images. I don't have anything like that at the moment, but
I have done that before. I'll look around and see if I have some old
stuff left here like that.
Yes, I know it can be done in CSS. But then you have CSS-per-page. Style
should be consistent across pages. But the images are specific to a page.
If the images are content then they should be coded in the HTML, no CSS
per page required.
If the images are backgrounds then they should be coded as backgrounds
in the CSS, hence you'll need a CSS class per image used. If you want a
different style for different pages, you need some extra CSS, nothing
wrong with that.
| I note that you continue with your refusal to accept that backgrounds
| are not content, various people have shown you the error of your
| thinking. There's no point in continuing this part of the discussion
| until you accept this basic fact.
It's not about whether backgrounds are content, but rather, about the
use of the mechanism to put an image in the background as a hack to
get the image to show up underneath other content because HTML lacks
any other means to do that.
I've dealt with that in a previous post.
If you say that an image under other objects is background
No-one said that. This is a result from your stubborn insistence to mis
label an image that is displayed behind other content as a "background".
The image could be content, in which case the positioning of text on top
of the image is styling, the domain of CSS.
Whatever it is you believe has been shown to me that would convince me
that use of backgrounds cannot be content, I apparently have read that
with a broader scope of experience and seen that it conflicts with at
least some element of real life. I don't remember a specific statement
in this case, probably because I readily dismiss things that conflict
with real experiences.
I'm not entertaining any more of this pointless discussion based on what
is obviously a kink in your thinking. We could have simply pointed out
how to do what you want to do, but instead of telling us this you seem
to prefer to argue whilst withholding what it is that you actually want
to do.
|>Konqueror messed up table structures, meaning I couldn't use it until
|>there was a good oppotunity to transition off table structures.
|
| Blame your code.
Code works fine everywhere else, and looks logically correct, in the
contents of the old way tables were used to create effects they were
not intended to do.
I have one web site still using this code in a major way. Feel free to
try it out. The site is destined for a big overhaul in the next month
or 2 or 3 but you can see the old method still there today.
if you want to say how my table code is broken, certainly feel free to.
But saying I should have used CSS doesn't mean the table code is broken.
At the time this was developed, CSS wasn't usable, and the overhaul is
most likely not going to use this effect (the table drop shadows).
The site is http://linuxhomepage.com/
The code might "look logically correct" in your eyes, the 232 validation
errors suggest that syntax checking is better done using another method: http://validator.w3.org/check?uri=ht...xhomepage.com/
--
Spartanicus
On 12 Apr 2006 13:44:03 -0700 VK <sc**********@yahoo.com> wrote:
|
| ph**************@ipal.net wrote:
|> Pass the octet stream received from the HTTP server to the code
|> that is an implementation for it, and get back a pixel array that can be
|> given to the GUI subsystem to display on the current page. This can be
|> with GIF, JPEG, PNG, etc ... so why not SVG.
|
| Because SVG has nothing to do with the above described mechanics.
On what basis do you say this?
I know for certain that SVG can be viewed as an image. The methods for
transforming the octet stream into pixels certainly differs from that
for a format like PNG. Both formats could be viewd in hexadecimal if
you want. The fact that it _can_ be viewed in other ways does not mean
mean that this way (images) is any less valid.
| Sorry, but you seem to demonstrate some missing knowledge on the
| subject. SVG is a set of textual command arranged into XML syntacs. Say
| this is a right targeted arrow image:
|
| <?xml version="1.0" encoding="iso-8859-1"?>
| <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
| "http://www.w3.org/TR/2001/REC-SVG-20050904/DTD/svg10.dtd">
| <svg xmlns="http://www.w3.org/2000/svg" version="1.0">
| <title>No title</title>
| <polygon
| points="159,0 209,51 159,100 159,55 103,55 58,101 0,101
| 50,51 0,0 58,0 103,45 159,45"/>
| </svg>
|
| It can be viewed as it is (as am .xml or .svg document) on a browser
| with SVG support like Firefox 1.5 or higher or Opera 7.0 or higher.
So. That doesn't mean it cannot be viewed as an image.
| It can be added directly to the document DOM tree using
| document.createElementNS (NS- because as you can see SVG doesn't share
| the default "HTML" namespace, it has its own). You don't need any
| <object> wrapper for it.
So. That doesn't mean it cannot be viewed as an image.
| I'm failing to see any sorrelation between *this* and a binary stream
| for <img>
Then I'm sorry to say but you have a very narrow view of the world.
You don't seem to comprehend that SVG can be viewed as an image.
If there is some definable way to transform any stream of data into a
renderable form under some purpose of rendering ...
examples of purpose of rendering:
1. To see the image it produces, if it is of a class to do so
2. To see the text making up its specification, if it uses text
3. To see the data stream itself, such as in hexadecimal
4. To utilize the data in other ways determined by its class.
.... then why limit this? Many collections of data have many potential
purposes. In the case of SVG, only idiots living under a rock could
deny that SVG can produce images, and could be used for such purpose.
Just because YOU don't have any need to view an SVG file as an image,
do not deny this to someone else.
| If we take your above quoted statement in the most wide sense, then it
| gets too general to be usable. With the same effect we could apply it
| then to HTML itself and ask <img> to support direct HTML code
| insertion.
It is general only to the extent that someone would implement a way to
transform the data stream in an array of pixels. But this can be done
with data stream of classes like PNG and SVG.
| Because it is too an octet stream from the server (HTML source code in
| TCP/IP packets) sent to an implementation for it (HTML parser) to get
| back a pixel array (graphics context produced in the browser window).
| You have to be careful with semantic - it may bite ;-)
It seems you cannot understand this concept.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Thu, 13 Apr 2006 00:45:20 GMT Spartanicus <in*****@invalid.invalid> wrote:
| ph**************@ipal.net wrote:
|
|>But what if there is no alternate content because the nature of the
|>content is such that only the image can represent it?
|
| That's no excuse for not supplying a text alternative, if only to
| provide a hook to allow people who have disabled the loading of graphics
| to retrieve images selectively.
In probably most cases, such an alternative can be provided. Just don't
assume that this will be so in 100% of cases simply because you have never
seen such a case.
|>So you must also agree that the original principle of HTML that all
|>that is not tags is content that must be displayed is wrong.
|
| It parses, but I can't extract what you are trying to say.
The original concept I learned is that you have content (text) and then
you mark it up. But marking it up does not change the content, but
instead, presents it better (supposedly ... of course someone could
just do a poor job of marking up).
|>| Some images are content, they should be referenced in the markup with
|>| fall back textual alternative, other (non background) images are
|>| decorative, they should be inserted as generated content by CSS, then
|>| there are images used as backgrounds, these should be coded as such in
|>| CSS.
|>
|>If the textual alternative makes no sense in a given situation (I'm not
|>saying all situations are like that, but I know some are), then what?
|
| I can't comment on "I know some are" if you don't specify the situation.
I was talking to someon just today about their use of images where they
want to provide some hints for things without revealing that anything
is actually there until the image displays. Alt text would defeat the
intent. It was part of a game system based on visual cues. It would
be totally useless in a non-image environment.
|>What one thinks of as decorations are often changing per page as well.
|>For example the buttons that provide some site navigation may the one
|>for the current page grayed out (or some other changed with the same
|>meaning). That would force each page to have its own separate CSS, and
|>that then defeats the ability to have one CSS for the whole site.
|
| On for example a site wide navbar the text that refers to the active
| page shouldn't be linked, this is then used to style it differently.
| Removing active page links can be done manually, but it's typically done
| by generating a page from a database or template, either locally
| resulting in static remote pages, or remotely by generating each page
| per request.
But still, if there is to be a visual cue that the button is not active,
that might be done through an image ... a different one in that particular
case on that page, than say one a different page.
|>| I'd need an example of the various bits of content, the relationship
|>| between them, and the need for expressing that relationship as a layered
|>| structure.
|>
|>Text over images. I don't have anything like that at the moment, but
|>I have done that before. I'll look around and see if I have some old
|>stuff left here like that.
|>
|>Yes, I know it can be done in CSS. But then you have CSS-per-page. Style
|>should be consistent across pages. But the images are specific to a page.
|
| If the images are content then they should be coded in the HTML, no CSS
| per page required.
|
| If the images are backgrounds then they should be coded as backgrounds
| in the CSS, hence you'll need a CSS class per image used. If you want a
| different style for different pages, you need some extra CSS, nothing
| wrong with that.
The problem is HTML lacks a mechanism to do the layering of the image
other than the background= attribute (which seems to only be an extension
for <td> and never was an actual standard).
One problem is people are actually pushing the boundary of what they want
to do with the standards that exist faster than teh standards groups can
expand the standards to accomodate. So we end up with bad standards and
even worse extensions.
But still, doing this in CSS means quite a lot of unique CSS for each
page.
|>If you say that an image under other objects is background
|
| No-one said that. This is a result from your stubborn insistence to mis
| label an image that is displayed behind other content as a "background".
| The image could be content, in which case the positioning of text on top
| of the image is styling, the domain of CSS.
I'm not calling it background. I'm calling it layering. The term
background comes in from other people calling it that, and me having
to use a mechanism ... an attribute ... called "background".
Maybe the constructive arrangement is style. But the choice of image,
e.g. the specification of what image file the client needs to request
of the server, is content.
I would think the <object> tag could easily be expanded to provide all
the capability needed.
|>Whatever it is you believe has been shown to me that would convince me
|>that use of backgrounds cannot be content, I apparently have read that
|>with a broader scope of experience and seen that it conflicts with at
|>least some element of real life. I don't remember a specific statement
|>in this case, probably because I readily dismiss things that conflict
|>with real experiences.
|
| I'm not entertaining any more of this pointless discussion based on what
| is obviously a kink in your thinking. We could have simply pointed out
| how to do what you want to do, but instead of telling us this you seem
| to prefer to argue whilst withholding what it is that you actually want
| to do.
I guess this is "ivory tower syndrome". Apparently we have different
experiences in life.
|>|>Konqueror messed up table structures, meaning I couldn't use it until
|>|>there was a good oppotunity to transition off table structures.
|>|
|>| Blame your code.
|>
|>Code works fine everywhere else, and looks logically correct, in the
|>contents of the old way tables were used to create effects they were
|>not intended to do.
|
|>I have one web site still using this code in a major way. Feel free to
|>try it out. The site is destined for a big overhaul in the next month
|>or 2 or 3 but you can see the old method still there today.
|>
|>if you want to say how my table code is broken, certainly feel free to.
|>But saying I should have used CSS doesn't mean the table code is broken.
|>At the time this was developed, CSS wasn't usable, and the overhaul is
|>most likely not going to use this effect (the table drop shadows).
|>
|>The site is http://linuxhomepage.com/
|
| The code might "look logically correct" in your eyes, the 232 validation
| errors suggest that syntax checking is better done using another method:
| http://validator.w3.org/check?uri=ht...xhomepage.com/
I'm not saying it is correct to today's standards. I'm saying it is
correct in how browsers expect to handle its semantics.
Of course, if you want to provide a counter example of perfectly validated
HTML, with corresponding CSS, that renders the same effect, go right ahead.
You probably won't want to as it did take me a few hours to accomplish that
and codify it in PHP in a modular way. I suspect it would take at least
twice as long to code it to web standards compliance as the standards are
today.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- ph**************@ipal.net wrote: On 12 Apr 2006 13:44:03 -0700 VK <sc**********@yahoo.com> wrote:
|
| ph**************@ipal.net wrote:
|> Pass the octet stream received from the HTTP server to the code
|> that is an implementation for it, and get back a pixel array that can be
|> given to the GUI subsystem to display on the current page. This can be
|> with GIF, JPEG, PNG, etc ... so why not SVG.
|
| Because SVG has nothing to do with the above described mechanics.
On what basis do you say this?
I know for certain that SVG can be viewed as an image.
Publisher and Writer:
W: I brought you my new book!
P: About what is it?
W: She loves him but...
P: I'm very short in time today, so very briefly please.
W: It is a very sad story about love.
P: I cannot take it - Shakespeare already wrote this.
Phil and Web Standards:
W: We've got all new technologie to extend graphics context.
P: Is it still image?
W: Not at all, it is...
P: Briefly - can it be used as a still image?
W: Well, yes, but...
P: So it is new still image format. Add it to <img> and do not bother
me.
By your lexicon in this thread there are few obvious conclusion to
make:
1) As you continuously referring to <object> and <embed>, you never had
a deal with real SVG xml+svg standard. You only sew some primitive
static samples with proprietary (besides being hugely ancient) Adobe
SVG viewer.
2) By your continuous references to some misterious "octet stream" it
is obvious that even in these samples you did not bother to check the
source file nor its MIME. You just wrongly presumed that it is some
precompiled data a la .swf
And with this more than narrow knowledge packadge you dared to deploy a
long discussion about Semantics and Standards ?!
P.S. I do not count to improve your mind, but I thought necessary to
add this info here. SVG discussions are still not too numerous in
newsgroups. In case if someone will come to this thread by "SVG"
search, I don't want them to leave with a completely twisted
dellusioned idea of that SVG is. <ph**************@ipal.net> kirjoitti
viestissä:e1********@news1.newsguy.com...
<snip>
Of course, if you want to provide a counter example of perfectly validated
HTML, with corresponding CSS, that renders the same effect, go right
ahead.
You probably won't want to as it did take me a few hours to accomplish
that
and codify it in PHP in a modular way.
What ever anyone is paying you, it's too much if it took that long...
I suspect it would take at least
twice as long to code it to web standards compliance as the standards are
today.
Not really that much at all... Couple of sleepy minutes
Quick test for stupid silly dropshadow. Shouldn't take rocket scientist and
HOURS to go on from that really. http://www.kolumbus.fi/ace/ng/drop-shadow.html
If you look code that ain't really complex at all. Most part were link
snippet from your page put in list.
<NOTICE>
Code ain't that much tested because I haven't got awaken properly yet so
there might be simpler and better way to do this..
</NOTICE>
Now I'm off to have my morning coffee, breakfast and beer to get engine
started... ph**************@ipal.net wrote: So far people here are telling me these things: 1: the standard does not
specifically prohibit use of SVG in <img> ... 2: if an image is used in a
background, then it cannot have content and it must be style ... 3: SVG
is not an image.
To me it remains clear and obvious that 2 and 3 are not true, but are,
instead, a matter of one's perspective on things in the world.
You are correct about 2. There is nothing in the standard that prohibits
putting content in the background. You are as free to put content in the
background as you are to display your content in black text on a black
background, or even #33CC66 text on a #33CC99 background. It's entirely
a matter of your perspective on practices that are foolish and
self-defeating. ph**************@ipal.net wrote: The tag issue was here because I saw it as a tag issue specifically.
Since I see SVG as usable where PNG is usable,
A different point on using SVG for a simple graphic: SVG *can* include
much more than a simple vector graphic representation. It has a whole
object model with a manipulable interface. Therefore, the engine needed
to process SVG is bulkier than the engines needed to display GIFs and
JPEGs and PNGs--more memory, and slower to load. So it would generally
be wise to reserve SVGs for uses where its capabilities beyond display
of static images (resizability, interactivity) are required.
Also--you do realize that most people don't have an SVG plug-in
installed, don't you?
Harlan Messinger wrote: do realize that most people don't have an SVG plug-in
installed, don't you?
Firefox 1.5 or higher and Opera 7.0 or higher have SVG support by
default (natively).
IE 5.5 or higher have VML support by default (natively).
90% or more of current UA's have native scriptable vector graphics support. Adobe SVG plugin - it is from the pre-historic times.
VK wrote: Harlan Messinger wrote: do realize that most people don't have an SVG plug-in
installed, don't you?
Firefox 1.5 or higher and Opera 7.0 or higher have SVG support by
default (natively).
IE 5.5 or higher have VML support by default (natively).
This is entirely consistent with what I said.
90% or more of current UA's have native scriptable vector graphics support.
VML support doesn't do any good for someone who wants to post SVG.
Adobe SVG plugin - it is from the pre-historic times.
Most people wouldn't see why they should have to install new software to
see a simple image, or they would be pissed if they installed it and
then found they'd gone through the whole process just for the sake of
seeing something that could perfectly well have been a GIF.
On Thu, 13 Apr 2006, Harlan Messinger wrote: You are correct about 2. There is nothing in the standard that
prohibits putting content in the background.
That's a point of view. But by putting anything into "the
background", *you*[1] define it to be part of the presentation, as
opposed to being part of the content. That's inherent in the
principle of separation of content (marked up in HTML) from
presentation (proposed from stylesheets).
So it's then rather perverse to insist on calling it "content" when
your own actions have defined it to be "presentation".
[1] the generic "you", not necessarily you personally...
On Thu, 13 Apr 2006 10:14:02 -0400 Harlan Messinger <hm*******************@comcast.net> wrote:
| ph**************@ipal.net wrote:
|> So far people here are telling me these things: 1: the standard does not
|> specifically prohibit use of SVG in <img> ... 2: if an image is used in a
|> background, then it cannot have content and it must be style ... 3: SVG
|> is not an image.
|>
|> To me it remains clear and obvious that 2 and 3 are not true, but are,
|> instead, a matter of one's perspective on things in the world.
|
| You are correct about 2. There is nothing in the standard that prohibits
| putting content in the background. You are as free to put content in the
| background as you are to display your content in black text on a black
| background, or even #33CC66 text on a #33CC99 background. It's entirely
| a matter of your perspective on practices that are foolish and
| self-defeating.
I'd rather not use a method intended for backgrounds as a means to place
certain content underneath other content. Problem is, there is no such
method. It's the lack of a method to do things the right way that results
in people finding wrong ways to do things that happen to work. HTML has
big history of that even without considering all the stuff in the standards
of the past that had to be depricated. What's most annoying to many people
is that some things that are being depricated, usually for some unrelated
reason, were the means to accomplish something that no right way existed
for, and no right way is even being included to do it. When something is
being depricated, the only consideration being made is what the original
intent was. Many hacks are being ignored in new standards (yes, using
background to display an underneath layer is a hack). It's as if the
standards creators didn't like people going beyond what they had thought
of. But I do see a lot of the "if I don't need to do it, no one does"
attitude around here.
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------
On Thu, 13 Apr 2006 17:26:45 +0100 Alan J. Flavell <fl*****@physics.gla.ac.uk> wrote:
| On Thu, 13 Apr 2006, Harlan Messinger wrote:
|
|> You are correct about 2. There is nothing in the standard that
|> prohibits putting content in the background.
|
| That's a point of view. But by putting anything into "the
| background", *you*[1] define it to be part of the presentation, as
| opposed to being part of the content. That's inherent in the
| principle of separation of content (marked up in HTML) from
| presentation (proposed from stylesheets).
|
| So it's then rather perverse to insist on calling it "content" when
| your own actions have defined it to be "presentation".
However, if there is no method available that is considered to be
content, that achieves the same effect, then no assumption can be
made about the intent. Whether it is content or presentation, as
long as there is only one way to do it, you cannot know just from
that way being used whether the intent is there. All we can know
for sure is that (probably) those that created the method had done
so with one of the intentions in mind, and (apparently) did not
give consideration to another intention. But no assumption can be
made about those who use it.
| [1] the generic "you", not necessarily you personally...
--
-----------------------------------------------------------------------------
| Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
----------------------------------------------------------------------------- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 4 Oct 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
