Related
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
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
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've been a web developer for quite some time and what has helped me in learning is to visually see what is going on.
That's the reason for Tools like Aardvark, Web developer, Firebug and many others.
But when i saw the Gecko Reflow Videos they just blew my mind.
Then my question is, is it possible to truly debug html (step through each element)? Or come close to it?
What i've been doing a lot is to use Aardvark and remove elements but Aardvark has its issues with "background" and same size elements and not being able to target those.
UPDATE: I've been trying to write a good update for this question since it has left me thinking about it more. But since English isn't my primary language its been tough.
In the past years it's been the browsers who have had the task of being compatible with the standards. As they get closer to that goal, it is us who should be thinking about what we can truly create when browser compatibility is minimal, and if there are techniques we can utilize that makes rendering a page faster.
We can think of the past decades as the early years of HTML/CSS, where the main goal was just to get the thing to work. Now we should be looking for techniques that speed up the current process. An example of this is in the video above where the Gecko engine is running through the code twice. Why is that? And are there other instances where its doing unnecessary things (even though they work and are compatible)
This is something that clearly needs to be tested to be confirmed, hence my original question of a true debugger.
My $0.02:
"True" HTML debugging, in the sense you're talking about, is not technically possible, because there is no requirement of HTML user agents (web browsers) to render HTML elements in a particular order, nor is there anything like an atomic unit of execution like a "statement".
For instance, when rendering a table, should a user agent reserve space for each <tr> before rendering their child <td>s (breadth-first)? Or should it render each child <td> and each <td>s child and so forth (depth-first)? In practice, user agents make all kinds of guesses to try to render pages as quickly as possible. In other words, there would be no guarantee that debug-order will match actual render-order, nor should there be.
HTML can be thought of as an declarative language in this sense, in that it specifies what should be done (the page rendered to spec) but not exactly how to do it (exactly which order to render elements to the screen). In general, it's best to assume that everything happens at once, although the W3C does give some tips on speeding up <table> rendering based on how user agents should render <table> elements.
IMO, the webdev toolbar and Firebug are the best we've got, where we can edit/disable specific HTML elements and CSS rules.
ok - serious answer.
Judging by the comments on the sites that I've followed from that link, I think that you and I know that there probably isn't. There are a lot of smart blokes and blokettes on those threads, and they all seam to point towards the "no, this is all clever $4!# that wont help us in understanding rendering.
However, I think that what your question might want to emphasis is that rendering at a browser level is very interesting.
Let me just throw this one out there. Do you think that putting body { overflow: scroll; } as a default might speed us up just a little???
In my professional opinion, there's really only one effective tool for time-factoring / assessing / debugging within the html milieu: The WebDev Iterator
Personally, I feel as long as your HTML validates to W3C spec, isn't that all that matters? One should develop their HTML to spec and let browser companies worry about their bugs (which are pretty rare these days) than to focus on old browser mistakes of the past.
HTML Validator plugin for Firefox (aka Tidy) is all any web developer needs to see if their markup is correct, what's wrong, and where it's wrong.
Even if you could do true debugging, each browser parses HTML it's own way, so even if you could step through Firefox to see how a rendering bug occurs, that won't help you with IE or Safari/Chrome at all because they execute parsing in their own manner. This isn't like PHP, .NET or Java where the parsing of the code is the same for everybody, debugging makes sense there.
Then my question is, is it possible to truly debug html (step through each element)? Or come close to it?
You could probably step through the page rendering process by running Firefox under gdb, or modify an open-source browser to have a "step" button, but I really doubt this will achieve anything useful.
CSS isn't that complicated, everything is basically a box, with a width/height/padding/margin.. The problem with web-development (CSS particularly) is every browser implements rendering slightly differently (some more differently than others)..
If you want to know the render-order to speed your page load up, I'd say you're going about this the wrong way.. The browser rendering the page probably accounts for maybe 5% of the load time, the rest is page-generation time and network latency.
You could possibly shave 2ms of your page load by reordering some tags and using a different CSS positioning method.. or you could reduce the page-generation time by 200ms by caching, and half the network latency by setting up a second web-server nearer your users.. Compressing your logo better, or minifying your javascript would most likely improve load-time (universally, across all browsers!)
Basically, if you're concerned about load time, there are much better places to start. If you're concerned about how the page is being rendered, Firebug(-Lite) and http://browsershots.org (or a virtual machine or two) are all you need!
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.