SVG for me.
1 I'd like to use Safari to test my SVG-maps.
2 makes Safari distintive from the crowd, for a while
3 giving SVG sort of a drive, like iMac traced the road for USB

XSLT

(4) MathML

CSS3 - it's almost ASCII art ;)

MathML might encourage more academics to use Safari (and therefore Macs), which though it may be a trivial effect, at least makes a nod towards justifiable business strategy for Apple. If it truly is an arbitrary choice, these 2 cents-worth might be enough to swing it!

SVG - because vector graphics are cool. ;-)

Seriously though, of the technologies listed, I'd prioitize this one first as whilst at first glance it looks a bit like flash to an end user, it's far more accessible, and in terms of uptake is probably the only one with any great near-term potential (MathML being the only other one, but obviously the audience for that would be a tiny by comparison).

CSS3 :D

WebCore is meant to be used in many applications besides Safari. While SVG seems the most useful feature (it is easy to generate using open-source tools or even programmatically and would be a great alternative to Flash), MathML would be nice used with e.g. Keynote (using an EquationService-like app) and other scientific/teaching apps.

(1) XForms
(2) CSS3
(3) XSLT

XSLT, and here's why.

It's an older technology that should be in any current web browser. Of the others that you listed Safari would be the only one to have some of them, and while that might be a mighty great marketing thing it doesn't mean squat in the real world.

Having SVG, CSS3, XHTML900, and whatever isn't going to make a difference because no other browsers can see them so web developers are going to be slower putting them in their sites.

XSLT is a viable technology that many business and technology companies use to get stuff done today. I would use it today. IE has great XSLT support but I just can't bring myself to use it...especially after the goodness that is Safari. Don't let this be something that the business types bring up as a con vs. Safari.

I agree with chris, i think XSLT or SVG would provide the highest payoff as the could be used by other applications.

(1) SVG
(2) CSS3

Oh...and if I had to put them in order for a "to-do" list:
1. XSLT - see above
2. SVG - is this thing ever going to take off? Let's go already.
3. MathML - same as XSLT, should be in every browser.
4. XForms - soon going to be a must have.
5. CSS3 - 'cause I dig CSS.
6. XHTML2 - hell most web designers barely know what XHTML is.

XSLT
CSS3
XHTML2

UAAG.
http://www.w3.org/TR/UAAG10/

You may well become the first accessible bundled browser if you take the User Agent Accessibility Guidelines on...

SOAP!

It would be really cool to be able to make SOAP calls from within Javascript in Safari as you can with Mozilla.

My second choice would be SVG and access to the data so that if can be built or manipulated client side.

As XSLT is so wanted, some feedback from me on what comes with it.
Implementing XSLT puts you in the area of "real" XML, common XSLT stuff (esp. the docbook XSLT stylesheets) use all there is in XML, notebly parsed entities. Be sure to answer some tough questions on your XML support during the implementation. unparsed-entity-uri is something not implemented in Mozilla, because the Mozilla DOM doesn't expose unparsed entities at all. The least tragic example, but one that may be tricky to fix.
Make up your mind what you understand XSLT to do. That is, do you want to serialize the result and pass it thru the parser like IE does or do you want to directly render the result tree like moz? Going without the parser smells like a perf win, but you can't do stuff like disable-output-escaping. Note that XSLT2 is much more clear about conformance and serialisation than XSLT1 was. Face that people use document.write in stylesheets producing html on IE. I know, going for XML source and render it with document.write? But people do.
Don't try to implement XSLT using the DOM, you end up in a big hell of slow string compares. Don't try to implement XSLT without stylesheet compilation, either. Don't do wrappers to expose the Safari DOM to a different engine. We take a descent hit on that decision in moz. A walker may be fine (one object vs. a object for each node), we just try that these days.

Guess that would be the most important points. In short, XML support, serialisation, perf decisions.

hm...
what about setting css (1,2 &3) support a priority?
Oh, and any cure for Safari trying to download again an image already viewed?
keep up the nice work :)

n.

I'd say CSS3 as the first step. As mozilla already support parts of it, and Microsoft seems to support it and the long time since IE 6 might just indicate a push at MS to push for new technology like CSS3.
Both MathML and Xform seems like good things to have to but MathML seems like a vary specific technology. Xform really isn't needed until we have Xhtml 2 support is it?
Xhtml 2 support seems straight stupid at the moment as the standard seems very likely to change before it's actually set.
Xslt is a nice technology put personally I see it as a server side technology. However some of the other comments has me thinking twice here.
SVG is available in Safari already, as a plugin from Adobe. The plugin seem to work just fine and it should be available on most machines anyway since it comes with Acrobat reader.

SVG - It's gaining momentum. For example - Microsoft Visio 2003 supports SVG.

(1) XSLT

As for SVG - there is a freely available browser plugin from Abobe (http://www.adobe.com/svg/viewer/install/main.html).

IMNSHO the XHTML/XML/CSS-areas are the most important, with the goal of always having as many browsers as possible being able to handle as much as possible of whatever is the current cutting edge of XHML+CSS.

MathML-support, though, would look nice as a "look what you can do with Safari"-feature.

(7) DOM3 load/save!!!

I would love to see xmlHttpRequest objects in Safaris Javascript engine. But then this is not quite WebCore, right?

So I vote for CSS3 then.

(1)CSS3
(2)XSLT
(3)SVG

CSS should be the top priority. always.

I would really, really like to see a mathematically "literate" computing platform in which mathematical expressions can be worked with everywhere styled text/graphics can be. Having MathML as a ubiquitous component of the graphical toolkit (through WebCore) would go a long way towards this, not to mention enabling Safari to view MathML. Although America is largely and tragically mathematically illiterate, I think this would be a great boon to a large number of people (both "academics" and otherwise).

All the technologies you listed, however, are useful and desired. Shouldn't SVG be implemented alongside PDF as a graphic format and not just in WebCore?

SVG or XSLT

XSLT - From a developer perspective, I think there is a wealth of existing code for XSLT that would make XSLT integration the easiest in the list. Aside from being easiest, enough browsers are starting to support XSLT and it would be nice for Safari to be among the crowd.

I would put SVG as second on my list, mostly because I dig it.

CSS3, starting with the selectors.

Not sure its W3C but what about LiveConnect so that ex RealOne will play properly in the browser. Even though it is installed it always asks for a plugin when watching RealOne content.

SVG - it is a better alternative than Flash. Flash is a propriaty format and without a real competition because currently the SVG plug-in is very limited. Built in SVG support should be the standard in any modern browser.

XSLT - as a second vote.

SVG and implement Mail.app to use the same Safari's Webcore. Then in second XSLT.

And "title attribute" technology ;-) It should be great to dump the implementation in the status bar and just use a tooltip-style implementation instead. (cf. Dave Hyatt, March 6th)

XSLT on the client side is a really bad idea IMO. Server side, yes (I use it there myself), but it'd take a lot to convince me that anyone other than a couple of geeks would actually use it for anything useful, especially if it has to be somewhat compatible with the Microsoft way of doing things.

Yes, whilst Adobe do produce an SVG plugin, it's not exactly a seamless fit, is it? To get the most out of SVG, only native support will do.

Say what you will about XSLT and CSS3 - but they require expert knowledge if you are to make any headway with them.

SVG is different from them as it is perhaps the most "democratizing" technology to emerge for quite some time: It's easy to pick up, fun to play with, and the results are very fast, very gratifying.

All it lacks is decent browser support.

I'd be very excited to see such support within WebCore. And would probably groan loudly if some feature nobody was going to use was given the nod ahead of it. ;-)

I'd like to see the following:

MathML
XSLT
SVG

I like to markup TeX documents and transform them to HTML/MathML via script. The addition of the above technologies sure would make my life easier :)

In addition, I agree with many of the commentators above regarding WebCore's integration with other apps. MathML in NetNewsWire would be nice . . .

XSLT - I'm going to say no to this, but only because I might be playing the lawyer with your "in Webcore" stipulation. This one should be implemented as a systemwide service that WebCore could hook into, not a part of WebCore itself. It's just too useful in other too many contexts to be a thing for WebCore alone. Maybe make an XSLTCore lib?

SVG - Oooh, I'd love to see this. Particularly if it's mixable with HTML.

MathML - It would be nice, but I'm not sure it should be a priority at this point.

XForms - See above.

CSS3 - Another highly useful one to implement, though not all parts of it are fully standard yet. But even if you only implemented the full Selectors module, you'd blow the lid off the design possibilities. How long have I been waiting for someone to implement :nth-child() again?

XHTML2 - Still in draft mode. Wait until it's at least Candidate Recommendation.

So my votes are for SVG and CSS3. Someone also mentioned UAAG; that could be useful. Or even Annotea, which is still pretty obscure but just useful enough that if a browser supported it as standard, with the kinds of nice interfaces that Apple is famous for, it could really take off.

The other thing I'd like to see -though I'm not sure if this would be a WebCore thing- is a Mozilla-style JavaScript console. Not necessarily the debugger; just the console.

Safari is not a developer-centric browser, and I can respect that. But people DO need to write code for it, and there needs to be a good way for them to figure out what's going on. I've run into problems with this myself, where I'll have DOM-compliant code that works in everything but Safari, and -as far as I can tell- no way to figure out what is going on.

-moz-border-radius!

title attribute as a tooltip.

(I know these are not W3C technologies.)

I love XSLT; don't particularly see the point of it on the client side.

CSS gets more and more programmable as version numbers increase--though without actually ever getting there. Not interested.

I use LaTeX, and I would *love* to see MathML on some level.

But the two things *Webcore* needs more are SVG and either enough additional CSS to do complete paged media support or enough XSLT to be viewed as competitive with IE and Mozilla.

I guess you could also say that XSLT is a transforming technology, and justify its implementation as a pun. :-)

SVG is needed because there is no support for it at all and it has been around for a long time (well it feels long).

SVG

It would be nice to finally see a browser that really supports this language.

CSS3 (and what's lacking in CSS2 support), then SVG, then XSLT.

Of the available choices, SVG.

Yes, I know of (and use) Adobe's SVG plugin. Builtin support would hopefully be better integrated with the browser, for example:
* "Open Link in New Tab" for links in SVG files.
* SVG background images.
* Probably faster.
* And no need to download the plugin, which is a serious limitation for general use of SVG.

XSLT, CSS3, and MathML seem worthwhile too.

Off-topic, but something else I'd like to see: HTML editing - which might work especially well for 'Apple's browser' because every .Mac user has write access to a WebDAV server.

CSS3 - To my mind, this is the only one of the options that is properly the part of an (X)HTML parser library, except of course XHTML 2, which is horrid and hopefully far from finished.

It's also good strategically, in the sense that MS have a rougher time embracing and extending the standard if they're the first to fully implement it. Not that they won't, it will just make their job a little harder and get the crucial early adopters doing it the Standard Way.

I agree with other comments that XSLT makes very little sense as anything but a server-side technology, and really belongs in an XML library, not an (X)HTML library.

The others (SVG and MathML), while neat-o, and worthy of browser-level support, should have their own libraries, possibly as implementations of an XML parser that WebCore can easily invoke. Plugins are a Good Thing, and I see no more reason for MathML or SVG to be implemented by an (X)HTML lib than, say, Flash.

However, good MathML and SVG support could go a long way toward making an Office-killer. Hmmm....

XSLT

Considering the 2 other major browsers have some support for it, and that it is a really cool Tech, I think this should be next. What Christopher Holland said, I agree with. Supporting technologies which are not supported by the other huge percentage of browsers out there is a waste of time. XSLT is supported, and if it was supported by all the majors, then more cool stuff could be done with it.

I'd pick SVG. Safari is not another 'me too' browser, but should stand on it's own. of all the techs you listed, this one seems the most innovative, and has the broadest possible impact on viewers.

I personally like the idea of an all-source-is-text browser. If Safari supports automatic decryption of .gz files like IE & Netscape do, then the potential exists for some seriously visually rich, yet speedy-to-deliver pages. Also, with the all-source-is-text model, it becomes really easy for developers to dynamically change files on the fly to meet the viewer's needs.

I also have hope that if Apple (meaning you) implements this feature, then, like USB, it would take off and be quickly integrated into the other browsers. With the code being open source, the adoption should indeed be quick.

Although I think all of the named standards are worth implementing I think SVG should be ranked number one as it brings something completely new and very very important to us: vectors.

Actually I would like to see Apple to support SVG the same way as PDF in Mac OS X anyway. But with Safari having a strong SVG 1.0 implementation it could spawn a strong SVG develoment on the Mac platform. With so many people using Illustrator and other vector programs on the Mac, SVG would be good fit.

CSS3 is important, but it is under development. First of all, Safari should go public with a clear "100% CSS2" tag on it so that designers finally have something to rely on before moving on to CSS3 which might bring interesting improvements in some areas. But SVG is important and opens completely new things while CSS is already here and needs more adoption anyway before we can continue on this track.

There is some relation between SVG and CSS anyway, so I think CSS development should be pushed in terms of supporting SVG.

My personal interest in MathML is not high but I guess the academic community would love to have this. It might be helpful for Mathematice and these tools.

On XSLT: although I love and use XLST a lot I think client-side XSLT has a long way to go still. Right now, the overall focus is on CSS. Safari should support the transistion by improving XML (Byte Order Marks!) and have a strong XHTML compliance-mode (with application/html+xml) in version 1.0!

Tim

Michael:

-moz-border-radius is a placeholder in Mozilla for the border-radius property, coming in CSS3. When that gets to a stable point, it'd definitely be worth implementing. But I would wait until then, to be honest.

CSS3 Color (which includes opacity) and CSS3 Selectors are the ones I'm really waiting for. The rest, while nice, isn't ready to be implemented yet, really.

SVG is really the big one, if you ask me, because that, combined with CSS3, suddenly adds massive new design possibilities. For example, embedding SVG into an HTML document to get scalable, stretchable gradient backgrounds without using external images.

XSLT

Just to reiterate what's been said before - XSLT is used in many places now and it would actually be great to have this at the OS level.

1) CSS3
2) SVG
3) MathML

I'm going to chime in for SVG, too. Have you gone into an Apple Store and used one of those super-HD flatscreens? Good lord! We need to start preparing for the shift away from resolution-dependent imagery, or we're going to get in big trouble and all need glasses in a couple years.

At the same time, however, somebody up there said that SVG support should be system-wide, though it wouldn't necessarily be to the extent that PDF is.

CSS2, er I mean CSS3! ;) Seriously, let's get CSS2 right before we think about anything else. Next, XSLT.

SVG
I think that SVG can make revolution of draw application representation.
There are a few applications which can show SVG, so I hope Safari become the leader for SVG just as iMac for USB.
Finally I hope NSSVGRepresentation is out from WebCore for Cocoa applications.

XSLT!

XSLT - It's all the big browsers

SVG! SVG! SVG!

And then maybe XSLT. I still haven't figured out a use for it.

I'm a bit torn between CSS3 and XSLT. The main problem is that I don't really understand what XSLT is, but I know it can do great things. Although I'd love to see CSS3 support so I can run amuck with my website again, I think XSLT is the next Big Thing. XHTML2 and XForms are quite a bit away from being mainstream (too many websites still at html 4 transitional). SVG and MathML would be useful, but again won't help as much.

So XSLT. And then someone can teach me how to use it.

I'd go for SVG with XSLT being a second place. The others are pretty esoteric or not even nailed down yet.

Justification? Somewhere to view SVG files on the Mac is sorely needed and I prefer to use XSLT server side.

SVG.
Because its spangly. And becuase I am developing an irrational hatred of the FlashMX UI (the program, not the plugin).

User Agent Accessibility Guidelines 1.0 are a must, integrating them with the OS X accesibility... hey I should be able to keyboard around fields in the browser and select drop downs with a keystroke

I would like to see PDF become a first class Safari citizen (I know it's not W3C). Behind HTML (and maybe Flash), PDF has to be the most popular internet file format, and it's painful to switch apps and get desktop trash to view transient PDF files. A third-party plug-in is not sufficient - built-in support would make it ubiquitous. This would be infinitely more popular than "MathML".

PDF! PDF! PDF! :-)

jeff

SVG would get us that much closer to finally being able to do vector layouts.

I agree. PDF compatibility would be great :)

Allow me to be the first to voice opposition to Jeff's idea of implementing PDF directly in the Web browser. With third-party plugins available, there's no reason to bloat the browser with more functionality that most people do not need.

However, it might be worth considering making PDF one of the "safe" formats to auto-open, if it isn't already. That way, the Acrobat Reader (or Preview, or whatever the user had chosen as a default PDF viewer) would spring to the front automatically, so there would be no action necessary on the part of the user, once a link is clicked, to view the PDF. This provides the clear separation of Web browser and PDF viewer while keeping things as convenient as possible.

The other major reason (other than bloat, that is) that I advocate keeping them separate is that PDF files are not Web pages, they don't work quite the same way as Web pages. The user should be aware of this, and putting it straight into the browser erodes that awareness, thus undermining usability.

XML support (XML-RPC, SOAP, XMLHttpRequest) is vital for Safari to be treated as a modern client development platform in these early days of Web Services. The mozilla guys figured this out. Sometimes a non-W3C de facto standard is too practical to ignore.

CSS3
XSLT
SVG

SVG!

SVG has been 'almost there' for so long. It would be great to see a browser that really pushed forward for support of it. And if it's a premier browser on the Mac platform, all the better! ;)

I would love to see SVG.

Of all of the tech listed, SVG has the most promise, is in an early stage(but well enough implemented), and would finally lift some very heavy design layout issues of web devs chests.

Plus, think about an all new application like Keynote... an Apple Made SVG authoring application.. woot! That would be some good stuff.

'Other'. My first two requests are for web-application-friendly features now available on both Mozilla and Internet Explorer / Windows. It is important that advanced web applications can de deployed on the mainstream Macintosh browser without having to make big compromises in functionality.

1 - Support for designmode and textrange to allow Midas-like WYSIWYG 'two-way-web' content editing in Safari

MSIE/win (5.5+) and Mozilla (1.3+) both support this very useful feature. Users of web content management and collaboration platforms which exploit the feature love it, and will soon come to expect it. There is no way to simulate this feature in Safari at present - Mac users must be instructed to use Mozilla if they want feature-rich text editing in an application that requests content from them.

ref:

http://devedge.netscape.com/viewsource/2003/midas/01/

-----

2 - Support for controlled XML data importing - document.load()

This would allow data-driven web applications to deploy on the mainstream Macintosh browser. To simulate this effect in Safari, web apps must currently use hidden iframes loading html laden with brittle onload handlers to effect javascript callbacks to requesting processes. ( PS - Am I the only one for whom Safari fails after the first call of the location.replace() method of a scripted iframe? I've resorted to setting the .src property instead in Safari, which means repeated "hidden" calls for data show up in Safari's history)

refs:

http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-DocumentLS
http://www.mozilla.org/newlayout/xml/#load

For a testable online example, see the * Apple * tech note at

http://developer.apple.com/internet/javascript/jstests.html#import

In Safari, this demo fails without any feedback, since Safari passes the test condition of defining document.implementation.createDocument, but does not support document.load().

-----

3 - SVG support in Safari could be effected without altering Webcore in the short-term, "simply" by allowing the Adobe SVG Viewer plugin to live in a security environment that allows ecmascript objects in the viewer to converse with javascript objects in Safari.

(This is the case in MSIE/win and Netscape 4, and would be an *enormous* boon to SVG developers, since there is now no OS-X browser which allows scripted SVG/html combinations - for example SVG to represent objects graphically with html form elements for user text input for notes, titles etc for those objects). Apologies - I know this is outside your own area of responisiblity :O)

OTOH, it would be wonderful if the Apple team could push the KSVG project forward to the point where inline SVG was available to developers on at least one widely available browser family.

As ever, thanks for resuing Mac users from web limbo... Safari is a great browser.

SVG support seems most potentially useful to me, but I'd say it should be implemented in Quicktime rather than in Webcore.

XForms, far and away should be the first choice. Be the front runner in the field, and help to implement something that hasn't changed since '96 :)

My second choice would be editable content, much like the Macromedia Contribute product, since Apple is big on WebDAV.

Just do it all. I mean, how hard can it be? :)

SVG would be sweet. And even better if it would be just one more graphics format supported by OS X everywhere, not just WebCore.

MathML would be incredibly useful, not just in the browser, but in Keynote, in Apple's much-rumoured Office Suite, etc.

SVG would be nifty (for many of the same applications), but from what I've read, it's a gnarly spec to implement.

I don't see the point of XSLT on the client side. But, perhaps that's just me.

CSS3 and XHTML2 don't exist yet (though some bits of CSS3 do), so I don't see how you can talk about implementing them.

CSS3

or CSS2 correctly ;)
What about fixing the bug which makes Safari crashes on the W3C QA Website.
I didn't touch the stylesheet... to help you to fix it.

http://www.w3.org/QA/

When you click on a link: Boooommmm

The problem seems to come from the arrows inserted in background on the right side menu.

In order: CSS1/2/3, XFORMS, MathML

XSLT definitely.

Christopher Holland makes an excellent argument for this above.....

MathML. It should be in every browser so scientists and mathematicians don't have to resort to crude, crappy-looking GIF's to display math on websites.

7. Tables.

All we really need is Tables, not all this "CSSinteger" and "X-6R4GB8-ML" stuff.

CSS3

Because more people will recognize what it is than any of the others, and Apple can then claim to have the browser compliant with the world's most advanced standards or something.

Type-ahead-find, a la Firebird, with an option to turn off "links only." It is such a useful feature.

d.w.:

While I agree that it would be great to have SVG as a part of QuickTime, there's also a good argument for putting it directly into WebCore: SVG-embeddability directly into HTML. This would actually be a very big deal, because it lends itself to some incredibly powerful possibilities.

Perhaps it's possible to do this in such a way that SVG still lives in QuickTime, not as a part of WebCore. If that can be done, then that's definitely the way to go. But if that can't be done, than it may be necessary to implement SVG twice -once in QuickTime and once in WebCore- because embeddability is too important to sacrifice.

1) SVG - because xml based vector graphics are useful and GIF patents are not

2) XSLT

CSS2. Ok, that was snarky. Sorry. CSS3.

CSS3 screams simplification. that's what apple is all about. but its not quite a recommendation yet.

SVG would be nice too. i know this isn't the forum for it, but why on earth didn't apple make the finder use SVG? These tiff icons are ridiculous. i read somewhere about a linux distro sporting a SVG GUI.

Could I suggest something a little different? How about Ruby?

http://www.w3.org/TR/ruby/

IE is the only browser I've found that supports it. As justification, I would say that this would be very helpful in various Asian markets, particularly Japan, and it shouldn't be that hard to implement, at least compared to some of the other suggestions on the list.

I think SVG is very cool, but it must be a very large project to implement. Couldn't Apple come to an agreement with Adobe to distribute their plugin with the OS? That seems to be the fastest way to get solid SVG out on the Mac (regardless of browser) and it avoids all the subtle incompatibilities that would come from a new implementation. Yes, it is less integrated, but as a web developer I think consistency would help SVG a lot more than multiple implementations. Maybe a Safari blog is the wrong place to say that, but it is true.

(1) CSS3
(2) SVG
(3) XSLT
(3) XForms

1: FTP: would be very handy
2: xForms: from the point of IS developer this is the way to go, it's not perfect, but it's there.
3: xmlHttpRequest: so you can do basic xForms.
4: SVG, perfect in combination with xForms!

is any implementor actually seriously considering XHTMl2?

0.) Absolute top priority is a complete implementation of CSS2 for version 1.0. Don't dilly-dally.

1.) SVG rules, and I would be *delighted* to see native support. I agree, however, that support should exist at the system level so that other apps can access it. That might preclude DOM support within Safari, and might necessitate implementing it twice, but so be it. Definitely a top priority.

2.) MathML is really useful for people who do that sort of thing, and there *are* still a lot of people using the internet for legitimate research purposes, even in this jaded commercialized era. A good second priority, and also lays the framework for Ruby support, which is nice for Japanese support.

Forget XHTML2, CSS3 and XForms. The first two aren't even finalized, and if you try implementing the third, you'll be working until the end of time. I agree that XSLT should stay server side for the time being.

-reg

SVG

The Adobe plugin is slower on Macs than on Windows. There are a lot of SVG implementations that only work on Windows. Also SVG often doesn't print on the Mac. That means SVG is another very promising technology where Mac users are discriminated. You'd be another industry's first since native support in Mozilla isn't coming foward and Amaya is not a serious Browser.

SVG, plain and simple. I ahven't really seen the need to do client side XSL Transforations, we always end up doing it server side. Mainly to the limited client support, need for cutsom extentions, and inconsistent implementations.

SVG on the other hand would be great. Just imagine of how many graphic heads you WOULDN'T have ot make any more because they'd be in SVG already. Of course, SVG would only be interesting if Safari supported font embedding and Java Script interaction.

XHTML2, because it offers such cool features, and requires XForms.
XForms then requires XPath which makes XSLT implementation easier ;)
So in fact you implement 3 items of the list with just XHTML2, and XHTML2 offers additional cool features =D

CSS3 and XSLT:
CSS3 has so many useful features, especially in the area of selectors (I say 'especially', because it's the area I understand the most). Anyhow, the more CSS support, the better, because it ultimately leads to better web authoring and extends skill sets that web developers are currently using the most.

XSLT, however, is a major technology that is already being used. It shows a lot of promise, and the fact that Mozilla and IE both support it means that a lack of support in Safari will either leave Safari behind or force developers to not use such a promising technology.

Incidentally, while XHTML2 is in my opinion a bit premature, I'd love to see browser makers start supporting XHTML2's concept of allowing an HREF attribute on any element sooner rather than later. I think that's a great, brilliant idea and I'd hate to have to use XHTML2 just for that one feature.

I realize that there probably isn't a standard for this, but I'd really like to see something like IE for Windows contenteditable functionality which allows you to turn any part of a page into an editor. This would be great for Content Management Systems.

XForms -- XHTML forms are a subset, so why not go with the superset? Besides which, JavaScript is nice and all but XForms lets you do the declarative route which is much easier to debug on the developer end. Debugging client-side JavaScript sucks, and DOM compatibility issues make it worse.

SVG -- Quartz should make this relatively strightforward, it fits in with other technologies like SMIL which are already in QuickTime, and it is slowly gaining traction in Gnome and KDE. The Adobe SVG browser has a crap DOM, misses half of the specification, and doesn't play well with others. Besides which, MathML can be rendered using SVG :)

Of course supporting SVG + XForms in the same document is vital ;)

[Rant On]

To be honest though, I'd really like to see a browser that actually supported standards 100% correctly (inasmuch as that's possible). This means DOM, ECMAScript bindings, the whole thing. Right now there is no perfectly complete SVG implementation, nor is there a perflectly complete XForms implementation (although XSmiles is close). Once, just once, I would like to be able to work on the web armed only with the standards.

[Rant Off]

I thought QuickTime had support for SVG already, and thus Safari inherits it. Yes/no?

Other than that, XSLT, then SVG image format without adobe plugins (though could we see that in Quartz and thusly not need to duplicate functionality?). After that, MathML seems the most likely. Take XHTML2 and CSS3 when they come. I've never heard of Xforms.

XSLT
CSS3
SVG
XFORMS

XSLT
CSS3
SVG
XFORMS

XSLT. None of the arguments against it hold any water: people who don't understand XSLT are no more likely to use it as a client-side tech than they are as a server-side tech. And XSLT support in webcore would make all XML docs on the system equal, and equally able to be displayed in webcore-based applications.

I'd be happy if Safari allowed Java applets to work in an object tag (see an example at http://homepage.mac.com/unearthed/worldTime/index.html ).

After that, SVG; then XSLT; then MathML; then XForms; then CSS3; then XHTML2.

Whatever is necessary to create richer, "one window" interfaces in DHTML/JavaScript, with data transfer to/from the server using rpc-xml (or similar) calls.

For example, see http://www.versalent.com

SVG. Here's why.

1) XSLT should be added eventually, however, most sites are using server-side XSLT, which I regard as much more realistic for the moment (considering that most browsers don't handle XSLT anyway).

2) XForms is far too unrealistic (Safari would, to my knowledge, be the first major browser to handle it at all), and we're not talking about a cutting-edge (in technology) product like Mozilla, but a simple, nice, cute, *working* browser.

3) SVG support in Mozilla is slowly developing, but it *is* developing. Combined with CSS 3 (see below), it's really one of the more important features.

4) MathML is a niche for me, sorry. Hardly seeing any sites that use image-based equations, so MathML isn't going to influence pages I visit regularly. Yet it should probably be added in a while.

5) CSS 3 isn't even done, nor close to it (as far as I can tell). Wait another year for it.

6) Don't get me started on the useless thing known as XHTML 2, a compromise that leaves everyone in the age of disadvantages. In addition, the same as CSS 3 applies - it's not "out" yet.

So the vote goes to SVG.

SVG. Here's why.

1) XSLT should be added eventually, however, most sites are using server-side XSLT, which I regard as much more realistic for the moment (considering that most browsers don't handle XSLT anyway).

2) XForms is far too unrealistic (Safari would, to my knowledge, be the first major browser to handle it at all), and we're not talking about a cutting-edge (in technology) product like Mozilla, but a simple, nice, cute, *working* browser.

3) SVG support in Mozilla is slowly developing, but it *is* developing. Combined with CSS 3 (see below), it's really one of the more important features.

4) MathML is a niche for me, sorry. Hardly seeing any sites that use image-based equations, so MathML isn't going to influence pages I visit regularly. Yet it should probably be added in a while.

5) CSS 3 isn't even done, nor close to it (as far as I can tell). Wait another year for it.

6) Don't get me started on the useless thing known as XHTML 2, a compromise that leaves everyone in the age of disadvantages. In addition, the same as CSS 3 applies - it's not "out" yet.

So the vote goes to SVG.

XSLT: because it makes browsing pure XML files much more practical.

I happen to disagree with those who don't see the value of client-side XSLT. If for no other reason, handing off the XSLT transformation to the client eases the processing load on the server... potentially even eliminating server-side processing. I also don't buy the XML vs XHTML rendering argument: isn't XHTML simply XML? Why not make WebCore a general-purpose XML renderer? And, as others have pointed out, other browsers are heading in this direction as well.

Also, it would make a killer replacement for css-based user stylesheets.

CSS3; at least those parts of it that are CR.

Since XHTML2 is still only a working draft we can safely ignore it.
MathML and SVG seem for now technologies better suited to some sort of plugin, Mozilla's efforts to offer them by default notwithstanding.
XSLT... well, let's just focus on things designed for the current web before going off into the far distance with that.
XForms would be my second choice, as the sheer possibilities because of it are overwhelming. Unfortunately as it's a pretty fundamental technology, there won't be many people starting to use it even if Safari implemented it to perfection.

And then there's CSS3. As CSS isn't _necessary_ to enjoy properly designed websites, designers can use it for 'fluff' in the safe assumption that browsers not implementing new parts of it won't mess up too badly, but still forging far ahead into the future. Just look at what CSS2 is doing for current weblogs; then look at the feature set of those parts of CSS3 that are already in CR stage. There is so much goodness there, and so much of it that can directly benefit users when applied right.

Furthermore there's the issue of webdesigners enjoying this most of all, and where webdesigners lead, other people shall follow - including with browser choice. An important goal is after all to put an end to the hegemony of crappy browsers, and offering technologies to draw people away from those is goooood.

(3) SVG
(7) XML as in Internet Explorer

If personal certificates were supported in Safari, MIT and lots of other schools would be incredibly happy. It would make a huge difference on campus, since we can't recommend Safari until this happens, since many of our web services rely on personal certificates for authentication. Did I mention that MIT would really wants and needs to have personal support in Safari? ;-)

I would also like to see MathML support in Safari. This actually came up in our user group meeting on Monday. I expect that the OCW initiative (http://ocw.mit.edu/) uses MathML a lot. Did I mention that MIT would really like to see MathML support? ;-)

From a Mac user's point of view, I would love to see SVG support in Safari/WebCore. It's something that would be immediately useful for lots of users.

-- Al

SVG, because I can use it as a lever to get SVG support incorporated into a certain Mac office suite.

MathML

Reasons

1. There is a widely used plugin on windows (Mathplayer) but none on the Mac, so Safari users are currently stuck
2. Mozilla already has MathML support working - it would be great if that codebase could be extended and improved, for both Mozilla and Safari to use.
3. Online publishing of scientific and technical content is now the primary mode of communication for that content.
Special characters and equations have always been the bugbears of scientific and technical content of the web.
Now that we have widespread unicode support, the special character issue is just about dealt with (finally).
MathML is on the brink of being able to do the same for equations, but the Mac is in danger of being left out of this.

4. MathML rendering in webcore would be a really cool and useful if it could be made available as a service available to developers of other apps (though I agree that SVG rendering at an OS level would be great too)

Why not SVG
SVG is great and would be next on my list, but for SVG there are widely available free plugins for both windows and mac which are already a standard, so it's not such a critical issue.

Why not XSLT?
Would be nice, but not clear to me whether widespread use of XSLT on the client would really make the world a better place...

Someone mentioned Liveconnect as another missing 'standard' that should be considered.

I'd second that: it's a prime reason for java sites (like www.mapminder.co.uk ) being totally unusable from Macs right now, which is a real shame given that Mac OS Java support is otherwise excellent these days...

CSS3, followed by SVG.

CSS3, at least the bits of it that are set.
Basically, there are still many layouts that you simply cannot achieve using CSS. I'm talking about very simple things that have been implemented for decades in publishing applications : vertical align, multiple columns, etc.

I would say SVG, but I think that is a job for QuickTime, not for Safari.

Personally, then, I think I'd be most interested in seeing MathML. It would be a real boon for many academics and "academic" websites, and of the options (sans SVG) it seems likely to be the next that will see major adoption.

Built in PDF support would be extremely awesome, wouldn't be Webcore obviously, and obviously not W3C as Hyatt's question really wants.

UAAG is my top pick. The web wasn't built for only those who can see, or only those who can use keyboards and mice, it was built for everyone. Although since this is Webcore we're talking about which will be used in many applications, System Preferences might be a place to stick the user options you're required to have.

Otherwise, Webcore, maybe some nifty RDF stuff? Who knows, let's see how far the rabbit hold goes.

(1) XML (more like Win IE)
(2) CSS3
(3) XHTML2
(4) XSLT
(5) XForms

I'm with the SVG supporters. Wider support for it would urge me into finally using it. ;-)

I was going to say XSLT, but as a designer I'd really prefer to see CSS3. Hopefully getting it in Safari would cause it to trickle down to other browsers.

XSLT. CSS3 would be better, but only useful in the real world if you could implement it in IE first... :)

CSS3

Having MathML support in Safari would be wonderful. You'd imagine that an implementation might not be quite as difficult as it would be in, say, Mozilla thanks to the neat-o keen font and typesetting technology that comes with OSX.

One of the niches Apple seems to be targeting these days is the UNIX/scientific community, and MathML would be welcomed there.

As someone pointed out, having the ability to display mathematics symbols and formulae throughout all Cocoa apps would definitely go down well -- your keynote slides, your web pages, your printouts, your emails, the readme.rtf with your latest piece of code, all with embedded formulae.

Another thing that it would be nice to fix is bookmark support. There needs to be a centralised Apple-defined bookmark repository for each user (ideally using something like XBEL). It's just too painful having individual bookmarks for each browser. Having sets of bookmarks in ~/Library and in /Library and /Network/Library would be very cool too. Not to mention some iTunes like way of sharing sets of bookmarks using Rendevous.

1- CSS full & complete
2- XForms
3- XSLT
.....
SVG really belongs in QuickTime, along with all other graphic formats.

MathML, since it's the only one of the items listed that's remotely close to being useful. It also has the benefit of not being as much of a bloody bloated mess as XForms or CSS3 (I'm not qualified to comment on the bloatedness of XSLT or SVG).

In my opinion, the sequence would be:

(1) XSLT -- pretty important stuff that should be in every browser
(2) CSS3 -- it might be even more important that XSLT, but it's pretty new and most browsers don't support it yet, so it isn't as pressing
(3) SVG -- vector graphics are cool and very useful
(4) XHTML2 -- if the browser already supports XHTML1 well, this should be not as bad as implementing many other technologies on the list
(5) MathML -- just 'cause -- not a very urgent thing, though
(6) XForms -- pardon my ignorance, but I don't see how this is so terribly important

1. XBL (maybe its already in? I think everyone is assuming it is based on your previous posts)
2. SOAP (This would be jewel in the crown)
3. XSLT (it's a requirement)
4. SVG (Macromedia has been ignoring the Mac community for to long, they need a wake up call, please give them one.)

SVG!

SVG is first choice.

If I'm allowed the second - it would be XSLT.

CSS3 follows

Others - I don't care.

Many good arguments have been made, so I won't add too much; I vote for SVG, then XSTL -> MathML

Yes, I meant XSLT, not XSTL! : )

XSLT is an important tech to support system-wide, and WebCore is the appropriate place for it, but I'd really like to see improved XML support, first.

As others have commented it would be great to have system-wide support for SVG as a media format (ala PDF)... but it's based on XML... does WebCore become more closely coupled to Quartz (yes, non-programmer talking!)

1) XHTML 2 & CSS3, because that are the both Technologies I want most to play with.

2) XHTML and CSS 2 correctly, because we still miss usefull things, e.g. the link-navigation or counters.

3) SVG, since we need a push to powerfull dynamic and vector-based websides beeing not by Macromedia

4) But over all there is my wish for a sidebar in Safari, since it is the only thing preventing me from switching. Steve Jobs may wet his panties about the new bookmark system, I think it is unusable in practice.

MathML combined with SVG and CSS3.

These could really put Safari at the front of opening up the web to more disabled users along with giving researchers easier to use tools. The commercial users tend to follow what the researchers are doing, finding ways to use these tools themselves... but it would be very handy to have something like a JavaScript script checker/debugger as an add-on tool for Safari, maybe keep the DeBug menu and put it there.

SVG

With version 1.0 specification and javascripts, one can effectively create an Mac desktop on a browser. The graphical control given to the designer is not as limited as in Flash interface.

More importantly, the richness of the language can be extended with other XML applications.

XSLT.

Because of mostly the same reasons as have been mentioned:

-It is already supported by IE (biggest browser market share)

-It is extremely useful

-It can be used by companies such as the one I work at to make web applications for the mac... if Safari had XSLT support, we'd have Mac support on our product.

Thanks!

:-)

Straying slightly from the W3C question, I have to agree with Brian Foley (above) about the benefits of an improved bookmarking system. Having a bookmark system that is accessible across browsers - as opposed to the standard approach of importing from IE/Netscape on first use - would be of huge benefit.

If bookmarks were to be re-envisaged in this manner it would also be useful to look at related tools, such as extra fields (to allow a bookmark name as well as added description/comments) and a validation function (to allow regular pruning for 404 and similar errors). Strangely I can't come across a utility providing this functionality for Safari.

MathML.

Some sort of technology is needed for displaying equations. Someone above argued that the use is too specific and limited people would take advantage, while this may be true, there is NO technology in place for web browsers that does anything equivalent. The other options listed, OTOH, simply extended and improve current capabilities, whereas MathML would add a new one.

This kind of technology is desperately needed! I wish they had just done an implementation that used LaTex syntax so we don't have to learn another syntax... but it seems that there are already programs to convert directly between the two...

I am a bit biased being a physics graduate student, but I think my argument isn't so bad... :-)

1) SVG
2) MathML
3) CSS3
4) XSLT
5) XForms
6) XHTML2

MathML

Please! Having to embed equations as GIF's in web-pages is so clunky! I can't wait for the day that MathML is implemented in all of the mainstream browsers. It will make my life so much easier posting lecture notes...

What gives us capabilites that we don't currently have?

1. SVG
2. MathML
3. CSS3
(4. XForms?)

XHTML 2 is a losing proposition, because there are no compelling end-user benefits over XHTML 1.1. It will never see widespread support or adoption, because it's wholly incompatible with HTML markup -- there's not even a compatible migration path. It's purely an exercise in design masturbation. It may fix all of HTML's faults, but it will never gain any mainstream traction. Google the "Worse is Better" essay by Richard P. Gabriel to understand why.

XSLT -- why exactly does this have to be available on the client side?

I don't know anything about XForms. HTML forms suck, so it might be a good thing. No friggin' menu separator item for you!

Why does everyone use gifs to embed their MathML stuff? PNGs would probably look better... :-p

SVG and MathML please! SVG would be nice for QuickTime, but it needs to be able to interface with the JavaScript side of the browser. I don't think it would be able to do that through the QT plug-in.

MathML for us science people!

SVG because this format rules.
and after SVG CSS3 of course :)

Why XSLT client-side is neccicary:

Because not everybody runs their own server!

I use .Mac's homepage solution, and many do not want to set stuff up serverwise, or cannot do so at all. Getting the benefits of dumping XML files on the server and running them through an XSLT stylesheet on the client has a very cool feeling to it, and it's not like it could harm anything.

XSLT support
SVG support as a generic renderer in either QuickTime or NSImageView (Don't know the framework behind that one.)
CSS - Fufill all the little things in CSS 1 & 2 first
XForums and XHTML2 - wait for standards to finalize on XHTML2
MathML, SVG, other image and media - special plugin format , perhaps modularized WebCore to allow others to add XSLT and things with little work.

Safari needs to become open source, at least WebKit. Not to sound blunt, but I hope Apple isn't just sitting on the framework until 10.3 to use it to get devs and consumers onto the new OS.

A global browser history, i.e., share your browser history between all browsers you use.

It is not W3C-standard, however, probably not that complicated to implement and very useful.

My vote goes for SVG.

SVG is the hottest ticket in town and is perfectly complementary to the technologies already implemented in WebCore (XHTML, CSS, DOM). Graphically it is just as capable as Quartz, but that's only the static part: SVG also mandates SMIL animation support. The SVG specification is fast evolving and promises to become more of an application platform (see latest SVG 1.2 drafts on the W3C website). SVG is a perfect fit as the basis of a XUL or XForms Basic implementation. SVG simply rocks.

The argument for client side XSLT is exceptionally weak. Whilst I agree in principle with its eventual incorporation, it should be way down anyone's priority list. Don't get me wrong, I don't think it's a bad technology, I use it exclusively when I'm building sites using AxKit and Cocoon, but its main power lies in being able to transform content such that any browser can access the page.

The "it reduces server side processing" arguments are red herrings as in order to satisfy multiple browser requirements you'd have to process it server side anyway, and with a decent caching mechanism your processing overhead for subsequent hits is usually fairly small anyway (there are exceptions, but if you're expecting your site to get more traffic than you can comfortably process, you'd have probably dismissed it as an option anyway).

Likewise, those who state that client-side support means they'll be able to get by with cheap hosting are probably not considering the amount of extra work this involves, especially if you also provide pages which work in non-xslt enabled browsers. Anyone considering either of these options is, IMO, barking mad. ;-)

Lets take a step back for a moment. What does XSLT on the client side really give us? Much that is simply plain unneccessary. Let the server handle the transformations. Then you've only got one implementation to debug. Unless you're bug-for-bug compatible with the MS implementation, you'll soon be entering a world of pain, and I can think of better ways to spend my time. Think back to the early days of javascript/livescript - and that's not *nearly* as complicated...

Anyway. Why should SVG be in the webcore as opposed to anywhere else? Well, SVG is so much more than just a graphics format. It's a fully programmable, interactive format, and as such it needs to be completely hooked into the browser DOM. It's potential is enormous. In the light of that, it amazes me that so many people think that XSLT in the client is important. It really isn't. SVG has the potential to offer so much more.

SVG

It is definetly the future and much more easier to implement. It also solves XForms and XHtml. What I mean is with svg xforms and xhtml can be done. From the svg developers list I see much more questions on svg then xslt, xforms, and xhtml.

Choosing only one isn't going to be easy, but I'd definitely go for SVG. It's tomorrow's rich client. Doubly so if it can be mixed with XHTML. And if you release SVG support back to the KDE folks :)

It's too early for XHTML 2.0. I don't care much for MathML. I've grown used to using XSLT on the server side, where its under the control of a single processor and doesn't hit various bugs in browser implementations.

Thus, as second and third choices: XForms and CSS3, with XForms seen as almost as important as SVG.

SVG!

SVG is THE future of web.
In 2 years nobody will use HTML or Flash.
It is possible to make X-Windows like applications in SVG, it is XML, MathML, CML can be renderd inside of SVG.

XSLT is important but this can be done serverside.

XForms is a new standard but it is very complicated and I'm not sure this is the future of forms.

CSS3 and XHTML2 ... why not

SVG.

There's two useful SVG viewers on the market, and Macromedia has no plans to help SVG become a useful alternative to Flash. There's a chicken-egg problem keeping SVG from growing: lack of editors, lack of viewers. Corel's doing the editor, but so far there's only one viewer: Adobe.

CSS3.

In case SVG becomes too humongous to support, I'd love to see CSS3 work. CSS2 has given me some awesome fun, but I'm still twitchy and triggering render bugs (see my website! and "it's not a bug" is probably true for one reason or another). CSS3 would add a whole new layer of fun to things, and would be very useful to start supporting now.

SVG is a really high priority. For so many client-side applications it makes a lot of sense, especially with its DOM integration. The future's devices have different DPIs, accessibility is an issue of great importance -- SVG is the only sensible way to address graphical presentation for these considerations.

I'm sitting here at the WWW2003 conference and there's a lot of use and excitement about SVG. Unfortunately there's only one significant vendor of SVG viewers, Adobe. This just isn't a healthy situation.

If you do implement SVG, it would be utterly wonderful to release the work back into the community. The open source world lacks a decent interactive SVG implementation.

-- Edd Dumbill

(Not a Safari user, but an interested web citizen)

because it's 'teh roxxorz'.

That should read 'marquee' because it's 'teh roxxorz'.

SVG, with Javascript integration and animation. I've been using this technology via the Adobe plugin in Windows IE for some time, and it really is superb. Extremely powerful and flexible, it enables you to produce content that goes way beyond (x)html, and all within the scope of a W3C standard.

The only things that I find really lacking are widespread support, and true integration within xhtml pages. Native browser level support would go a long way to remedy this. Croczilla is good, but really needs a hard push to make it better - and make it into the official release builds.

Only when a well-known browser has native support, and people actually start to see what can be achieved with this technology, will people really start to 'get it' (and therefore, hopefully, demand it in other browsers).

SVG is a technology waiting to happen in a big way. It just needs a little push. Native Safari support would help that push a great deal.

And now having read the comments, I'll shift my vote to SVG+XHTML2+CSS2/3; there's good reasons described above. SVG gives us vectors, XHTML2 gives us the power of Docbook in HTML, and CSS2/3 gives us layout joy. SVG *first*.

Off-topic: PLEASE fix Preview.app's Thumbnail feature. I cannot wait five minutes to view a downloaded PDF because it's more important to show me a thumbnail than it is to let me page through the PDF. Bad, bad, bad design usability flaw: a task the computer is slow at that isn't impeding user interaction otherwise should *never* interfere with the user's ability to do things.

SVG!

-Dom

SVG!!!

SVG 1.1 or 1.2 (!!)

This would help immensely to get us away from HTML as the primary communication medium for web applications. Native SVG support - or at least SVG Tiny support would finally provide a plugin-free implementation of a vector graphics system. This would be a huge plus to the web community imho.

Ronan

SVG!

The sooner it's widely implemented, the better the world will be.

7. Ruby-ML

SVG + CSS3 Media Queries.

The web is moving in a direction where the diversity of User Agents grows - from 101x73px displays on mobile phones, to super-high-res displays, and we need a graphical technology that scales well.

Still: no matter how well SVG content scales, there is still some need to present data differently based on device capabilities, so Media Query support is also needed. Imagine this: Your device presents the content of a site in one single column, when the device width is {n} ems.

I've got a test suite for this here: http://www.virtuelvis.com/gallery/mediaqueries/ (AFAIK, the only browser that supports this at this moment is Opera 7)

(3) SVG

My vote goes to the technology will be of the greatest benefit to Mac apps other than Safari. Safari is already pretty good and any improvement in WebCore will definitely make it better, but the promise of WebCore is more important IMHO.

iTunes Music Store - totally cool. I can't wait to see more cool uses of WebCore throughout Mac OS and all the apps, Apple's or otherwise.

From my limited knowledge and for the above reason I'll suggest SVG followed by MathML but will happily defer to Dave for a final decision.

By the way, good question. Love the debate its sparked!

SVG would definitely be a big plus for Konqueror/Safari/KDE.

SVG is one of the most important new W3C standards which could be the base of many interactive graphical applications and visualizations.

SVG could and should be used not only in Web-Browsers, but also Desktops and other graphical applications.

Adding semantic informations, SVG is so much better than competing graphical file-formats.

DISCLAIMER: W3C Team Member and editor of W3C SVG specification.

I vote for GIF.... no wait... I mean SVG.

One of the design goals of SVG was to enable seamless
integration (as much as possible) with other web technologies. You should be able to use your existing XML parser, CSS engine, DOM implementation, JPG/PNG libraries and ECMAscript engine in your SVG code. Safari already has these things.

The remaining things are (a) drawing the graphics, and (b) animation (if you choose to implement it). For (a), you have the fantastic Quartz library to do most of the hard stuff. For (b), you have Quicktime code, which has implemented most of the SMIL animation features used by SVG.

It's also worth noting there are smaller profiles of SVG, SVG Basic and SVG Tiny, which are still really useful and would be a good starting point for an implementation.

I'd also argue that it would be easy for Apple to support SVG at the system level, similar to its PDF support. Having a true graphical XML format for input and output would be great. And if you convince the OS/Quartz people to do it, integration with WebCore would get be a lot easier :) They could also have a true vector desktop also.

What things would SVG get you? You could use SVG for element background (including the page). Text embedded within images (within the XHTML) would be searchable. You'd get smaller file sizes for most diagrams. Lots of people above have already mentioned more. And so on....

Enough evangelisation :)

I'd also love to see CSS3, MathML, XHTML2 and XSLT, but my second vote would go to XForms. It's fantastic technology.

More UAAG would be nice (hi Matt!). Mozilla's type-ahead-link-find thingy would also be fun. Oh, and since I'm now well off topic, a real full-screen mode a la Opera's presentation mode (which can automatically switch to the correct CSS @media stylesheet) or WinIE's F11.

BTW I love Safari. Whatever you choose, keep up the great work.

Dean Jackson

SVG

THAT WOULD ROCK!!

The adobe SVG plug-in is WAY to heavy to download. If you can get it built into Safari without any major increase in footprint (>1MB) it would really make Safari stand out. If you could build it as a framework which could be used by other apps, that would be killer.

SVG

Definitely XSLT - it's a mature technology, and all current browsers should have it implemented!

-B

MathML. This is becoming more prevalent in the scientific community as a way to communicate (and display) complex formulae.

Ex. SBML (Systems Biology Markup Language, http://www.sbw-sbml.org/) has adopted MathML for representing equations in biological simulations.

Hmm. Tough. I want most of them. I'll go for SVG because I'm terribly tired of bitmap graphics on the web. They're so... 1980s. The thought of having graphics that can scale with the webpage with no jaggies is just delicious.

SVG- because I saw an SVG demo yesterday at WWW2003 and it was VERY impressive. Same for XForms, XHTML, and CSS3. You can do some very cool things with these three technologies. XSLT is nice, but I condier it more a server side technology. It should be included at some point, but like MathML has a much smaller affected user base than the ones I menitoned above.

I'm not a Mac user, so I guess my voice isn't worth that much really, but here's my would-be priority order:

CSS3 (Because it's partly CR and fixes a lot of the problems that CSS2 didn't manage to fix)
SVG
XForms
MathML
XSLT (Not really needed clientside, if you ask me)
XHTML2 (XML (with knowledge of the XHTML2 namespace?), coupled with a default stylesheet should enough for this?)

Does Safari have XML and XLink support? Those should be first priority if not, if you ask me.

I don't know that I can justify my answer, because I don't know if I can decide between XSLT and SVG. I do software development within web browsers, and right now we're only using XSLT on the server-side, but we've got SVG stuff that only work in MSIE. The plugin is just awful.

So I guess I vote for SVG because it is the one technology listed that I'm actually using regularly within the browser context, and the plugin situation is just awful.

In order of importance to me:

1. CSS3
2. XSLT
3. SVG
4. XForms
5. XHTML2
6. MathML

SVG would, by far, be the most useful. There never really has been a web equivalent of tools like Photoshop and Illustrator for designers, except perhaps for Flash. Unlike Flash, SVG is open source XML and can be used so powerfully to create interfaces and display data.

7. data: URIs

They're easy to implement, they're useful, and they're lots of fun!

I would like to see SVG integrated together with XHTML, so that on the browser side, I can use script to manipulate both in a single DOM.

Wait a minute... I just thought of something.

We've all been arguing about the merits of implementing SVG as part of Safari vs. part of QuickTime. And there are good reasons for that.

What if, in addition to WebCore and JavaScriptCore, a third library -SVGCore- were to be created? It should be possible to have WebCore use this to tie SVG into the DOM, so we'd get the embeddability, and a QuickTime codec could wrap around SVGCore/JavaScriptCore, so we'd get QuickTime support.

The real question is, can this approach be used while retaining XML-embeddability? If not, then it's no good, because that really is too important to ignore. But it's something worth looking into anyway.

SVG, without question.

If one were to write a requirements document for a Web language that does what people want today, HTML would definitely not be it. People want the power to draw anything to screen, and to create interactive, distributed applications that have user interfaces as general as any desktop application, yet run over the Internet. Operating systems provide general drawing APIs and user interface elements on the desktop; now we need the same thing to be provided by browsers so that the same functionality will be available over the Internet. SVG provides such a drawing API, and due to its compatibility with other standards such as DOM, ECMAScript, SMIL and CSS, it fits into a much more general API for creating fully functional user interfaces to Web applications and services.

The only other standard on your list worth comparing in terms of importance is XSLT; however in today's application designs it is much more common to run XSLT on the server than on the client, so I would be much happier with an SVG-capable XSLT-incapable Safari than the reverse (of course supporting both would be even better, but I realize you are trying to prioritize here).

SVG would be my answer. Why SVG? Because you can create more radically cool web stuff stuff with SVG than with all the rest of the standards mentioned there combined.

SVG would be great. Imagine a www with as much vector graphics as bitmap. Websites would have less constraints placed on their design and would be more efficient to download as well. SVG is a great vector graphic format for the web; anyone with a text editor can sit down and create some interesting graphics without much trouble and there is a lot of authoring software available that can save as SVG. Now we just need better client side support.

SVG Please.

"If one were to write a requirements document for a Web language that does what people want today, HTML would definitely not be it."

That's funny because that's exactly why HTML has won out and all the other supposedly better "web languages" flounder.

I don't really think any of the items listed need immediately attention.

I don't know where it fits, but the browser needs HTTP get/posting capabilites that can be called from script. This enables much richer interfaces in the browser.

As a web application developer, I often get jealous of IE's showModalDialog function.

Typically I try not to use dialogs, for usability sake, but sometimes they are unavoidable. I suppose DHTML dialogs may be a better fit?

Either way, I'm still surprised nobody else like Moz has picked this up, or that it isn't part of the W3C DOM.

SVG!

SVG, please. As a user of adobe's SVG plug-in I can not wait to see a better support for SVG.

FTP Site Browsing.

I have to say Safari needs to be able to browse FTP sites. Using the Finder is pretty lame; I don't think anyone enjoys this. And while I adore curl and ftp on the command line, they're not good for browsing either. All other web browsers can burrow through an FTP site directory and I think that's something Safari/WebCore needs too!

SVG

It's terrrible to have users depend upon an unsupported plugin because something that really should be supported by the browser native (eg a graphics format. Mozilla supports GIF, JPEG and PNG... SVG is just an extension of that policy)

SVG

Best graphics format to date. Would love it!!

SVG is the one I have the most use for, followed
by XForms.

(3) SVG

I was part of the team that built the SVG used on battlebots.com I was very familiar with this technology long before most knew what it was. Using it in its early days it became clear SVG was never intended to be a plugin technology. I personally long for the day when web graphics that start as vector based designs are implemented that way instead of being sliced down and converted to bitmaps. I have seen so much DHTML/CSS used to hack this. SVG was built for it. When browsers allow SVG to be a seamless part of a web page, dynamically driven by server-side code, i believe we will see a signifigant advance in the quality of internet based interfaces.

How about properly recognizing my SSL proxy settings. That would be nice. This has been a bug since day one. Safari simply ignores my SSL Proxy settings.

My vote is for SVG, because I can comfortably use it today.

Of SVG, XSLT and CSS3 (my 3 favorites from your list), it's the one with a well-defined fallback mechanism, meaning it's easiest to put into use on a site that needs to support any user that comes in. A little [object type="image/svg+xml" data="logo.svg"][img src="logo.gif" alt="Blahblah" /][/object] and I can use SVG *today* to make a nice logo with a less-nice fallback position.

(or [object svg][object png][object gif]text[/object][/object][/object] if you like... giving it a little thought, I'd likely to with [object svg][object png][img src=gif alt=text][/object][/object])

With XSLT, I might as well do translation server-side until everything users have can do it client-side. And if I'm already translating it server-side, why bother doing it client-side sometimes?

CSS3 would be nice and I'm sure it's got lots stuff I'd love to do, but "If you don't know how to do X then try Y instead" isn't particularly easy in CSS, but fairly easy in HTML. CSS3 would be my second choice, I suppose.

General rule of thumb:
First do the things that other browsers are doing.
Then do the things that are easy to fall back from if they're not supported or if they're inaccessible to the disabled.
(In other words, if I can't reasonably easily use something in a way that leaves the site usable for everybody, I basically can't use it for professional work. Accessibility is legally required and compatibility with IE4.x and NN4.x is a practical requirement for years more.)
I suppose MathML probably works via an easy fallback mechanism ([object math][object picture of math]text description of math[/object][/object]), but I haven't looked into it and just don't need to do math on webpages very often.

Put my vote in for MathML. We worked with the Geometry Center (Robert Miner) back in the early to mid-90's on WebEQ. We also presented one of the first fully functional implementations for technical publications to the W3C Math working group. It would be cool to see this capability finally make it into the mainstream.

In my day, it was either gifs or embedding 10's of java applets (with the corresponding WebEQ markup) unless you went with Bob Sutor's plug-in for direct rendering of LaTex or you moved down the path of PDF or PS with it's print orientation.

I also agree with one of the posters above that a MathML decision would directly drive hardware sales in academia, engineering, technical manufacturing, life sciences organisations, and many other fields that require mathematical representations as a part of their daily work.

This would definitely be a specialized capability, but one for a community hungry for such a solution. Oh, and they have money to spend.

ps. message to the education market: Dell, can you do this?

Arguments for XSLT

Setting aside the argument about where the transformation takes place, we should be more concerned with the size of the content that is minimized with a client side XSLT solution.

If the server transforms my 20k of data and

It adds up fast when you've got many clients browsing and instead of each of them getting a transform they only get the source for them to transform themselves.

Additionally, then the browser can still have access to the underlying data and retain it for further transforms.

(7) All of the above!

I'd love SVG support, since we're already using PHP to generate SVG charts from a MySQL database on our web site.

But the truth is that Adobe's SVG plugin is pretty good already. Wouldn't it make sense to just distribute Adobe's plugin with Safari, and then teach Safari just enough about the plugin to be able to redirect inline SVG to the Adobe plugin for rendering?

Hi Dave, I guess you suspect by now that there was a "get out the vote" effort going on.... ;-)
http://groups.yahoo.com/group/svg-developers/message/29978

I liked the previous comments here about finding a particular audience and serving it better... tools for web developers, scientists, the differently-abled, something like that.

No offense, but I can't see a feature in Safari changing the existing content of the web. A proponent of a specific technology would love an endorsement from a browser, sure, but this may not actually increase the use of such features in mainstream web pages. Key: What type of *difference* can a stronger browser make?

If web developers started saying "Hey, Safari just plain makes it easier to create and test my pages" or "If you're a scientist it makes a lot of sense to switch to Safari" or "It's smart to buy a Mac so you can use Safari's accessibility features"... that would be cool. Better to make a significant difference to a targeted group of people than a meaningless difference to a large group of people...?

http://www.accessify.com/articles/how-accessible-is-safari.asp

tx,jd

SVG because it sounds like a cool alternative to Flash. An adoption of SVG in a cool browser like Safari may prompt others to support it. :)

I would rank them as:

1. SVG - should actually be supported in NSImage as well

2. XSLT - if webcore is also aimed at server-side apps.

3. MathML - OK, I'm a math grad student. Especially

If I were to implement any of these technologies, they would go right into WebCore and not into other libraries as some have suggested.

For SVG, MathML, and XSLT, tight integration with the rest of WebCore is critical, and you don't want to have to use thick cross-framework APIs (e.g., Obj-C wrapped DOM nodes or XPCOM in Mozilla) in order to communicate with your DOM, to access CSS information, to lay out your object, or to render.

Safari has a nice advantage over Mozilla in that it's really tiny. You could do full implementations of SVG, MathML, and XSLT in WebCore and worst-case you'd only double WebCore's size. Doubling the code footprint would still leave Safari smaller than Camino's code footprint. My point is that we have tons of room to grow. :)

I also don't believe SVG belongs in QuickTime. The *entire* point IMO of implementing SVG in WebCore would be to get seamless integration with XHTML, CSS, Javascript, and the DOM. If you don't plan on being tightly integrated, then you might as well use the Adobe plugin and not bother implementing SVG at all.

In case people are curious, my opinion (which is quite selfishly based on which would be the most fun to work on) is as follows:

(1) CSS3 Selectors (Safari supports many of these already)
(2) CSS3 image borders and opacity
(3) SVG/MathML (tie, both would be a blast)
(4) Other CSS3
(5) XSLT
(6) XForms
(7) XHTML2

The biggest non-W3C technology that IMO WebCore should support is contentEditable and the ability to do HTML editing. A close second would be Web Services (e.g., SOAP). Third would be XBL.

(7) Unicode. Especially RTL scripts...
Not a W3C technology but all the other acronyms are pretty useless with this...

CSS3, please!!

SVG first.
Some CSS 3 modules are done, some aren't, CSS2 isn't even supported by IE, no point getting that far ahead.
Besides, it might motivate the mozilla guys to finally fix their SVG issues.

SVG!

XForms would be nice, but it's much newer than SVG, there are tonnes of tools that produce SVG, and I can't wait to generate my HTML documentation with embeded SVG diagrams.

No more GIFs!

I vote for SVG. A fantastic way to design for the web. Has a lot of new potential, such as XML font delivery technique. My web site is completely done in SVG and uses no graphic files for the UI (except the obvious jpeg's). All graphics are in a font format so the underlying SVG files can not be copied.

Please don't waste your time on SVG. The responses you have received come from a pool of techies and techies are sometimes out of touch.

Speaking as a developer of big ole web sites. In the real world, flash is used. the tools are there and i could care less about flash's "propritery" format. so what.. 99% can read flash so i allow flash in our sites.

that's all i need, content on my site that only the bleeding edge of browsers support. Sure. And I don't care about a chicken and egg scenario. I feel Safari should concentrating on the html - css looks and form of a site.

My vote is:

(1) CSS3 Selectors (Safari supports many of these already)
(2) CSS3 image borders and opacity
(3) Other CSS3

XSLT

4. MathML

MathML. The web can handle, as text, nearly any language invented by humans except for the universal one: math.

SVG first. Very versatile format, especially if integrated properly with DOM, SMIL, etc. Plus, KSVG is sitting there waiting to be ported. It's not complete but IMHO it'll be a good base.

MathML next, but I concede that this is a niche format.

Peter

Hyatt, don't you tease me. You implement contentEditable and I'll buy a Mac the next day (okay, I admit it, I'm one of those slimy Linux users). It doesn't have to be compatible with MS' version, just the same 'set any block editable' idea. I've got a CMS my clients love and find extremely easy to use, and contentEditable is a big part of it.

I've been killing myself trying to make Midas work anywhere near as well so my Mac using clients aren't left out in the cold, but it's a lost cause. I'll keep at it because it's better than nothing, but an iframe based implementation just can't measure up (never mind the fact that my default document type is XHTML 1.0 Strict, which doesn't even have an iframe tag). Mozilla has blown big chunks here, and having a contentEditable implementation on the Mac would just friggin' rock.

It also might finally convince the Mozilla folks (do you still have influence there? Tell them we need this, please?) that Midas is *not* a suitable substitute for cE functionality.

Damn, now you've got me all excited. That was downright mean if you don't follow through... ;)

In order of preference:
1 SVG
2 XSLT
3 XForms
4 MathML
5 GML, CML, MusicML, etc__________ (Other)

SVG - Why? Because:
In our organisation, we generate *lots* of graphics daily, disseminated to lots of customers, and the current web graphics solutions are inappropriate. CGM was the appropriate solution 10-15 years ago, SVG is the best technical solution now, even without scripting, etc.
We already generate SVG for specific customers, but will not re-vamp our complete production chain to support SVG until there is evidence that the big industry players will not try to kill it.
Native support in a popular browser is such evidence.
Native support may also improve rendering efficiency slightly compared to a plugin, and a small percentage is worth it in our case because of the volumes. We cannot force our customers to
replace their 300MHz Pentiums and Netscape4.7.
If Safari+SVG is very popular, Microsoft may have to respond.
The current Microsoft SVG offering of import and export from Visio in Office2003 strikes me as a toe-in-the-water and see what happens.

XSLT Why? Because:
Then XML data, including GML, CML, MusicML, XForms, etc all become readily transformable into presentation formats such as SVG.

Summary: Vector Graphics has been well understood since 1976, so, Industry, please stop re-inventing wheels, and making them not-quite round as if it was an improvement. we want interoperability and vendor independence, and will pay for it.

Work on getting CSS2 to be impletmented 100% to comply with the standards, and then move on to CSS3. The others - what are these???

Also, work on fixing the Safari bug - there seems to be a serious problem with file:///Library/Preferences/SafariEnhancer/html4.css (2) - file doesn't exist. This seems to prevent me from opening several websites on first attempt, and sometimes the sites don't open at all but will come up in other browsers. This is very, very annoying. Used to be Safari would work flawlessly. But now . . .

One other thing . . . please enable the functionality that will allow URL Manager and WebConfidential to be accessible from Safari.

SVG.

Why?
XSLT makes more sense on the server IMHO, at least for a long time to come.
CSS3 is not ready yet, but it would be one of my second choices.
MathML is very specialized.
SVG is generally useful, of high quality, an open, XML based graphics language. Future versions will feature video and sound.
XForms will be useful especially in combination with SVG; it would also be one of my second choices.

contentEditable. The mozilla version sucks, so base it around the IE one. With mozilla implementing it now, its not just a luzury its a necessity. Be ahead of the game and implement it now.

1. XBL
2. CSS 3

SVG! SVG!

1) SVG
2) CSS3
3) XHTML 2

svg would be my choice.

I too would prefer MathML. Thore expressed it well - a technologically flexible community that would quickly adapt Safari if it supported MathML.

(7) None of the above.

I don't think Safari should be too far out in front on things like this. It should hang and make sure standards stick before implementing. Let Mozilla make the mistakes.

It first needs to catch up to IE and Moz on things like HTTP POSTing from script.

(1) XSLT!

Clearly a problem on the Mac as it is today. Quite a problem when you are in a win centered environment that uses that kind of technology quite a bit.

SVG. Too bad XBL is not a W3C spec yet ;)

(7) <blink>

:-)

Getting CSS 1, 2, and 3 working should be job #1.

CSS3

One step ahead of anyone's interesting. Current CSS standards can't handle some complicated layout without resourcing to hacks. Columns in CSS3 would be very nice.

XSLT - serverside technology - could be second chioce.

SVG - would be great - but not very urgent.

SVG

SVG could make way for more dynamic and usable graphical sites. Since the image's components can be manipulated via Javascript, graphical sites could do things impossible with raster images. The business benefits would increase also since reports and graphs could be created real-time and displayed on the web, then modified by Javascript without having to post back to the server.

Does Keynote support SVG? If not, this could be a very compelling reason to add it to WebCore, and use WebCore for Keynote's rendering. A truly portable standards-based file format for Keynote!

Rather than browsing FTP sites, I'd rather have Safari respect the user's default FTP client, rather than just passing everything off to the Finder (unless, of course, that's what the user had set as their default).

XSLT for most of the same reasons as expressed above

MEMORY LEAKS!!! :)

I'm seeing Safari use HUGE chunks of VM and real RAM. As in Gigabytes after many days of use.

I'd like to see Safari show a Flash animation at anything close to the speed the animation is set at. Flash animations run at the specified speed on everything from Win98 to WinXP. They run slow as heck on any Mac. But I guess this is out of the hands of Apple, and more of a deficiency on the part of Macromedia.

Right now I'd like to see a version of Safari that renders pages in non-extra-humongous font.

Other than that, SVG would be the highest on my list.

-Chilton

CSS3 and better Flash support

The new webMathematica 2.0 has these new features: "MathML, SVG, and XML Support: Support for MathML and SVG is built into webMathematica 2.0, allowing you to describe equations and graphics in standard XML formats that can be read by browsers. "

Which browser will that be on the Mac? Safari!

MathML

As a practical matter, you are losing Mac sales to academic institutions because of the lack of support. At last summer's MathML conference it was made clear that there isn't much work required to make MathML work on the Mac but noone in the core group had enough time or interest to make it happen.

Best,

Daniel

CSS3, and complete support for CSS1 and 2.

Oh, and if you've got a moment, please fix this :first-letter bug in Webcore (look at the title for the post).

http://www.beatnikpad.com/archives/2003/05/20/000451.php

I would implement these things in the order from easiest/most fun to hardest/most pain in the ass because I'm a programmer.

If you figure that they all need to be done (assuming for version 1.0), does it really matter what the order is they get done in?

XSLT!
Since IE 6 and Mozilla support XSLT already, KHTML should support it also!
Man, I can't wait for Safari and Konqueror to support XSL! With XSL you are able to do so nice things!

I'll echo Al's request for SSL and say it needs to be a priority.

Yes, all the nice rendering technologies need to be supported, but without a solid, flexible, usable way to use them in a secure fashion, they can't be used for anything but webcomix.

no, seriously, Mozilla is the only browser with good SSL support on the Mac, and that's more than a bit of a shame.

It means that as SSL becomes more of a critical technology, Safari will migrate to the 'banned' list because it will be viewed as an impediment to secure connections.

john

SVG: lets kill Flash and take some sanity back into the WEB

Just a quick 1st-pref graph as of now:

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
svg

iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
css3

iiiiiiiiiiiiiiiiiiiiiiiiiiii
xslt

iiiiiiiiiiiiiiiiiiiiiii
mathml

iiiii
uaag

iiii
xforms

ii
xhtml2

with SOAP, liveconnect, pdf, ruby-ml, and contentEditable being double write-ins :)

mmm, 'i's.

XSLT. To claim having XML support in Safari without XSLT is a joke. Well, XML support on Mac OS X is a joke, so that's par for the course. Thank god for Fink and /sw. Sorry guys, BillG's got you beat by a mile.

SVG, CSS, ...? Really, why bother with window frames or tiles on the roof when the foundation is still missing a few layers of bricks?

1) SVG
Because a wider Browser-Support leads to more use of the format.

2) CSS3
Because it's the future... :)

SVG alternative...

I hate to turn this into a SVG forum but the Corel's recent release of her SVG viewer (PC only) make a native SVG support paramount on Macs:

http://www.corel.com/svgviewer

No! perhap we should just ask Corel to release the MacOS version!

How about less crashing in general? I continue to reliably get memory related crashes in the latest build. Google image search for something common, then cmd-click a couple images to open new tabs. Flip back and forth between the Google tab and the various opened results.

Chances are, crashes will come fast and often.

SVG, CSS3, MathML

SVG. There's no widespread, universally compelling need for things like MathML; the rest of the world is still coming to grips with CSS2 (nevermind CSS3), and Safari still hasn't got it quite right; XSLT and XForms are too much of a narrow focus. But we can all benefit from small-bandwidth, reliable vector graphics right now.

Hope not to be too off-topic:
I'd like to have ActivEdit supported - It's something unrivaled in content management field. They say Java implementation of Apple/safari doesn't support live connect class.
they web site is www.cfdev.com/activedit

None of the above. I'd concentrate on supporting something so pervasive it might as well be a standard (and pretty much is, if not an official one) - Flash. I'd work with Macromedia to get the performance of the Flash player to meet or exceed the performance on windows, and I'd work to make sure that Safari is first-in-line to support their XML-to-SWF product in development, code-named Royale. I'm personally hoping that will kill or absorb SVG anyway. :-)

SVG, for the many good reasons given in previous posts.

Or better yet.. implement some cool stuff in Firebird :)

SVG. I hate damn xForms, that's for sure. I say we pretend xforms doesn't even exist.

LoL, reminds me of your OTHER site:

http://kevan.org/brain.cgi?h0tsoup

7. None of the above.

As said before, you need to implement MIDAS or some contentEditable-like editor. It allows you to edit HTML from the web browser. Such a thing is required for some of my projects. Also, it must be compatible with Moz and IE (duh). This is needed for "professional" use of Safari.

On another, "yet-another-feature-request" note... when you hold COMMAND and push enter in a web form, it should submit the form into a new tab.

I was reading the online version of the ruby book (www.rubycentral.com/book/tut_classes.html). I noticed that Header Tags are not rendering properly on this page. In Safari, they render on top of the text of the following paragraph. However this page renders properly in Camino.

Just thought I'd post this info, if I need to post it somewhere else, someone please let me know.

NTLM Authentication...KIDDING :)

XSLT/XML Schema

Dave: I really like the lineup that you said you preferred. Go for it!

After reading all posts and summarizing the importance and relevance of the various technologies it comes down to SVG and MathML.

Many undermine the importance of MathML as they are thinking aminly of the developers not of the people that view the content - be it in a browser or otherwise.

Almost every child in the world uses mathematical statements at some point in their life and as alot of educational material goes electronic, it is inevitable that the importance of of this technology will rise exponentially, especially since other scientific languages adopt it.

Also the tangible "side effects" as mentioned above cannot and should not be undermined. Apple makes alot opf its money from high end, high margin computers and it can be shown that pervasive support for MathML (MathML+WebCore - with support in all Apple applications) can translate into direct hardware demand and sales.

Someone above said the rule of thumb should be to do what other browsers are doing first. Besides the fact that that is not in Apple's "genes" what value would that add to macs vs. the others.

Also, should Safari be ported to Windows as is rumored (to support iTunes 4 WIN i presume) this has the possibility of Safari taking off as an alternative browser even though i doubt that was Apples intended goal when they created it. If Safari were to support the stuff that IE supports first, then there woul;d be no need for Windows users to even download it as they have IE. But if Safari came out with the first full support for SVG and MathML, then the opposite could be true.

XForms! Its going to be *the* way to handle online forms, and support in Safari would put Apple (again) at the forefront of the pack...

Actually, i requested XSLT support yesterday, but then over night I realised that the biggest current problem with Safari is its failure to render XML doc's correctly.

Open a simple XML document in M$ IE 5.x and it renders nicely and allows you to open/close nodes etc. Open the same XML in Safari, and you get a non descript mess.

This is really frustrating and should be sorted out. Safari is much better than Monopoly IE 5.x, apart from this area.

There are some good arguments here for SVG and XSLT. I posted earlier and still believe that XSLT is the thing to do first. For those that think XSLT should stay on the server side, I think you are crazy. The savings in CPU time and BW could be huge, thus taking a serious load off the server farm and allowing us poor, starving Internet based companies to possibly make a profit one day ;). The server could still process the docs for those lousy browsers that don't support the advanced features - thats easy enough to do.

Also, the advanced browser would be running on an advanced CPU. How much of your CPU is used? I think there is a huge unbalance in this world between client/server side processing. There is so much CPU available on a users machine now, and its generally unused. Quite a shame. Between XSLT, CSS2 and good JS support, I could put a substantial part of my product onto a users workstation and they could browse my content all day without having to access my site again, i.e., sorting the data, filtering, searching, etc - never touching my servers. How is that not a huge deal?

So, yea, SVG is very cool and a lot of people will geek out on it - which is great. But it doesn't save or make me any money. Microsoft 'created' and industry by creating products which people could make money around. Apple should learn something from that - and this would be a great place to start.

I would say MathML without a doubt. The scientific community worldwide would find it a huge advantage and would further the advantage of macs in this particular sector.

XSLT
The other choices are enabling technologies, but XSLT has the most Swiss Army Knife possibilities.

second choice: SVG
Spiffy graphics were a big part of the initial success of the web. Flash kind of occupies this space now, but the simplicity of SVG is much more appropriate for the web experience.

SVG for me. CSS3 would be great too but as it's not all there yet and XSLT though cool isn't my thing. A REAL full robust implementation of SVG where we could manipulte the SVG's DOM with [your languagechoicehere/js] would be truly awesome.

XSLT - You have to have that to play at all.
SVG - Cool, but secondary.

SVG SVG SVG SVG!

* XSLT *

By far this would be the most useful thing on your list :) I would also LOVE to see image properties added to the browser - so you could right click an image and get the size, the dimensions, and other information. As a web developer this is one area where I feel Safari falls short.

Keep up the good work!

W3C User Access guidelines. Still have to find a browser that implements these and does so elegantly and flexibly w/o getting in the way if you do not need a particular UAG feature. (And I don't mean 10000 new prefs)

XSLT please, I'm learning it now and I use safari all the time so it'll annoy me to have to switch to another browser to check out my work...

SVG

Because most of the graphics on web sites could and should efficiently be reduced to vectors.

I work for Design Science, and we make the MathPlayer behavior plug-in for IE on Windows, which allows MathML display in web pages. MathML support in browsers is a top priority for us, because we make authoring tools for science and math documents and we want people to be able to use browers to share those documents.

We've looked into KHTML and Safari's plugin support, and unfortunately there is only Netscape-style support there, which isn't enough to do a good job with math. Equations have to be able to ask questions about their environment (current font and size, and baseline) and need to be able to set their own rectangular size, rather than be handed a static size in pixels.

Given the above, we would definitely encourage Apple to add MathML support directly into Safari, and while they're at it, submit the changes to the KHTML folks. MathML is no longer an emerging standard, it's really being used on Windows and in Mozilla, so any platform that wants to be important to the educational community would find it difficult not to consider MathML support important.

Design Science is happy to help Apple out with adding MathML support to Safari.

Two notes about XSLT

-transformation can be done at upload time, there's no need for server- or client-side support...

-...except for MathML. If SVG is implemented, and (internal) client-side XSLT is available, MathML is practically implemented as well...

VRML!!!

Just kidding.

Seriously though... I vote for XSLT.

CSS3!!

http://maccessibility.com/graphics/obeyuaag_lg.gif

OBEY
UAAG

Full W3C DOM support please.

7. how about IE or Mozilla emulation, so we can use Safari for online banking.

SVG for me.

Anything to give it a boost. I know its my future.

XSLT
because it's useful and add features needed.

after
SVG
we need to support the xml based vector format. a lot of more flexible than flash, and webdeveloppers will love to use vector based graphics in their layout.

XFORMs
actual forms are too much limited.

Mathml
useful for mathematicians, well known.

CSS3
I love all the new additions of CSS3... O my !
but It's less needed than others above

XHTML2
the latest one because we have not a real DTD/Xschemas and definite specifications of xhtml2
and , a good xhtml1 navigator can understand xhtml2. it's not urgent.

an other tiny things :
Well, I would like Safari be "strict" like Mozilla when it got a "well formed xml document" with a strict definition + type mime application/xml+xhtml

0. HTML 4 support. Why does OBJECT still as thoroughly broken as EMBED?
"Plug-in not found. [...] You do not have a plug-in installed for this MIME type, so this content can not be displayed." That is in complete violation of the HTML spec. Please fix that first.

1. SVG. The Mac claims graphics superiority. 'Nuff said. :)
Well, OK, one more thing: the Adobe plug-in is wonky if you magnify/reduce.
OK, amongst our weaponry are such diverse elements as extending the DOM into an SVG object. (Is that feasible? Imagine the possibilities on the client side. And if it is feasible, it certainly wouldn't be if SVG were opaque via QuickTime or other plug-in.) See Chris Carline's comment.

Why SVG itself is a good thing: as a text format, it can be generated on the fly by the server. This will drive such things as charts/barcodes on demand and new whiteboarding applications. Imagine the possibilities.

7. Apple Object Model direct AppleScript access to the DOM. No JavaScript.

(Could someone please explain the Ruby/Japanese connection? I thought Ruby was just some third-party scripting language. Where does Nihongo enter the picture? Is there more than one "ruby" out there? Something other than the one that's installed as part of Jaguar?)

As much as I like the idea of equations on the Web, isn't TeX preferred to MathML? That's the impression I've gotten over the past couple of years. Yes, I know TeX is presentation based and MathML is structure based, but if scientists are just converting TeX to MathML, the structure won't be accurate anyway (it would be like converting HTML into XML). May as well convert TeX to SVG. :)

And while MathML is interesting, doesn't IBM's techexplorer plug-in handle it?
And of course that leads me right back to Safari's violations of the HTML spec with the Object tag. That MUST get fixed before Safari 1.0. MUST.
(Yes I submitted a bug report on that back in v51, and v74 is still broken.)

-Walter

Walter -

Your 7) idea confuses me.

"Apple Object Model": are you trying to foist proprietary stuff on Safari users?

"AppleScript access to the DOM": Why? Honest question, because you are suggesting a technology which would tie users to a niche browser on a niche platform. This is not a recipe for success.

"No JavaScript": Are you suggesting removing JavaScript support completely? Or a way for Safari AppleScripts to get at the DOM of a page, thus opening security holes a mile wide? Or do you just not want to learn JavaScript?

The toughest one to work around (or at least the one that results in the ugliest hacks) is MathML. Granted, you don't need it all the time, but when you do... Plus, it's something that can't hurt in the educational market.

This question is on par with "have you stopped beating your wife yet?"

Given that you created XBL, and given your opinions on XBL vs. XSLT in the client, you should know the answer: the majority of W3C standards since 1999 aren't worth implementing.

As much as people probably expect me to say CSS3, I don't think it's the top priority. It isn't anywhere near done, and outside of CSS3 selectors, it's still in too much flux. There's no point attempting to implement it when the specification could change out from under you.

CSS2, on the other hand... fully implementing that (and I mean all the way, minus perhaps aural styles) would be my #1 interest. So... "Other: CSS2/CSS2.1," I guess.

Of the choices you explicitly provided, I'd have to say XHTML2, at least once it's done, with the understanding that also means full implementation of previous (x)HTML versions.

Second choice: XSLT, mostly to bring the feature set closer to that of Gecko and IE.

Third: SVG, because it would allow for much more efficient pages and could be used as a substitute for MathML.

XForms!

Almost nobody is saying XForms, probably because most are unfamiliar with it. There are few implementations of it, and of those, no "real" working implementations (that don't really on transforming the XForm to a plain old html form and handling intermediate stages on the client side).

But XForms would be the most revolutionary technology to choose. The benefit would be in being the first, being the best implementation, to really take a clear lead of all other browsers out there. XForms could really clean up things for small web-enabled devices, and also for big web-based applications. If both sets of developer communities have a browser that can truly handle XForms as it was meant to be handled, the technology could take off really fast and carry you with it.

Millenium,

To clarify: No, I'm not suggesting eliminating JavaScript support; my "no JavaScript" comment was in the context of AppleScript. The "do script" command is meant for things that are impossible via pure AppleScript, and the DOM is by no means impossible to access; browser developers have just been lazy, that's all.

Why do you think it is a security hole? Web pages are public data anyway. I'm not talking about having pages run scripts, I'm talking about the opposite: scripts accessing pages.

Remember, the DOM was MEANT to be accessible by ANY scripting language. AppleScript is the premier Macintosh scripting language. Ergo, we must have AppleScript access to the DOM. NOT leveraged off a "do javascript" hack, but DIRECT access.

And you're right, I do not want to learn JavaScript, but that is beside the point. The point is that AppleScript access is paramount. AppleScript is the glue which ties the Mac together (ok, Apple events underneath), and that deserves first-class access to the DOM.

There is nothing about AppleScript access to the DOM which ties anyone to anything. It is for Macintosh scripters, of which there are thousands.

-Walter

More complete support for CSS 1,2, and 3 as sites (like mine) coded with CSS as opposed to using tables don't render correctly in Safari whereas they do render correctly in Mozilla and it's derivatives. And yes, this is a purely selfish request.

"Why do you think it is a security hole? Web pages are public data anyway. I'm not talking about having pages run scripts, I'm talking about the opposite: scripts accessing pages."

Ah. That's something different then.

But that wouldn't really be part of WebCore, then. It would be part of AppleScript. And in this context, it's a great idea. It's the other way around that could cause security issues.

SVG.

I write software to generate financial reports for a living. I generate lots of graphs. For distribution via email I use PDF. But to put the graphs on a web page mixed with text right now in the year 2003 there is still not a good universal (ie widely supported) scalable vector graph format to use.

SVG solves a business problem that a lot of people have. WMF and EMF are Microsoft-specific. PDF requires that users have Acrobat Reader or something similar. HTML+SVG would be more web-friendly.

The use of bit maps in the year 2003 for informtion that is naturally vector format is dumb. It limits what we can do. It makes reports look worse than they have to look. SVG support is needed.

XSLT - because my webpage uses it. :)
and second, XUL - cause it has no use!
*ooooh, burn*

As a web application developer who is interested in a standard interface in browsers for some basic tasks, I'd really like to see support for the HTML LINK tag. A well thought out implementation of the LINK-element in Safari could be -huge-, providing a standard interface element for web developers to adopt in their applications.

The LINK element was introduced as part of the HTML 2.0 standard. It's time for the web to grow up and this is an existing standard that can help. The web page referenced below does a wonderful job of describing how useful LINK could be:

http://www.euronet.nl/~tekelenb/WWW/LINK/

All these fancy emerging standards are great and all, but if Safari is going to be the first browser to actually implement the standards properly why not fill in some of the existing holes?

- Nathan
(who thinks Safari is headed mostly in the right direction, but wishes to please be rescued from the brushed aluminum of doom! ^_^)

CSS3, if only for the box-sizing declaration:

http://www.w3.org/TR/css3-ui/#box-sizing

XForms and XSLT, pretty please!

I'm working on an application that is currently in C++ with a lot of XML (and running on Windows), but I've designed it with the hope that eventually I can port it to pure XML / XHTML / XForms and run it in a browser.

If Safari gets this rolling, I'll be able to make a convincing case for the Mac, which is currently completely absent from my field of employment.

The other stuff sounds cool, though. ;)

MathML - The web really needs an improved method of conveying mathematics, MathML could be it, but it needs to be more widely adopted.

How about finishing implementing the current stuff in WebCore first? I keep having problems with form displays over at http://www.taxfreedom.com (TurboTax free E-File tax service).

Radio and checkboxes show up as text fields under Safari, but properly with Mozilla or derivatives.

Once that's all done, my choices would be XHTML2, CSS3, MathML, SVG and the rest in that order.

Esteban,

I tried going to taxfreedom.com, but cannot find the forms of which you speak. Looks like they might require a login. Can you save a copy onto your Web site for test purposes?

thanks,
-Walter

SVG, hands down. To give developers the chance to create beautiful easily updated grafix natively within Apple's browser would be awesome. Plus, if Apple kicks back the source to the community, we may end up having more than one browser natively supporting SVG.

Having the opportunity to quickly update and create site graphics in SVG would be tremendous. The time savings would be huge, and would have more impact across the board than any of the other technologies mentioned.

Just my two cents, but I'd love to see it happen.

No one has mentioned support for the accesskey attribute, but presumably this is because they consider it to be such a standard feature that no credible browser would actually not support it.

"As much as I like the idea of equations on the Web, isn't TeX preferred to MathML? That's the impression I've gotten over the past couple of years. Yes, I know TeX is presentation based and MathML is structure based, but if scientists are just converting TeX to MathML, the structure won't be accurate anyway (it would be like converting HTML into XML). May as well convert TeX to SVG. :)"

The problem is that displaying the equation in SVG would mean the equation is being represented by a graphic, which does not lend itself well to copying and pasting. It'd be the same problem we have today with using GIF's; it'd just be a prettier problem. Using MathML would allow one to take the code for the equation straight from the source and put it on his own website or convert it back to TeX.

MathML, please please let it be MathML.

the scientific community drastically needs this, and until some browers start supporting it, it can t happen!

Damien,

With both GIF and SVG, you can still have a TeX expression as a text string "behind" the image, and then you would copy that. Perhaps a browser could make it easier by putting the alternate representations into the contextual menu for copying.

(object ...mathml...)
   (object ...svg...)
      TeX equation
   (/object)
(/object)

and then you could have
  Copy MathML
  Copy SVG
  Copy Text

-Walter

I'd say CSS3 first, followed by SVG, XForms, and maybe XHTML2 (though I hear it will cause many people headaches). I haven't seen MathML used much at all, but it would indeed be a hit with the educational crowd.

To be honest, I have no clue what XForms and XSLT are on about, but I know the former is important. I may be slipping a bit.

SVG all the way. We need a flash killer before Macromedia wins the vector war.

As well, right or wrong, things only become practical to use when Internet Explorer implements them. SVG works in IE (with a plugin) currently which means SVG can be deployed right now. What good is MathML, CSS3, etc at the moment when 95% of the browsers in use won't understand them?

As someone who has coded 3 professional applications that use XSLT client side, I would say Safari needs XSLT support and needs it quickly if Mac is to get anywhere in the corporate arena.
I code for Mozilla as a way to bring cross platform support to our products and Safari often fails to match the rendering which both IE5/6 and Mozilla perform. If Safari persists the old go-it-alone mentality of Apple that bought us NIH (not invented here), it will continue to be the last browser website designers check for.
SVG sounds great but it's not going anywhere folks, just look how it's dropped from Adobe's priorities. Flash won. Just because it's a proprietary technology, doesn't make it bad. Binary data files are small and don't require parsing, that's what makes Flash files quick and responsive.
Browsers get used for lots of different things, my focus is business, any my vote is for XSLT.
If the Mac has given up on corporate computing then I would go for matching Window IE rendering as closely as possible, that means CSS. So CSS3 would be my second option.

"SVG sounds great but it's not going anywhere folks, just look how it's dropped from Adobe's priorities."

Adobe is sort of in a holding pattern at the moment in terms of SVG. Its the chicken and the egg... developers won't use it until it has wide, native support at the browser level, and companies like Adobe won't support it until developers are using it...

"Flash won."

Many cellphone companies have committed themselves to SVG to deliver animation... its not over quite yet.

"Just because it's a proprietary technology, doesn't make it bad."

It depends on how you look at it. The web was surely not designed to use proprietary technologies as that can lock people/devices out which goes against the fundamental goals of universal accessibility intended by the creators of the web like Tim Berners Lee who heads the W3C which releases the SVG recommendations. So if proprietary technologies are considered "bad" by those who created the web, then that's good enough for me. Flash is bad. It takes too much control out of the hands of the user and places that control in the hands of the author. If I want to copy a line of text, or turn off sound (without having to turn off my speakers) I should be damn well allowed to do that... it shouldn't be up to the author to grant me those rights.

"Binary data files are small and don't require parsing, that's what makes Flash files quick and responsive."

Can't argue there...but isn't there some equivalent SVG binary compression called SVGZ or something like that...i know the adobe plugin can read those files but I am not sure if its a w3c thing or an adobe proprietary thing.

Sort of off-topic but I figured I'd throw this idea out there. Has anyone else thought of making the tabs in Safari movable? I guess I'm just tired of having links open new windows in Safari and I'd like to move those new windows (well, their tabs) to the main window I am operating from. Drag and drop that tab from the newly opened window into the window I have been doing all my surfing on. What else does everybody think about this...?

"Drag and drop that tab from the newly opened window into the window I have been doing all my surfing on"

Sounds great... i wish that feature was added to Mozilla too.

CSS 3, definitly, but its useless till it gets implemeted by all the browsers. SO, its a moot point. So why dont you stick to makin sure current technologies work, lol.

I know some people suggested (in jest) the blink tag.

That actually wouldn't be a bad idea for the user to be able to configure certain effects with blink and marquee and whatever other annoying tags are around.

If the blink text were rendered solid and static, but had a slowly fading and growing highlight behind it (like a powerbook in sleep mode) or even just a solid "shine" that didn't animate at all.

It would help those of us who have to look at pages that make use of this tag (because we need to see that semantic importance the author feels they're giving the text) but not be as migraine inducing as other browsers renditions.

Perhaps marquee could do the same (keep the text solid) but render a subtle highlight that scrolls or pingpongs according to the settings the author used. Fortunately marquee isn't nearly as popular with the middle school student crowd so this could be given a pass if time were of the essence.

Of course even better would be an option to render these as other completely static styles like bold or smallcaps or something without the use of a user stylesheet.

"Binary data files are small and don't require parsing, that's what makes Flash files quick and responsive."

Incorrect.

Binary files can be small. This is what SVGZ (compressed SVG) is all about; XML has this habit of compressing quite well, to the point where the size difference between the two files is not large.

As for not requiring parsing, this is also not true: all files require parsing of some kind or another, be they binary or text. Depending on how the libraries are written, this might be hidden from the programmer, but parsing still takes place. Also, keep in mind that a file is generally only parsed once, at load time, and thus it doesn't affect the responsivity of the media contained within the file.

It all comes down to how well it is programmed, in the end.

Mike Malloch says he wants "data-driven web applications to deploy on the mainstream Macintosh browser". I agree. The biggest improvement to WebCore for me would be enabling the Tridion R5 CMS (www.tridion.com) to run on Safari - at present it squeaks that it needs IE 5.5+ for Windows. (More to the point, if Tridion were usable on a Mac, then I could nominate it for PerversionTracker.)

Hey, how about 2 editions of Safari: one designed for non-geeks, called "Safari"; and one designed for geeks, called "Safari Extreme" or maybe "Wild Safari" or something. The Wild edition would have all the bleeding edge enterprise stuff and a zillion user preferences, while the lite/tame version would be the default/easy installation.

Just a wild idea.

-Walter

Oh, and thanks to Kynn for explaining to me what "ruby" is.
If it had been called "furigana" then I would have understood the Japanese meaning. ;)

-Walter

1) XForms, without a doubt. With this one addition, Safari could step out ahead of the browser pack and advance the state of the art on the web. With the ever-increasing importance of web-based applications, XForms is an essential piece of architecture for an efficient web.

2) XSLT. Another critical piece of architecture for moving more of the web application toward the client.

3) SVG. It's gotta happen someday.

4-7) CSS3, XHTML2. These will be nice, but they wouldn't have a significant impact on the web until the majority of browsers support them.

8) MathML. Because I hate math.

Ok, so it's not a W3 standard. But I believe it's not proprietary (it's a MIME document), and it is the single best thing about Internet Explorer. It is incredibly convenient to be able to save and conveniently message a web page as a document.

The output header of a .mht file (as saved by IE) is below.

-------------

From:
Subject: Faughnan Documents
Date: Tue, 3 Jun 2003 09:05:56 -0500
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_NextPart_000_0000_01C329AF.579A6E20";
type="text/html"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165

This is a multi-part message in MIME format.

My two favorites are MathML and SVG.

Oh, and I can't remember if I sent these bugs test cases with the bug button (one is a crasher):
http://michelf.webhop.org/safari-bugs.html

I am sorry if this is not he proper place to post this. I couldn't figure out the logic just yet.

I think I have a found a bug in safari.

I have several pages which are based on a template. These pages all have DHTML dropdown menus which use a show hide layer. These all work great until i add an inline frame to my page. The iframe is named and id'd and the pages which load into them are very basic. Anyway, the menus work intermittantly. They show and hide when they feel like.

I love Safari - and my clients are mostly MAC based so I want to fix this. Any suggestions?

Much appreciated.

why not quickly put together a web crawler that determines a usage statistic for these technology. eventually you might want to pair the data with website ratings (no. hits), and then you simply implement the most-frequently used technology.

All of the above in any order, immediately after fixing the caching problem.

I update a page on my website. Safari shows the old page. I flush the cache. Safari shows the old page. I could probably delete the document from the server and Safari would still show the old page. This drives me absolutely nuts.

CSS - Why is it so hard for web browsers to support CSS fully. It is very easy to learn and apply for the average web-designer. CSS is almost as basic as HTML and the browser designers still don't seem to care. Except for Dave of course because he asked us. CSS can become a powerfull tool when combined with other languages.

Let's get the basics down and supported then work up to the more complicated items. Everyone wants to jump ahead and skip the little things. How does that make a solid browser?

CSS3 for god sakes! On my website, my stylesheet doesn't affect inputs under Safari and it's beginning to seriously bugging me...

How about caching URLs ? There is a nice tool called "au" (see VersionTracker) that speeds up browsing significantly because Mac OS does not need to resolve the base URL for every element on a page any longer but directly goes to the IP address.

Just my 2 cent

CSS3 - I believe the current coding specifications are good as they are - no need for XHTML2, but any extra features for page layout would be excellent! I haven't used any of the others, so I can't say anything about them.

SVG should be a top priority.

MathML is interesting/useful for a small subset of users.
XHTML2 seems to be too religiously fanatical to ever gain full acceptance in the real world.
CSS3 is an incremental improvement over CSS1/2
XSLT and XForms are interesting but feel less useful to a broad pool of developers

SVG, on the other hand, seems like a broader solution that could give developers a technology that enables at least a subset of the benefits of the other technologies mentioned.

A serious and weird bug concerning the Flash plug-in and using "POST" when sending variables to the server.

Every browser except Safari does it right. What happens is that I create a LoadVars object with, among other things, a username which gets sent to the server. The problem is that in Safari the username ALWAYS loses it's last character(!). No other browser exhibits this problem.

I'm not sure if it is the Flashvars(set in htmlpage which loads flash content), that Flash plugin receives or if its the "POST" not working properly in Safari(which is what I suspect Flash really uses when it sends variables). This makes Safari unusable in a large project we are working on.

OTHER - How about fixing the animated gif bug!!

The multiple smilies in the Macintoshian Achaia forum still don't animate even in Safari v80!!

http://arstechnica.infopop.net/OpenTopic/page?a=tpc&s=50009562&f=8300945231&m=2420935965&r=8850975965#8850975965

SVG is my choice. It could simplify the world by taking away the need to use Flash and some Java Applets.

(1) SVG
(2) CSS3
(3) XSLT

MathML please!

My personal preference would be for SVG first, and then XSLT. SVG demos are just so much fun, look good, and get developers thinking about standards being useful rather than a burden. XSLT is more in the useful category; having widespread clientside support will make it more acceptable for folk to risk deploying new XML formats in the Web without worrying that they'll be unrenderable.

I'd also love to see RDF support in the client, but can get by with doing RDF stuff serverside, while SVG really doesn't flourish until it has desktop support.

imho etc.,

--danbri

Client side XSLT!

1) Enterprise and Major portals applications love to push the processing requirements off to the host machine. Is'nt this the much desired separation of data and presentation weve all been begging for?
2) SVG? I dunno, seems lie theres no stoping FLASH and from my perspective XSLT would be so much more useful.
3) IE Does it

I'd have to vote OTHER and fill in the multipart-mixed/x-mixed-replace mime type.

I used this in the distant past for pages that responded to live changes on the server side and it works great. For example watching a log file in real time in a formatted page. Imagine an IFrame with live updating status data in it?

Please?