[standards-jig] Icon Styles again (JEP-0038)
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