코모도 방화벽은 보안/PC관리>개인방화벽
매월 10일경엔 윈도우즈 보안업데이트하세요 !!!
웹표준 사용하기 : 브라우저/플랫폼 독립 페이지 개발
20110101 | 202
브라우저/플랫폼 독립 페이지 개발
Developing Cross Browser/Cross Platform Pages
크로스 플랫폼과 DHTML 개발을 위한 중요한 실천은 여러분의 페이지를 보는 브라우저의 능력을 결정할 수 있게 하는 것입니다. 여러분은 오류를 피해야하고, 가능한 광범위한 사용자에게 여러분이 작성한 작성문을 분명하게 전달할 수 있으면 할 것입니다.
An important practice for doing cross-platform and DHTML development is to able to determine at runtime the capabilities of the browser that are viewing your page. You need to avoid errors, and may want to ensure your script reaches as wide an audience as possible.
공통적으로 사용되는 한가지 방법은 브라우저를 알아내서, 브라우저의 능력에 맞는 수단을 제공하는 것인데, 이것은 문제가 많습니다. 해당 페이지를 방문하는 모든 현재의 브라우저의 능력을 알아야 하기도 하며, 그에 맞는 적절한 코드라는 것이 앞으로의 브라우저에 일어날 일을 안다거나 안전예방서비스(safe fallback service)를 제공하는 데 만족한다는 가정을 두고있고, 무엇보다 브라우저를 알아낼 수 있어야 한다는 것입니다.
One process, commonly used is to attempt to identify the browser, and have the user at design time decide what that means by way of the capabilityies of the browser, this is fraught with problems, it requires the user to have knowledge of the capabilities of all current browsers that may visit the page, and code appropriately for them, it requires the user to make assumptions about what will happen with future browsers, or be content with giving them a safe fallback service, and it requires users to be able to identify browsers in the first place.
이런 처리방법을 간혹 "브라우저 스니핑(browser sniffing)"라고 하는 데, 브라우저의 버전과 형식을 점검하는 ECMAScript 함수로 대개 처리되는 것이며, 필요하다면, 다른 함수를 사용하거나 다른 페이지 또는 웹페이지를 가리키도록 하는 방식입니다. (그러나 이것은 링크, 북마크, 검색엔진, 또는 "잘못된" 브라우저 캐시를 통해서 해당 페이지를 들어갈 수 있기 때문에 안전한 방법은 아닙니다.)
This process, often referred to as "browser sniffing," is usually handled by ECMAScript functions that test the version and type of the browser and, if necessary, use different functions or point the user to different pages or web content (This is very dangerous though as people may enter the page through a link, bookmark, search engine, or cache with a "wrong" browser). The following is a short list of sniffing functions for different browsers:
인터넷익스플로러 버전 감지
Internet Explorer Version Detection
appVer = navigator.appVersion;
ver = parseFloat(appVer); // 네스케이프와 다른 브라우저
iePos = appVer.indexOf('MSIE');
if (iePos != -1)
ver = parseFloat(appVer.substring(iePos+5,appVer.indexOf(';',iePos)));
브라우저 스니핑 코드
Browser Sniffing Code
이 스니핑 코드에서, navigator 객체는 버전에 대한 신호를 전달합니다. 해당 버전이 "6"이면, 브라우저는 네스케이프 6이라고 생각하게 됩니다. 그렇지 않고, 속성 부분으로 "MSIE" 문자열이 발견되면, 해당 브라우저는 IE5가 되는 것이죠.
In this sniffing code, the navigator object is interrogated for its version. If the version is "6", then the browser is understood to be Netscape 6. Otherwise, if the "MSIE" string is found as part of the property, then the browser is IE5.
if (navigator.appVersion.charAt(0) == "5")
{
if (navigator.appName == "Netscape")
{
isNav6 = true
alert('NS6')
}
}
else if (navigator.appVersion.indexOf("MSIE") != -1)
isIE = true alert('IE')
이런 식의 점검은 그런대로 작동할 수 있지만, 냉철한 독자라면 IE6.0, 오페라 또는 다른 버전의 브라우저은 어떻게 하느냐고 생각할 지 모릅니다. 새로운 브라우저가 나오게 되면, 이에 따라 코드를 업데이트해야 합니다. 이런 방법은 브라우저에 맞추어서 적절한 전환을 할 수 있게는 합니다.
While this kind of checking can work in a crude sense, sharp readers may wonder what happens with IE6.0, Opera 5.0 or other version 5 browsers. As new browsers are released, it becomes necessary to make updates to code such as this, which attempts to narrow down the client and make the appropriate switches.
이런 접근방식의 다른 문제는 브라우저의 실체가 위조될 수 있는 데, 많은 더많은 현대적인 브라우저에는 navigator.appVersion 를 사용자가 설정할 수 있는 문자열이기 때문입니다. 모질라는 "general.useragent.override"라는 환경설정을 이용하고 있고 오페라는 메뉴에서 이 문자열을 설정할 수 있으며 IE는 윈도우즈 레지스트리를 사용하고 있습니다. 즉 사용자나 브라우저 배포자는 그들이 원하는 것을 이 문자열에 입력할 수 있는 데, 이렇게 되면 작성된 코드가 엉뚱한 브라우저에 대해 실행할 수 있게 됩니다. 정확하게 인식된 브라우저조차도 원하던대로 작동하지 않는 경우 많습니다.(아래 DOM implementation를 참고하세요)
The other problem with this approach is that the browser identity can be "spoofed," because in many more modern browsers, navigator.appVersion is a user configurable string. Mozilla uses the preference "general.useragent.override"; Opera allows you to set this string in a menu, and IE uses the Windows registry. A user or browser distributor can put what they want in the string, and this may trick your code into executing for the wrong client. Moreover, there are many cases where even the accurately-identified browser does not perform as it is reputed to (see DOM implementation notes below).
객체 감지
Using Object Detection
"브라우저 스니핑"이 신뢰할 수 없으며 난제가 있다면, 다른 브라우저에 대해 안전하게 어떻게 코드를 작성해야 하는가? 한가지 대안은 "객체 감지"를 사용하는 것입니다. 객체 감지를 사용한다고 할때는, 브라우저에서 먼저 테스트한 지원기능만을 처리하는 것입니다. 이 방식은 모든 것이 아니라 작성한 코드의 기능이 브라우저에서 지원되는 지를 테스트만하면 됩니다.
So if "browser sniffing", can be unreliable and difficult, how do you code safely for different browsers? One alternative is to use "object detection." When you use object detection, you only implement those features whose support you have first tested on the client. This method has the advantage of not requiring you to test for anything except whether the particular features you code are supported on the client.
객체 감지는 아래 예제에 잘 설명되어 있습니다:
Object detection is best illustrated by an example:
if (document.getElementById &&
document.getElementById(id) &&
document.getElementById(id).style)
document.getElementById(id).style.visibility="hidden";
document.getElementById 에 대한 이런 반복된 호출은 가장 효과적인 것은 아니더라도 브라우저의 DOM implementation에 있어 특정 객체나 기능을 체크할 수 있는 것이지만, 어떻게 객체감지가 꽤 깔끔하게 처리하는 지를 보여줍니다. (더 최적화된 다음의 두가지 예제와 아래의 DOM hasFeature를 참고하세요),
These repeated calls to document.getElementById are not the most efficient may to check for the existence of particular objects or features in the browser's DOM implementation (see the next two examples for more optimized versions and see the DOM hasFeature discussion below), but they illustrate how object detection works quite clearly.
상단의 if절은 문서객체에 있는 호출된 getElementById 객체가 있는 지 찾는 것인데, 브라우저에서 DOM을 지원하는 가장 기본적인 것중 하나입니다. 만약 있다면, 해당 코드는 getElementById(id) 가 요소를 반환하는 지 보고서, style 객체를 점검합니다. style 객체가 해당 요소에 있다면, 이렇게해서 객체의 visibility 속성을 설정하는 것이죠. 사용자가 이것을 미처리 속성으로 설정했을지라도 브라우저는 오류를 일으키지않을 것이기 때문에 visibility 속성 자체가 존재하는 지 점검할 필요가 없게 됩니다.
The top-level if clause looks to see if there's an object called getElementById on the document object, which is the one of the most basic levels of support for the DOM in a browser. If there is, the code sees if getElementById(id) returns an element, which it then checks for a style object. If the style object exists on the element, then it sets that object's visibility property. The browser will not error if you set this unimplemented property, so you don't need to check that the visiblity property itself exists.
Generally object detection code like this should be placed in functions so that your code doesn't become too complicated or unmaintainable:
function hideElement(element_id)
{
if (document.getElementById &&
document.getElementById(element_id) &&
document.getElementById(element_id).style)
document.getElementById(element_id).style.visibility="hidden";
}
// 예제:
// <button "hideElement('d1');">hide div</button>
// <div id="d1">div one</div>
어느 브라우저가 DOM 방식의 getElementById 를 가지고 있는 지 알 것없이, 바로 그 방식을 테스트한 것입니다. 이 방식을 사용한다면, 미래의 배포판과 여러분이 알지못하는 브라우저의 userAgent 문자열을 포함한 모든 브라우저는 여러분이 작성한 코드를 처리할 것입니다.
Now, instead of needing to know which browsers have the DOM method getElementById, you test for that very method. Using this method, you ensure that all browsers--including future releases and browsers whose userAgent strings you don't know about--will continue working with your code.
그런데 이들 예제 어느 것도 네비게이터 4와 익스플로러 4 브라우저에는 작동하지 않는다는 사실입니다. 이들 구버전의 브라우저에서 작동하는 객체감지 코드를 작성하려면, 또다른 점검 레벨을 추가해야 하는 데, 말하자면 표준적인 document.getElementById 를 지원하지않는 브라우저에 적당한 객체 참고자료를 제공하는 것입니다. 방법은 각각의 브라우저 플랫폼에서 document.getElementById 대신에 IEGetElementById와 NN4GetLayerById 라는 두가지 함수를 호출하는 것입니다.
Note that neither of these foregoing examples works for Navigator 4 and Internet Explorer 4 browsers. To create object detection code that works on these older browsers, it's necessary to add another level of checking, where browsers that do not support the standard document.getElementById are given some means of returning the appropriate object reference. The two functions at the top of this listing, IEGetElementById and NN4GetLayerById are called in place of document.getElementById on their respective browsers platforms.
function IE4GetElementById(id)
{
return document.all[id];
}
function NN4GetLayerById(id)
{
// see xbStyle on the evangelism site
// for details on a possible implementation
}
if (document.layers)
document.getElementById = NN4GetLayerById;
else if (document.all && !document.getElementById)
document.getElementById = IE4GetElementById;
function getStyleObject(id)
{
var elm = null;
var styleObject = null;
if (document.getElementById)
elm = document.getElementById(id);
if (elm)
{
if (elm.style)
styleObject = elm.style;
else if (document.layers)
styleObject = elm;
}
return styleObject;
}
function hideElement(id)
{
var styleObject = getStyleObject(id);
if (styleObject)
styleObject.visibility = 'hidden';
}
DOM implementation 객체 사용
Using the DOM implementation Object
DOM1 호환 브라우저는 document.implementation.hasFeature()에 잠재적으로 유용한 객체를 담고있기도 한데, 특정한 기능이나 지원레벨을 질의하는 데 참(true)/거짓(false)를 반환하는 것입니다.
DOM 1 compliant browsers also contain a potentially useful object in document.implementation.hasFeature(), which should return true/false on being queried for a specific feature or level of support.
if (document.implementation &&
document.implementation.hasFeature &&
document.implementation.hasFeature("DOM","2.0"))
alert("DOM version 2.0 support available");
else
alert("No DOM 2.0 support.");
이런 접근방식은 불행하게도 항상 실용적이지는 못합니다. DOM implementation 정보가 잘못 전달될 수 있거나 다른 브라우저에서 잘못 처리될 수 있기 때문입니다(네스케이프 6의 첫배포판에서 ECMAScript 지원이 그런 예입니다). 일부 브라우저에서는 기능을 지원하지도 implementation.hasfeature() 방식 자체를 지원하지 않기 때문에 이런 방식이 거의 쓸모없게 될 수 있습니다. hasFeature()를 사용한다면,위의 object detection 예제에서처럼 implementation 객체와 hasFeature() 방식을 사용해야 한다는 것을 기억해두세요.
This approach isn't always practical, unfortunately, since DOM implementation information can be misleading or false on different browsers (ECMAScript support in the first release of Netscape 6 is a case in point.) Some browsers have support for features but not for the implementation.hasfeature() method itself, which can render this method nearly useless. If you do use hasFeature(), remember to use object detection on the implementation object and hasFeature() method, as in the object detection example above.
인터넷 이용자라면 반드시! 꼭!! 개인방화벽을 사용하세요 !!!
권장하지 않는 요소
다음글이 없습니다.
