Google has announced yesterday that it will be releasing a new web browser... Google Chrome...
What does this mean for the Web Browser industry? More competition... And from a Giant like Google, it's sure to be very interesting!
So what can a new browser do for us? well for the user, it means a cleaner interface with some feature and performance boosts.... for us developers, it means real sandboxing, true garbage collection, significant JavaScript performance boosts including compiled code before it runs, better security, and even the ability to run in a browser window that is stripped of all things "browser" allowing our "Browser Apps" to feel more like "Apps" and less like "browser".
I gladly welcome this new arrival and look forward to the innovation that Google will bring to the market!
Here's a link to their blog post:
http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html
Showing posts with label browser. Show all posts
Showing posts with label browser. Show all posts
Tuesday, September 2, 2008
Thursday, July 24, 2008
IE 7 Bugs are at it again!
Today's fun is with Unordered Lists. The basic structure is like this:
list-style-type
list-style-image
list-style-position
So why does it have to be so hard for Internet Explorer to render these little buggers correctly? If you can answer that question, Fly to Seattle and let MS know... maybe they'll make you a millionaire...
Okay... enough of the bashing and onto the issue at hand.
1. IE does not correctly handle margin/padding with image bullets... lets say you want there to be a 10px top margin so that your bullets are not stacked right on top of each other, FireFox does just fine... IE moves the text but forgets to line up the bullet... the solution? Take your bullet image and add some transparent canvas to the top... luckily, FF will still line the image up for you.
2. IE does not like if you specify a height on an LI where you are using "list-style-position:inside;". For whatever untold reason, IE decides to make it "list-style-position:outside;" instead. This is clearly a bug. FF also handles this correctly... the solution? either add padding-bottom to the LI or margin-top to an element inside the LI.
3. If you set the UL & LI to "padding:0;" and "margin:0;" and set "list-style-position:inside;" with a nested LI that is set to "list-style-position:none", IE does not correctly align the first line within the nested LI.
The first line within the nested LI gets indented to the same position it's parent LI, while every subsequent line is flush to the left. Again, clearly a bug... Again, FireFox handles this fine making both lines flush left. The solution? Add a break tag before the text... the downside is, this leaves vertical space between "item:" and your first line of text in BOTH browsers. Another solution is to use an empty div tag with it's height set to 0. This will fix indention problem in IE, still giving a horizontal space (because of a separate but related bug that causes the div to live below the indented first line) but still allowing FF to render correctly. Man what a pain! Thankfully, I was able to "overcome" this issue by making the background image of the header for the bulleted LI taller and just using a the blank div tag fix... This unfortunately won't work for everyone...
I know there were a couple others I had to deal with, but I am way too tired after spending the last 5 hours trying to make this work...
So you ask yourself why even use these pesky unordered lists if IE is so incompatible? I am asking myself that right now... HA! No, but really, the reasons are two fold. First, it gives the content semantically correct placement on the page, which is important for things like search engines and screen readers. Secondly, it is to create an accordion style menu that can expand and collapse showing additional navigational options.
I keep hoping and praying that one day, Microsoft will figure out how much pain and suffering they have been putting web developers though and start working as a standards compliant browser. There's always hope for IE8... of course that's what everyone was saying about IE7...
- something
- something else
- another something
list-style-type
list-style-image
list-style-position
So why does it have to be so hard for Internet Explorer to render these little buggers correctly? If you can answer that question, Fly to Seattle and let MS know... maybe they'll make you a millionaire...
Okay... enough of the bashing and onto the issue at hand.
1. IE does not correctly handle margin/padding with image bullets... lets say you want there to be a 10px top margin so that your bullets are not stacked right on top of each other, FireFox does just fine... IE moves the text but forgets to line up the bullet... the solution? Take your bullet image and add some transparent canvas to the top... luckily, FF will still line the image up for you.
2. IE does not like if you specify a height on an LI where you are using "list-style-position:inside;". For whatever untold reason, IE decides to make it "list-style-position:outside;" instead. This is clearly a bug. FF also handles this correctly... the solution? either add padding-bottom to the LI or margin-top to an element inside the LI.
3. If you set the UL & LI to "padding:0;" and "margin:0;" and set "list-style-position:inside;" with a nested LI that is set to "list-style-position:none", IE does not correctly align the first line within the nested LI.
The first line within the nested LI gets indented to the same position it's parent LI, while every subsequent line is flush to the left. Again, clearly a bug... Again, FireFox handles this fine making both lines flush left. The solution? Add a break tag before the text... the downside is, this leaves vertical space between "item:" and your first line of text in BOTH browsers. Another solution is to use an empty div tag with it's height set to 0. This will fix indention problem in IE, still giving a horizontal space (because of a separate but related bug that causes the div to live below the indented first line) but still allowing FF to render correctly. Man what a pain! Thankfully, I was able to "overcome" this issue by making the background image of the header for the bulleted LI taller and just using a the blank div tag fix... This unfortunately won't work for everyone...
I know there were a couple others I had to deal with, but I am way too tired after spending the last 5 hours trying to make this work...
So you ask yourself why even use these pesky unordered lists if IE is so incompatible? I am asking myself that right now... HA! No, but really, the reasons are two fold. First, it gives the content semantically correct placement on the page, which is important for things like search engines and screen readers. Secondly, it is to create an accordion style menu that can expand and collapse showing additional navigational options.
I keep hoping and praying that one day, Microsoft will figure out how much pain and suffering they have been putting web developers though and start working as a standards compliant browser. There's always hope for IE8... of course that's what everyone was saying about IE7...
Friday, June 20, 2008
IE and another JS blunder...
So I report with great disdain, yet another problem with IE and cross browser compatibility. IE does not (by design) support the .innerHTML property correctly for elements like TABLE, THEAD, TFOOT, TR, and TBODY (even though it's not listed there). They decided for some unknown reason to be different on this topic than EVERY OTHER browser on the market.
Now, I will say, as a matter of practice, I resist the use of innerHTML as much as possible, using the DOM's document.createElement instead. I have, however, run into a case where this is not only impractical, it is not possible due to the very dynamic nature of the project I am working on.
So I built my project using FireFox (as usual) then crossed my fingers and launched it in IE to test compatibility. I was greeted with an ever-so-informative "Unknown runtime error". Even running they handy script debugger didn't give me any more information as to why .innerHTML would cause this sort of thing.
After much searching and much testing, I was forced to just destroy the table and use innerHTML on the parent DIV to recreate it.
What a pane... it's no wonder my boss made the early decision to only support FireFox for the administrative side of our software... too bad we can't do the same with the public side.
Now, I will say, as a matter of practice, I resist the use of innerHTML as much as possible, using the DOM's document.createElement instead. I have, however, run into a case where this is not only impractical, it is not possible due to the very dynamic nature of the project I am working on.
So I built my project using FireFox (as usual) then crossed my fingers and launched it in IE to test compatibility. I was greeted with an ever-so-informative "Unknown runtime error". Even running they handy script debugger didn't give me any more information as to why .innerHTML would cause this sort of thing.
After much searching and much testing, I was forced to just destroy the table and use innerHTML on the parent DIV to recreate it.
What a pane... it's no wonder my boss made the early decision to only support FireFox for the administrative side of our software... too bad we can't do the same with the public side
Tuesday, June 10, 2008
The glorious "Adjacent Sibling Selectors"
Ahh, how I love CSS... It truly makes life wonderful! Today I found what I consider to be one of the more elegant of CSS selectors... the "Adjacent Sibling Selectors".
Basically, using the syntax: "E1 + E2{ }", tells the browser to match for the element E1 and E2 within the same parent, directly following each other. It then only applies that style to E2.
For example:
<style>
b + i {font-weight:bold;}
</style>
<span>The <b>Quick</b> <i>Brown</i> <i>Fox</i>
Would render like:
The Quick Brown Fox
instead of:
The Quick Brown Fox
Notice how "Brown" is bold and italicized and "Fox" is only italicized... this is because "Brown" is the child to <i> that is a direct sibling of Quick's <b> while "Fox" is a child to <i> which is a direct sibling to Brown's <i>.
Why would you ever want to do this? Anytime you want an element to act differently only when preceded by a specific element.
For instance, if you have a H1 (Header 1) followed by an H2 (header 2), you might want the H2 to be vertically closer to the H1 than it would be anywhere else on the page. You can accomplish this by simply adding H1 + H2 {margin-top: -5px} to the style sheet.
For more information, check out the W3 specification.
Basically, using the syntax: "E1 + E2{ }", tells the browser to match for the element E1 and E2 within the same parent, directly following each other. It then only applies that style to E2.
For example:
<style>
b + i {font-weight:bold;}
</style>
<span>The <b>Quick</b> <i>Brown</i> <i>Fox</i>
Would render like:
The Quick Brown Fox
instead of:
The Quick Brown Fox
Notice how "Brown" is bold and italicized and "Fox" is only italicized... this is because "Brown" is the child to <i> that is a direct sibling of Quick's <b> while "Fox" is a child to <i> which is a direct sibling to Brown's <i>.
Why would you ever want to do this? Anytime you want an element to act differently only when preceded by a specific element.
For instance, if you have a H1 (Header 1) followed by an H2 (header 2), you might want the H2 to be vertically closer to the H1 than it would be anywhere else on the page. You can accomplish this by simply adding H1 + H2 {margin-top: -5px} to the style sheet.
For more information, check out the W3 specification.
Wednesday, March 5, 2008
Upper limits of the query string...
So I ran into a problem recently where information was not correctly being passed from one remote page to another... It took quite a bit of digging to finally find the root of this issue. It turns out, that in addition to having to deal with issues with cross-browser compatibility regarding JavaScript, we also have to deal with it regarding the querystring!
Now I know what you are thinking... who in their right mind passes so much information in the querystring that it would reach the upper limits??? I agree with you, but it is currently out of my hands.
Building "widgets" and "plugins" for commercial sites that expect to be able to "remote authenticate" can be quite tricky... especially if they are built on 4th party CMS's that decided to build their own proprietary server side scripting language (that remotely resembles classic asp)...
Okay, long story short, I am passing variables to the remote authenticator via POST variables... that software is then authenticating the users and moving all of those POST variables to the querystring as GET variables to return the user back to the clients CMS where we then process their data... I know, I know, it's an incredibly complex mess, but until the CMS is able to provide us with methods to read and write cookies, we are stuck with it.
So, it turns out that although this specific case works fine with FireFox and even Safari, it breaks in Internet Explorer (what a surprise =). Because of this I did some testing... and here are the results:
Now I know what you are thinking... who in their right mind passes so much information in the querystring that it would reach the upper limits??? I agree with you, but it is currently out of my hands.
Building "widgets" and "plugins" for commercial sites that expect to be able to "remote authenticate" can be quite tricky... especially if they are built on 4th party CMS's that decided to build their own proprietary server side scripting language (that remotely resembles classic asp)...
Okay, long story short, I am passing variables to the remote authenticator via POST variables... that software is then authenticating the users and moving all of those POST variables to the querystring as GET variables to return the user back to the clients CMS where we then process their data... I know, I know, it's an incredibly complex mess, but until the CMS is able to provide us with methods to read and write cookies, we are stuck with it.
So, it turns out that although this specific case works fine with FireFox and even Safari, it breaks in Internet Explorer (what a surprise =). Because of this I did some testing... and here are the results:
Browser version querystring upper limit
FireFox 2.0.0.5 8182
Safari 2.0 8184
IE 7.0 2047
Monday, February 4, 2008
YUI and Bookmarklets
I am a big fan of YUI (Yahoo User Interface) as it truly simplifies the cross browser implementation of JavaScript. In some ways it can be bulky, in some ways it's easier to implement my own light-weight controls... In other ways it has revolutionized the way I program JavaScript. Recently I came across one man's idea of implementing YUI everywhere you go. The idea is simple, add a simple script as a bookmarklet and you can utilize the power of YUI on anyones website!
The code is simple:
(function(){
var s = document.createElement('script');
s.src='http://yui.yahooapis.com/2.2.2/build/utilities/utilities.js';
document.getElementsByTagName('head')[0].appendChild(s);
})()
Once the script is run you can run additional scripts like:
var all = document.getElementsByTagName('*');for(var i = 0; i < all.length; i++) {new YAHOO.util.DD(all[i])}
Which will make all elements dragable, allowing you to mess with web pages in some pretty unique ways!
It is stuff like this that really makes being a web designer exciting!
The code is simple:
(function(){
var s = document.createElement('script');
s.src='http://yui.yahooapis.com/2.2.2/build/utilities/utilities.js';
document.getElementsByTagName('head')[0].appendChild(s);
})()
Once the script is run you can run additional scripts like:
var all = document.getElementsByTagName('*');for(var i = 0; i < all.length; i++) {new YAHOO.util.DD(all[i])}
Which will make all elements dragable, allowing you to mess with web pages in some pretty unique ways!
It is stuff like this that really makes being a web designer exciting!
Friday, January 25, 2008
setTimeout / setInterval and object scope
I have found over time, the need for setTimeout/setInterval is pretty rare... however, when the need does arrive, it is an invaluable tool!
The problem that I have consistently run into as of late (now that I am writing primarily object based JavaScript) is that when you use these functions, you loose the scope of your object. (i.e. if you call setTimeout(this.myFunc,900); this no longer refers to your object, but rather window, causing your script to fail). In search of a solution, I found an interesting article by Kelvo.
Klevo points out that in FireFox, setTimeout allows you to pass an additional parameter stating the implied scope. So by simply changing our command to: setTimeout(function(that) { that.methodToCall(); }, time, this); fixes the issues with scope... We basic create a proxy function that accepts an object as it's only paramater and gives us access to of that functions methods! This is a beautiful solution, if all you are developing for is FireFox.
From there, I found Alex's article who gives a simple yet elegant workaround for IE as well.
Check it out, it's absolutely worth a read for anyone who has run into trouble with setTimeout and JavaScript objects.
The problem that I have consistently run into as of late (now that I am writing primarily object based JavaScript) is that when you use these functions, you loose the scope of your object. (i.e. if you call setTimeout(this.myFunc,900); this no longer refers to your object, but rather window, causing your script to fail). In search of a solution, I found an interesting article by Kelvo.
Klevo points out that in FireFox, setTimeout allows you to pass an additional parameter stating the implied scope. So by simply changing our command to: setTimeout(function(that) { that.methodToCall(); }, time, this); fixes the issues with scope... We basic create a proxy function that accepts an object as it's only paramater and gives us access to of that functions methods! This is a beautiful solution, if all you are developing for is FireFox.
From there, I found Alex's article who gives a simple yet elegant workaround for IE as well.
Check it out, it's absolutely worth a read for anyone who has run into trouble with setTimeout and JavaScript objects.
Tuesday, January 8, 2008
Safari for Windows????
How ridiculous I thought... Safari for windows? Who in their right mind would even consider that???? Most Mac users don't even like Safari!!! But, I figured as a matter of standards I better try it... cause I'm gonna have to start supporting it... Here's the thing... I actually think they have done an excellent job! This is not the Safari that I am used to... it's clean, responsive (maybe even more responsive than FireFox...), AND... it even passes the elusive Acid 2 test!... well, almost... Who knew!?! Now, it's only in beta for windows at this point, but even at that I am starting to like it... So far every site I have visited has seemed much more responsive and every site I have built and tuned for FireFox has worked without a hitch! The jury is still out on this one for me, but I am happy to welcome this new contender to the ever growing browser battle! (that statement may come back to bite me some day ....)
Subscribe to:
Posts (Atom)