W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: unify ancient tags, Re: handling fallback content for still images

From: Dmitry Turin <html60@narod.ru>
Date: Thu, 5 Jul 2007 16:23:03 +0300
Message-ID: <1982249903.20070705162303@narod.ru>
To: public-html@w3.org

RB> we would be justified in introducing other elements (such as
RB> <audio>, <video>, <picture>, and <canvas>)

I vote to opposite tend: let's unify (instead of branching)!

<video>, <audio>, <canvas>, <embed>, <applet>, <picture>
is slow death of user
(maybe you prefer to work manually instead of computer?).

(1) What's about rich fallback,
maybe it's better to use LINK inside BODY to overcome cultural resistance?
Something like

  <link          href="./a.jpg"><i>rich</i> <b>fallback<b></link>
  <link classid= href=         ><i>rich</i> <b>fallback<b></link>
  <link          href="./a.htm"><i>rich</i> <b>fallback<b></link>

(2) I even think,
that browser should notify user by fallback of LINK inside HEAD,
when css is not accessable or renderable.
This way has no un-compatibility.
Something like

  <link type="text/css" href="./a.txt"><i>rich</i> <b>fallback<b></link>
(3) Of course, i'd like to use LINK instead of IFRAME.

MS> <video src="foo.mp4"> is more intuitive than <object type="video/mpeg4" data="foo.mp4">
<object data="foo.mp4"> is still better,
<link   href="foo.mp4"> is the most intuitive.

RB> The algorithms should simply branch on the different media types.

Dmitry Turin
HTML6     (6.1.1)  http://html60.chat.ru
SQL4      (4.1.0)  http://sql40.chat.ru
Computer2 (2.0.3)  http://computer20.chat.ru
Received on Friday, 6 July 2007 12:48:51 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:16 UTC