58 ms·

Introduction to HTML Components

284 points by Jasper_ 9y ago

jflowers45 9y ago
I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017
- enb 9y ago
  FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.
  - abritinthebay 9y ago
    It was a truly great release.
    - detritus 9y ago
      haha, it really was too, no hint of sarcasm! Young'uns these days probably can't believe what a saviour Microsoft from the clusterfudge that Navigator represented back then. . Typed on Firefox :)
      - abritinthebay 9y ago
        Oh no, I agree. IE got its bad reputation due to neglect, not because it originally wasn’t good. It just wasn’t good enough to last 10 years without updates
  - colordrops 9y ago
    Is that really true? IE 5.5 had shadow Dom?
    - TazeTSchnitzel 9y ago
      Yes, it's described by the article.
- nimchimpsky 9y ago
  Did you even read the article ?
- flomo 9y ago
  To a great degree, "modern web standards" are an exercise in reinventing proprietary Microsoft stuff from the 1990s. (Or replacing some thing that Java or Flash had done for years.)
urvader 9y ago
I used HTC a lot and waited for the other browsers to implement it. XBL came around but waited many years until it became web components. Great post!
- DaiPlusPlus 9y ago
  All this talk of HTCs reminds me of HTAs: HTML Applications. https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a... They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example. Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI. I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately. Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
  - vittore 9y ago
    This! I love simplicity of electron but it is absurdly resource hungry.
    - DaiPlusPlus 9y ago
      I don't agree that Electron is simple. Electron runs a Node.js instance as a websever and application server in-proc, while also running Blink/WebKit for each frame instance. There's no consolidation going on, and I feel for a majority of Electron applications there's no need for the Node instance because all they're serving is an Angular app using the built-in `chrome.` APIs. What would be simple is if a script tag in a single HTML file could access the filesystem or Windows registry - but under Electron they can't.
shadowmint 9y ago
Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it. Most people don't actually derive much benefit from writing custom UI widget primitives. Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful. I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special. That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful. They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference. It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having. ...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...
- Fifer82 9y ago
  I really tried with Polymer (for the last few months) but it was particularly verbose. I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand. Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening.... Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs... So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer. I do look forward to going back there though when 3.0 is available.
  - chenster 9y ago
deleted 9y ago
[deleted]
ab8 9y ago
I am not sure it is not a coincidence that the same idea keeps resurfacing. I remember reading pretty early on that HTML/XML/XHTML would eventually lead to a world where "chemists would have their own tags to represent chemical formulas" and similarly each discipline would develop their own tag language. Browsers would just know how to render them! People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.
- cwyers 9y ago
  > Browsers would just know how to render them! They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.
  - wiredearp 9y ago
    I guess the rendering of custom XML documents was more supposed to be controlled by CSS via the processing instruction <?xml-stylesheet type="text/css" href="styles.css"?>. It's a little known fact that this was actually working in Mozilla/Firefox all this time, but not anymore I suspect.
bradneuberg 9y ago
Nice; I used these "back in the day" while at Google to implement the illusion of native SVG support in Internet Explorer 6-8; I used hidden Flash for the rendering and Microsoft Behaviors wrapping it all so that the fake SVG would look like it was part of the DOM for full JS scripting. Fun times. Check it out here: https://github.com/BradNeuberg/svgweb https://github.com/BradNeuberg/svgweb
jlebrech 9y ago
creating apps in html is like creating a spreadsheet in word. why didn't we stick to xml and use a language to transform it into ui.
- pjmlp 9y ago
  I was a big fan of XHTML and all related XML Components, but then politics won.
  - em_te 9y ago
    Yeah but having to switch to createElement, appendChild, insertBefore, createTextNode just because innerHTML was not allowed was a pain in the butt.
    - jlebrech 9y ago
      at this point i'm considering creating a backend framework that sends a grid of images and uses imagemaps for clicks. with fast internet raster images shouldn't be a big issue.
      - pjmlp 9y ago
        Just use SVG/CSS with JavaScript events, that is the approach for the new FitBit SDK.
      - girvo 9y ago
        Adobe ImageReady... now that is giving me some flashbacks. Pun sort of intended.
        jlebrech 9y ago
        we could send 60fps image diffs now, we have the bandwidth. and all the browser does is send the window size and cursor position.
        9y ago
fish_fan 9y ago
Wow, reading this is like a blast from 2004. DHTML? JScript, the propriety IE javascript dialect? All without the marketshare of the time, thankfully.
finchisko 9y ago
As far I remember that time, I would say IE Components didn't succeeded, because at that time server side rendering was far more popular. I personally was doing sites in PHP and tried to avoid JS at all costs. Strange that today I'm doing exactly opposite.
- bojanvidanovic 9y ago
  Exactly this!
- newforice 9y ago
  And even stranger that with concerns about battery life; we should now be moving back towards server side rendering.
  - always_good 9y ago
    Unfortunately there's no real downside to eating people's battery. 99.9% of people just aren't going to know why, just that their battery dies faster.
stupidcar 9y ago
I remember discovering these in the mid-2000s, and thinking along the same lines as the author: why hadn't they caught on and been standardised like XMLHttpRequest, etc. had been? I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps. A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites. Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them. My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?
- wiredearp 9y ago
  XBL 2.0 was doing well on the standard track and would have made that happen [1], but it died along with all the other technologies whose acronym starts with an X. Flexbox was by the way implemented in Mozilla back then, I used it all the time in XUL, but then that acronym also starts with an X [2]. [1] https://www.w3.org/TR/xbl https://www.w3.org/TR/xbl [2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
drawkbox 9y ago
A great early site back in the DHTML/component days where IE4 was really pushing things was WebFX [1]. This was back when IE was actually a good browser as Netscape was fading due to DHTML/early AJAX (which was the XMLHttpRequest object originally from Exchange Server). DHTML at the time was mostly easier in IE because it didn't draw a new DOM for each layer i.e. document.layers (Netscape) each layer was a new full DOM and document.all (IE) was one DOM. [1] http://webfx.eae.net/ http://webfx.eae.net/
fergie 9y ago
"Why did IE5’s HTML Components never quite catch on? Despite what you might think, it’s not because of a lack of open standards" Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000. Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.
erikatoni 9y ago
Nice Article, Any other reference article for web designing.
deleted 9y ago
[deleted]
trumpownsyou420 9y ago
i'd rather jerk off with sandpaper, thanks.
JepZ 9y ago
I think the main problem with IE technology was the way Microsoft pushed it down our throats. The tech wasn't necessarily bad, but when the giant corporation pushes new features while not respecting/implementing the existing standards very few people support their efforts. So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.
- byte1918 9y ago
  I was young in 1999 so not very experienced with technology but I really doubt people were hating on Microsoft back then. Sure, every company will have a hate camp but I doubt it was as spread as it was in the past few years.
  - JepZ 9y ago
    Actually, it was much worse back then. Nowadays Apple Macs are affordable and alternative PC operating systems are quite usable too. In 1999 there was a usable but limited/old Win 95 and Win 98 which was crashing on a daily basis. So you can imagine how frustarating it was to work with such a machine. Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents https://en.wikipedia.org/wiki/Halloween_documents Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)
  - UncleEntity 9y ago
    coughWindows MEcough
lucaspottersky 9y ago
> "Why did IE5’s HTML Components never quite catch on?" because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)
MatmaRex 9y ago
These were widely used for at least one thing in practice: adding support for :hover pseudoclass on arbitrary elements (not just <a>) in IE6. https://peterned.home.xs4all.nl/csshover.html https://peterned.home.xs4all.nl/csshover.html
ausjke 9y ago
Polymer will ditch 'html-import'(which is similar to the HTML component) as it is not widely implemented on browsers and such. Polymer 3 will switch to ES6-loader and npm, probably one year away? I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2). I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.
coldtea 9y ago
I think Web Components will have/already had the same fate. To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen". At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery. We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done. React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.
- pas 9y ago
  It's happening, slowly: https://platform-status.mozilla.org/#shadow-dom https://platform-status.mozilla.org/#shadow-dom And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed) And see also http://ishoudinireadyyet.com/ http://ishoudinireadyyet.com/
  - coldtea 9y ago
    >It's happening, slowly That's browser adoption. XHTML was also adopted by all browsers. I'm talking about developer adoption.
jomido 9y ago
Chronological snobbery? https://en.m.wikipedia.org/wiki/Chronological_snobbery https://en.m.wikipedia.org/wiki/Chronological_snobbery
rsj_hn 9y ago
This goes into the bucket of scary, poorly thought out features that makes the web hard to secure. It's just like expression(), in that it allows code within a style take to result in script injection. CSS, due it's weird parsing behavior (data is not quoted, so it's hard to determine whether a token is data or code without a full CSS parse) is very hard to escape, and it's common to let user defined variables into CSS. Stuff like this is a nightmare for developers concerned about locking down their apps. And to the best of my knowledge, there's no way to disable it. Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.

284 points by Jasper_ 9y ago

I'm slightly confused by the combination of "introduced in Internet Explorer 5.5" and "offers a powerful new way" being written in an article posted on August 28, 2017

enb 9y ago
FTA: cough OK, obviously it’s 2017 and Internet Explorer 5.5 isn’t relevant anymore. But if you’re a Web developer, this should have given you some pause for thought. The modern Web Components pillars: Templates, Custom Elements, Shadow DOM, and Imports, were all features originally in IE5, released in 1999.
- abritinthebay 9y ago
  It was a truly great release.
  - detritus 9y ago
    haha, it really was too, no hint of sarcasm! Young'uns these days probably can't believe what a saviour Microsoft from the clusterfudge that Navigator represented back then. . Typed on Firefox :)
    - abritinthebay 9y ago
      Oh no, I agree. IE got its bad reputation due to neglect, not because it originally wasn’t good. It just wasn’t good enough to last 10 years without updates
- colordrops 9y ago
  Is that really true? IE 5.5 had shadow Dom?
  - TazeTSchnitzel 9y ago
    Yes, it's described by the article.
nimchimpsky 9y ago
Did you even read the article ?
flomo 9y ago
To a great degree, "modern web standards" are an exercise in reinventing proprietary Microsoft stuff from the 1990s. (Or replacing some thing that Java or Flash had done for years.)

urvader 9y ago

I used HTC a lot and waited for the other browsers to implement it. XBL came around but waited many years until it became web components. Great post!

DaiPlusPlus 9y ago
All this talk of HTCs reminds me of HTAs: HTML Applications. https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/bb250409(v=vs.85).a... They behaved like a native app, with control over their native chrome, and without any browser sandboxing: their JavaScript (JScript) or VBScript could use COM components to access to the file-system and other features, including loading other binaries in-process. File-system access was through Scripting.FileSystemObject, for example. Some built-in Windows components were/are built as HTAs, like the previous versions of the Microsoft AntiMalware / Windows Defender UI. I tried to use it for a project in 2013 but couldn't because HTAs are forced to run in Quirks-mode, so you can't use IE11's Edge mode, unfortunately. Best of all: they ran while needing only a few megabytes of RAM. Compare with Electron-based apps and it makes me weep because this, right here, is evidence that a Web-View can be used as the basis for an application, using a platform that was available since 1998/1999, without it dragging my PC down.
- vittore 9y ago
  This! I love simplicity of electron but it is absurdly resource hungry.
  - DaiPlusPlus 9y ago
    I don't agree that Electron is simple. Electron runs a Node.js instance as a websever and application server in-proc, while also running Blink/WebKit for each frame instance. There's no consolidation going on, and I feel for a majority of Electron applications there's no need for the Node instance because all they're serving is an Angular app using the built-in `chrome.` APIs. What would be simple is if a script tag in a single HTML file could access the filesystem or Windows registry - but under Electron they can't.

shadowmint 9y ago

Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it. Most people don't actually derive much benefit from writing custom UI widget primitives. Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful. I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special. That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful. They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference. It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having. ...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...

Fifer82 9y ago
I really tried with Polymer (for the last few months) but it was particularly verbose. I remember implementing an "<iron-ajax>" tag, and thinking that this is so wild and "Out There" that I may simply never understand. Annoyingly, there is a whole "Hybrid" mode as well. So there is no distinction between V1 and V2. If you are confused,you go to the docs, they aren't giving you what you need, so you go to one of the sample elements, and it is written in V1. So you have to read the migration guide to translate what is actually happening.... Then Polymer Summit happens, and now it is all JS based which, is far better for me but now it seems pointless to stay on Polymer 2.0, and Polymer 3 is a preview with no docs... So I aborted this path, went to Angular and to be honest, it is beautiful. It is almost trivial compared to the bag of questions and confusion I had going on with Polymer. I do look forward to going back there though when 3.0 is available.
- chenster 9y ago

deleted 9y ago

[deleted]

ab8 9y ago

I am not sure it is not a coincidence that the same idea keeps resurfacing. I remember reading pretty early on that HTML/XML/XHTML would eventually lead to a world where "chemists would have their own tags to represent chemical formulas" and similarly each discipline would develop their own tag language. Browsers would just know how to render them! People have tried to materialize this idea in multiple ways over time - HTC, microformats, web components etc. It should not be surprising that the solutions are similar. This isn't to say the first implementation was the best, and the others have just forgotten history. I am sure there are some pretty senior web developers around who remember their history, and were even part of it. If anything we should be optimistic that the new implementations have learned from the mistakes of the past.

cwyers 9y ago
> Browsers would just know how to render them! They wouldn't "just know," there were supposed to be DTDs published that would tell the browser how to render that specific kind of markup.
- wiredearp 9y ago
  I guess the rendering of custom XML documents was more supposed to be controlled by CSS via the processing instruction <?xml-stylesheet type="text/css" href="styles.css"?>. It's a little known fact that this was actually working in Mozilla/Firefox all this time, but not anymore I suspect.

bradneuberg 9y ago

Nice; I used these "back in the day" while at Google to implement the illusion of native SVG support in Internet Explorer 6-8; I used hidden Flash for the rendering and Microsoft Behaviors wrapping it all so that the fake SVG would look like it was part of the DOM for full JS scripting. Fun times. Check it out here: https://github.com/BradNeuberg/svgweb https://github.com/BradNeuberg/svgweb

jlebrech 9y ago

creating apps in html is like creating a spreadsheet in word. why didn't we stick to xml and use a language to transform it into ui.

pjmlp 9y ago
I was a big fan of XHTML and all related XML Components, but then politics won.
- em_te 9y ago
  Yeah but having to switch to createElement, appendChild, insertBefore, createTextNode just because innerHTML was not allowed was a pain in the butt.
  - jlebrech 9y ago
    at this point i'm considering creating a backend framework that sends a grid of images and uses imagemaps for clicks. with fast internet raster images shouldn't be a big issue.
    - pjmlp 9y ago
      Just use SVG/CSS with JavaScript events, that is the approach for the new FitBit SDK.
    - girvo 9y ago
      Adobe ImageReady... now that is giving me some flashbacks. Pun sort of intended.
      - jlebrech 9y ago
        we could send 60fps image diffs now, we have the bandwidth. and all the browser does is send the window size and cursor position.
        9y ago

fish_fan 9y ago

Wow, reading this is like a blast from 2004. DHTML? JScript, the propriety IE javascript dialect? All without the marketshare of the time, thankfully.

finchisko 9y ago

As far I remember that time, I would say IE Components didn't succeeded, because at that time server side rendering was far more popular. I personally was doing sites in PHP and tried to avoid JS at all costs. Strange that today I'm doing exactly opposite.

bojanvidanovic 9y ago
Exactly this!
newforice 9y ago
And even stranger that with concerns about battery life; we should now be moving back towards server side rendering.
- always_good 9y ago
  Unfortunately there's no real downside to eating people's battery. 99.9% of people just aren't going to know why, just that their battery dies faster.

stupidcar 9y ago

I remember discovering these in the mid-2000s, and thinking along the same lines as the author: why hadn't they caught on and been standardised like XMLHttpRequest, etc. had been? I think the reality is, Microsoft introduced these technologies at the tail-end of initial "dot com boom". Shortly afterward, most of the companies who might have built ambitious web apps using them went bust. Microsoft stopped investing in IE, and for quite a while afterwards, web development regressed to people building document and brochure-style sites. People were too busy trying to figure out complex CSS, and what `hasLayout` meant in IE to build component-based apps. A few years later, web development crept out of the doldrums: JavaScript's reputation began to be rehabilitated, the term "AJAX" was coined, and companies like Google began building more ambitious web apps. But by now Firefox was the browser of choice for most developers, and had gained enough market share that you couldn't build IE-specific sites. Mozilla teamed up with Opera and Apple, and later Google, to create what became HTML5, and that included reverse engineering and standardising a number of proprietary IE APIs. However, they chose to ignore element behaviours. Presumably because they had their own component technology, XBL, and wanted to make that the basis of web apps. And, since element behaviours never made it into Firefox, developers never started using them. My guess is, had Firefox adopted them, they'd now be a standard part of the web platform, and we wouldn't have web components as they currently stand. There are a lot of similar "what ifs" in the history of the web. For example, what if Microsoft had adopted XBL? What if flexbox and grid had been implemented in early 2000s when they were originally designed, instead of fifteen years later? What if ES4 had been accepted and implemented? What if Cassowary had been built into CSS when it was proposed, instead of being ignored (and later used by Apple as the basis for auto layout)?

wiredearp 9y ago
XBL 2.0 was doing well on the standard track and would have made that happen [1], but it died along with all the other technologies whose acronym starts with an X. Flexbox was by the way implemented in Mozilla back then, I used it all the time in XUL, but then that acronym also starts with an X [2]. [1] https://www.w3.org/TR/xbl https://www.w3.org/TR/xbl [2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL

drawkbox 9y ago

A great early site back in the DHTML/component days where IE4 was really pushing things was WebFX [1]. This was back when IE was actually a good browser as Netscape was fading due to DHTML/early AJAX (which was the XMLHttpRequest object originally from Exchange Server). DHTML at the time was mostly easier in IE because it didn't draw a new DOM for each layer i.e. document.layers (Netscape) each layer was a new full DOM and document.all (IE) was one DOM. [1] http://webfx.eae.net/ http://webfx.eae.net/

fergie 9y ago

"Why did IE5’s HTML Components never quite catch on? Despite what you might think, it’s not because of a lack of open standards" Actually thats precisely why it never caught on. Source: I was front end developer at one of the big dotcoms ca 2000. Also, its remarkable how many people skimmed this article, and didn't understand that the first part was from 1999. That really says a lot about people's expectations when it comes to Microsoft and web technology.

erikatoni 9y ago

Nice Article, Any other reference article for web designing.

deleted 9y ago

[deleted]

trumpownsyou420 9y ago

i'd rather jerk off with sandpaper, thanks.

JepZ 9y ago

I think the main problem with IE technology was the way Microsoft pushed it down our throats. The tech wasn't necessarily bad, but when the giant corporation pushes new features while not respecting/implementing the existing standards very few people support their efforts. So as a result 96% hated the IE and the other 4% were using other browsers. No wonder nobody wanted to use the newest Microsoft only features.

byte1918 9y ago
I was young in 1999 so not very experienced with technology but I really doubt people were hating on Microsoft back then. Sure, every company will have a hate camp but I doubt it was as spread as it was in the past few years.
- JepZ 9y ago
  Actually, it was much worse back then. Nowadays Apple Macs are affordable and alternative PC operating systems are quite usable too. In 1999 there was a usable but limited/old Win 95 and Win 98 which was crashing on a daily basis. So you can imagine how frustarating it was to work with such a machine. Furthermore, microsoft was fighting open source software which didn't make them more popular: https://en.wikipedia.org/wiki/Halloween_documents https://en.wikipedia.org/wiki/Halloween_documents Compared to those times the data collection on modern Win 10 systems and forced updates are small sins ;-)
- UncleEntity 9y ago
  coughWindows MEcough

lucaspottersky 9y ago

> "Why did IE5’s HTML Components never quite catch on?" because technology per se is just one of the variables that matter. For example, you are missing things like "timing", "marketing strategy" and a whole lot of other things. =)

MatmaRex 9y ago

These were widely used for at least one thing in practice: adding support for :hover pseudoclass on arbitrary elements (not just <a>) in IE6. https://peterned.home.xs4all.nl/csshover.html https://peterned.home.xs4all.nl/csshover.html

ausjke 9y ago

Polymer will ditch 'html-import'(which is similar to the HTML component) as it is not widely implemented on browsers and such. Polymer 3 will switch to ES6-loader and npm, probably one year away? I spent quite some hours with Polymer, but finally give up for now, one reason is that I want Polymer 3 today, but it is not there yet, also big companies tends to make its stack for big players(look at Angular2). I will use Vue.js for new projects at the moment, I read somewhere saying, Vue.js could be the next modern jQuery, and I kind of agree.

coldtea 9y ago

I think Web Components will have/already had the same fate. To paraphrase the meme: "Stop trying to get Web Components/Polymer to happen. They aren't gonna happen". At least not in this version of them. It's like XHTML that went about for years before it was taken out of its misery. We needed something like Web Components for a long time -- but the current implementation is exactly how it should not have been done. React/JSX got the good parts of it, and added even more useful things. If we could add the missing parts on top of that (like encapsulation from the external DOM), it would be perfect, and the rest of their horrible API/design can vanish.

pas 9y ago
It's happening, slowly: https://platform-status.mozilla.org/#shadow-dom https://platform-status.mozilla.org/#shadow-dom And "XHTML experience" is now built in to browsers, no developer effort needed (implementation consistency, the ACID tests, strict mode for JS, and WASM for speed) And see also http://ishoudinireadyyet.com/ http://ishoudinireadyyet.com/
- coldtea 9y ago
  >It's happening, slowly That's browser adoption. XHTML was also adopted by all browsers. I'm talking about developer adoption.

jomido 9y ago

Chronological snobbery? https://en.m.wikipedia.org/wiki/Chronological_snobbery https://en.m.wikipedia.org/wiki/Chronological_snobbery

rsj_hn 9y ago

This goes into the bucket of scary, poorly thought out features that makes the web hard to secure. It's just like expression(), in that it allows code within a style take to result in script injection. CSS, due it's weird parsing behavior (data is not quoted, so it's hard to determine whether a token is data or code without a full CSS parse) is very hard to escape, and it's common to let user defined variables into CSS. Stuff like this is a nightmare for developers concerned about locking down their apps. And to the best of my knowledge, there's no way to disable it. Fortunately, like expression, it's gone now in newer browsers, but this was not a proud moment for web security.