Hello, another Ryan! 😄👋

First of all, I have to say I absolutely love this idea & project. Thank you a million for putting it together, it's a genuinely novel & lovely addition to the Spring-o-sphere, and one I'm certain will have users... as I'm already in need of it! I really want to toss my current embedding code and use this everywhere instead.

This risks dipping into Spring '83 spec territory, but in my limited experience I've yet to find a reason for <spring-board> to not default to display: block. 🤔 Setting width, height and background-color on the element doesn't really work out the box otherwise.

This is my bad — I forgot that attributeChangedCallback and connectedCallback will fire when a custom element connects.

I think the answer is to make sure the current value for this.href and the third parameter of attributeChangedCallback (often called newValue) do not match before allowing the fetch to happen.

Closes #15.

The branch name is a bit misleading because we do still use innerHTML... we're just using it with template elements instead. 😅

This is technically a more performant approach (though boards are so simple so that's likely pretty moot) but it does make it easier to eventually query these fragments for a <time> element or a link=next and could open the door for clients to intercept the board HTML and make modifications before insertion. This should also make it a bit easier to react to pesky nested <spring-board> elements per #10.

This is slower than using the modern <template> method and just generally feels dated. The other benefit is it makes it possible to make alterations and run queries against the board HTML without having to inject the whole thing into the live DOM first.

A <spring-board> element should be able to "announce" it has loaded. This could solved via an event (this.dispatchEvent(new Event('spring-board-loaded'))) or perhaps via .loaded property with a Promise that resolves once the board is ready. I personally like the second idea a bit more though it's a bit more complex.

Closes #11.

This certainly isn't covering all the bases, but it at least establishes a loose foundation for actually testing improvements and fixes going forward.

Fixes #5.

This adds display: block to the default :host styles for <spring-board>. Also added a default-board.css file to make it easier to change/update the spec styles later.

Could certainly automate away the manual minify step, but no need to complicate it yet, I think!

Fixes #3 and #4!

They were surprisingly interwoven — to better support the possibility of <spring-board> elements being created at will in JavaScript, pointed at different boards, etc., the expectations around the href attribute needed to be loosened. As originally written the this.fetch call being in two locations was just asking for trouble, and it caused it — the most common way someone will likely use <spring-board> (loaded as HTML with a href attribute) would always trigger them both.

As currently written a <spring-board> element will always throw an error the moment it gets added to the DOM and activated if it is missing an href attribute. (And if you remove it!) However — this makes it difficult (impossible?) to treat a single <spring-board> as more of a viewer where you change the href to load different boards.

It's much more "native element"-esque as well to allow this — you are totally free to add an <img> or <video> tag to the DOM and it won't complain a bit.

Right now it's actually impossible to do this without changing the href to something else and swapping it back to the board you want, possible triggering a mess of network requests. Just need something boring like board.reload().

Was absolutely baffled why I was getting a foo is not a valid URL error all of a sudden only to finally trace it back to @robinsloan's dev board that I use in my preview/dev environment. 😅 The <spring-board> example found within the <code> block is a valid element and the custom element is trying to render it.

I think in this case this is HTML that needs to be escaped when wrapped in <code>, but it did reveal a scenario I didn't think about — boards could just daisy-chain <spring-board> instances like a nesting doll if given the opportunity. 🙃

Maybe during connectedCallback it audits whether it has a parent of <spring-board> and throws an error if so? Or perhaps right before it attempts to request the board?

Just like how <img> and <iframe> can defer loading based on distance from the viewport, it may be nice to do the same for boards as well. I think we'd still default to an eager loading strategy.

Per the most recent draft of the spec clients should be mindful of when a board communicates that its publisher is moving to a new URL via a <link rel="next"> element.

It's outside the scope of this element to do something with it in the context of a server, but it certainly should make it easy for the larger client to do so!

Maybe when the element discovers a <link rel="next"> it should set its own href to what it finds to start the validation and render cycle?

It's without question possible to do this as part of the validation step, but what should the element do when a board it is loading fails? It could possibly:

• Dispatch a spring-board-invalid event and leave it up to the larger client to decide.
• Refuse to display the loaded HTML at all...
• ...and instead render some sort of generic "not valid" output...
• ...or not! I've yet to see (so far) any other client actually attempt to enforce this part of the spec.