Re: why a different tag for SVG images?

On Wed, 12 Apr 2006 06:48:49 GMT Spartanicus <invalid@xxxxxxxxxxxxxxx> wrote:

| phil-news-nospam@xxxxxxxx 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/ |
-----------------------------------------------------------------------------
.