Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Vector Graphics Lead Wish List For Future Browsers

Posted by timothy on Tue Jul 22, 2008 12:18 PM
from the unlisted-options-involved-pornography dept.
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."
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • "Community" ? (Score:5, Interesting)

    by qoncept (599709) on Tuesday July 22 2008, @12:21PM (#24291583) Homepage
    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..
  • by mdm-adph (1030332) <(moc.liamg) (ta) (hpdamdm)> on Tuesday July 22 2008, @12:22PM (#24291605) Homepage

    ...keep your art out of my code (and off my lawn)!

    Native JSON should clearly be at the top of this list. I call shenanigans.

          • by mdm-adph (1030332) <(moc.liamg) (ta) (hpdamdm)> on Tuesday July 22 2008, @01:37PM (#24292887) Homepage

            Trust me, that's why it's called JavaScript object "notation" -- it's not actually a JavaScript object. You still have the extra step of converting it out of string form when you get it from the server.

            • by multipart/mixed (163409) on Tuesday July 22 2008, @02:14PM (#24293403)

              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/ [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 [devpro.it] -- 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.

  • by spazdor (902907) on Tuesday July 22 2008, @12:23PM (#24291617)

    Guys, guys.
    We've got it covered. Just close your eyes, bend over, and wait for Silverlight.

      • by Anonymous Coward on Tuesday July 22 2008, @02:00PM (#24293209)

        You realize adobe has released an official flash player for Linux right? How did such an ignorant post get modded insightful?

        Microsoft is not to be trusted, they have proven this time and time again. Silverlight itself is built on a platform designed to screw everyone in the IT world over.

        Microsoft tried to corrupt Java and make it Windows only... and got stopped. So they cloned Java, e.g. .NET, and made it Windows only.

        Mono is a few major revisions behind Microsoft's implementation. It doesn't support a large part of Microsoft's software stack. It is basically "Managed Wine."

        It's not the kind of thing I'd want to rely on and no one in their right mind should let Silverlight put Microsoft in a position to take over the Internet.

        So in short: avoid Silverlight like the plague that it is.

          • by edward chan (1330765) on Tuesday July 22 2008, @02:33PM (#24293721)
            "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." What are you talking about? I happen to know several engineers on the Flash Player team at Adobe that currently work on the Linux version. And as far as I know, the upcoming version, FP10, fully supports Linux as well.
      • by croddy (659025) * on Tuesday July 22 2008, @02:14PM (#24293397)
        All that is nice, but what we need is a vector graphics kit that's not shipped by yet another fucking vendor. Something that's a spec, not a binary.
      • by Red Flayer (890720) on Tuesday July 22 2008, @04:15PM (#24295427) Journal

        Silverlight supports 32-bit and 62-bit browsers.

        Sweet, where can I get a 62-bit browser?

        I already have a two-bit browser, that would be IE7.

        /Ducks

  • by Mordok-DestroyerOfWo (1000167) on Tuesday July 22 2008, @12:23PM (#24291619)
    Where I work we're constantly scaling our web software needs to fit the situation, and I have yet to be able to cross a vector and a scalar!
    <ducks>
  • by unity100 (970058) on Tuesday July 22 2008, @12:27PM (#24291689) Homepage Journal
    and also openajax alliance constitutes what we call 'browser users' on the internet ...

    that alliance should try to make ajax actually something of use to the internet, rather than trying to shape future browsers to their preference by staging limited scope polls and then pushing it as browser community's preferences.

    or, we can just kill all buzzword crowd and get it over with.
  • by PontifexPrimus (576159) on Tuesday July 22 2008, @12:28PM (#24291691)
    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.
    • That's what the Super Back Button is for.

      This could be the start of the back button arms race...

    • by urcreepyneighbor (1171755) on Tuesday July 22 2008, @12:37PM (#24291869)

      <sarcasm>Well, you see... our new, half-assed, pieced-together technology will only properly work if we force users to use it the way we want. Remember: it's OUR content, so we get to determine how the USERS use it!</sarcasm>

      <serious>UseIt.com [useit.com].</serious>

    • Re: (Score:3, Interesting)

      Overriding the back button would lead to evil behavior on some websites. I think what would be better is to have a way to register "the page has advanced" events with the browser when dynamic content is loaded. In other words, the back/forward buttons could be tied to application states that aren't necessarily a result of a complete page load. This would be like the YUI Browser History Manager [yahoo.com], but with a simpler set up and no libraries to include.

      The only problem is that sites could load up the application

      • Re: (Score:3, Interesting)

        And nothing "traps" you in a page; just close the tab.

        That kills the browsing history of that tab. Thank you very much for trapping me on that page.

          • Re: (Score:3, Insightful)

            Well, if you're using a decently made web app it's going to have opened in its own personal tab/window anyway. No history concerns that way.

            If a web-app is well made, all is well. But this is going to be abused by those too lazy to make a good webapp. Anyway, if a webapp opens in a new window, will it ever have a history to go "back" to? Will the back-button even be enabled in that case?

          • by bberens (965711) on Tuesday July 22 2008, @12:49PM (#24292075)
            I don't consider any webapp that opens its own special window to be decently made. The window I open you in should be quite sufficient tyvm.
      • by Overzeetop (214511) on Tuesday July 22 2008, @12:36PM (#24291847) Journal

        As an end user and a project manager, I'd have to ask you why your code doesn't allow such a possibility. Not that I don't understand the added effort and difficulties (okay, technically, I don't; I don't program for the web), and it would suck to have to make it all work properly, but that's kinda your job.

          • The problem is the back button causes a very very very large break in the sanity of web applications. You can kiss a consistent state goodbye.

            I know I'm contradicting my sig, but I want to explain why you are wrong.

            Session state is maintained on the server, not the client.

            If you trust the client to provide you valid data about the state of the application, you are very stupid. This is how people get owned.

            As such, you should remember what the user was doing, and if they open the application again, return them to where they were.

            Disabling the back button is wrong. If your application cannot handle me leaving it any any time gracefully, it is a piece of shit. And if you absolutely must have control of my system, well, that's why we have xulrunner. In fact, I would go so far as to say that the web is probably not even the best way to deliver an application of that nature, but you could argue that one back and forth all day - my main argument is that users expect web pages to behave in a certain way.

            The real issue here is that a webpage is not a standalone application, and you run into problems like these when you try to make it one. Webpages are forms, like screens on mainframes, and are request-oriented. Your web applications should be the same.

      • by Mongoose Disciple (722373) on Tuesday July 22 2008, @12:39PM (#24291891)

        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.

          • by Jeffrey Baker (6191) on Tuesday July 22 2008, @12:52PM (#24292129)
            If you consider yourself a "web developer" and don't know how to manipulate the URI fragment to make the back button work with AJAX, then you should just quit right now and become a politician or a lawyer or something. The back button is fundamental and all AJAX applications should work with it.
            • Re: (Score:3, Insightful)

              Hey, that's a bit harsh, don't you think? I develop for the web. Just because I don't use every trick of the trade, you shouldn't try to call me names (lawyer).

              Should I not call you a "car driver" because you can't do the Nurburgring in 8 minutes? No, because that would be silly.

              (Or, like has been said elsewhere, just open a web app in a new window/tab. Problem solved.)

              • On one hand, you have a point. On the other hand, anyone who would hire you to write an AJAX application when you can't do this is not competent to hire you (typical, though.) This is more like not calling you a car driver because you don't know how to parallel park.

                P.S. If you open a new window, and I don't need to use your site, I will close the window and never return. I prefer to avoid incompetents who think they should control what my browser does. Thank you.

          • I do web development work. I'm not completely talking out my ass here. You do have some options.

      • by isomeme (177414) <cberry@cine.net> on Tuesday July 22 2008, @04:59PM (#24295989) Homepage Journal

        The back button works fine, and without data loss potential, if you follow a simple recipe:

        * Never return a page from a POST; redirect to a GET instead (after processing the POST).
        * Never modify business data from a GET.
        * Never allow pages containing dynamic data to be cached.

        Follow those rules, and every page in your app will be safely bookmarkable and play nicely with the back button.

        • Re: (Score:3, Informative)

          There kinda is -- you hook into the "onunload" event on a web page, prompting the user with a dialog. It's how web apps like Meebo.com handle this problem.

        • by ShieldW0lf (601553) on Tuesday July 22 2008, @12:50PM (#24292089) Journal

          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.

  • by TorKlingberg (599697) on Tuesday July 22 2008, @12:28PM (#24291705)
    It seems the vote was open to anyone on the internet, and only 222 people answered. There will probably be more people writing comments in this thread.
  • ...who doesn't want cross-domain access? I'm perfectly fine with making server side code to parse whatever I need and then feed it to the browser via the local domain.

    Am I missing something? Something about making a browser more independent of the server or something?

  • Sliding Panes (Score:3, Interesting)

    by Doc Ruby (173196) on Tuesday July 22 2008, @12:36PM (#24291829) Homepage Journal

    I'd love Firefox to let me set not just exclusive tabs each with their own page, but also to let me slide around a dividing border between two panels, each with its own page in it. Side by side, or top/bottom, or a grid of X x Y. Let me look at two (or more) pages at once, scrolling each independently inside its pane. Comparing. copy/pasting. Like Excel and OO.o spreadsheets can allocate ranges of cells to separate window "portals" onto the sheet below.

  • SVG animation (Score:5, Insightful)

    by gr8_phk (621180) on Tuesday July 22 2008, @12:37PM (#24291863)
    I'm glad Firefox has SVG and is improving it. I really want to see SVG animation. It sucks to use java script just to cause a diagram to have a few moving parts when animate transform would do the trick.
      • Re:SVG animation (Score:4, Interesting)

        by gr8_phk (621180) on Tuesday July 22 2008, @01:00PM (#24292277)
        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...
  • by apathy maybe (922212) on Tuesday July 22 2008, @12:41PM (#24291937) Homepage Journal

    Don't we already have that? Yes, yes we do, it's called TinyMCE [moxiecode.com] and it is licensed under the LGPL and can be included on your form with just a couple of lines in your HTML code.
    Oh wait, you want native rich text editing? Yeah, like you are really going to get a consistent experience across different browsers...

    You know what I want from my web browser? I want it not to freeze when loading large (and/or lots of) images, and I want secure JavaScript, including killing off all JavaScript easily (none of this take over the browser with 50.000 alerts crap). Yeah, I know Opera has that last one, but I want a [i]free[/i] browser as well.

    Anything else? Security sounds nice. I personally don't have much of a use for vector graphics as a developer, but I can see how they would be useful for everyone else.

    Ummm... Maybe I'm just not very imaginative, but I tend to find that stability and security top my list of what I want nearly every time.

    (Though I have to admit, the new address bar in Firefox 3 is nicer then the Firefox 2 bar.)

  • by Doc Ruby (173196) on Tuesday July 22 2008, @12:44PM (#24292003) Homepage Journal

    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.

  • by oodaloop (1229816) on Tuesday July 22 2008, @01:03PM (#24292313) Homepage
    You'd think on a geek website the CSS would work, links wouldn't take you to random parts of the page, text wouldn't constantly overlap, etc. If maybe we could get that simple stuff to work first before we take on all this over stuff.
  • by doti (966971) on Tuesday July 22 2008, @01:12PM (#24292463) Homepage

    Funny, just now I was checking the Roadmap for Inkscape [inkscape.org]. 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?).

  • by JustShootThemAll (1284898) on Tuesday July 22 2008, @01:17PM (#24292553)

    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 (Score:5, Interesting)

    by rs79 (71822) <hostmaster@open-rsc.org> on Tuesday July 22 2008, @01:21PM (#24292619) Homepage

    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.

    • I tought SVG is already implemented in most modern browsers...

      Not when you weigh each browser by its usage share on home and business workstations. As long as Windows Internet Explorer doesn't implement SVG, and as long as Windows Internet Explorer has more than 50 percent usage share, "most modern browsers" don't implement SVG.

          • Re: (Score:3, Interesting)

            but being realistic, if you don't consider the market leader to be a "modern browser" then the concept is pretty useless, because pretty much anyone writing a modern web site is likely to want to cater for IE users

            I'd say that making "modern" become a synonym of "widely deployed" is what makes the concept useless. If you want to write a modern website, it's ok to exclude MSIE. If you want to make a popular website, then perhaps it doesn't. But why can't we say "modern" when we mean modern and say "widel