[
Lists Home |
Date Index |
Thread Index
]
Hi Manos!
Emmanuil Batsis (Manos) wrote:
> Robin Berjon wrote:
> * Luck of extensibility mechanisms. I want custom elements and I want to
> define their rendering and behaviour in a standards way, not the
> hackiish approaches we struggle with every day.
That's what the part of the SVG 1.2 WD I pointed at is for.
> * A higher level of remote data awareness and utilization. True, XMLHTTP
> is (a non standard but) implemented in at least two major browsers and
> can be combined with DOM scripting to allow interactive content without
> refreshing the whole page each time but it's too low level.
That's also being addressed. If you look at
http://www.w3.org/TR/SVG12/#WindowObject you'll see some bits that will help on
the interface. I don't think it'll end up being exactly the way it is in that WD
but it shows that there's work in that direction.
> * A more flexible box model. XUL has a more advanced box model; a
> superset of HTML's.
Here it depends on what you want from a box model. SVG has a different approach
here (though one can implement box models on top of it).
> For once, I cannot agree with you. (X)HTML documents have been used as
> application UIs for a long time. Their role as such is increasing as
> time goes by VS the plain document role.
I don't dispute this. I'm merely saying that from reading the XHTML spec(s) I
don't get the impression that XHTML as an application medium was high on the
requirements list. That's not meant to be disparaging -- I really like XHTML as
a doc format -- but I do feel that judging it on grounds it wasn't meant to
cover is a little unfair.
However, I'm not blind to the fact that it is (almost said "was" :) used for
application UIs (having done that myself more than once as many here I'm sure)
and that we need to learn from its shortcomings. Obviously I'm biased, but I
think SVG is going in the right direction there.
> XForms is a leap forward of course, but
> it only solves part of the problems we face each day, plus it's far from
> being widely implemented.
It's still in CR (where it seems it has been delayed). There are quite a few
implementations already if you look at the page. I don't think the effort to
push it out and advocate it will start before it reaches Rec. But it'll be worth
pushing, and I expect great things in the area of XForms integration with other
technologies. This year.
>> Please see: http://www.w3.org/TR/SVG12/#rax . It's an early WD
>> description. Imho it's the way forward.
>
> Sounds promising but it's too early for me to bet on it.
Ooh, I wasn't saying you should bet on it *now*, you wouldn't even find an
available UA for it. However, I do think people should keep an eye on it.
> SVG support in
> browsers is rather dissapointing. Even worse, plugin-based support
> cripples what could be done with mixed markup (SVG+MathML for example)
> although the document you point out will probably try to address that.
Browsers are disappointing no matter what. Plugins are indeed broken, but if you
get to do everything inside the plugin then you're fine. You're just using the
browser to put some UI around it :)
> I don't want to compare the two approaches but XUL/XBL offers me much
> more than any other implementation of foo in the browser area. XUL
> support for RDF datasources for example, may provide some insight on how
> SVG could do [1].
Yes, I think that's probably the way to go, or something similar. Jim Ley has a
partial RDF processor in Ecmascript and he uses it for really nice SVG stuff.
> Finally, I strongly believe that if SVG could adopt something like XBL,
> it would probably become *the* UI platform. XBL allows one to build
> custom elements, including their presentation, events and generally
> interaction logic. Of course widgets can be build on top of other
> widgets... but the XUL element set is limited; if something like XBL
> could be used with a vector language like SVG... it wouldn't even have
> to provide widgets; I bet libraries would become available all over the
> web, much like DHTML scripts are today.
I think we totally agree on where the future's at ;)
--
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway http://expway.fr/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
|
