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."
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..
Whale
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.
-- Language is a virus from outer space.
I'd like HTML forms to include a tag that uniquely identifies the site publishing the form, and the form itself. Probably a hash of the form's field names, signed by the site with its SSL certificate. Then I could click an option on the form to repopulate it with the last data I already inserted into that same form the last time I filled it (or any previous time, in a history). Storing that data on my local terminal, rather than leave it stored at the remote site.
And I'd like for the full range of common personal info fields to have standard names, so I could click to fill out the neverending series of personal info forms the Web challenges me with all day, every day. Click to refill the form with the same info as last time I visited it. Or one dataset from a list of named profiles stored on my local machine. So I don't have to remember what personal info I disclosed to this or that site, or scrounge for it from the other places I keep that info stored personally.
If the system let my browser point at a "personal info server", I could click to populate these personal info forms using anyone's terminal, not just my own, though I'd have to trust the terminal not to exploit the personal data exposed while using its browser as a transfer point. Maybe these personal info forms could also take a URL that points directly at my personal info server, and let the challenging server direct its request to my personal info server, which lets the challenging server login (as prearranged) and get the data specified as available to it.
That infrastructure would take some work. But it would save me a lot of trouble every day. And therefore save a lot of trouble for millions of others in the same boat. While lowering the transaction barriers, without sacrificing security. And indeed increasing security, by minimizing the personal data stored outside my control, at numerous (and forgettable) unaccountable remote servers.
--
make install -not war
That patch has been available for a while (and has improved) and was there prior to Firefox 3.0. It was "too late" for 3.0 so was to be postponed until 3.1. And now history repeats...
Funny, just now I was checking the Roadmap for Inkscape. SVG animation is planned for the next-next release (0.48, it's 0.46 now, 0.47 will be basically some internal re-factoring).
Unfortunately, multi-page support, which was the feature I was looking for, is planned for 0.49 (or 0.50?).
factor 966971: 966971
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.
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.
Need Mercedes parts ?
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.
Do daemons dream of electric sleep()?
Like Split Browser?
Ok, I'll bite (again).
"Adobe repeatedly refused to release an updated Flash plugin for Linux. That is why they skipped a version. They said they were done with Linux support. One guy kept pestering Adobe offering to code it for free, and the eventually let him create an updated Flash plugin. Allowing one man to do the work unpaid begrudgingly is not what I'd call supporting a platform."
That sounds fucking crazy to me. Yes, Adobe skipped a version. However, they did so because that version was a transition to a pretty new codebase. I'm not arguing that proprietary Flash is great... it pretty much sucks. However, Adobe isn't in a position to use Flash to create greater lock in for "Adobe OS" or whatever. So Flash is the lesser of two evils in this case (and I mean actual evils, not just metaphorically).
"You suggest Silverlight is designed to screw everyone."
Silverlight is about screwing everyone but Microsoft. It's prime reason for existing is to promote Vista and Windows. That's it. If Flash only ran on Windows, Silverlight wouldn't exist.
"Not every Apple product is a massive success. Not every Apple product is great for graphics. Not every Apple product has a great UI."
Uhh, ok, not sure what this tangent is referring too.
"Not every OSS product is really "open" (take a look at OpenOffice and Sun's strangehold)."
You clearly don't understand what open source is do you? You realize IBM has forked OpenOffice from Sun's "strangehold." Have you ever heard of NeoOffice? Same deal. They took source from OpenOffice and made their own version.. for their platform or product.
"Not every Microsoft product is terrible. Not every Microsoft project is evil."
You're right, not every product and project is evil. But Silverlight definitely is, to anyone with a brain.
"And Mono is completely different from Wine."
Are your years of programming experience failing you now?
Wine is a reimplementation of the Win32 software stack. Microsoft's version only works on Windows. So, some enterprising developers used Microsoft's own specifications (when available) to create a clean room reimplementation of Win32 for various platforms.
Mono is a reimplementation of the .NET software stack (the successor to Win32). Microsoft's version only works on Windows. So, some enterprising developers used Microsoft's own specifications (when available) to create a clean room reimplementation of .NET for various platforms.
Now, considering Wine only runs about 10% of Win32 applications well and Mono only runs about 10% of .NET applications well, perhaps you understand why I see similarities in the two.
"You offer vague accusations with no proof."
I anxiously wait your poignant response, refuting me.