Forgot your password?
typodupeerror
Firefox Internet Explorer Programming

Best Browser For Using Complex Web Applications? 347

Posted by timothy
from the fatal-error-encountered dept.
yanyan writes "I'm fairly new to the field of web application development. Currently I'm working on a big online ticketing system for passage and freight for a local shipping company. It's a one-man show and the system is written in Ruby and uses Rails. Aside from the requisite functionality of creating bookings the system must also print reports and tickets, and this is where I've discovered (the hard way) that most, if not all, browsers fall short. I've had to switch from Firefox 3.6.3 to Opera 10.53 because of a major printing bug in Firefox, but the latest stable Opera is also giving me its own share of problems. To complicate things, an earlier version of Opera (10.10) doesn't appear to have 10.53's printing problems, but I'm wary. What browsers and specific versions do you end up deploying for use with big, complex web apps that include printing? Also consider CSS accuracy and consistency."
This discussion has been archived. No new comments can be posted.

Best Browser For Using Complex Web Applications?

Comments Filter:
  • by FuckingNickName (1362625) on Friday June 18, 2010 @07:46PM (#32620784) Journal

    Hahaha, I kid, I kid. If your interface is complex, why are you using HTML/CSS/Javascript/etc? Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java or *shock* the native environment?

    The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience. Google are excellent at marketing it as some sort of advance, but it really isn't. Don't shoehorn.

    • by amicusNYCL (1538833) on Friday June 18, 2010 @07:57PM (#32620920)

      Why not take advantage of a more advanced and mature UI widget set, such as that provided by Java

      Java is 20 years old, Javascript is 15 years old, and Java is mature while Javascript is not? Does that extra 5 years really make that much of a difference? Was Java considered not mature in 2005? There are plenty of mature Javascript UI libraries around that developers can take advantage of (ExtJS/Sencha, jQuery, Mootools, etc). There are several use cases where Java is a pain in the ass and an offline application is not an option. A rich internet application implemented in Javascript is perfectly fine for many situations. There's no shoehorn involved when it's the best tool for the job.

      • by Anpheus (908711) on Friday June 18, 2010 @07:59PM (#32620946)

        For recent programming languages, 5 years is a lifetime. Compare Java now to Java five years ago, or Javascript now to Javascript five years ago.

        • Re: (Score:3, Informative)

          by dave87656 (1179347)

          The big difference is that all the browser has to do for java is host the runtime. For javascript, the browser has to support the entire instruction set. Java takes longer to start. But once it has started, it gives you much more control.

      • Re: (Score:3, Insightful)

        "rich internet application"

        Can you define that term? I have seen it used to refer to half a dozen vaguely related concepts so far, so it would be nice to know which one you are referring to.

        "There's no shoehorn involved when it's the best tool for the job."

        The web is not the best tool for every job though, which I think was OP's point.
        • by nixkuroi (569546) on Saturday June 19, 2010 @12:24AM (#32622462)

          I will be flayed alive, but Silverlight 4 is a "Rich Internet Application" framework and with the most recent version, they built in some very tight and effective printing functionality. That, in combination with the ability to pretty much lay things out exactly as you want, export to an image or text format, export the app to an out of browser desktop app, and print in whatever format you see fit, makes it ideal for the kind of ticketing system you're talking about.

          Here's a blog on how to implement it: http://wildermuth.com/2009/11/27/Silverlight_4_s_Printing_Support [wildermuth.com]
          And another: http://www.silverlightshow.net/items/A-look-at-the-Printing-API-in-Silverlight-4.aspx [silverlightshow.net]

          and here's Microsoft's page hyping it: http://www.silverlight.net/getstarted/silverlight-4/ [silverlight.net]

          Here's a blog on linking Ruby on Rails with Silverlight as well: http://techblogging.wordpress.com/2008/03/26/using-silverlight-with-rubyonrails/ [wordpress.com]

          Hope this helps.

          • by koreaman (835838) <uman@umanwizard.com> on Saturday June 19, 2010 @01:41AM (#32622748)

            I would say about 75% of my time at work is spent working around inconsistencies and bugs in Silverlight. To be fair, I've only tried 3, not 4, but they really should have called it "Silverlight Beta 3", not "Silverlight 3". It works flawlessly cross-browser (with a few odd, rare exceptions), and it seems like a big leap forward from HTML/JS for this sort of thing, but I have to say it's not quite ready to compete with desktop solutions.

            However, if you absolutely must have it run in a browser and don't want to use hokey Java applets, Silverlight is something you should really look into.

            • by Anonymous Coward on Saturday June 19, 2010 @03:36AM (#32623274)

              NONE of you posting in this thread section can read, obviously. The question is what BROWSER is best for complex web applications. It is NOT what programming/scripting language is best for making such applications.

              Heck, as wrong of an answer as it would be, "Internet Explorer would be best!!!" would be a better answer than the ones you all are fighting over. At least it's on the list of possible answers to the question.

              Someone needs to mod you all to Off Topic oblivion. There's nothing "Insightful" in you all not even remembering what the question was...

            • Re: (Score:3, Insightful)

              by Pieroxy (222434)

              What are you smoking? The whole point of the web is that it can run on almost every platform out there. Phones, web tvs, Linux boxes, PCs, etc...

              Silverlight, as nice as it may be, will never be able to compete on that front. Look at where flash is today.

              As you say, if you absolutely must have it run in a browser, write it in HTML/js/css. That's what browsers understand.

              • Re: (Score:3, Insightful)

                by jscotta44 (881299)

                The root of this story is about a guy trying to solve a specific internal application problem – not a widely distributed and publicly available application. And, he is writing the application in Ruby, which is good for web development.

                However, I think that I would have written a native application to the platform that they are using instead of a web application.

      • by FuckingNickName (1362625) on Friday June 18, 2010 @08:05PM (#32621016) Journal

        Maturity isn't defined by the number of years since conception, but by its origins and the development and engineering which has gone into it since. HTML/Javascript has only comparatively recently been considered as a serious app development platform to contend with native apps, still building on the hypertext + scripting language paradigm. Even Google knows what a pain it is to work with HTML/Javascript directly and has developed a translator from Java to implement their web apps.

        What's more, there are very few use cases where an offline application (I assume by that you mean "not HTML/Javascript" - I'm not sure what's "offline" about Java) isn't an option. The basic selling point with HTML apps is that you don't have to spend 30 seconds downloading and installing a small binary. When you're writing for a corporation, that's reduced to insignificance because it'd be installed as part of the deployment procedure.

        • Re: (Score:3, Informative)

          "I'm not sure what's "offline" about Java"

          Not that I disagree with you, but there are plenty of offline applications written in Java, using Swing. Java is not limited to applets and application servers, there is a mature library for standalone/offline application development. As I remember things, the reason we do not see more desktop applications written in Java is the bad reputation Java had in the 90s for taking a long time to loa, and to some degree the fact that Swing does not integrate with the d
      • by DaveV1.0 (203135) on Friday June 18, 2010 @08:42PM (#32621268) Journal

        I'm sorry but you have confused HTTP/HTML/Javascript with the internet.

        The fact is that this trend of using the browser as an interface is nothing less than having a hammer and treating everything as a nail.

        • Re: (Score:3, Interesting)

          by Hooya (518216)

          after close to about 12 years of developing for the web - from perl CGI scripts to PHP, Java JSP - JSF, python, RoR and various other related things I've finally given up on browser based apps. I do use HTTP/JSON for an interface between the server side and the client side. That allows the server side to be used from AJAX frontend or from a Java desktop app or what have you. But a strict browser based software - never again.

          For a 'rich' client app I would use either: Qt (python/ruby/c++ in order of preferen

      • Javascript, GMFB (Score:2, Informative)

        by fnj (64210)

        Forget the comparison of years of age. "Javascript" and "mature" are not words which in any sense could ever be considered compatible. After one hundred years, Javascript will still not be a mature language. It is crap by its nature.

      • Re: (Score:3, Insightful)

        Javascript is mature enough, it is the DOM that needs to evolve and be consistent over the different browsers. And CSS.

        Still, I'm not always convinced making everything a web application is an efficient choice...

    • The wheel is reinvented in computer science every so often.
      • The wheel is reinvented in computer science every so often.

        With the web, it's reinvented veeeeeeerrrryyyy slowly. At this rate, it'll pass Windows 3.1 in about fifteen years.

    • I don't think this is particularly insightful advise. A web interface works well, but regarding printing is a sore point. If they need particular printing enhancements, having a network accessible printer and the printing driven from the server may be better. Having the server issue a .pdf, or .ps set for the client to print would work too. Hell writing an extension for formatted printing would probably be ideal and I'd be surprised if nobody has an ns* extension for such a feature already written (thou
      • In the variety of web-based (or web-frontended) systems I've seen, it is somewhere between common and ubiquitous for any serious printing(ie. where fidelity matters, not where somebody just needs a bunch of text to scribble on or take to a meeting) to be handled by having the server spit out a .PDF, as you suggest.

        HTML, by design, Is Not a fixed-layout page description language. This is one of its great virtues. Assuming the designer doesn't muck it up, it should reflow nicely, or at least adequately, on
    • >The web is about where MacOS was 20 years ago in terms of ability to deliver a rich application UI experience.

      Don't insult the mac like that. There were Mac apps back in 1984 that you can still only badly mimic via a web "application."

      The fact is that a web browser is an application that retrieves and renders hypertext documents over a network, and nothing more. Just because it has scripting and the web can make available documents to huge numbers of people, too many people think they can shoehorn any

      • Re: (Score:3, Interesting)

        Don't insult the mac like that. There were Mac apps back in 1984 that you can still only badly mimic via a web "application."

        You're right. I'm forgetting the beauty, simplicity and consistency of the 1984 Mac. I've been using the comparative UI mess that is OS X for too long.

        There used to be some very nice client/server GUI form and reporting tools back in the 90s

        The whole display / presentation / business client / business server / database multi-tier thing seems to have been broken horribly, so now presentation, business client and business server are merged on some cloud and delivered to a dumb graphical display. Why? Well, to take away control, of course.

    • By the way: Why don’t we replace the browser with a window containing tabs of virtual machines that un-freeze a tiny local memory image containing common libraries (also for backward compatibility) that can run remote executables, either as a thin client or as a real application.
      Then we only have to have the ability to separate tabs our to being their own windows and having the ability to have an icon in your start menu.

      And suddenly we have the best of both worlds: Complete encapsulation, simple devel

  • IE or Firefox (Score:5, Insightful)

    by ageoffri (723674) on Friday June 18, 2010 @07:46PM (#32620790)
    Given that IE and Firefox pretty much set the standard, if you aren't developing for both of them then you are setting yourself up for failure. Sure you may be trying to do things the right way, i.e. fully standard compliant, but it isn't the real world answer.

    Figure out what you need to do with your application to make it work in IE and Firefox is the only real solution.

    • Re: (Score:3, Insightful)

      by X0563511 (793323)

      The real world answer is go ignore IE and let all the people still using it go cry.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Actually, the real world answer is design it for IE. If it works in IE then it will work in everything else. Besides, the JavaScript debugger in IE (Visual Studio) is vastly superior to Firebug, and yes, I've used both... I just don't suck the open source/free software ****.

        • by X0563511 (793323)

          Well, if you are going to be like that, I do. Fuck IE, I don't care who uses it. I'm not, and my intended audience shouldn't either.

          (I'm not a developer though, so "fortunately" you don't have to deal with my opinion in any real manner)

      • Re: (Score:3, Insightful)

        The real world answer is go ignore IE and let all the people still using it go cry.

        That's not a "real world answer". That's an absurd geek fantasy. Love it or hate it, most people still use IE [wikipedia.org].

        If you're a web developer, you cannot afford to ignore that your users will make choices about which browser they use that may be different than your own.

      • Re: (Score:3, Insightful)

        by powerspike (729889)

        The real world answer is go ignore IE and let all the people still using it go cry.

        .
        No that is not the real world answer. If you don't get your application working in IE, the people will go find one that does. You might get away with not working in IE if your only designing for the tech crowd, but if your designing for business or the public, then your killing your own business before it's started.

    • That's only true if the system is used by travelers and not travel agents to allow for the bookings.
    • Alternatively, if Firefox has bugs, has he filed a bug report?

    • Re: (Score:3, Informative)

      by blincoln (592401)

      Sure you may be trying to do things the right way, i.e. fully standard compliant, but it isn't the real world answer.

      I managed to write a web application a couple of years ago that not only displayed consistently in IE and Firefox, but also printed consistently from both of them, while remaining standards-compliant and not using HTML or CSS hacks. The printing was by far the harder part - the browsers initially returned very different printed results even though they rendered the page on-screen almost ident

    • From the summary "What browsers and specific versions do you end up deploying"

      That sounds to me that they're *deploying* a specific browser to a specific client desktop. That it may work in 'the real world' would seem a moot point.

      That said, avoiding too many browser-specific hacks may ensure a smoother upgrade path when deploying, say, version 3 to Chrome9.1 sometime in the future. (But hardly answers the question of which browser *today* prints best.)

    • Re: (Score:3, Insightful)

      by Hurricane78 (562437)

      I’m a long-term professional, and if you are developing for any specific browser, you are a failure, and not a professional.
      The goal is to know the W3C standards by heart in every minute detail (yes, it can be done, since I did it for years without problems), and design to it. In a way that allows you to spot things where not you are wrong, but the browser is!
      You only add browser-specific quirks after you’re done. Separated from the main code wherever possible.

      Otherwise you end up with a huge no

  • My experience: (Score:5, Informative)

    by Roadmaster (96317) <(roadmr) (at) (tomechangosubanana.com)> on Friday June 18, 2010 @07:49PM (#32620816) Homepage Journal

    In my experience, the easiest way to get a consistent and stable printing experience is by generating PDF. I have yet to have stability problems if this is done properly. As you're working with Ruby on Rails, using Prawn and Prawnto might be useful. However, if you absolutely positively must NOT use PDF for printing, then this probably won't help you.

    • Re:My experience: (Score:5, Insightful)

      by Jah-Wren Ryel (80510) on Friday June 18, 2010 @07:54PM (#32620868)

      PDF gets used for all kinds of wrong reasons - I freaking loathe web designers who think a PDF is an appropriate substitute for a web page - but printing is the one place that PDF shines. Just make sure the user can easily and intuitively specify the paper size and you should be good to go.

      • Re: (Score:3, Insightful)

        by FranTaylor (164577)

        If the user is printing out standard forms to be used in shipping the last thing you want to do is let the user change the paper size.

        • Re:My experience: (Score:5, Insightful)

          by mikael_j (106439) on Friday June 18, 2010 @08:24PM (#32621158)

          He should at least make sure the form works with both A4 and Letter size papers, otherwise the company will be in for quite a shock when they decide to expand their business outside the US and find that the most common reaction to mentions of letter size paper is "Letter size? Is that what you call A4?".

        • If the user is printing out standard forms to be used in shipping the last thing you want to do is let the user change the paper size.

          The user already gets to decide what paper is in the printer.

      • Re: (Score:3, Informative)

        by DiegoBravo (324012)

        Just please give the Windows users a link/suggestion to download a good PDF viewer, or at least anything less evil than Acrobat Reader.

    • by Gr8Apes (679165)

      I will second this. PDFs are THE solution for printing, or even sharing strictly formatted documents, even electronically.

    • Re: (Score:3, Interesting)

      by afidel (530433)
      The only problems I've had is how in relationship to certain HP printers using Postscript drivers, they'll occasionally run into problems with certain PDF's containing values that are valid in later PDF specs but not valid for PS. If we hadn't done a huge amount of form design around PS I'd switch em to PCL and be done with it.
      • Re: (Score:3, Informative)

        by drinkypoo (153816)

        If we hadn't done a huge amount of form design around PS I'd switch em to PCL and be done with it.

        I've had pretty good luck printing postscript to non-postscript printers using ghostscript as a filter. These days it's not even that computationally intensive, all things considered.

    • I have to totally agree here... PDF is probably the appropriate tool for the job... though if it's an internal application and the printers are network enabled, you could drive the printing from the server, which may work better. Either way, there will be some issues in place. It would be nice if there were an *easy* option in browsers to actually set the browser to *NOT* print the header/footer for certain sites, then have respectable print css options, and it could work well still... The biggest drawbac
    • Re:My experience: (Score:5, Insightful)

      by Vellmont (569020) on Friday June 18, 2010 @08:07PM (#32621032)

      Absolutely agreed.

      Anything mission-critical like printing a ticket should absolutely NOT use something that could cause the whole system to break down when a single trivial update happens. HTML wasn't designed for printing, and it never will be. The browser is just a band aid put on top of a fundamental disconnect in technology and application.

      I'd even go so far as to say that unless you're outputting and printing from PDF or some other well defined and standardized print format, don't proceed any farther. You'll pay more for the problems down the road when the whole she-bang doesn't work for some dumb reason.

    • Ditto. I wouldn't rely on HTML/CSS and browsers to render something to be printed. Use PDF or an image to provide reliability in printing. If you plan to use barcodes, I'd suggest either interleaved 2 of 5 or one of the 2-d barcode formats like PDF417.
    • It may also be worth noting that this is exactly the solution that no less minds than those at Google settled on. When you "print" in Google Docs, you get a PDF that you can print from the local machine's native print faculties.

      -Peter

    • by IdahoEv (195056)

      I agree with using PDF for print consistency, I've used the pdf-writer gem in my Rails apps.

      On the other hand, I've never had a problem with printing and print stylesheets in Firefox, and have used that solution whenever I don't need pixel-accuracy in my printouts.

    • by pctainto (325762)

      If you don't want to learn Prawn and are more comfortable with HTML, use something like PDFKit [github.com], which is a wrapper around wkhtmltopdf [google.com], which basically just packages WebKit for PDF printing. You'll be able to use CSS3 and other niceties and it'll be consistent, since it's creating a pdf. Perhaps you can do better things with Prawn, but I guarantee that writing moderately complex reports will be easier with PDFKit then with Prawn.

    • You might also consider PostScript. It's a lightweight solution and you can output it without relying on an external library. Making lines and text is simple, so it's well-suited to printed forms.
  • by Simmeh (1320813) on Friday June 18, 2010 @07:49PM (#32620818)
    Export your data to XML or PDF on the fly and have something sensible print it.
    • XML, as in XHTML?

    • by darkain (749283)

      I'll second this. Look around and found some decent F/OSS PHP libraries to generate PDF documents. They do exist, and works well enough. This is what I had to do for an inventory management system that I develop for a client.

  • Chrome, PDF (Score:5, Insightful)

    by amicusNYCL (1538833) on Friday June 18, 2010 @07:50PM (#32620826)

    Even though I don't use it for development, I've got several of my clients using Chrome to take advantage of the Javascript engine. My applications use a lot of Javascript for the interfaces, and Chrome speeds up the rendering of large data sets compared to IE or Firefox.

    For printing, the only solution to keep you sane is to export reports as PDF and let them print through their reader. That's specifically what PDF is for (consistency in displaying and printing). Depending on the report, they may also appreciate a CSV version that they can do their own filtering and sorting on.

  • Lynx! (Score:2, Funny)

    by turtleAJ (910000)
    All the way!
  • by John Hasler (414242) on Friday June 18, 2010 @07:53PM (#32620864) Homepage

    ...is a much more serious bug than any possible printing problem.

    • ...is a much more serious bug than any possible printing problem.

      I'd say mod parent up, but other people recognize the wisdom and have done so already.

      Do not write a web application tied to a particular browser, or even two particular browsers. You will repeat mistakes made 15 years ago when people used to do the same thing for Internet Explorer or Netscape. Those who come after will curse your name forever.

      Remember all those sites that used to say "Best viewed in IE5" or "Best viewed in Netscape"? You don't want that.

      • But nobody has discussed how to actually achieve the 'don't write for a specific browser'. The answer is to use a library (Yahoo, ExtJS, Google, Prototype, etc) that takes care of that for you. Then, you write to the library and your problems are solved.
  • by EmperorOfCanada (1332175) on Friday June 18, 2010 @07:54PM (#32620878)
    If you forced me to use Opera to use your system I would demand that they find a new developer. Or as a customer I would find a new system.

    This is a classic example of a developer trying to tailor the user to the system instead of the system to the user.

    Stop your whining and just make it work in one or more of the common browsers. I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried; but made them work in the end.
    • Wish I had mod points, parent is absolutely correct. Stop complaining and trying to find some panacea for your architecture problems. It seems you want to have something you can show your client 'There! it works on THAT browser!' instead of thinking about the common denominator. There's no way I'd be happy having to use not just a particular browser, but a particular version of that browser - who are you trying to kid? The client and the user, it seems. Sorry if this seems harsh but that's my opinion.
      • by cosm (1072588)

        Wish I had mod points, parent is absolutely correct. Stop complaining and trying to find some panacea for your architecture problems. It seems you want to have something you can show your client 'There! it works on THAT browser!' instead of thinking about the common denominator. There's no way I'd be happy having to use not just a particular browser, but a particular version of that browser - who are you trying to kid? The client and the user, it seems. Sorry if this seems harsh but that's my opinion.

        +1 Insightful. Browsers make decent end user solutions for light web apps, but finding an enterprise class solution that will only work for one build on one browser is like telling golfers they all have to use the same set of clubs to complete a course. It will not go over. No matter how 'great' it looks in X build of Y browser. Don't tie your application down to a specific environment; understandably web design is like trying to make a shoe that fits everybody, but making everybody else lop off toes to fi

    • by Qzukk (229616) on Friday June 18, 2010 @09:06PM (#32621420) Journal

      I have been forced to bend crap environments to my will and I suspect that most developers around slashdot have bent bad systems until they cried; but made them work in the end.

      I bent and bent, then cried and gave up and I had to tell my users to use IE. There's a table printing bug from 2005 that is still open, though fortunately my specific flavor of printing problems (entire rows of data going missing at page breaks) eventually went away several versions after firefox 2.

      Nowadays I use PDF, though several PDF generation libraries I've tried had serious deficiencies like being unable to tell me how much space a block of text will take before it places it on the page, or being unable to override Acrobat Reader's default printing settings, which fuck up anything you're trying to print onto an existing form. (I hacked it into fpdf once, but it was essentially a copy-and-paste of a command from another pdf that was able to force me to print with auto-fuckup-and-center turned off. It worked for me and my version of reader, but I didn't dare put it into production since I had to change the spec version fpdf inserts into the header (1.3) to one that supported overriding the printer options).

      If your reports don't need anything too fancy and they already pop out in HTML, you can use html2ps | ps2pdf to get something kinda resembling the original webpage. You can't make it look pretty and I'm fairly certain it's text only, but it'll print out exactly as it appears no matter what browser you are using.

  • It sounds like the web-app you're using isn't coded well. Hate to put it that way, but if you're having this many problems with it, it's probably true. As for browsers to use - just switch until you find one that works. Try each of the rendering engines and browsers that use them (trident, webkit, gecko, presto, etc). Find one that works, use that.
    Next time around though, write the app better. Export to PDF/PS if you need formatting to be absolutely preserved.
  • What are the "printing problems" you're having?

    If the problem is that you're having trouble making things look the way you want to (you mentioning printing bookings, which I suspect might need a very rigid format), you're not going to get away from that. HTML is designed to allow variation by browser implementation and by user preference. It's not supposed to look the same everywhere.

    If you need accurate, precise print reproduction everywhere, your best bet is to generate some kind of PDL (Page Descriptio

  • yea...there's a reason why there's a media type definition for CSS.
    Plus using javascript to load browser specific CSS so I don't have to rely on CSS hacks and also keeps things "valid"

    Oh, and I dropped support for IE6.
    IE7 is going soon too as IE8 becomes mainstream among IE users.
    Still, I hate IE with a passion.

    My main browsers are FF3.0x+/3.5+, Chrome/Safari, and Opera 9/10....in terms of testing.

  • by Zadaz (950521) on Friday June 18, 2010 @08:00PM (#32620950)

    The only way that anyone does proper printing of web documents is as PDFs, and to hell with the browser. This is for very good reason.

    If your system absolutely must print from a web page, use Flash. Yes, I know. But it will print from within the page, it produces identical prints in all browsers/platforms, and everyone already has it installed.

    • Output to a PDF document and have them print it out.
      PDF is an open format. Go for it! Enjoy.

      Flash is an OKAY solution, but the printer support is hopeless unless your users have downloaded and installed an AIR application.

  • I wouldn't use the browser for printing. I would render the document to an RTF on the server, then hand it over to the client for printing.
    • by TomXP411 (860000)
      Darnit, I didn't mean RTF. I meant PDF. :-) Although, RTF's work too, as long as a good word processor is installed.
  • that isn't clear from the description: Is this a tool meant to be used internally by the company or is it meant to be used by the general public?

    Because if it's the latter, whatever your solution, it better work in every browser and not just specific older version of Opera.

    • that isn't clear from the description: Is this a tool meant to be used internally by the company or is it meant to be used by the general public?

      Because if it's the latter, whatever your solution, it better work in every browser and not just specific older version of Opera.

      It doesn't matter. You cannot guarantee what browser a user will have loaded today, much less a few years from now, whether it's in a corporate environment or not.

      • Most place I've worked at recently have firefox installed, except for that one pesky intranet webapp that only runs in IE6 (and higher if you're lucky!)

        I'm not advocating the tie-in to a specific version of Opera. However, with an army of IT support personnel keeping things real, I don't see it should be a huge deal, given whatever other cruft they routinely install and maintain in an SOE.

        (Assuming of course this application is locked down to an internal network)

  • The "Best Browswer" is the one your paying customers use. For better or worse.
  • Generate PDF tickets on the fly. There are plenty of open source and commercial libraries to help you out.

    As for a "major" Firefox printing bug etc: you're doing something wrong. I presume that's since you're new. I have an in house monstrosity that prints invoices (think tables, lots of lines and tight alignments) fine across the spectrum: from IE6 to every contemporary browsers. All using CSS and HTML. So it can be done, and I've yet to run into any printing bugs, major or otherwise. There are hacks to be

    • by micheas (231635)

      The problem I had was that every browser had different printing preference settings.

      Do background images print?

      Are images scaled?

      Do images print at 72dpi? 300dpi? the alt text?

      Are fonts over ridden?

      The list just went on and on.

      Use a pdf library, it will save you time.

      Make sure that you can embed the fonts in the pdf. otherwise you will be dealing with all sorts of stupid bug reports.

  • If you want to do quick cross-browser testing, try Browser Lab. [adobe.com]
  • You'd best cover IE, Firefox, and Safari at a minimum. I've been using the Google Web Toolkit (http://code.google.com/webtoolkit/) for the past 3 years and have been very happy with it.
  • Ok, I'm presuming that the problem is native browser printing. The printer section of CSS is the red headed stepchild of the spec with only Opera getting it remotely right. That leaves PDF which has been discussed. Given your description of the situation you might have a third option.

    If you're building this for an in house company as it sounds and the server is onsite consider creating a Postscript file and then commanding the OS to print the file normally. This cuts the browser out of the equation entire

  • by poor_boi (548340) on Friday June 18, 2010 @08:59PM (#32621364)
    You've got it backwards. You don't write a web application and then go around installing 9 different browsers at 20 different patch levels in a search to find one which finally doesn't break while using your app. Rather, you write an application and install 9 different browsers at 20 different patch levels to make sure none of them break while using your app. Fix the app, not the browser. And if the problem is intractable in the most popular versions of the most popular browsers, change your framework.
    • by reiisi (1211052) on Saturday June 19, 2010 @03:43AM (#32623304) Homepage

      I really, really wish I could agree with you.

      But there's a fundamental problem. An intractible problem, even.

      Browsers simply try too hard to be all things to all people.

      That's an impossible task without making all people conform to your definition of all people. Woops, totalitarian dictators and religious idealogues keep trying that one and finding it doesn't work either.

      We should not be continuing to try to build or define the ultimate browser. We should, instead, be defining standards for browsers for specific application fields in specific countries.

      Open standards, not standards led by any industry leader or special interest group.

      Simple, standard browsers, implemented and implementable by small teams with unencumbered tools. With an overall API a single developer can grasp, and libraries that don't require teams just to find out where to find the answers.

  • Forget about trying to make HTML into dependably formatted print output. Just use a library like Cairo to render what you want into a PDF and provide that to the users.

  • by corsec67 (627446) on Friday June 18, 2010 @09:08PM (#32621436) Homepage Journal

    I also develop for Ruby on Rails, and we have to support IE 6-8. (Of course the developers all use Firefox for Firebug)
    For printing, I switched to using LaTeX, and returning the PDFs.

    HTML just doesn't give you the kind of control that you need on a piece of paper.(Try having custom page headers/footers, for example) I ran into the bug in firefox where it would skip rows of a table going over a page boundry, and then there was other issues with it dropping images on other pages.

    Plus, LaTeX just looks better. HTML is great if you don't know what it is going to be displayed on, but when you do know what kind of paper it is going to be displayed on, HTML isn't the best choice.

    (Specifically, I used the rTeX plugin, with pdflatex)

  • Don't even bother trying to use HTML to make printing work. Generate something else (pdf is good.. consistent, widely supported.. evil) and have the user print that.

  • had to write to or (in b2c) the website is expected to handle any browser the user might reasonably have, starting with IE6.

  • HTML should render adequately in any browser - or your doing it wrong. In print I thoroughly suggest very literal html/css as in absolute measurements for everything. Or if warranted pass the HTML through princeXML on its way to becoming a PDF, you will have much more consistent results that you can count on.

There are running jobs. Why don't you go chase them?

Working...