Monday, April 16, 2012
Web Browser Control rendering mode
Tuesday, May 27, 2008
SOP - Same origin policy
The term "origin" is defined using the domain name, protocol and port. Two pages belong to the same origin if and only if these three values are the same.
Tuesday, October 09, 2007
Thursday, August 16, 2007
7-es elotti IE-nel problemat okozhat a HEAD-hez uj elem hozzaadasa, ha van mar beolvasott BASE tag
Ran into a JavaScript problem with everybody’s favorite browser recently. Manipulating the head element from within (say by adding additional script or link elements before the page loads) was resulting in an enormously helpful “Operation Aborted” error message in versions of Internet Explorer prior to 7. Of course, like all things IE, this error’s appearance was inconsistent.
I was eventually able to track the problem down to the presence of a base tag. It didn’t matter if it was an open <base> or a self-closing <base />, if it came before the <script> that was manipulating the head, then IE stopped everything and issued the error. (At this point in script execution document.getElementsByTagName('head')[0] is a valid HTML element so testing for its availability before attempting to appendChild() doesn’t avoid the error. try/catch() is also of no assistance.)…
Sunday, August 05, 2007
Henri Sivonen: Activating the Right Layout Mode Using the Doctype Declaration
In order to deal with both old tag soup written to old browser quirks and new CSS-compliant pages, Firefox (and other Mozilla Gecko-based browsers), Safari, Opera (7 and later), Internet Explorer 6 and 7, Mac IE 5, and Konqueror (3.2 and later) have two main layout modes. In one mode the layout engine attempts to render conforming pages according the CSS specifications. In the other mode the layout engine tries to mimic old browsers. In Firefox these modes are known as “the Standards mode” and “the Quirks mode” respectively. In this document the same names are used also when referring to the modes of the other browsers.
Background
The bugs and non-standard behaviors of old browsers such as Netscape Navigator 4.x and IE 5 for Windows are called “quirks”. For example, not inheriting styles into tables is a quirk. Sometimes pages have been authored in such a way that their layout depends on quirks.
Most quirks are related to layout and, hence, are in conflict with CSS. Rendering quirky pages according to CSS would make them look different from what the author most likely intended. On the other hand, being able to use CSS as specified is a big win compared to writing for old quirks forever.
Layout Modes
To address the conflicting goals of backwards compatibility and CSS conformance, contemporary browsers have two or three layout modes.
Quirks Mode
In the Quirks mode the browsers violate CSS specifications in order to achieve backwards compatible layout. Different browsers implement different quirks. Therefore, “Quirks mode” is not a single target. For example, Mozilla focused on imitating Netscape 4.x initially. Windows IE 6 and 7, on the other hand, are focused on imitating Windows IE 5.
The point of the Quirks mode is avoiding “breaking” old pages. If you are authoring new pages now, you are supposed to comply with the relevant specifications (CSS 2.1 in particular) and target the Standards mode.
Standards Mode
In the Standards mode the browsers try to give conforming documents the specification-wise correct treatment to the extent implemented in a particular browser.
Almost Standards Mode
Firefox, Safari and Opera 7.5 (and later) also have a third mode known as “the Almost Standards mode”, which implements the vertical sizing of table cells traditionally and not rigorously according to the CSS2 specification. Mac IE 5, Windows IE 6 and 7, Opera prior to 7.5 and Konqueror do not need an Almost Standards mode, because they don’t implement the vertical sizing of table cells rigorously according to the CSS2 specification in their respective Standards modes anyway. In fact, their Standards modes are closer to Mozilla’s Almost Standards mode than to Mozilla’s Standards mode. It is important to remember that even though the various browsers have conceptually similar modes, the corresponding modes of the different browsers are not identical.
…
Firefox, Safari, Opera (7 and later), Windows IE 6 and 7, Mac IE 5 and Konqueror (3.2 and later) all use doctype sniffing in order to decide the layout mode for text/html documents. This means that the mode is picked based on the document type declaration (or the lack thereof) at the beginning of an HTML document. (Documents served using an XML content type always get the Standards mode.)
Szinten itt talalhato egy tablazat is arrol, hogy melyik browser melyik doctype-ot hogyan rendereli.
++++
Anne van Kesteren pedig keszitett egy tablazatot arrol, hogy a browserek hogyan impelementaljak a clientHeight, offsetHeight es scrollHeight-ot a body es html tagen quirks es standards mode-ban.
Friday, July 27, 2007
tag soup
Thursday, July 26, 2007
Tenni Theurer: Maximizing Parallel Downloads in the Carpool Lane
Az IE-nel a registy manipulalasaval:
- Start Registry Editor (Regedt32.exe).
- Locate the following key in the registry:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings - On the Edit menu, point to New click DWORD Value, and then add the following registry values:
Value name: MaxConnectionsPer1_0Server
Value data: 10
Base: DecimalValue Name: MaxConnectionsPerServer
Value data: 10
Base: Decimal - Quit Registry Editor.
Firefoxban pedig az about:config oldalon a
network.http.max-persistent-connections-per-server atallitasaval.
Kimertek, hogy mennyit huz a sebessegen, ha tobb hostname aliast hasznalnak amivel arra szorithatjak a browsert, hogy egyszerre tobb elemet toltson le, de az jott ki, hogy 2 aliasnal tobbet nem erdemes hasznalni, mert csak meglassabb lehet az egesz, de gyorsitani biztos nem fog.
Ryan Bran merese szerint viszont siman megeri 3 kulonbozo subdomaint hasznalni.
Friday, July 06, 2007
Honnan tudjuk, hogy az utolag include-olt javascript mar betoltodott. [2]
function loadScript(src, callback) {
var node = document.createElement("script");
if (node.addEventListener)
node.addEventListener("load", callback, false);
else
node.onreadystatechange = function() {
if (this.readyState == "complete") callback.call(this);
}
node.src = src;
document.getElementsByTagName("head").item(0).appendChild(node);
node = null;
}
// load 30k script.
// Listener.cleanUp is defined at the bottom of drag.js
callback = function() {
var self = this;
alert("Loaded: " + this.src + "\nListener.cleanUp (nested):" + Listener.cleanUp);
};
loadScript("http://dhtmlkitchen.com/editor/js/drag.js", callback);
[Update]
Ahogy Jan Volter is emliti jobb vigyazni ezzel a readyState propertyvel es onreadystatechange eventtel, mert:
The “this.readyState == ‘complete’” test doesn’t actually entirely work. The readyState theoretically goes through a series of states:
0 uninitialized 1 loading 2 loaded 3 interactive 4 complete
But in fact, states may be skipped. In my experience with IE 7, you get either a loaded event or a completed event, but not both. It may have something to do with whether you are loading from cache or not but there seem to be other factors that influence which events you get. Sometimes I get loading or interactive events too, and sometimes I don’t. It’s possible the test should be “this.readyState == ‘loaded’ || this.readyState == ‘complete’“, but that risks triggering twice.
Honnan tudjuk, hogy az utolag include-olt javascript mar betoltodott.
Stoyan (mar torolt) irasa szerint egy 1998-as MSDN cikkben talalkozott a readyState property-vel es azt hasznalva ez a kodreszlet IE-ben (csak ott!!) mukodik:
The idea is that after a new DOM element (a script tag) is created, you can have access to the readyState property of the element. If it says “complete”, then the new script is included and it’s OK to call functions from it. If you want to “listen” when the script download will be completed, you can attach an listener to the onreadystatechange event, just like with XMLHttpRequests.
Here’s an example:
var js;
function include_js(file) {
var html_doc = document.getElementsByTagName('head').item(0);
js = document.createElement('script');
js.setAttribute('type', 'text/javascript');
js.setAttribute('src', file);
html_doc.appendChild(js);
// alert state change
js.onreadystatechange = function () {
alert(js.readyState);
if (js.readyState == 'complete') {
// safe to call a function
// found in the new script
imready();
}
}
return false;
}
A commentek kozott Aaron Bassett egy masik megoldast javasolt, amihez modositani kell egy kicsit a betoltendo scripten (mar ha ez lehetseges), de szerinte minden browserben mukodik (bar nem probalta):
This untested but I dont see any reason why it wouldnt work, and should work across all browsers.
Right at the end of the external js file set a variable like:
var externalScriptLoaded = true;
Then in your main code you could use:
function checkScriptLoaded() {
if(!externalScriptLoaded) {
setTimout("checkScriptLoaded", 500);
} else {
// script loaded and ready to use
}
}
If you have multiple external files you want to check just make sure each has a unique variable name being set and check them accordingly.
This polling every half-second isnt perfect but it will work.
Your other option would be to create a function/method in your main script which inits the actions to perform when the external script is loaded.
Then as the very last thing in your external script you could just call that function/method
externalScripts.myScriptLoaded();
As this call would be at the end of your file it wont be run until the rest of the file ahead of it has been downloaded.
Once again this method is untested but am 99% sure will work and will be cross browser.
Saturday, June 30, 2007
Nicholas C. Zakas: dynamically inserting CSS into your page
Safari requires dynamically created <style/> elements to be inserted into the for the rules to be applied
…
When IE encounters style.appendChild() it throws the rather obtuse and not-very-helpful error message, “unexpected call to method or property access”. Try replacing that with a call to set innerHTML, and you’ll get an equally useless error message of “unknown runtime error”. What’s going on here? It turns out that IE won’t let you manipulate <style/> elements in this way. There is, however, a different way to do the same thing. IE supports a styleSheet property on each style element that allows for the manipulation of the style sheet and the rules contained within. The styleSheet property has a property called cssText, which can be used to set and retrieve the CSS text for the style sheet.
…
This code now works in all A-grade browsers:
function addCss(cssCode) {
var styleElement = document.createElement(”style”);
styleElement.type = “text/css”;
if (styleElement.styleSheet) {
styleElement.styleSheet.cssText = cssCode;
} else {
styleElement.appendChild(document.createTextNode(cssCode));
}
document.getElementsByTagName(”head”)[0].appendChild(styleElement);
} A warning: IE only allows writing to styleSheet.cssText one time per <style> element. If you try to do it more than one time, it can crash the browser. For this reason, it’s best not to reuse <style> elements on your page. Instead, remove them or just add new ones.
…
A commentek kozul:
According to the HTML 4.01 spec section 14.2.3, style tags must be contained in the head element: “HTML permits any number of STYLE elements in the HEAD section of a document.”
Link to the spec:
http://www.w3.org/TR/html401/present/styles.html#edef-STYLE
browser csoportositas a YUI-nel
C-grade
C-grade is the base level of support, providing core content and functionality. It is sometimes called core support. Delivered via nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.
C-grade browsers are identified on a blacklist. Approximately 3% of our audience receives a C-grade experience.
Summary: C-grade browsers are identified, incapable, antiquated and rare. QA tests a sampling of C-grade browsers, and bugs are addressed with high priority.
A-grade
A-grade support is the highest support level. By taking full advantage of the powerful capabilities of modern web standards, the A-grade experience provides advanced functionality and visual fidelity.
A-grade browsers are identified on a whitelist. Approximately 96% of our audience enjoys an A-grade experience.
Summary: A-grade browsers are identified, capable, modern and common. QA tests all A-grade browsers, and bugs are addressed with high priority.
X-grade
X-grade provides support for unknown, fringe or rare browsers. Browsers receiving X-grade support are assumed to be capable. (If a browser is shown to be incapable — if it chokes on modern methodologies and its user would be better served without decoration or functionality — then it is considered a C-grade browser.)
X-grade browsers include all browsers not on the C-grade blacklist or the A-grade whitelist. Approximately 1% of our audience receives the X-grade experience.
Summary: X-grade browsers are generally unknown, assumed to be capable, modern, and rare or fringe. QA does not test, and bugs are not opened against X-grade browsers.
The Relationship Between A- and X-grade Support
A bit more on the relationship between A and X grade browsers: One unexpected instance of X-grade is a newly-released version of an A-grade browser. Since thorough QA testing is an A-grade requirement, a brand-new (and therefore untested) browser does not qualify as an A-grade browser. This example highlights a strength of the Graded Browser Support approach. The only practical difference between A and X-grade browsers is that QA actively tests against A-grade browsers.
Unlike the C-grade, which receives only HTML, X-grade receives everything that A-grade does. Though a brand-new browser might be characterized initially as a X-grade browser, we give its users every chance to have the same experience as A-grade browsers.