> 안녕하세요?
> 윈도우미디어플레이어 7.01을 쓰고 있는데요.
> 두밥(doobob)사이트에서 뮤직비디오를 볼려고 하는데요 화면이 뜨질 않는데...
> 방법이 있을까요?
> 자세히 알려주시면 감사하겠습니다.

> ◈ 자유맨 ─ 안될겁니다..새버전을 기다리는 수밖에는...혹시 모르니 메뉴바>뷰>소스>에서 주소를 찾아 보세요...함 보니까 내부 주소를 불러 내는 것 같은데 그걸 못합니다...;;


방금 두밥에 가 봤습니다. 안 되더군요. 윈도우즈에서는 "더" 잘 됩니다. 그냥 되는 게 아니라 "더" 잘 된다 이 말입니다. "더" 잘 되게 하기 위해서는 다른 플랫폼을 무시할 수 밖에 없습니다. 그런데 다른 플랫폼은 사실 우리나라의 경우는 1 %도 안 될 겁니다. (리눅스 사용자들은 대부분 윈도우즈를 함께 쓰죠.) 따라서 무시하는 게 결코 변태가 아닙니다. (반대로 이 1 %가 안 되는 비윈도우즈 플랫폼 사용자들을 변태라고 볼 수도 있습니다.^^)

이 윈도우즈 지향적인 개발자들은 사실 플랫폼 호환이니 표준이니 하는 소리를 들으면 그냥 허허 웃습니다. 현실을 모르는 어린애들의 헛소리라는 거죠. 마이크로소프트의 기술이 하나도 대단할 거 없다? 인정. 대단하지 못 한 수준이 아니라 문제 투성이? 인정. 시장행위가 치사할 뿐 아니라 불법적? 인정... 근데... 그래서 어떻다는 거냐? 이겁니다.

그들은 이런 비판에 반론조차 제기하지 않습니다. 그러니 떠들어 봐야 입만 아픕니다. 다 인정한다니까요? 관심이 없어서 그렇지... 문제는 당파성입니다. 그래... 우리 조직이 좀 그래... 하지만 여긴 우리 조직 관할이야... 그리구 난 이 조직의 일원이구...

이 상황의 정치적 의미는 일단 접어 두고, 역사적 배경과 전망에 대해서 구체적으로 소개한 글을 퍼 왔으니 관심 있으신 분들(특히 개발자)은 한 번 읽어 보시기 바랍니다. 일반적인 통념과는 달리, 윈도우즈에서만 작동하는 DOM은 현재로서는 마이크로소프트 스스로가 지양하는 추세라는 것입니다. 현재를 흔히 사람들은 마이크로소프트의 3E 주기(Embrace-수용, Extend-확장, and Extinguish-축출)에서 Extend를 하는 주기라고 말합니다. W3C 표준의 적극적인 지원과 마이크로소프트가 꼭 차지하고 싶어하는 XML 표준에 대한 지원... 이런 분위기입니다. 따라서 현재 우리나라에서 많이 사용되고 있는 플랫폼 비호환 DOM들은 윈도우즈 지향적인 개발자의 관점에서 봐서 구닥다리라고 해도 틀린 말 아닙니다.

마이크로소프트는 현재 전선과 전략을 다차원화하고 있습니다. 시장이라는 차원(그 안에서도 여러 차원), 정치라는 차원, 언론이라는 차원, 등등등... 여러 차원에서 아주 복잡다단한 얽히고 설킨 전술/전략을 구사하고 있습니다. 우리나라 시장은 이런 차원 중에 한 부분을 차지합니다. 요지는, 한 차원의 양상만 보고 어떻다고 말해선 안 된다는 겁니다.

때로는 정치적 선택에는 여러 선택 사항이 있는 게 아니라 딱 두 가지만 있을 때도 있습니다.

"죽을래, 말래..."

"말래요."

이 대답이 우리가 할 수 있는 유일한 대답이 아니기를 바라면서...



ADC(Apple Developer Connection)에서 퍼 온 글입니다.
_________________________________________________________________

Scripting for IE 5 Macintosh Edition

Alexander Pope may have been only half-correct when he wrote, "A little learning is a dang'rous thing." A Web developer who has mastered the massive Microsoft Internet Explorer Document Object Model (DOM) for the PC may, in truth, have too much learning when it comes to writing scripts that are compatible with Macintosh versions of Internet Explorer (IE).

Windows-centric developers might expect compatibility problems with non-Microsoft browsers, such as Netscape Navigator, Opera, and others. What trips up many developers, however, is that the IE/Windows DOM includes many proprietary features that rely on the internal architecture of IE/Windows and the Windows operating system. Microsoft's Web developer documentation doesn't always highlight the features that are not available in the Macintosh version of Internet Explorer. This article will show Windows-centric IE developers what they can expect from the Macintosh version of the Microsoft browser.

How We Got Here
Internet Explorer 4 significantly advanced the concept of the DOM. Previous versions of the DOM provided scripting access to a very limited set of elements in an HTML page. While IE4 maintained backward compatibility with older versions of the DOM, this browser version was the first to treat every HTML element on the page as a scriptable object. Changes to an element's content were reflected instantly with the help of an automatically reflowed page that moved surrounding content around a modified element. A new way of addressing an element object came by way of the document.all collection -- an array of all HTML element objects on the page. Assign an identifier to an element's ID attribute, and your scripts could reach that object through the syntax:



document.all.elementID




Or, because the document.all collection is always implied in IE, simply:

elementID

The IE4 DOM included scripting control of Cascading Style Sheets (CSS) for both Macintosh and Windows versions. However, the IE4 DOM also included several documented features that worked only in the Windows version of IE. More on these issues in a moment.

While IE4 for Windows and Macintosh tempted the world with true dynamic content (Netscape Navigator 4 was still saddled with a static page that, at most, could have layers of HTML content float dynamically above the static page), the World Wide Consortium (W3C) assembled a public standard for a DOM that applied to both HTML and XML content. The W3C DOM was backward compatible with the original DOM (referred to as Level 0), and it also assumed that a document was as dynamic as IE4 demonstrated it could be. So as not to step on existing code, the W3C DOM developed a rather distinct syntax for addressing an HTML element object and its content with scripting statements. For any HTML element that has an identifier assigned to its ID attribute, the reference to the element requires a new method of the document object:

document.getElementById("elementID")


For more on these methods and the W3C DOM, read to these two articles on the subject.

Microsoft faced a dilemma. On the one hand, developers for IE4 had already invested heavily in the IE4 style of referencing objects; on the other hand, Microsoft had participated in the W3C DOM effort and could not ignore it. The result, as implemented in IE5, is a hybrid model that maintains compatibility with the IE4 DOM and supports at least the basic way of referencing objects in the W3C DOM syntax. Redundant? Yes.

In fact, scripters who have grown comfortable with the document.all approach to addressing elements have wrenching decisions to make as the installed base of W3C DOM-compatible browsers begins overtaking that of the Internet Explorer 4 world. The natural tendency is to keep all existing code running as long as possible, adding as few tweaks as are necessary to make scripts run in browsers that support only the W3C DOM. For newly created applications, however, you may be tempted to work with the W3C DOM syntax (e.g., using document.getElementById() rather than document.all) for the growing list of browsers that support the syntax (such as IE5+ for Windows and Mac, Netscape 6, and Opera 5). And yet your server logs may indicate that a substantial number of visitors still use IE4. It may be too soon to jetison document.all entirely as a way to reference element objects.
------------------------------------------------------------------------

document.all in Nav 6
You can simulate the document.all collection in Netscape 6 in a variety of ways. For a page whose element structure does not change under script control, you can instruct NN6 to create a document.all property through W3C DOM syntax. The following function, which should execute immediately after the page loads, shows a compact implementation:

function initAll() {
document.all = (document.all) ? document.all :
((document.getElementsByTagName("*").length > 0) ?
document.getElementsByTagName("*") : null)
}
...



After this function runs, any IE4 or W3C DOM browser provides access to an element object through the document.all.elementID syntax.
------------------------------------------------------------------------

The IE5/Mac DOM Implementation
Many are surprised to hear that separate Microsoft teams produce Macintosh and Windows versions of Internet Explorer. This is quite different from, for example, the way Netscape Navigator 6 shares the same core browser engine in all operating systems. One result of Microsoft's approach is that the two browsers are not always on the same release schedule and therefore do not necessarily contain the same DOM features. Moreover, if you compare the resulting DOM implementations in IE5 for Windows and Macintosh, you might conclude that the Mac development team exercises its own discretion when it comes to implementing DOM specifics. The Windows version of the DOM may contain both Microsoft proprietary and W3C DOM syntax for a particular property or method of an HTML element object. In contrast, the Macintosh version may omit the Microsoft proprietary syntax in favor of the W3C DOM version. Overall, IE 5.0 for Macintosh provides more direct support for W3C DOM syntax than even the later IE5.5 for Windows does.

Lest you throw your hands up in the air in despair, take comfort in knowing that you can still count on a lot of basic DOM functionality and syntax implemented in versions of IE for Mac and Windows. For example, in addition to support for the document.all collection, both platforms support the popular set of element object properties that facilitate direct manipulation of page content:innerHTML, innerText, outerHTML, and outerText.

Scripts in both browsers can control style sheet properties by way of an element object's style property. The fundamental IE4 event model is also consistent across both platforms.

In the Version 5 implementations of IE, both the Macintosh and Windows versions support enough of the W3C DOM node object model to be functional. Since the W3C DOM provides syntactically identical access to style sheet properties as the IE4 DOM does, you don't have to learn any new tricks to be compatible in that department. Perhaps the largest omission in the IE5 family is the W3C DOM event listener model, but IE5 for both Mac and Windows continue to support the IE4 event model.

Viewing the compatibility scene from high overhead, it appears as though a lot of code written for IE/Windows would run smoothly under IE/Macintosh -- and it does. But if you let your script writing be governed by all of the syntax devised for the Windows version, you could find yourself in trouble when you get down to the details. It's time to see which Microsoft DOM items are out of bounds once you leave the Windows version.

Win32-Only Technologies
Internet Explorer for Windows bundles numerous ActiveX controls, some of which the browser requires for normal operation. The browser also has instant communication with other ActiveX controls on the client machine, whether the controls are part of the Windows operating system or are downloaded or installed from third parties. What most other browsers treat as "plug-ins" are implemented as ActiveX controls for IE/Windows. Although IE5/Macintosh offers a modicum of support for ActiveX, the controls devised for Windows do not run under other operating systems, nor have IE/Windows built-in controls (such as the basic Web Browser Control, on which many IE/Windows features are built) been implemented as such in IE/Mac.

As a result, a few powerful Windows-only features are not available on the Mac version. These include Data Binding (direct connectivity to server data sources via the Data Source Object), CSS filters (for transition visual effects and text effects), DHTML Behaviors (the action-oriented equivalent to external style sheet definitions), IE 5.5 content editing, executing external commands (via the execCommand() method), and the TextRange object (allowing script control of arbitrary blocks of text independent of their HTML containers).

Admittedly, this is a long list of features not built into IE/Mac. Most of them are also missing from Netscape Navigator 6 on all OS platforms because (with the exception of the similar, but incompatible TextRange object) these features are not part of the W3C DOM standards -- at least not yet. Therefore, if you want to deploy these features on a public Web site's pages, apply them as additive, rather than mission-critical, aspects of the page. For example, you can apply barndoor transitions between pages of your site, but only IE/Windows users will see the effect.

Fewer Event Types
Compared to Explorer 4, versions 5 and 5.5 for Windows nearly double the number of event types that HTML element objects recognize. For instance, several event types in IE5 signal user dragging motions with respect to an element (onDrag, onDragEnd, onDragEnter, onDragLeave, onDragOver, onDragStart, onDrop). Another event group provides script control over cutting, copying, and pasting content (onBeforeCopy, onBeforeCut, onBeforePaste, onCopy, onCut, onPaste). And still another event type (onContextMenu) makes it easy to interrupt the system-produced context (right-click on the Windows mouse) menu and create custom menus.

In contrast, the IE/Macintosh event repertoire stays within the W3C DOM. Thus, you have the range of mouse, keyboard, and system-generated events that you have come to know and love in IE4 and NN4.

Speaking of events, the IE/Macintosh event object is a property of the window object, just as it is in IE/Windows. In IE5/Mac, however, the event object's properties include not only the IE4 properties, but also some W3C DOM event object properties, such as event.charCode (character and key codes are not necessarily the same values) and event.target (the W3C DOM equivalent of event.srcElement).

The Measure of Things
Far more difficult to predict are differences in the ways the Windows and Macintosh versions of IE render HTML elements that are not absolute-positioned and explicitly sized (in pixels). For example, form buttons render very differently on each OS platform, affecting not only the look of the form control, but also the space it occupies on the page. Additional differences in the ways the browsers report page scrolling and event coordinates can yield unexpected results. Complicating the situation even further is that your page's layout or design scheme can influence these differences. This makes it difficult to offer you simple workarounds or golden rules that apply to all designs. Even so, you should be on the lookout for key mismatches.

For one, if you employ element positioning in your page, you should experience little or no problems if you use the style object's positioning properties (style.left, style.posLeft, style.top, style.posTop) exclusively in your script manipulation of the elements. Avoid trying to mix and match regular element positions (as exposed by properties such as elemObject.clientLeft and elemObject.clientTop) with style object positioning properties. The offset-related properties of non-positioned elements report widely different values in the two OS browser versions, especially if the non-positioned element is a component of a TABLE element. For example, attempting to position a floating element atop a TD element that is nested inside a TABLE will be difficult to accomplish across browsers without a great deal of browser-specific hand tweaking of values.

Reading mouse event coordinates in an element requires slightly different treatment in Mac and Windows versions of IE, especially if there is a chance that the page containing the element can be scrolled. At issue here is determining the coordinates of the event within the element. The event.offsetX and event.offsetY properties in IE/Windows accurately report the offsets within the element. IE/Mac does, too, provided the page holding the element hasn't scrolled. If the page has scrolled, however, then the scrolling values (as determined by the document.body.scrollTop and document.body.scrollLeft properties) are automatically subtracted from the event coordinates before they are reported. Thus, for the Mac version, you must add back the document.body scroll values to the event coordinates:

var leftInsideElem = event.offsetX + document.body.scrollLeft
var topInsideElem = event.offsetY + document.body.scrollTop

The Mouse Offset Lab page provides a living laboratory in which to experiment with the different event offset behaviors in IE4 or later on both operating systems. The page is wired so that anywhere you click the mouse pointer, the event offset values are displayed, as well as the tag of the element receiving the event (event.srcElement). Two sets of coordinates appear in the table. One set displays the values returned from the event.offsetX and event.offsetY properties. In IE/Windows, if you scroll the page, the values returned by these event object properties report the correct values. In IE/Mac, however, the "raw" values are effected by the scrolling of the window (note the live scroll counter in the statusbar). To arrive at the desired values for the Mac, the scroll values must be added back to the offsets (see boldface lines of code the offset lab).

Playing with this lab page in both browsers reveals numerous subtle, but nonetheless important, differences in the way each OS version renders elements and treats transparent padding around some elements (where offset event coordinates can be negative values in both OS versions). For example, if you click in the centers of the checkboxes in both browsers, you see that the sizes are slightly different. Notice, too, how in IE/Mac, you cannot convey a click event to the very left and top edges of the BODY element.

Unimplemented Properties and Methods
In addition to the Windows-only features outlined earlier, a handful of Microsoft DOM properties and methods that are implemented in IE5/Windows (and some newer ones implemented in IE5.5/Windows) are not supported in IE5/Mac. If you have been developing pages for sites that must also accommodate IE4, then you are probably not using any of these IE5-only properties and methods. But if you have been limiting access to IE5 or later browsers, then see the table below for a list of the more popular properties and methods that you might be using but are not available in IE5/Mac.
Unsupported Properties and Methods in IE5/Mac
Object Type Property Method
HTML Elements
canHaveChildren attachEvent()