[standards-jig] Icon Styles again (JEP-0038)

Mattias Campe mattias.campe at rug.ac.be
Sat Dec 21 18:26:20 UTC 2002

Adam Theo heeft geschreven:
>> 2. The JEP currently uses <graphic mime='image/foo'/> and <sound
>> mime='audio/bar'/> to define multimedia files associated with a text
>> shortcut. I tend to agree with Mattias that we can determine the
>> multimedia format from the MIME type, and that it would be better to use
>> something like <object mime='blah'/> to provide a more generalized format
>> (people might want to include multimedia formats other than graphics and
>> sounds, e.g., applets). Adam's reasoning for leaving it as-is is that the
>> JEP was intended to support only graphics and sound files, but it can do
>> that just as well without hardcoding the element names, since the MIME
>> type can be determined from the value provided in the 'mime' 
>> attribute. It
>> seems to me that the cost of making this more generic is small, and that
>> is worth changing before the JEP goes to Draft.
> Well, another problem I have with trying to create a generic object tag 
> for every multimedia file is that not all multimedia files have the same 
> types of attributes. I'm thinking about adding 'length', 'width', 
> 'filesize', and 'seconds' attributes for the graphic and sound tags to 
> help clients figure out if the multimedia files are the proper "size" 
> for the client. I could create an object tag with all fo these 
> attributes, but then where does it stop? I'm sure flash, java files, and 
> other "new" multimedia files have attributes other than the basic 
> graphic & sound ones.

Well, the w3c sees the use of a generic object tag, so I really can't 
see why not using a generic tag here as well. A lot of clients even save 
chat histories in the form of .html, what could be an indicator that 
stuff that works for a web browser also could work for a Jabber client...

> I do allow for the support of these "new" media types, in the <x/> 
> element included in the latest version. Using those, developers can 
> agree on standard ways to define different multimedia files, including 
> all needed attributes. This allows the most-often used multimedia types 
> of graphics and sounds to remain uncluttered.

That's reinventing the wheel (and even a hack): the w3c started with 
"<img>", then java came, so there needed to be an "<applet>" tag too and 
then there was also the need to include another html document with 
"<iframe>". Then, they realised that this all could be done in 1(!) 
generic(!) straightforwarded(!) way: 1 <object>-tag...

Anyway, here's a w3c explanation about <object> 
http://www.w3.org/TR/REC-html40/struct/objects.html. Maybe you could 
read it... and you might even like it ;) Anyway, a paragraph that could 
be important for this JEP38:

Previous versions of HTML allowed authors to include images (via IMG) 
and applets (via APPLET). These elements have several limitations:

     * They fail to solve the more general problem of how to include new 
and future media types.
     * The APPLET element only works with Java-based applets. This 
element is deprecated in favor of OBJECT.
     * They pose accessibility problems.


>> 4. It seems a bit messy to include things like <version/> and 
>> <author/> in
>> the body of the XML file that defines the icon style. Usually
>> meta-information like this is contained in a header of some sort (this is
>> typical in XHTML, DocBook, and the JEP format itself), and I'd prefer to
>> see the same thing done for <icondef/> files -- we could use <meta/> or
>> <header/> or <iconinfo/> as a wrapper for all the meta-information.
> I don't like this approach for the same reason you do like it: personal 
> preference and how it looks to our eyes :-) I prefer to have as few 
> levels as possible going down into the XML, as long as it doesn't scroll 
> off a screen.
> Since it is just a personal preference, I'd be willing to change it if 
> the majority of opinions here say so. Democracy!

My personal preference is a <meta/> or <header/> or <iconinfo/> as a 
wrapper for all the meta-information.


More information about the Standards mailing list