
Introduction to HTML Components - Jasper_
http://blog.mecheye.net/2017/08/introduction-to-html-components/
======
shadowmint
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...

~~~
pjmlp
I think that people that disregard Polymer fail to understand that Web
Components are already here.

They are fully supported on Chrome and Safari, and hopefully Firefox and EDGE
will eventually catch up with them.

And they have to, because Chrome and Safari own the mobile web.

Polymer is transitioning to being a thin layer on top of what the browsers
support, which basically means a Polyfill for Firefox and Edge, and utility
classes to make writing components easier.

Web Components is what is making me finally get to love web development again.

If it is to make an application platform out of browsers, then give me a
platform, not an application for doing hypertext documents that we try to bend
for something else.

Chrome settings panel, the new You Tube, all new EA gaming portals are already
using Web Components.

I look forward to have something like Blend for Web Components.

[https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s](https://www.youtube.com/watch?v=otcmcNY-3pk&t=17s)

EDIT: fixed a few grammar issues

~~~
dmitriid
> I think that people that disregard Polymer fail to understand that Web
> Components are already here.

No. Polymer is here. As Rob Dodson said, "Polymer is the jQuery of
WebComponents".

No one in their right mind would even think about writing and using
WebComponents in vanilla JS.

Hence we're coming back to the problem with WebComponents: they are a solution
in search of a problem.

~~~
pjmlp
Angular and React also have plans to eventually move into Web Components.

~~~
peterhunt
This isn't true [https://facebook.github.io/react/docs/web-
components.html](https://facebook.github.io/react/docs/web-components.html)

~~~
dmitriid
It's partly true, see [https://custom-elements-everywhere.com](https://custom-
elements-everywhere.com) and linked issues.

The main problem: when the framework makes the developer decide whether to
pass attributes or properties to Custom Elements, it's mostly ok. The
framework should also allow binding any events (which cna be named as onEvent,
or on-event or...)

Frameworks that are trying to be clever and hide the complexities of DOM
behind proper APIs, and that implement their own event systems suffer greatly
because DOM APIs and WebComponent APIs are a pile of steaming crap.

~~~
allover
The site you linked to is about frameworks 'playing well with' custom
elements. It says nothing to the assertion about React moving to web
components.

Also it is not helpful to call standards 'a pile of steaming crap' without
backing that up with something substantive, examples/alternatives etc.

------
bradneuberg
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)

------
fergie
"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.

------
ab8
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
> 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
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.

------
stupidcar
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
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)

------
finchisko
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.

~~~
newforice
And even stranger that with concerns about battery life; we should now be
moving back towards server side rendering.

~~~
always_good
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.

------
coldtea
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
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
> _It 's happening, slowly_

That's browser adoption. XHTML was also adopted by all browsers.

I'm talking about developer adoption.

------
drawkbox
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/)

------
rsj_hn
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.

------
lucaspottersky
> "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. =)

------
jlebrech
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
I was a big fan of XHTML and all related XML Components, but then politics
won.

~~~
alwillis
If you call web browser vendors mutinying against the W3C who was pushing
XHTML 2 down their throats "politics", which lead to Apple, Mozilla and Opera
creating the Web Hypertext Application Technology Working Group (WHATWG) and
to HTML5--then I'm okay with the politics.

Yeah, I could close my tags and validate my code with the best of them back
when XHTML was a thing--but that's no way to live. I'm glad WHATWG stepped in
and literally saved the web from itself. OMG! XHTML 2 would have sucked so
much!

~~~
wiredearp
The way I remember it, there was a guy called Hixie something that was in
charge of standards implementation at Mozilla and made a terrific job at that.
But then he got hired by Opera and saw that there was no point in competing
with Gecko and so he started a FUD campaign called "XHTML considered harmful"
to lower market standards. He bluffed you into believing that namespaces are
far too complicated for the human mind to comprehend, when in reality XHTML
hadn't caught on because the CMS systems were not up to date. He did a
terrific job at that, so he got hired by Google to publish a competing
specification that was actually based on the way that Internet Explorer 6
parses HTML4. He did at terrific job at that, so we are finally back where we
started, with a standard that lives forever while IE6 is long gone, and Goggle
can scavenge the specifications from this forgotten future for ideas they can
present as original. Even Mozilla played along with the HTML5 scheme, it was
like watching a nuclear superpower go down in a fist fight. How can you not
call that politics?

------
jflowers45
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
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
It was a truly great release.

~~~
detritus
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
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

------
ausjke
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.

------
JepZ
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
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
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 ;-)

------
urvader
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
All this talk of HTCs reminds me of HTAs: HTML Applications.

[https://msdn.microsoft.com/en-
us/library/bb250409(v=vs.85).a...](https://msdn.microsoft.com/en-
us/library/bb250409\(v=vs.85\).aspx)

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.

~~~
ricardobeat
You can still do this, and in OSX too using MacGap (or writing a tiny webview
wrapper yourself). The main reasons this is not widely done are incomplete
device APIs, no control over browser versions/features - app might break at
any moment for different subsets of users, and the lack of cross-platform
compatibility. Electron actually solves most of those pain points despite the
heft.

~~~
DaiPlusPlus
Does the Cocoa WebView expose any kind of non-sandboxed COM-like API for
system access? That was what made HTAs so useful.

------
MatmaRex
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)

------
jomido
Chronological snobbery?
[https://en.m.wikipedia.org/wiki/Chronological_snobbery](https://en.m.wikipedia.org/wiki/Chronological_snobbery)

------
fish_fan
Wow, reading this is like a blast from 2004. DHTML? JScript, the propriety IE
javascript dialect?

All without the marketshare of the time, thankfully.

