W3C home > Mailing lists > Public > public-html@w3.org > January 2008

Re: img issue: should we restrict the URI

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Fri, 25 Jan 2008 12:57:21 +0100
To: public-html@w3.org
Message-Id: <200801251257.21524.Dr.O.Hoffmann@gmx.de>

Guillaume Ludwig wrote:
> Dr. Olaf Hoffmann wrote:
> > I think, these problems show mainly, that the img element
> > of html is outdated since the object element was introduced.
>
> Perhaps, however "object" can't replace "img" from a semantic point of
> view.

object is more a generic element for problematic cases, if nothing
else describes the purpose of the content better. Maybe authors
have to use attributes like role/class to specify it better.

>
> > Therefore the best approach would be to replace img by
> > image with the same functionality as object and doing
> > similar things concerning functionality with video and
> > audio to get the same approach as in SMIL - the naming
> > is only related to semantics, the authors thinks is right,
> > the functionality is always the same for all of them...
>
> Then, we'll have an "image" element, but what are the differences with
> the "img" element, only semantics ?
>
> (note: I prefer a image element than a img element)
>

No, if it has the same functionality than object, authors have
the chance to provide alternative content in different formats
and if the viewer/user-agent provides an interface, the
reader/user may chose what is the best 'display' for
the intended purpose and his access to the problem.
Unforunately as we can see every day, the world in
general and even such a small part as the internet is
not so easy at all, therefore it is a more democratic
approach to give anyone the chance to be responsible
for the best access to the content - author can provide
different formats, programmers can try to interprete different
formats and readers/user may have the choice, what to
display with which program/plugin in the given case -
this is needed, because we know, specifications, documents 
and implementations are faulty, therefore never completely
relyable for any purpose - especially not for this multimedia stuff.
Received on Friday, 25 January 2008 12:05:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:29 UTC