Vector Graphics Lead Wish List For Future Browsers

Coach Wei writes "Community voting results and a summary report have been published from OpenAjax Alliance's recent "community wishlist for future browsers" effort. When the voting closed on July 13th, 222 people participated in this open community initiative, with 143 people voted, 55 feature requests being written up, and contribution from many industry leaders. The voting indentified and prioritized 37 features. The top 10 are related to vector graphics, security, performance, layout, rich text editing, Comet, audio and video. Among all the feature requests, 2D Drawing/Vector Graphics is clearly the most desired feature by the community. It received most votes (110 people voted for it), and highest total score (over 10% higher than the second feature request). Looks like that it is time for all browsers, in particular, IE, to seriously consider supporting standards-based vector graphics."

Comments

"Community" ?

[qoncept]

I don't think the OpenAjax Alliance's poll reaches quite what would constitute the "web browser users" community. I'm also trying to figure out what the "particularly Internet Explorer" comment meant. Not that I read the article..

Re:"Community" ?

[maxume]

Except for AJAX...

http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support

I mean, they didn't come up with the cute name, but they did package the technology first.

"Override Back Button Event"???

[PontifexPrimus]

Ok, I'm normally a peaceful person, but if someone invents a way to trap me on a page and disable my back button I'll hunt that guy down and kill him. Seriously. I understand that AJAX doesn't play well with the back button, but if this cancellation of functionality is implemented so that every site can deploy it easily it will break the web as we know it.

Re:"Override Back Button Event"???

[Mongoose Disciple]

Do a lot of web development? This is one feature I would love -- users can completely destroy how a web app works just by clicking on the back button and asking "where'd all my data go?"

They sure can. This might put the onus on you as the web developer to build a smarter app. Or to not build that particular as a web browser app at all. You've got options, and it's not like the back button is a new feature that's surprised you and thrown off your assumptions.

Re:"Override Back Button Event"???

[ShieldW0lf]

Would seem to me that both camps can be made happy by allowing the developers to indicate that "THIS" page should not be added to the browser history.

So, if the user goes to the home page, then goes to a "view product" page, then goes through a purchasing process, you could suppress the pages involved in the purchasing process from being added to the history. If the user hits the back button half way through making a purchase, it would take them back to the "view product" page. If they then hit "forward", it would do nothing, because the "view product" page is the most recent entry.

The ONLY thing that is needed is...

[JustShootThemAll]

The ONLY thing that has to be added, and needs to be added about ten years ago, is a date input field in forms.

One that is locale-aware (DD-MM-YYYY, MM-DD-YYYY, or whatever you're locale used). Currently you have to jump through several hoops and it is near impossible to get a foolproof date input.

'Bout time

[rs79]

Oh sure, NOW people understand we need vector graphics.

I saw NeWS demo'd by sun in 84. I used native postscript extensively in 88+.

Then I watched html make a mess out of nearly everything to do with the network (html email? huh?).

Bout friggin time poeple woke up.

Re:Damn graphic artists...

[multipartmixed]

Of course you have to convert it to/from strings, duh, you can't put an abstract concept like an object on a wire and send it across the internet. So we represent the object some other way. A string is a perfectly fine way.

And -- Oh -- it's a string which which contains a JavaScript object literal. Now, what do you call the language subset which defines the string appearance of a Javascript object literal? JavaScript Object Notation seems pretty damned reasonable.

Don't like calling eval() to parse the object literal? Why not? It's an object literal; to turn ANY piece of source code (and that's what it is, source code for an object) you need to run a parser over it. It turns out that eval() is a pretty damned good JavaScript parser.

You could, if you we were so inclined, parse the JavaScript yourself. And, in fact, if you only wanted to support objects -- not the whole JavaScript language -- you might want to only parse a limited subset of JavaScript, which some freaky has guy (who works at Yahoo) has decided to call JSON.

Now, what's the best way to write a limited-function parser in JavaScript, and still have it be really fast?

Use native constructs.

Hmm, but does JavaScript have any native constructs which allow us to easily build parsers which understand small regular grammars? Hint: there's a reason they're called regular expressions.

So, the current common/secure technique is to use a regexp parser to validate the input to eval(), because that's the fastest way (two calls, both into native code).

Now, how the hell can we MAKE these objects? Well, it's pretty easy from JavaScript; the .toSource() method and/or uneval calls work pretty good.

So, we now have a general-purpose way to serialize/deserialize javascript objects into something we can send over a network. If you wanted to, that's enough to start a cult and try to build a career around. You could even describe it really complicatedly (like on http://www.json.org/). Or, you could build a compilcated object/class hierarchy around it, like this guy http://www.devpro.it/JSON/files/JSON-js.html -- I suppose you could even come up with something as complicated as DCOM or CORBA if you were really bored.

But it's still nothing more than winging JavaScript source code around the internet, and validating it somehow [regexp] if you don't trust its contents.