Plugins
Just type in about:plugins in the addressbar and press enter.
Cache
Just type in about:cache in the addressbar and press enter.
Advanced Configuration Settings
Just type in about:config in the addressbar and press enter.
Friday, 29 October 2010
Tuesday, 26 October 2010
Javascript proxy generator uses full URL in set_path in .NET 4
The javascript proxy generator for WCF services used to send just the path as the argument to set_path in .NET 3.5, such as:
service.set_path("/service.svc");
You can see a line of code similar to this if you go through the proxy javascript code.
In .NET 4, this has changed to the full request absolute url:
service.set_path("http://host/service.svc");
I have noticed this change recently when we had an issue with this in IE8. I was getting "Access Denied" exception when the site is requested via HTTPS and the service method is called on click of a button in the page. After spending some time to debug the JavaScript using IE8s built-in developer tool I found the reason for the error is this particular line of code.
Th work around is if you have control over calling the service through the proxy, call set_path on the proxy with the correct path before making the service call as below.
Service.set_path("/ProxyService.svc");
Service.CallMethod(arg, CallBackResult, CallBackError, context);
Read more >>
Read more >>
service.set_path("/service.svc");
You can see a line of code similar to this if you go through the proxy javascript code.
In .NET 4, this has changed to the full request absolute url:
service.set_path("http://host/service.svc");
I have noticed this change recently when we had an issue with this in IE8. I was getting "Access Denied" exception when the site is requested via HTTPS and the service method is called on click of a button in the page. After spending some time to debug the JavaScript using IE8s built-in developer tool I found the reason for the error is this particular line of code.
Th work around is if you have control over calling the service through the proxy, call set_path on the proxy with the correct path before making the service call as below.
Service.set_path("/ProxyService.svc");
Service.CallMethod(arg, CallBackResult, CallBackError, context);
Read more >>
Read more >>
Monday, 25 October 2010
CSS Hacks
Dealing with browser inconsistencies often makes up a majority of the work for a web designer. Sometimes there is no reasonable way to accomplish a desired layout in all major web browsers without the use of some special exception rules for certain layout engines. Hacks necessarily lead to potential complications and should be avoided whenever possible, but when the circumstances require hacks to be used, it's best to know what your options are and weigh the consequences appropriately.
Some bugs are better than others. In this case, CSS parsing bugs can help us target specific versions of IE using a specially crafted selector:
* for IE7, prepend any rule with *+html,
* for IE6, prepend any rule with * html.
An example of a stylesheet containing rules for IE7 and IE6 compatibility:
1. div.highlight {
2. background: red;
3. float: left;
4. margin-right: 10px;
5. outline: 1px solid blue;
6. }
7.
8. /* IE7 doesn't support outline, use border instead */
9. *+html div.highlight {
10. border: 1px solid blue;
11. margin: -1px;
12. margin-right: 9px;
13. }
14.
15. /* IE6 needs to fix doubled margin bug */
16. * html div.highlight {
17. display: inline;
18. }
So far, there has been no CSS parsing bugs identified that would help us target IE8 using a selector only. What we can do, however, is use declaration parsing bugs to target specific versions:
* to target IE8 in standards mode, use /*\**/ before the colon and apply the \9 suffix to the value declaration,
* to target IE8 and below, use \9 before terminating a CSS value declaration,
* to target IE7 and below, use the * prefix before a CSS property declaration,
* to target IE6, use the _ (underscore) prefix before a CSS property declatarion
To illustrate, let's apply a few of these rules just for fun:
1. .myClass {
2. color: black; /* normal CSS declaration */
3. color /*\**/: red\9; /* IE8 standards mode */
4. color: green\9; /* IE8 and below */
5. *color: blue; /* IE7 and below */
6. _color: purple; /* IE6 */
7. }
Using CSS hacks enables us to apply fixes without the need for conditional comments, but at a cost – hacks usually don't validate, are hard to understand without additional comments and can be confusing for IDEs, depending on their validation and syntax highlighting implementations.
Given the choice between CSS hacks and conditional comments, I always pick the latter as my go-to method when dealing with browser version targeting. It has served me and my clients well in the past and continue to make my code more standards-oriented, readable and future proof – who knows when or if these hacks will start interfering with newer or other vendors' browser parsers. Granted, if all you need is to fix a declaration or two, you can still use this in your existing style sheets, but as soon as that number grows beyond, say, a half a dozen, you should consider creating a separate style sheet.
So what's the best way to address browser inconsistencies? Well, from my experience, I've decided on a strategy that seems to work best: let the oldest browser carry the burden of compatibility.
Remember, you are building websites that, ideally, should not need periodic check-ups and redevelopment (save for the obligatory redesigns, of course). So why should the browsers of tomorrow carry the burden of the browsers of yesteryear?
The way I've tackled this problem is including the following <head> structure:
1. <link rel="stylesheet" href="bridging.css"/>
2. <!--[if lte IE 8]>
3. <link rel="stylesheet" href="ie8.css"/>
4. <![endif]-->
5. <!--[if lte IE 7]>
6. <link rel="stylesheet" href="ie7.css"/>
7. <![endif]-->
8. <!--[if lte IE 6]>
9. <link rel="stylesheet" href="ie6.css"/>
10. <![endif]-->
In this case, IE6 will load all four style sheets (including additional @imports), and each subsequent version of IE will load one less. The beauty of this is that all CSS bugs are dealt with in a backwardly fashion, meaning rules need not be overridden for posterity. And when support for a specific version is dropped, so can the conditional comment, reducing the CSS code needed to maintain the website.
Click here for more information.
http://www.webdevout.net/css-hacks
1. Conditional comments
2. In-CSS hacks
3. Unrecommended hacks
4. Third party translations
Using Bugs to Your Advantage
Some bugs are better than others. In this case, CSS parsing bugs can help us target specific versions of IE using a specially crafted selector:
* for IE7, prepend any rule with *+html,
* for IE6, prepend any rule with * html.
An example of a stylesheet containing rules for IE7 and IE6 compatibility:
1. div.highlight {
2. background: red;
3. float: left;
4. margin-right: 10px;
5. outline: 1px solid blue;
6. }
7.
8. /* IE7 doesn't support outline, use border instead */
9. *+html div.highlight {
10. border: 1px solid blue;
11. margin: -1px;
12. margin-right: 9px;
13. }
14.
15. /* IE6 needs to fix doubled margin bug */
16. * html div.highlight {
17. display: inline;
18. }
So far, there has been no CSS parsing bugs identified that would help us target IE8 using a selector only. What we can do, however, is use declaration parsing bugs to target specific versions:
* to target IE8 in standards mode, use /*\**/ before the colon and apply the \9 suffix to the value declaration,
* to target IE8 and below, use \9 before terminating a CSS value declaration,
* to target IE7 and below, use the * prefix before a CSS property declaration,
* to target IE6, use the _ (underscore) prefix before a CSS property declatarion
To illustrate, let's apply a few of these rules just for fun:
1. .myClass {
2. color: black; /* normal CSS declaration */
3. color /*\**/: red\9; /* IE8 standards mode */
4. color: green\9; /* IE8 and below */
5. *color: blue; /* IE7 and below */
6. _color: purple; /* IE6 */
7. }
Using CSS hacks enables us to apply fixes without the need for conditional comments, but at a cost – hacks usually don't validate, are hard to understand without additional comments and can be confusing for IDEs, depending on their validation and syntax highlighting implementations.
Given the choice between CSS hacks and conditional comments, I always pick the latter as my go-to method when dealing with browser version targeting. It has served me and my clients well in the past and continue to make my code more standards-oriented, readable and future proof – who knows when or if these hacks will start interfering with newer or other vendors' browser parsers. Granted, if all you need is to fix a declaration or two, you can still use this in your existing style sheets, but as soon as that number grows beyond, say, a half a dozen, you should consider creating a separate style sheet.
Hacks vs. conditional comments
So what's the best way to address browser inconsistencies? Well, from my experience, I've decided on a strategy that seems to work best: let the oldest browser carry the burden of compatibility.
Remember, you are building websites that, ideally, should not need periodic check-ups and redevelopment (save for the obligatory redesigns, of course). So why should the browsers of tomorrow carry the burden of the browsers of yesteryear?
The way I've tackled this problem is including the following <head> structure:
1. <link rel="stylesheet" href="bridging.css"/>
2. <!--[if lte IE 8]>
3. <link rel="stylesheet" href="ie8.css"/>
4. <![endif]-->
5. <!--[if lte IE 7]>
6. <link rel="stylesheet" href="ie7.css"/>
7. <![endif]-->
8. <!--[if lte IE 6]>
9. <link rel="stylesheet" href="ie6.css"/>
10. <![endif]-->
In this case, IE6 will load all four style sheets (including additional @imports), and each subsequent version of IE will load one less. The beauty of this is that all CSS bugs are dealt with in a backwardly fashion, meaning rules need not be overridden for posterity. And when support for a specific version is dropped, so can the conditional comment, reducing the CSS code needed to maintain the website.
Click here for more information.
http://www.webdevout.net/css-hacks
1. Conditional comments
2. In-CSS hacks
1. Easy selectors
2. Minimized attribute selectors
3. !important
4. @import "non-ie.css" all;
5. body[class|="page-body"]
3. Unrecommended hacks
1. _property: value and -property: value
2. *property: value
3. body:empty
4. a:link:visited, a:visited:link
5. >body
6. html*
7. !ie
8. !important!
4. Third party translations
Wednesday, 13 October 2010
URL Encoding
Some characters cannot be part of a URL (for example, the space) and some other characters have a special meaning in a URL: for example, the character # can be used to specify a subsection (or fragment) of a document; the character = is used to separate a name from a value. A query string may need to be converted (that is what URL Encoding is) to satisfy these constraints.
In particular, encoding the query string uses the following rules:
* Letters (A-Z and a-z), numbers (0-9) and the characters '.','-','~' and '_' are left as-is
* SPACE is encoded as '+'
* All other characters are encoded as %FF hex representation with any non-ASCII characters first encoded as UTF-8 (or other specified encoding)
The octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by"~" without changing its interpretation.
The encoding of SPACE as '+' and the selection of "as-is" characters distinguishes this encoding from RFC 1738.
Technically, the form content is only encoded as a query string when the form submission method is GET. The same encoding is used by default when the submission method is POST, but the result is not sent as a query string, that is, is not added to the action URL of the form. Rather, the string is sent as the body of the request.
http://en.wikipedia.org/wiki/Query_string
http://en.wikipedia.org/wiki/URL_encoding
There are two built-in methods in ASP.NET which can be used to encode a string or URL. They are Server.URLEncode()and Server.URLPathEncode().
Server.URLPathEncode method
URL-encodes the path portion of a URL string and returns the encoded string. It will leave the querystring, if present, as it is.
The Server.URLEncode method
The URLEncode method applies URL encoding rules, including escape characters, to a specified string.
URLEncode converts characters as follows:
* Spaces ( ) are converted to plus signs (+).
* Non-alphanumeric characters are escaped to their hexadecimal representation.
In particular, encoding the query string uses the following rules:
* Letters (A-Z and a-z), numbers (0-9) and the characters '.','-','~' and '_' are left as-is
* SPACE is encoded as '+'
* All other characters are encoded as %FF hex representation with any non-ASCII characters first encoded as UTF-8 (or other specified encoding)
The octet corresponding to the tilde ("~") character is often encoded as "%7E" by older URI processing implementations; the "%7E" can be replaced by"~" without changing its interpretation.
The encoding of SPACE as '+' and the selection of "as-is" characters distinguishes this encoding from RFC 1738.
Technically, the form content is only encoded as a query string when the form submission method is GET. The same encoding is used by default when the submission method is POST, but the result is not sent as a query string, that is, is not added to the action URL of the form. Rather, the string is sent as the body of the request.
http://en.wikipedia.org/wiki/Query_string
http://en.wikipedia.org/wiki/URL_encoding
There are two built-in methods in ASP.NET which can be used to encode a string or URL. They are Server.URLEncode()and Server.URLPathEncode().
Server.URLPathEncode method
URL-encodes the path portion of a URL string and returns the encoded string. It will leave the querystring, if present, as it is.
The Server.URLEncode method
The URLEncode method applies URL encoding rules, including escape characters, to a specified string.
URLEncode converts characters as follows:
* Spaces ( ) are converted to plus signs (+).
* Non-alphanumeric characters are escaped to their hexadecimal representation.
The Default View Source Editor Has Changed in Internet Explorer 8
When you click the View Source command in Internet Explorer 8, it uses the built-in viewer, which is part of the Developer Tools in Internet Explorer 8. The built-in viewer lets you dynamically refresh the view source window, increase or decrease the text size and lists other standard options.
Changing the View Source Editor in Internet Explorer
Internet Explorer 8 includes a built-in option to change the default view source editor. The setting is provided in the Developer Tools.
1. Open Internet Explorer
2. Press the F12 button to start the Developer Tools
3. From the File menu, click Customize Internet Explorer View Source
4. Select one of the following options:
* Default Viewer
* Notepad
* Other…
Changing the View Source Editor in Internet Explorer
Internet Explorer 8 includes a built-in option to change the default view source editor. The setting is provided in the Developer Tools.
1. Open Internet Explorer
2. Press the F12 button to start the Developer Tools
3. From the File menu, click Customize Internet Explorer View Source
4. Select one of the following options:
* Default Viewer
* Notepad
* Other…
Wednesday, 6 October 2010
Sitemaps
The Sitemaps protocol allows a webmaster to inform search engines about URLs on a website that are available for crawling. A Sitemap is an XML file that lists the URLs for a site. It allows webmasters to include additional information about each URL: when it was last updated, how often it changes, and how important it is in relation to other URLs in the site. This allows search engines to crawl the site more intelligently. Sitemaps are a URL inclusion protocol and complement robots.txt, a URL exclusion protocol.
he webmaster can generate a Sitemap containing all accessible URLs on the site and submit it to search engines. Since Google, Bing, Yahoo, and Ask use the same protocol now, having a Sitemap would let the biggest search engines have the updated pages information.
Sitemaps supplement and do not replace the existing crawl-based mechanisms that search engines already use to discover URLs. Using this protocol does not guarantee that web pages will be included in search indexes, nor does it influence the way that pages are ranked in search results.
The Sitemap Protocol format consists of XML tags. The file itself must be UTF-8 encoded. Sitemaps can also be just a plain text list of URLs. They can also be compressed in .gz format.
A sample Sitemap that contains just one URL and uses all optional tags is shown below.
<?xml version='1.0' encoding='UTF-8'?>
<urlset>
<url>
<loc>http://princepthomas.blogspot.com
<lastmod>2010-10-06
<changefreq>daily
<priority>0.5
</url>
</urlset>
he webmaster can generate a Sitemap containing all accessible URLs on the site and submit it to search engines. Since Google, Bing, Yahoo, and Ask use the same protocol now, having a Sitemap would let the biggest search engines have the updated pages information.
Sitemaps supplement and do not replace the existing crawl-based mechanisms that search engines already use to discover URLs. Using this protocol does not guarantee that web pages will be included in search indexes, nor does it influence the way that pages are ranked in search results.
File format
The Sitemap Protocol format consists of XML tags. The file itself must be UTF-8 encoded. Sitemaps can also be just a plain text list of URLs. They can also be compressed in .gz format.
A sample Sitemap that contains just one URL and uses all optional tags is shown below.
<?xml version='1.0' encoding='UTF-8'?>
<urlset>
<url>
<loc>http://princepthomas.blogspot.com
<lastmod>2010-10-06
<changefreq>daily
<priority>0.5
</url>
</urlset>
Subscribe to:
Posts (Atom)