HTML Web Components

I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes?

I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable?

Vue/React/Angular don't seem like they are trying to "replace" HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.", in the "On The Web, Augmentation Wins in the Long Run" section), they are taking HTML/CSS/JS and building on top of them. If they all used canvas to render instead I might buy that argument but they don't. They absolutely push those technologies to their breaking point but it's nothing short of amazing in my book what you can accomplish with them compared to just HTML/CSS/JS and even "web components".

I was excited when Web Components were first announced but they are incredibly lackluster with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do. Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.

Also read these articles for more on the idea of "HTML Web Components":

https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the...- "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web."

https://adactio.com/journal/20618then suggests the catchy name.

I'm not sure I buy the "React is replacement, not augmentation" argument. At the end of the day/render, React still renders HTML elements... with javascript event handlers. Wrapping an '<img />' in a React component doesn't mean I've taken away any functionality of 'img'. I just add to it -- augmentation.

Maybe the author has worked in different React codebases than I have, but in my experience, we use built-in browser functionality unless we have a reason not to. Maybe I've just been lucky?

But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

Unless you... server-side render them. Then your definition of "render" needs to change

React components cannot do this — full stop.

Render your react components on the server and send them over the wire as plain html. no client side javascript required — full stop.

they can render before JavaScript. React components cannot do this — full stop

Not afullstop; SSR means theycouldrender beforeclient-sideJS.

The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.

I am more a fan of the augmented style because it doesn't entrap you in dev lock-in to platforms.

The problem with frameworks, especially web frameworks, is they reimplement many items that are standard now (shadowdom, components, storage, templating, base libraries, class/async, network/realtime etc).

DOM rendering speeds have been improved due to virtualdom but is no longer needed with shadowdom.

The web standards of today are amazing and take away the need for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.

React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over.

If you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice. [11]

Google Lit is like a combination of HTML Web Components and React/Vue style components. The great part is it is build on Web Components underneath.

[1]https://caniuse.com/template

[2]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4]https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

[5]https://caniuse.com/shadowdomv1

[6]https://caniuse.com/custom-elementsv1

[7]https://developer.mozilla.org/en-US/docs/Web/Web_Components

[8]https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

[9]https://developer.mozilla.org/en-US/docs/Web/CSS/transition

[10]https://developer.mozilla.org/en-US/docs/Web/CSS/animation

[11]https://lit.dev/

<user-avatar>

<img src="https://example.com/path/to/img.jpg" alt="..." />

</user-avatar>

I thought the standard way to do it is:

<img is="user-avatar" src="https://example.com/path/to/img.jpg" alt="..." />

I think I've finally seen the light when it comes to Web Components:

https://github.com/kennyfrc/cami.js

No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.

Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.

It's a nice idea and I'm glad we can expand the language to differentiate between html web components and javascript web components. That's important because the vast majority of use of web components are in the form of javascript web components. The only time I've ever seen HTML web components are on blog posts talking about how you can use web components. Never on an actual website about something besides web components.

I want to believe... but reality is stacked against HTML web components. I'm just going to stick to HTML and leave the HTML with dashes to others.

But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

Umm, that's why SSR was created?

Doesn't this create some nasty coupling since your web components look like a div but can actually require an arbitrarily complex HTML schema underneath? Can I write that down somewhere?

Apparently not widely know, but…

Svelte components can also be compiled to custom elements (aka web components) using the customElement: true compiler option.

https://svelte.dev/docs/custom-elements-api

This would negate the "vendor lock-in" arguments and allow Svelte for component development but web component for consumption and use. Best of both worlds. All the DX advantages of Svelte over web components without sacrificing interoperability.

For those who read to the end... Angular still uses XMLHttpRequest and not fetch, IIRC.

Funny, huh.

React Component is a function.

HTML web component is NOT a function.

You don't just compare those things, they work and compose differently.

I would rather combine them: A html web component renderer for React.

web components are a failed standard, it was a good idea 10 years ago but now its a very bad idea

Maybe it is just me but for me web-components were never able to deliver what they promised or a viable solution for a simple reason: i18n/translations. As a European freelance web dev, I've virtually never been in a project where we develop single-language UIs - its always at least the national language plus English. Those translations can't reside within a "component" itself for a simple reason: Translators push you to always share translations across components to achieve consistency throughout your UI. Now with react-intl or react-i18n-next those translation strings will live in a single or just a couple of files for the whole UI, and be provided through a react Context. It is also one of my pet peeves when people talk about "independent, self-sustained components". That is just not a thing in UI land, in most bigger projects each component has quite some external dependency from some form of enclosing context (translations beeing the most common one). In the article, user-avatar is probable one without any text at all, but thats the minority of components.

I can't tell if people who champion web components don't understand why the React model took off, or purposefully pretend to not know why since web components don't really solve most of the things people using React care about, and thus look bad in comparison.

This article is a good example of this. For starters, the "one shell component" thing is kind of a red herring. There's plenty of React components that interact with children, and you can clearly make web components that also "hide all the details". So this seems to be more of a "general" good practice they want to encourage, than anything specifically tied to React or Web Components in particular.

Critically however, the whole idea of "hey, web components still look good before JavaScript!" is either intentionally obtuse or really misses the point of React -- React can have abetternon-JavaScript initial render, thanks to SSR, which is significantly harder to do with Web Components. I don't really care if <user-avatar><img></user-avatar> "falls back" to some lame Web 1.0 rendering if my SSR-ed UserAvatar looksidenticalto the fully "active" component on first paint before any JavaScript runs. That is one of the main selling points of React and React-like systemstoday. You can't just ignore that completely and expect to convince anyone who's currently using that sort of system. But I understand why they don't address it, since the only real answers involve using some sort of build system with Web Components, which they'vealsodecided to say are the worst thing ever. So their only choice is to compare non-SSR Web Components to non-SSR React Components. And, I dunno, maybe they're better than the way we did things 8 years ago when that was the case? I'd have to think hard about that purely academic question.

The funny thing is that these are often the same people that would push for as little JavaScript as possible, and yet Web Components arefundamentally tied to JavaScript. Whereas React-style components can actually generate fully static JavaScript-free pages if you want to. This sort of situation springs up a lot: Web Components go on and on about not being "shells single components", and yet React-style components make itso much easierto deal with children. You aren't forced into the ugly slot system which immediately removes the "illusion" of it being a "real" HTML component, and is easier to deal with in the catch-all case too. Not to get into another huge differentiation, but I also personally prefer a more "functional" approach of writing a single render function vs. dealing with a bunch of lifetime callbacks to track the changing states of attributes and children.

Web Components are highly versatile. I built a chat app with GitHub OAuth login, blockchain-based authentication and access control using only 120 lines of HTML in a single .html file with no custom code, no framework, no custom server-side code. It can run anywhere:

https://github.com/Saasufy/chat-app/blob/main/index.html#L23...

You can try the app here (if you have a GitHub account):https://saasufy.github.io/chat-app/

The backend is serverless built using Saasufy.com - The platform/startup I'm working on currently:https://saasufy.com/

An effective approach I've found is to create components which consume slotted <template> elements to produce HTML that can be fully customized and injected with data they loaded from a back end. This allows you to create components which are declaratively bound to specific back end resources.

I've recently just started playing with Web Components without a build environment. Meaning, no npm, no bun, no webpack, etc, and no dependencies; in typescript. Intellij can autocompile down to js and the browser view injects a small onchange handler for live updates when developing. So far no problems.

The only thing holding web components back seems to be HTML Modules; being able to link to a .html file instead of a .js file to import a web component. Because of this if you want to use templates or anything more complicated you need to do the ugly inject of .innerHtml = `<tag soup>...`, which I thought would be a problem but the IDE parses the template string very nicely. It would be great to make a component in HTML and any javascript you would put in a <script> tag. It seems like there a lot of bureaucracy involved in getting HTML Modules out the door since its been eight years.

https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

As someone forced to use an in-house library of html web components at work,I will opine, run. Run at full speed away from the shadow DOM. It's cumbersome to work, poorly supported in testing tools, and web components themselves are a pain to deal with when your use case doesn't perfectly match the original build.

I'd like to like them, but, no.

With the massive caveat that I'm not a web developer or react developer, doesn't this stuff just look XML? I know html is a subset of XML but this stuff looks more and more like the XML that everyone complains about.

Edit: I'm meaning the attributes being longer than what the tags are denoting.

I'm a backend php dev who is hopelessly behind on the frontend literature, so here's pseudocode for how I would like web components (dynamic tag definitions) to work:

  <html>
    <tag>
      <my_tag $message="Hello, world!">
        <script>
          alert($message);
          setTimeout(function () { alert("Boop!"); }, 10000);
        </script>
        <img src="my_image.png"/>
        <p>$message</p>
      </my_tag>
    </tag>
    <tag src="my_other_tag.html"/>
    <body>
      <!-- shows "Hello, world!" -->
      <my_tag/>
      <!-- shows "Hello, override!" -->
      <my_tag message="Hello, override!"/>
    </body>
  </html>

That right there would make browsers run about 1000 times faster regardless of how many tabs are open, as well as stop most of the slowdown from ads.

Maybe <tag> should be <tag tag="my_tag"> to make it inline. Or <$my_tag> so as to not confuse new tag definitions with existing tags. As they say, the devil is in the details. But I think it makes sense to nest the tag definition in case <head> or <script> tags are needed, which would maybe get installed in the parent page. And there are endless use cases for passing variables to/from tags which are beyond the scope of this comment. Probably that would happen through data tags, passing JSON or raw Javascript like for onclick="alert('Hello')" where myTag.data = 1 + 1 would be like re-rendering with <my_tag data="2">.

But if we had something like that, frontend code would end up several orders of magnitude smaller, because we'd get back to declarative interfaces with progressive enhancement, more like what Htmx is working towards.

Keep in mind that I thought of this in 1995 when I very first saw NCSA Mosaic, and was flabbergasted that html tags weren't dynamically defined this way. When Netscape copied Mosaic but failed to fix even the slightest oversights like this, I knew that the future of the web was in perile and that we'd end up with the imperative stateful mess we live with today.

when is ‘composability’ getting added to the dictionary?

it is a pretty intuitive term - interoperable building blocks in areas that suffered from fragmentation - but isn't really part of the lexicon by the lexicon gods

I don't like web components because of the flash of undefined elements[1]. Hiding it with css tricks is clunky and ugly too. The sad thing is that web components seem like a great idea otherwise.

[1]https://www.abeautifulsite.net/posts/flash-of-undefined-cust...

It will be nice if/when these components can also be defined within HTML

<template type=component name="user-avatar" parameters="[src,alt]"> <img src="{src}" alt="{alt}"/> </template>

Web components are encapsulated very well. It is different from template frameworks such as react. It is somewhat similar to frameworks such as angular. As we all know, angular fails because of its complexity. It uses javascript to look like java. Web components look like It is not that complicated, but it also introduces a lot of concepts. These concepts are rarely used by ordinary developers. It is generally difficult to change the developers' inherent concepts and development habits to adapt. If there is no react or vue, I feel that it may not be successful because there may be other simpler frameworks.

My takeaway is: if you’re looking for longevity, opt for a technical approach of augmentation and enhancement over replacement.

This is my experience too, and this philosophy have made my web projects last a long time with minimal maintenance and dependencies.

What's the preferred way to version web components since their name is global and you can't risk breaking old usages when you introduce a breaking change? user-avatar-v2? What's todays suggested practice?

*Shameless self promotion warning*.

If you're looking for a middle-ground between React and Web Components, check out Joystick [1]. I designed it to take a React v1 approach to ergonomics but you write your components with vanilla HTML, CSS, and JavaScript (no attribute hacks or new syntax to learn—if it's on MDN, it will work in Joystick).

[1]https://github.com/cheatcode/joystick

This is what I do with my web-component framework:

https://realm.codes

The website itself also built with web component

I didn't have to read very far:

...they can render before JavaScript

what? Because web components are written in and run on magic?

a design of composability... composing core content with HTML and then wrapping it in a custom element that enhances its contents with additional functionality

Put aside the self-reference, that's not what composability usually means, but I guess that sounds fancy to the uninitiated

I recently used Web components to make a fairly complex form. It works well, but I am absolutely building the entire DOM tree inside the component in JS. The component relies on a bunch of tags being in the right place in the tree, with the right id. If the tags were specified by the HTML then there's too much opportunity to get it wrong. Templates might be do-able but there's no convenient way to add a template to a script file, or specify a template in JS (I guess this is why JSX came to be).

I definitely feel like I'm doing it wrong, but all the guidance I see doesn't help - they're all very "hello world" examples that don't get into the difficult stuff.

This feature of web components encourages a design of composability.

I am not a React, Vue (and friends dev) at all. Heck, I haven't done front-end or full stack for a long time now.

However, taking React as an example, where does it not encourage composability?

I like Web Components. I even spent the last couple of weeks playing only with the vanilla APIs (no Lit, etc.) just to see what is like:

https://lpedrosa.github.io/blog/web-components-part-3/

https://github.com/lpedrosa/webcomponents-blog-examples

Like many other people have pointed out in this post, it is great that you can leverage the platform. All the things you will learn e.g. DOM APIs, native elements and events, etc., are things you can carry over to React and Vue.

However, I believe articles like this fail to acknowledge the contribution React and friends brought to developer experience.

Building complex desktop like UIs was no longer impossible to maintain. You can easily make components and compose them, customise them, etc.

The general complaint is more around "you don't need Next.js" to build a news/marketing/blog website. The pendulum is swinging, especially with things like HTMX gaining traction.

IMO, people do it because:

- It's easier to hire developers that know the framework du jour

- Custom Elements are very flexible, so it's hard to enforce a particular style

- There aren't enough examples of people using vanilla Web Components (and I mean vanilla, not Lit and friends), so why use a web component framework when I can use a react based one?

Write more about how we can combine things like Custom Elements and "traditional" server side templating.

Write more about how a native element reacts to changes to its attributes or how it communicates user interaction and how that helps building a good custom element.

Or how building a good custom element is similar to building a good React component, and where it differs.

Antagonising existing knowledge or even the status quo is not constructive, and leads to poor discussions e.g. "Web Components is a failed technology" or articles like OP

I don't really agree that frontend framework components are meant to be replaced completely and are not composable. Maybe from the outside, but I use slots quite a lot in my components because they are very easy to do and they trivially work. Web Components on the other hand are usually demonstrated as insert <img-editor></img-editor> which basically inserts a ton of code to create some kind of an editor. Using slots in Web Components is a pain, a lot of appending nodes manually, templates as strings, for some more complicated things when I tried them I had to listen to the slotchange event etc. It's essentially the DOM api, which if it wasn't terrible, we wouldn't have switched to frontend frameworks like react etc.

Also disagree with the side note that XHTML failed because it didn't augment HTML. IMHO it failed because if forced the applications to be completely valid and it put the validation on the client/browser. If you'd really used real XHTML a small error in the markup would've crashed your page. So we all validated our XHTML to be future ready, but it was always utopia that a business would risk crashing their, well, business because a p tag was not properly closed.

I always saw web components as the missing leaves to the root that CSS frameworks embody.

web components are the quantum realm of CSS. What you know as normal might not work when you're trying to write style customization. My org has multiple teams working with different stacks, so at one point someone decided to write our component library using web components. Everyone hated it and we're now moving away from it.

My first book on Javascript was "DOM Scripting" by Jeremy Keith. He is still at it, pushing progressive enhancement, making HTML more useful with JS. I love this.

Why even build a component, when it is an image which could have styles applied using a class? I understand web components appeal when building complex elements, but this probably just slows down website, especially when element is repeated hundreds of times on page.

A web component should do ONE thing whereas a JS framework is a whole ecosystem.

I made a video player web component that could take in various inputs, with a torrent file being the most complex of them. I was then able to port it to Vue/React with StencilJS [0] (although it was good to go without). Just drop the `<awesome-player src="torrentOrVideoFile"... ></awesome-player>` along w/ its exported class from `awesomePlayer.js` and you have yourself a copy/paste HTML5 video player that plays torrents!

I also strongly suggest your web component attempt to mimic existing HTML elements, when possible, such as how I used `src` because `<video>` does. That way the consumer doesn't have to RTFM to interact with it.

[0]https://stenciljs.com/

We use web components in our project (a reactive Python notebook that, among other things, lets users build simple web apps [1]) to make it easy for the user to instantiate and compose our UI elements. Users can easily interpolate these elements into markdown, for example, since their representation is just HTML.

[1]https://github.com/marimo-team/marimo

Am I misreading this or is it whathttps://htmx.org/provides?

One problem is that "web components" is not a thing, you don't make "a web component". "Web Components" is the name a stack of three things that, taken together, make up the Web Components API.

You don't really make "a web component", what you make is a Custom Element, which might use a Shadow DOM, and might use an HTML template. Three things of which the most important one is the custom element.

With the core concept being that you're just making "more HTML elements", everything you can do with those, including which attributes and JS API they support, is up to you, and the way you put them on a page, the way you interact with them, the way you listen for events on them, etc. etc. is the exact same as any other HTML element. If you known how to write web pages the "old school" way, then you already know how to use custom elements. You just need to learn how to declare them.

I think this article is emphasizing custom tags / code reuse as the primary feature of React, which isn't really the case? The whole reason React was a game changer was because it eliminated (as much as possible, anyway) the invisible extra state stored in the DOM from your app and made its rendering declarative, which greatly reduces how much state you have to keep in your head when reading and reasoning about your app UI logic.

Web components don't address this on their own, which is why a lot of libraries still exist that build on top of them.

A problem I faced recently with web components using shadow dom is styling nested components within custom element:

From <user-avatar> we can give styles to <img>

<user-avatar> <img src="https://example.com/path/to/img.jpg" alt="..." /> </user-avatar>

but not anymore when its below <picture>

<user-avatar> <picture> <img src="https://example.com/path/to/img.jpg" alt="..." /> </picture> </user-avatar>

https://lnsy.dev/blog/custom-html-components.html

Here is my blog post about custom HTML Elements. It covers state changes, etc.

P.S., I am looking for a Front End project, preferably writing vanilla JS. My email is on the page.

With web components, you might even say React’s component model is being ported to the browser. But it’s being done in a way that works to enhance how the web already works, not replace it.

I wouldn't say that React's component model is being ported to the browser, just that a component model is being implemented in the browser, independent of and different than React.

Microsoft ActiveX Dynamic HTML Behavior Components (HTC files, introduced in IE5, after DHTML finally started working well) allowed you to augment HTML in the same way, and that's very old technology (circa 1999 or so) compared to React.

https://news.ycombinator.com/item?id=27405137

[...] At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.

Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.) [...]

HTML Components:

https://en.wikipedia.org/wiki/HTML_Components

HTC Reference:

https://learn.microsoft.com/en-us/previous-versions/ms531018...

I used them to implement nested piemenu components in a way that let you easily augment them with html in the browser (which was the wall I'd hit with OLE, not being able to easily use an animated gif or html table as a pie menu item, for example, having to draw everything myself with Win32), so you could embed snippets of HTML to define the menu background, center, items, and dynamic feedback.

That worked nicely in conjunction with XSLT to transform XML models into HTML pages with embedded trees of HTML components.

For example, the Punkemon Pie Menus used an XML database of Punkeland regions and Punkemon characters to make a tree of nested pie menus.

JavaScript Pie Menus - Punkemon Pie Menus:

https://youtu.be/R5k4gJK-aWw?t=177

Pie Menu ActiveX Behavior Control (htc file as text):

https://donhopkins.com/home/PieMenu/piemenu.htc.txt

Punkemon Pie Menus XML Database (xml file as text):

https://donhopkins.com/home/PieMenu/punkemon.xml.txt

XSL Style Sheet (xsl file as text):

https://donhopkins.com/home/PieMenu/punkemon.xsl.txt

For example the XSLT transforms the XML Punkemon database into HTML with embedded nested <piemenu> <item> and arbitrary html, like a table inside one of the items to make a gigantic pie menu item at the bottom, whose purpose is more like an info panel than a menu item, just showing you some information about the magnified animated gif of the character in the top item.

ActiveX Pie Menus that "hit the wall" (discussion near end of video):

https://www.youtube.com/watch?v=nnC8x9x3Xag

Well, I ran into a wall of complexity with this ActiveX control, and I wanted to be able to have as the menu items animated gifs, mpeg movies, fonts with nice attributes, and things like that. The first thought was "well let's just put a web browser in every item!", but that was a little heavy-handed. So instead I put the pie menus into the web browser as dynamic HTML components, which I'll show next.

All this stuff I explained in the video is incredibly obvious now, but it seemed really cool at the time in 2001, and it was a hell of a lot better and more web-centric than binary OLE/ActiveX controls. (Pardon my unabashed XML and Microsoft technology advocacy, but it really was a step up from what came before it, and you couldn't do anything remotely similar in Java!)

But it illustrates that the idea of augmenting and embedding html in components like that goes way back, and that HTML Web Components were obviously influenced by Microsoft ActiveX Behavior Controls more than they were React.

JavaScript Pie Menus: example of augmenting neste piemenu components with html:

https://youtu.be/R5k4gJK-aWw?t=339

Transcript:

Now the really convenient thing for user interface designers is that the way these pie menus are specified in XML markup language.

This test pie menu has eight items here, and North has a sub menu with four items. Now that map's very nicely into an XML tree. It has a piemenu element, and that has a name and ID.

The neat things is that you can put arbitrary HTML inside of the XML, and that is just copied and just dumped right into the middle of the menu to make it look any way you want. And then the menu, this pie menu item, contains, besides this stuff to display in the middle an item, an item.

It contains eight items, and this item's name is north, and that's its name to the program, which could be different, and that's what is displayed to the user here. Now it contains the sub piemenu, which is the North menu, and has even more.

You can see how you can intersperse XML and HTML to specify all this that you need to describe for the pie menu.

One of the really great advantages of using XML for the piemenu is that there are many ways to generate XML and many things that are represented by XML that you might want to make and then use for. In the case of the punkemon pie menus I really didn't want to make all those pie menus directly.

So maybe I'm making a card game and I have this XML file that I use to print all the cards and maybe do the online game and everything. I've defined the markup language for punkemon cards. There's the punkeverse contains punkeland where they live, and that contains a bunch of punkemons.

Now all these give information that is needed to make the menu for that. It's an application specific markup style, but it has information for menus in it. Basically all this gets translated into all this very automatically by an XSL stylesheet.

That's a macro language for XML that takes the nice clean to the point punkemon xml file and then transforms it into a piemenu tree and a web page that pops that pie menu up.

punkemon.xml:

https://donhopkins.com/home/PieMenu/punkemon.xml.txt

    <?xml version='1.0'?>
    <?xml-stylesheet type="text/xsl" href="punkemon.xsl" ?>

    <punkeverse>

      <punkeland
        name="Rave Caves"
        itemradius="60"
        pieradius="100">

        <punkemon
          name="Candibi"
          foundin="Rave Caves"
          attacks="Disturbing Cuteness, Pacifier attack"
          likes="Candy, Stuffed Animals, Loops"
          dislikes="Ambient music, spankings, bed-time"
          creator=""
          url="http://www.gothic.net/~luvcraft/punkemon/rave/candibi.html"
          image="Punkemon/candibi.gif">
          <description>                                                                                                                                                                                   
            The youngest and perkiest denizens of the Rave Caves, Candibis                                                                                                                                
            spend much of their time spinning around in circles with one                                                                                                                                  
            hand high in the air and the other hand tightly clutching a                                                                                                                                   
            large stuffed animal. Naturally shy, these cuddly creatures                                                                                                                                   
            can often be enticed into a Punkeball with large amounts of                                                                                                                                   
            candy, especially if the candy comes in perforated sheets."                                                                                                                                   
          </description>
        </punkemon> [...]

punkemon.xsl:

https://donhopkins.com/home/PieMenu/punkemon.xsl.txt

    <?xml version="1.0"?>
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
      <xsl:template match="/">

        <HTML>

          <HEAD>
            <TITLE>Punkemon Pie Menus</TITLE>
          </HEAD>

          <BODY>

        <DIV ID="Barf"></DIV>

        <DIV STYLE="width=100%;height=80%;behavior:url(piemenu.htc)"
          onchange="ChangePunkemon(event)">

          <CENTER>
            <H1>Punkemon Pie Menus!</H1>
            <IMG SRC="Punkemon/island.jpg"/>
          </CENTER>

          <XML>

            <piemenu
              id="root"
              fixedradius="90"
              centermargin="50"
              centerbackground="white"
              itemnormalbackground="white"
              itemselectedbackground="gray">

              <html>
                Punkemon<BR/>
                Pie Menus
              </html>

              <xsl:for-each select="*/punkeland"> [...]

The behavior attaches this JavaScript code to it and allows it to receive input events and translate them to a higher level semantics and then send these output events like the pie menu changed, and it's going to call my JavaScript function that's on this web page to handle it.

Now this div is the thing that's presented on the page that you click on, so it's got a little picture of the island there. Inside the div besides its presentation is an XML data island, which is just embedded XML that instead of being displayed on the page is just data that can be referred to.

The pie menu looks in there, finds the XML, pulls out the pie menu definition in it, and uses it. You can pack these things nicely together. You can also point to another file that contains the pie menus externally. But in this case we're going to have them inline.

The Punkemon piemenu contains the words "Punkemon Pie Menus". And then it uses the XSL macro language to loop over all of the punkelands, making items for each one of them. And that item is made by extracting fields from that punkeland, and just sticking them into HTML as either properties or content.

You can get the value of the name of this guy and stick it into that guy, and put a bold marker around it, and make a div. This is just a bunch of nested loops that loops over the database and renders it out as dynamic HTML embedded in a piemenu tree embedded in a web page.

And it works! That's what you're seeing over here.

There's a lot of other really neat applications of automatically generating the piemenus or any other kind of user interface from an XML specification, that could also be used for a lot of other things. And you're just describing your data in one place, and then algorithmically rendering it out to all sorts of other things.