In My approach to HTML web components Jeremy Keith goes into a naming convention for both web components and their attributes. While I don’t have any opinions on attribute naming, I do have a strong opinion on element names, and that’s if you decide to namespace your elements it should be done using a post-fix and not a pre-fix. As an example, all the elements we’ve build in Skia Infra are post-fixed with -sk:

Based on a Twitter discussion about optimizing the performance of web apps, I implemented a very crude polyfill for an idea I recently had. HTML forms support multiple target values, i.e. where should the result of submitting the form be displayed, but there is no value for of target for inline, that is, you submit the form and instead of the whole page refreshing the server returns HTML that takes the place of the Form contents.

Over 5 years ago I wrote No more JS frameworks and just recently Jon Udell asked for an update. It's almost 4 years since @bitworking said: "Stop using JS frameworks, start writing reusable, orthogonally-composable units of HTML+CSS+JS." I'm curious, Joe, about what you've since learned, thought about, and done with the idea.https://t.co/zdKjEZfIe3 — Jon Udell (@judell) July 17, 2019 I have been blogging bits and pieces over the years but Jon’s query has given me a good excuse to roll all of that up into a single document.

I’ve launched a new micro-blog at stream.bitworking.org, which has an Atom Feed if you want to follow along. You can also follow along on Mastodon by following @stream.bitworking.org@stream.bitworking.org thanks to https://fed.brid.gy/. Any entries will also appear on Twitter thanks to https://brid.gy. Interactions on any of those sites should flow back to Stream thanks to webmention support via github.com/jcgregorio/webmention-run. Finally the admin interface to Stream is a PWA that supports the Web Share Target API, which means I can trivially share content to Stream using the native Android Share intent.

Is there an OpenID Connect for US Citizens run by the US government? I’m not sure why I’ve been thinking a lot about such a utility lately. )

Via Alex Russell, I just found Guidelines for creating web platform compatible components, which further contains a link to The Gold Standard Checklist for Web Components, both of which look like excellent resources when creating custom elements. This is a good time to mention that work is progressing on elements-sk, a set of neat Vanilla JS custom elements.

My VanillaJS project, where I re-implement popular framework sample apps in vanilla JavaScript, has now been ported over to ‘a la carte’ web development. In this case that means they all use pulito for their tooling and directory structure, and individual framework ports bring in templating libaries as needed. For example, the React sample rewrite uses lit-html for templating, and the Angular sample rewrite uses hyperHTML for templating. This is a perfect example of the power of a la carte web development, where you get to pick the components you want and only have to ‘pay’ for what you use.

Stop using JS Frameworks is something I’ve been advocating for years now, and a legitimate question I get is what do you replace it with? The answer is “a la carte” web development. Instead of picking a monolithic solution like a web framework, you just pick the pieces you need. I don’t mean any old random pieces, below I am going to outline specific criteria that need to be met for some components to participate in a la carte web development.

“Neat” – as applied to drinks served in bars – refers to a shot of liquor poured directly from the bottle and into a glass. There is no chilling involved with a “neat” drink. There is never an additional ingredient in a drink served “neat”. Up, Neat, Straight Up, or On the Rocks The Custom Elements V1 spec has reached concensus and implementations are going well, which is all great news, but what I find surprising is the lack of VanillaJS custom elements on WebComponents.

I love custom elements! I've been building UIs with them since Polymer 0.5 was announced in 2014. One of the things that I've questioned with custom elements has been Shadow DOM and its relationship to CSS. This page is an experiment for comparing custom elements with and without Shadow DOM. Press the buttons below and 1,000 spinners will be displayed on the page, when 'Light' is pressed the custom element uses CSS defined for the whole page, and when 'Shadow' is pressed the custom elements have a style sheet attached to their Shadow DOM, and when 'External' is pressed the CSS for the element is still encapsulated in the Shadow DOM, but it is loaded as an external stylesheet.

I just recently finished adding support for Twitter metadata to the blog, mostly motivaged by brid.gy’s ability to use Webmentions to automatically post my blog entries to Twitter. As I worked on the Twitter metadata I wondered if other silos had their own metadata they supported. Indeed they do, and Kevin Marks brilliantly demonstrates how ridiculous the situation is by creating a blog post that appears different in every silo.

As Chris suggested, I have gone beyond my minimal webmentions, and thanks to the heavy lifting of Will Norris, I got to avoid handwriting a microformats parser in the process. This is what they should look like in action:

Ryan Barrett celebrating over 1 Million Webmentions in the wild. Not bad for a specification that only became a recommendation a year ago.

I spent some time over the holidays porting web framework sample apps over to vanilla JS. I’ll add the same caveat here that I also included in the code: The code works w/o polyfils in Chrome. To get it to run in a wider range of browsers you will need to add polyfills and, depending on the target browser version, compile the JS back to an older version of ES, and run a prefixer on the CSS.

Now that Custom Elements has reached v1 and is starting to appear in browsers, let's make some elements. We'll start with one of the simplest elements possible, a busy spinner, or activity indicator. Caveats: No accessibility. spinner-bw { display: none; border-radius: 50%; width: 2em; height: 2em; border: 0.4em solid #a6cee3; border-left: 0.4em solid #1f78b4; animation: spinner-bw-spin 1.5s infinite linear; } spinner-bw[active] { display: inline-block; } @keyframes spinner-bw-spin { 0% { transform: rotate(0deg); } 100% { transform: rotate(360deg); } } window.

It was over three years ago that I wrote No more JS frameworks, at which time I was roundly criticized for not understanding that data binding could only be done via JS framework, the two were inextricably linked, and only 2-way data binding would do, as one way data binding was for weak-minded fools who weren’t building real applications. You can find the comments on HN yourself, I don’t link to that cesspool.

Note: This post was updated in Jan 2017 to use the Custom Elements V1 spec. One of the questions that comes up regularly when talking about zero frameworksis how can you expect to stitch together an application without a framework? The short answer is "the same way you stitch together native elements," but I think it's interesting and instructional to look at those ways of stitching elements together individually.

Stop writing Javascript frameworks. Translations: Chinese Japanese Russian Here's the talk, based on this essay, that I gave at OSCON 2015. [Slides] The 100-line templating library presented as a Gist has been cleaned up, documented, and published as the Stamp library. JavaScript frameworks seem like death and taxes; inevitable and unavoidable. I'm sure that if I could be a fly on that wall every time someone started a new web project, the very first question they'd ask is, which JS framework are we using?

What I said last year, now the W3C apparently agrees. In short the case that was presented for distributed extensibility was weak.

XML namespaces are designed to provide distributed extensibility using URIs. Distributed extensibility means that multiple people, or organizations, can extend an XML format with out any communication between them, and if they follow the rules they will avoid syntactic collisions. That statement shouldn't be controversial, it's a statement of fact, the definition of distributed extensibility. The problem is that everyone seems to accept the underlying assumption that distributed extensibilty is a desirable property.

At a previous employer we made tensile testing equipment. Now for tensile testing a material you cut it into a dogbone shape and then pull at each end of the dogbone, plotting out the change in length of the specimen against how much load is on the specimen. Once you have all that data you can plot stress-strain curves and learn all sorts of interesting things about said material. Now if you are developing a new material, or in general working in a laboratory setting, the amount of material to test isn't large, and the amount of work of preparing specimens and loading them into a tester and reading off the results falls into that's-what-we-have-interns-for.

The Atom Publishing Protocol is a failure. Now that I've met by blogging-hyperbole-quotient for the day let's talk about standards, protocols, and technology. This is all the fodder I was going to throw together for a presentation I proposed for OSCon. Since that proposal got rejected I'm going to post it here. On the other hand, my App Engine tutorial got accepted, so I'll still see you at the conference.