5 ms·
What the Heck is Shadow DOM?
- TimothyBurgess 16y agoTeens seem to like it.
- TimothyBurgess 16y agoDid you people downvoting this comment actually read the entire article? "Teens seem to like it" (referring to "Team Edward" in his pseudo code) was without a doubt one of the most hilarious things I've read in a tech article. Lighten up... geez.
- yanowitz 16y agoIt was a very funny line in the article and I didn't down vote you, but I suspect people did because your comment added nothing to the discussion not out of maliciousness. Even: "If you are on the fence, reading this article for the one liner on teens is worth it." Or "This article contains a one-liner that is the funniest thing I've read in a tech article in a while." I've found I can make controversial statements without getting down voted (perhaps I'm lucky) but glib me-toos are ruthlessly suppressed. I think it makes the place nicer though.
- jbeda 16y agoIE 5.5 had a lot of this with behaviors. IE 6 built on it further. Firefox push a lot of similar concepts with XUL. These ideas aren't especially new. There are a lot of subtlties that make this stuf really tricky. For details on behaviors see http://msdn.microsoft.com/en-us/library/ms531079(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ms531079(v=vs.85).as....
- dglazkov 16y agoYup. This is heavily inspired by DHTML behaviors, like most of the componenty stuff today on the Web. IE team did some great trailblazing work back in the day! :)
- aboodman 16y agoTotally agree. I had so much fun playing with that stuff way back when. Sad it never (or took so long to?) caught on.
- jbeda 16y agoPerformance improvements in modern browsers (V8 and webkit) along with more memory and faster processors are the game changers here. Keep in mind that at the time it was all based on the Trident rendering engine introduced in IE4. The system requirements at the time were Win95 and 16MB of RAM. You write different code for that vs. a modern desktop today.
- DjDarkman 16y agoSadly it's just a dream to create something in the DOM and make it private, if we ever get there, we will go to mashup heaven. The ability to limit the scope of a script tag would be desired too. Something like: <script> var notsoglobalobject = {}; </script> <script global-object="notsoglobalobject" src="yourevilscript.js"></script> But stuff like these are both hard to design and hard to make real standards.
- thristian 16y agoThis sounds very much like Mozilla's XBL ("XML Binding Language"), currently being standardized by the W3C: http://www.w3.org/TR/xbl/ http://www.w3.org/TR/xbl/
- dglazkov 16y agoYes indeed! In fact, the public-webapps discussion is around its latest draft (also mentioned in the blog post): http://dev.w3.org/2006/xbl2/ http://dev.w3.org/2006/xbl2/
- euroclydon 16y agoThe ability to hide stuff sort of takes the "script" out of Javascript.
- sid0 16y agoWhat do you mean by that? A closure like function foo() { var x = 0; return function () { return x++; } } and the equivalent in Python/Ruby/any language with closures hides x even better than a private member in Java would.
- gruseom 16y agoI've found that, for the most part, encapsulation is a solution in search of a problem. Once you stop taking for granted that it's a Good Thing because everyone knows that it is, you notice that the collisions that are supposed to be such a problem for the most part aren't, and when they do pop up it's not hard to find workarounds. What's far more common, at least in encapsulation-driven environments, is to be thwarted because you can't get at something you need. (Of course, "encapsulation" means a lot of different things. I'm not talking about, say, separation of concerns in design. I'm talking about the whole public/private/protected way of locking things away from external use.)
- benreesman 16y agoyou're absolutely right, and you present quite a compelling argument against object oriented programming itself. we're still paying the price for a prank a bunch of consultants played in the early 90s.
- InclinedPlane 16y agoIt depends entirely on the type of software you are creating. Encapsulation in system code (libraries, APIs, frameworks, etc.) is probably a good thing. We've seen the nightmare that comes when people exploit the full range of behavior of systems without regard to whether it's part of the official spec or the public API. You create a compatibility nightmare that forces you to do crazy things like release bug-compatible updates for the foreseeable future, and to make excessively sharp breaks between API generations.
- yason 16y agoThe value of encapsulation is in defining an interface. I mean a contract along the line of "These two blobs of code should be able to talk with each other using i, j, k, and l; if they really aren't, let's do more thinking." This is a good thing, it suggests you to think in terms of independent modules instead of spaghetti code. However, when it comes to encapsulation by enforcing information hiding it sounds awfully lot like trying to protect random dumbfools from themselves. It certainly ought to be sufficient to define the public interface in the documentation or headers, and expect people to adhere to that. A smart programmer really can find his way through into what was in the first place encapsulated if he really, really has to. Conversely, in the case where a dumbfool would ignore the documentation and poke around with private code he would simply do equally stupid but alternative things if he was prevented from touching any private parts (Hehe). That is, if one can't do the job he can't do the job no matter how severely his options are limited.