-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jussi-Ville Heiskanen wrote:
In complete contra-distinction to Eriks post, this
on the face of it appears to be a useful contribution
to the discussion about file formats.
:)
If I understand correctly, you are saying that flash
can benefit us not as something in which our
content in the sense of the "original" document
is kept, but as a form of conveying that "original"
document to a prospective single time user. That is
not conveyed to somebody who wants our content
for mass reuse, but who wants just that one snippet
of content, that one time.
Well, here's how I might summarize the issue: Flash is a _software
platform_, not a _content format_.
Now, we don't tend to like big flashy take-over-the-whole-site Flash
thingies. Who does? When Flash replaces a whole web page it tends to
make things harder to use.
But for specific things that classic HTML is limited at (like, say,
interactive vector graphics), it could be a useful *delivery tool* in
our toolbox *alongside* the lovely HTML 5/W3C/"open web standards" tools
we love, when they're not available.
Flash-as-a-video-player only supports patent-encumbered audio and video
codecs. The issue there isn't really Flash, but the underlying media
formats the Adobe Flash Player supports.
Flash-as-a-lightweight-client-platform has different characteristics:
* The de facto standard implementation has something like 90% market
penetration, and is not open source.
(Same with Internet Explorer, which we support as a target for our
HTML+JS+CSS output.)
* Open source implementations exist, but they are incomplete and rarely
seen in the wild.
(Unlike plain HTML, it's not a de jure standard *or* a de facto standard
in the world of FOSS operating systems. Thus it shouldn't be our sole or
primary target since we care very much about supporting users in that
world.)
* The file formats Flash uses to load its software are not open
standards, but they _are_ now documented without NDA restrictions.
Further, core development tools for the platform such as bytecode
compilers are open source.
(MediaWiki's own wiki text format is also not an open standard, but what
documentation exists is open, the tool is open source, and we deliver to
open standards.)
The second part of your message, do I understand
it correctly that you are suggesting that content
we would already have in some form, could be
conveyed to people who can not digest it in the
format in which it is stored, by some <magic>
fashion can be made available to them, by the
expedience of using flash, when nothing else
would serve?
*nod*
The example I used is the <canvas> element for scriptable in-browser
graphics. This has become a part of next-generation HTML standards work
thanks to de-facto adoption by the various major web browsers... except
for Internet Explorer.
http://en.wikipedia.org/wiki/Canvas_(HTML_element)
So this is a neat tool for more interactive web goodies which is part of
the open standards movement; you can make something using <canvas> which
will work on Firefox, Safari, and Opera. But today, you need something
_else_ for Internet Explorer.
One way to do this is to make an emulation layer which provides the
standard <canvas> programming interface. One such project uses Flash as
a base, since it provides similar graphics capabilities and lets you
provide a JavaScript interface:
http://www.azarask.in/blog/post/flash-canvas/
There are also VML-based implementations for IE which don't require
Flash. AFAIK they're all limited, and we don't do any <canvas> stuff
today anyway. :) But it's something I wouldn't want to rule out at this
stage.
Progressive enhancement for uploading tools is more likely to happen in
the short to medium term.
(As an amusing side, note, somebody's been working on an Ogg Vorbis
decoder for Flash, which compiles to ActionScript:
http://barelyfocused.net/blog/2008/10/03/flash-vorbis-player/
No Theora video support yet. ;)
- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org
iEYEARECAAYFAkjmVN0ACgkQwRnhpk1wk46QvACgjt8feoKwnUZ7ggEFWLNnHxi2
fpEAn3VKyqbcr3bfMBTwhtFK1GVYqzbK
=C1vM
-----END PGP SIGNATURE-----