I have developed working D3 driven charts and as far as all the other browsers go, there are no problems.
but recently the need to support them also in Internet Explorer 8 cropped up.
But so far i can't make this html display in IE8.
these are the tags used in D3:
<svg> <path> <g> <line> <circle> <rect>
for the last 6 hours i have skimmed through a lot of materials and questions including:
"Display inline SVG in IE8" which has this answer from October 2012:
I have been looking into this too and a number of options came up.
Chrome Frame - A browser plug-in that actually uses chrome underneath, meaning SVG just works. This is great if you're able to deploy plugins to the browser, for a real commercial environment however this may not be possible.
SVG Web - The aim is it bring SVG to all browsers. It looks like a fairly large project, one that's had Google's input. This doesn't however work out of the box with D3 though I don't know much about the issues.
D34Raphael - You've mentioned this one, I found again it doesn't work out of the box. Check the project out on GitHub, there hasn't been any commit activity in months and there's some pull requests "first pass on trying to get support for .on() required for event binding". If it doesn't support events, is that an issue to you? I'd generally keep away from this one.
R2D3 - Again another one you mentioned. I took the Sankey example from the D3 website and had to make a few changes to get it working. The main things I couldn't get working (Drag Events, Groups - though can use an alternative). It took about a day of effort to get the example working in IE8 and I believe is in a useable state. The project on GitHub is also much more active, the developer is committing, pulling work in and is very active on discussions etc. This gets my vote.
Also:
D3 IE8 Compatibility?
wikipedia.org/wiki/Scalable_Vector_Graphics
SVG Web Compatibility
But the solutions using client-side plugins are not acceptable and so far it looks that i can't display svg in IE8.
So the solution is to find some other ways to render vector graphs.
I presume that others have had the same problems
Edit:
either way, people that will encounter this same problem after me will at least have somewhat concentrated materials and will realize that there is no easy/real solution to display svg on IE8 and better to spend time starting on the existing code rewriting/adjusting for non-svg version
Edit:
after some testing i would say that its worth trying to go through R2D3 examples and see if its possible to simplify/execute the code in IE8
Samples
Edit:
During the process of testing different elements separately some r2d3 problems seem to arise
most common would be Invalid argument and Object doesn't support this property or method
as i am not used to develop for IE8 there were some useful tips that i found:
dump javascript vars
and
display objects
Not sure if you are still looking for an answer, but I ran into this issue on a project a few years back. We ended up switching over to HighCharts for the browser compatibility. At the time it was still in its infancy as a charting library, since then it's become much more powerful and still maintains browser support back to IE6.
Unfortunately for most people now supporting IE8 its down to client restrictions rather than consumers.
Without informing those that have requested it of the restraints, backwards compatibility and cost implications along with valued links from this post, the solutions for making canvas work in IE7/8 and using the JScharts variants is your best option.
Of course, it means not using D3 unless you want to double your work load = cost. Just remember to mention that every time.
Good luck
IE8 (as far as I can see) simply doesn't support SVG. The only solution I can see working is using a different graph library which uses a canvas to draw it's components. Think of libraries like CanvasJS, ChartsJS, GoJS or VisJS Network Graphs and then using excanvas to make them work for IE8.
Another solution I found when researching this topic is using Chrome Frame. It makes IE8 support SVG. Though, sadly, Chrome Frame is retired and no longer supported anymore.
Knowing all this you have to ask yourself: "Is it worth going through all of this for the less than 0,1% of people who still use IE8 and below?".
Because, if you want complete d3 compatibility you probably would have to write your own converter from svg to canvas and even then, you still have to hope that excanvas supports all the canvas functions you write.
Edit: Changed browser percentage to current IE8 usage
Related
I have a Windows 7 with service pack 1, and Internet Explorer 10. And I have my site, http://www.gfcf14greendream.com/ . It looks great on Chrome, Firefox and Safari, but not in Internet Explorer. For starters, I wanted to test how my site looks using IETester, and it's a mess (please compare by clicking the link above):
The thing is, I think that maybe the issue could be that IE8 doesn't load well from <object> tags, is that it? I use three object tags to load the three white parts: header, vertical menu, and "site log" (you can see them here: http://www.gfcf14greendream.com/header.html , http://www.gfcf14greendream.com/verticalmenu.html , http://www.gfcf14greendream.com/thesitelog.html)
To load those three sites, I use the following code:
This one for the header, <object type="text/html" data="http://www.gfcf14greendream.com/header.html" width="100%" height=185></object>
This one for the menu, <object type="text/html" data="http://www.gfcf14greendream.com/verticalmenu.html" height=484 width=100%></object>
And this one for the log, <center><object type="text/html" data="http://www.gfcf14greendream.com/thesitelog.html" height=600 width="90%"></object></center>
Please let me know if anyone has any ideas concerning this "mess". Thank you!!
This isn't a real answer (It's a quick and careless answer at best, so don't take it too seriously)
But I just thought I'd mention that the the W3C markup validator might be useful to you if you don't already know about it.. It catches bad markup practices or errors on your page and can give you more information on how to fix them. At the time of writing, your front page alone has 10 errors and 3 warnings on it. Maybe this could point you in the right direction?
upon a quick skim of your page you don't seem to be utilising CSS properly. That is to say, that I see you are using css but you have elements on your page (use of <center> HTML tags, inline styling and things like that) that go against the grain of why CSS was invented.
If you haven't already seen the CSS zen garden, take a quick read/look at it. It should set you right on why we use CSS instead of tables and alignment tags.
(People sometimes don't get this immediately, but , click the links on the right in the zen garden. The same HTML and page content are completely restyled using one html file and seperate CSS sheets)
Good luck!
Edit:
Oh, I almost forgot to mention that internet explorer 8 doesn't have much (if at all) HTML5 compatibility. If you want to develop websites and web apps in HTML5 you'll be hard pressed to serve your I.E 8 visitors and may end up spending more time fixing bugs than you are developing the content.
Some developers are already boycotting I.E 8 entirely to usher in the new era of the web with HTML5 and CSS 3. There are a few js compatibility libraries out there (like excanvas for the new <canvas> element for example) but they don't work flawlessly and you will eventually have to draw the line somewhere. (lol. canvas.. draw line.. get it?) That being said, i did find this article and this may be useful to you:
turn-on-html5-in-ie8-or-lower
Not every website requires HTML5 and it's new technologies, but if you plan on using it for things like the <canvas> tag, Id suggest (from my own personal opinion) you forget about I.E 8 and concentrate on browsers that utilise it.
Remember that you can make checks in your HTML to see what browser version your visitor is using.
You can see if they are using an incompatible browser, and if so, you can then alert them that their software is out of date and suggest to them alternatives (such as chrome or firefox)
There's a bunch of tutorials on-line about this, here's the first decent looking one I found in a quick Google search this article covers using this technique for seperate CSS sheets but there are others that talk about the problem I mentioned in more depth and I'm sure you can probably figure out how to do it anyway once you read the article.
Either way, I'd say you've got a little bit of reading ahead of you to understand why your humble website does not work in an increasingly obsolete browser.
Again, good luck to you in your future endeavours.
Edit was too harsh:
Having looked a the site I would start by suggesting in future you think about design from a users perspective - the colour scheme you're using isn't very friendly on the eye, the red text against the green is particular troublesome to people with red/green color blindness, you also should consider how your content is presented.
End Edit:
However, regarding your IE issues.
First things first, with any work is getting a firm plan of what you hope to achieve and setting a good groundwork before starting. With HTML that means leveling the playing field with regard to browser quirks, and to achieve that, you use a reset css file.
This ensures that all browsers (as close as possible) behave in more or less the same way, regarding padding, spacing, line heights etc, and can go along way to prevent these sort of problems from happening, and allow you to achieve consitancy.
There's more info at the link below.
http://meyerweb.com/eric/tools/css/reset/
Secondly your HTML version - your declaring HTML5 but then use HTML4 values and attributes - basically your site (as pointed out above) is not valid markup.
Assuming I already have valid code, is there a tool or plugin that I can use to evaluate my website code and highlight areas where different browsers could potentially display the code differently? I am aware of websites like browsershots and I have VMs to test, but I'm wondering if there is something to shortcut the process by looking at the code and warning of well known cross-browser compatibility red flags.
For example, when using CSS which is not universally supported yet. The following is valid CSS 2.1:
display: run-in;
Validators which are aware of CSS 2.1 will pass it with flying colors, but really, a red flag should be thrown, indicating that it does not work in Firefox 3. On the other hand,
border-radius: 10px;
is actually pretty well supported in updated browsers, even though it is CSS3.
This is new in Javascript, but is also passed by validators:
getElementsByClassName();
but it would be better if a warning popped up notifying me it won't work in IE8.
Another example is well known rendering bugs, which can be triggered by weird (valid) situations. I understand there is no replacement for opening up the website in every single browser on every system to really see how it works, but I am just wondering if there is some tool that can help check that I'm writing interoperable code as I go, so that I can test more frequently in the development process and spend less time working out bugs later.
Unfortunately, the answer is no.
I once started looking into creating a tool exactly as you describe. The reality is that most libraries like jQuery actually make use of browser incompatibilities and different interpretations of standards (or ignoring the standards).
So, if you're using any of the standard libraries then you'd receive tons of warnings and actually get very little out of it. The amount of spam simply will shadow the actual bug you might have introduced.
What matters more is whether the incompatibilty actually affects the end result. Hence we went for what-you-see-is-what-you-test method instead of static code analysis.
I'm developer of Construct 2, a HTML5 game editor for Windows. It's at http://www.scirra.com.
Recently I've been trying to add a feature that will modify an image by transforming it on a canvas. It's pretty straightforward - draw an Image to the canvas and call getImageData() to get the pixels.
When the user clicks 'preview' in our application, all the files are dumped to a temp file on disk and a browser launched to show it. Uploading to a server is not an option for previewing - some games are megabytes big.
However most browsers block you using getImageData() to get the pixels of any image loaded from disk at all. I've tried putting all the necessary image files in subdirectories as MDN suggests in its description of file:// access policies. That doesn't work either!
Chrome's --allow-file-access-from-files flag fixes it. However, I need to support all major browsers. Is there a similar workaround for at least Internet Explorer and Firefox? I have no idea about Internet Explorer, and I really wish there's something which doesn't involve manually going to about:config in Firefox, otherwise we will be deluged in support requests asking "why doesn't it work in Firefox?!".
Also, why on earth is this security policy necessary?!? It seems way over the top and makes applications like ours really difficult to write.
Any help appreciated.
Your name sounds familiar from HN.
This is pretty laid out in stone in the spec by now, though this upsets an awful lot of people. http:// and file:// are different origins, and anything that tries to put one on the other will dirty the origin. As you noted file uri's themselves have their own set of rules that make things even trickier.
Drawing something to a canvas whose origin is not the same? Too bad, the origin-clean flag henceforth is false, which then disallows you from doing various things.
A complete list of those things is located in the spec here.
But I'm sure you know all this by now. You want to get around it.
I'd suggest ins instead of trying to strong-arm the browsers around it, you bundle in some kind of lightweight web service so that things are all appearing from the same origin. It will cause a lot fewer headaches in the future.
You'll probably want something like the Python SimpleHTTPServer. But that decision really depends on what you've already got included in your product already at this point.
Recently, I have been battling with: weird table borders/margins, div alignments, positioning problems, and am having a down right nightmare supporting Internet Explorer 6. I know a lot of you like me are forced to support, IE6-IE8, Web-Kit, and Mozilla based browsers.
My questions to you are:
What are the important rules you use before hand, when developing across multiple browsers to save you time?
How do you prevent yourself from writing incompatible tags?
What is the best way to avoid hacking your code?
Where do you find research on browser compatibility, do you use any tools?
Finally, when do you cross the line/where do you draw it?
I usually code against Firefox (or Safari) first. That usually produces the best results across browsers other than IE. I then hit IE8, IE7, then finally IE6.
Know what tags are going to cause you trouble and avoid using them at all costs. It's all about how familiar with each browser's issues.
Don't use hacks. Use IE conditional comments. By using conditional comments, you can load one stylesheet for all other browsers, one for IE8, one for IE7, and yet another for IE6 (if you need that kind of granularity to fix your issues). It will give you nice clean stylesheets with as little hack-i-ness as possible.
LitmusApp
There really aren't lines to cross. If you need compatibility, you need compatibility. You just whiddle down your issues as best as you can one at a time until you have something usable.
I would say to start with standards-compliant code. Always test in a standards-compliant browser first like Firefox, or Safari/Chrome. I prefer Firefox for the addons (such as Firebug, HTTPFox and the Web Development Bar). Then work your way DOWN (and by down, I mean all versions of Internet Explorer).
Try to stay away from temporary fixes per situation or site and generalize your code as much as possible. For example, as Justin Neesner said in his answer, using conditional comments and a general style sheet for IE6 , 7, and 8 will knock out most of your problems with layout and formatting, without using (too many) hacks. You can reuse the IE stylesheets, and just place the site-specific code in it.
Use a testing platform like browsershots, netrenderder or LitmusApp so you can see what your site is doing in as many versions of browsers out there. Studying browser compatibility deeply will make you pull your hair out, but any great resource like quirksmode.org can give you information on the little gnats of incompatibility, so you don't go crazy, and bald.
As far as when do I cross/draw the line, it's 99% Internet Explorer issues, and if it's close enough to looking like FF or Chrome/Safari, I'm done. Almost like art, it's not when you're finished adding, it's when you're done removing the crap you don't want to see; that's when you know it's done.
I say there is not that much you can do except sticking to the basics:
Code standards compliant HTML
Validate early, validate often
For Javascript, use a framework like JQuery, Prototype or Dojo
Pick one "main browser" you optimize for first.
in every project, there will be a number of issues, but if you stick to these points, not too many.
I find it extremely helpful to build 100% W3C valid code. Not because it matters - much of what the W3C validator complains about will not make any difference in real world browsers - but because being able to run a validation, and getting a green light and knowing that all is well on that end is very helpful.
To test multiple IE instances at once, you can use IETester. It's not perfect - conditional comments won't work in it for example - , but mostly usable in everyday development work.
use a doctype like html 4.1 transititional which makes ie6 render in standardsmode. You can also use a reset stylesheet.
Use strictly compliant HTML and CSS markup and do not use browser proprietary extensions to CSS.
IE 6 does not implement CSS correctly beginning with its absolute ignorance of the box model.
IE 8 on the other hand has a test suite to prove they implement every aspect of CSS 2.1 correctly (which no other browser does).
Develop for Firefox as stated above and make a decision about supporting IE 6 & 7 or not. Frankly, I no longer develop separate style sheets for those browsers. They don't have enough market share (at least on my site.)
Given the interest in HTML 5 and the lack of interest in XHTML 2, develop HTML 4.01 Strict and follow these practices: (which are recommended in HTML 4, and required in HTML 5 and XHTML 1.1)
all elements and attribute names must appear in lower case,
all attribute values must be quoted,
non-Empty Elements require a closing tag,
no attribute minimization is allowed,
In Strict mode, all inline elements must be contained in a block element.
Why to learn HTML 4.01 Strict with references.
Also see the CSS 2.1 Test Suite
So I have been running around for a while now, 26 days later I think I am ready to give some feedback to my findings.
Coding:
First of all, I found that column systems seem to cut down the amount of HTML and CSS written. They are also very cross-browser friendly. Although there are many of them, I found that the 960 Grid System works the best for me: http://960.gs
Next up I found that Ruby has a cool extension for CSS called, LESS. This has been ported over to .NET and can be found at: http://www.dotlesscss.com. It is easy to setup, and is very powerful when used right.
Javascript, can be tricky but I found out that avoiding certain selectors and shortcuts in languages like JQuery will not only speed up the performance of your application, but exhibit less awkward behavior.
Testing the browsers:
Here comes the interesting part. Without any software I found that testing my applications against Internet Explorer 6 and Safari at the same actually helped increase the speed of my development. Firebug and Firefox actually cause me to develop around the problems and this is what causes a lot of extra code. When developing simple code against IE6 and Safari I found that going back to Firefox and IE8 is incredibly easier. Most problems I have had were with border widths, which were easy fixes.
The best software solution I found that was accessible to me was Expression Web with Superpreview, if you ever wonder why Microsoft releases a bunch of version of IE, its probably so they can sell you tools like these.
Anyway, that's my 2 cents for right now.
I'm looking for feedback on peoples experiences with developing sites that work across browsers. It seems to me there are at least two obvious ways to approach the task of making your site/webapp work across browser:
Constantly test across all supported browsers every step of the way; or
Pick a browser, get everything working in it as a reference implementation and then make all the other browsers match the reference implementation.
Each approach has an obvious drawback -- the problem with #1 is that you end up doing a lot of unnecessary work -- especially if you are developing a webapp that is going through a lot of iterations/prototyping/spikes etc. You will make a bunch of stuff work across browsers that will subsequently be discarded/removed.
The disadvantage to approach #2 is that while it makes the initial development much quicker and more painful it makes it much harder to figure out where some of the specific errors arose, especially for more complex issues -- whereas if you had been developing for all browsers at once you should catch it right away and know what change(s) introduced the problems.
A somewhat obvious third option would be a hybrid approach, but it seems to me that you would end up losing more by experiencing both of the problems with #1 and #2 than you would gain from the benefits of doing both.
What have you found to be the most effective way(s) to approach this challenge?
I’ve found that if you get too deep into developing a website without looking at other browsers you’ll quickly get to a place that is too much of a headache to debug. I consistently open my web pages in all the browsers I care about.
I strongly suggest you verify all browsers each time you make a large change to the site.
Make it work with all browsers up front. This will mean extra testing during development but will cause you less pain later. I find it's usually easier to diagnose problems if I've just developed the thing, rather than coming back later and trying to figure it out...along with a list of other issues.
It partly depends on whether you know it's going to have to work in all browsers up front. If you do, then you really are better off just making it cross-browser to begin with. You don't need to test that everything is 100% compliant every step of the way, but you should code toward that.
And really, it's not that hard, especially what with JS frameworks like jQuery and Dojo around that take care of the scutwork. If you find yourself continually battling one browser or another, you might want to reconsider your design, as you may have chosen to do things in a way that is inherently more difficult to do when cross-browser compatibility is important.
Well, you do #1, but you do it whilst greating a style guide. A litle bit like this: http://www.sitefromscratch.com/content/html-xhtml-css-testing.
So when designing a new site or design, you create a page containing the desired HTML for all the visual elements that will be used on your site. Ignore style for now, just use the HTML that makes the most sense.
Then you style it. Preferably, your style guide would be all on 1 page so it can be open in each browser you're supporting and all you need to do is hit refresh between changes, (avoid opting for several pages, because it will take you longer to inspect them all).
When you build your site, build from the style guide. If it's not in the style guide, add it and test it there first. If you discover a problem when building the site, (perhaps you didn't consider a particular element when it wrapped, for example), replicate and fix the problem in the style guide.
Here's the killer advantage: A new version of one of your supported browsers is released, what would you prefer to test, your entire site, or the style guide?
So that's the CSS taken care of, now you need to do that all over with your generic JS functions, if any.
I created an interface compatibility layer between the browser and my code - basically, I wrapped certain functionality and made the wrappers determine what javascript/html was needed.
As browsers change, you change this compatibility layer and you can leave the rest of your code alone.
If you have this layer in your architecture, the answer to your question becomes "whenever you want".
If you can get an enterprise lock-in then multiple browser support can become less of an issue, e.g. if your customers are all companies using Internet Explorer then why build the site to look good in Safari or Chrome?
If though you are making something for the general public then there is a hybrid approach I'd use which is that I use one browser to get all the functionality there and working and then test across browsers when I'm in that "pretifying" phase of the project. Initially the key is for it to work, then it has to look good.
I don't think I could see a logic to testing across all browsers as I initially fill out a form or do some other basic functionality as it could be a big productivity drain to test across at least a few browsers, e.g. IE 6 & 7, Firefox 2 and 3, Opera 9.5, Safari, and Chrome if one wants to get all the big boys, and at least a couple O/S as Safari on a Mac can be different than Safari on Windows, which is a lot of tests even for just one or two pages. On the other hand, near the end, this is when I can refactor my CSS and inline styling and make the code better for handing off for someone else to maintain, archive until a service pack project is planned, or keep some documents just in case something has to be done. Also, by waiting to clean things up, I can have more confidence in the final UI parts as these can evolve and change considerably over a short period of time.
I usually start out ensuring that all the HTML and controls that I write/use adhere to the specification.
Tools-->Options-->Text Editor-->HTML-->Validation-->Check Show Errors and choose your Target
This starts me out on a solid base. I functionally test new features in a single browser and then about once/twice a day test the full set of them across all browsers.
Using this approach, CSS and JS are the usual suspects when something isn't right, its rare that it's the actual HTML markup.
If you can do it right the first time. Do it then. It will probably never be right later.
Depends mostly on your experience, which could be applied to any programming activity including this one. If you know in advance what likely pitfalls you're going to have to avoid (eg. in cross-browser development, don't make it hard on yourself by trying to do something that is going to be a hassle in a different browser), then you can probably safely develop everything in one browser and then go in after it's done and tweak things to get it working everywhere.
I usually advise junior developers to keep all browsers open during development and to refresh each browser when making changes, but I myself tend to write everything with Firebug for support and then go back and see how it's doing in IE7 (etc) afterwards. Since I've been doing this for several years, most of the time I can predict what's going to be causing a headache and often immediately know where to look to fix it.
If you are new to Web Design/Development then getting things right in different browsers can be a chore at times.
However, it's really not that hard to get a website working in every major browser and coded towards the W3C standard. In my opinion EVERY designer/developer should do this out of principle, otherwise they are no better than they were in the IE years.
Develop cross-browser code, make sure it validates and never think about designing for one browser again.