⚠️ 📖 DRAFT: <include- src={uri}> Client Side Include

[brandondees]

there are some major limitations for now
namely included scripts do not run
and nested linked stylesheets are not loaded
but images and inline styles do work
which makes this useful enough for some common cases

I'd like to do some homework to round up other folks' existing examples of how to approach this functionality. Ideally this can become easy enough and useful enough that it can gain some traction in terms of actual usage and lead to the standards groups accepting the idea as worth specifying as a platform feature. Part of the ideal is that html includes (inlining remote partials, not imports) should work without any JS and without need for any server side render code or build-time operations. HTML authors can simply re-use partials across pages by including them with a tag.

Related Internally

• #71 Current Statust of Web Components
• #77 PWA Web Performance Checklist
• #86 Component Naming Conventions

Related Externally

• <link> loading now allowed in body! SPEC APPROVED ✅
• Open PR to "Dynamic Imports"

Current Implementions

• html-include (Super tiny impl)
• StarCounter.io HTML partials/includes
• Juicy imported-template

[brandondees]

I'm open to discussion about whether it is important to support included linked stylesheets, as well as included scripts. I'm not sure what other potential caveats this functionality might have, so feedback and suggestions are welcome.

[snuggs]

OH WOWW

[snuggs]

@brandondees 🙏 Super proud of you on this attempt. We've got a long way to go but looking forward to this journey. Because...The web has been waiting for this since PHP and we finally can make a difference in contribution. /cc @pachonk @robcole @Robertchristopher @mrbernnz @btakita @dcchuck @janz93

[snuggs]

@brandondees updated with references as per your request. We are already wrangling some in #71

[snuggs]

@brandondees this could be valuable. Will find the canonical spec reference but will provide value for CSS (and other import resolution strategies). Has done the hard (early) work for us. We just need to prune the bonsai bush. Adding to PR definition as this thread may get long. 💍 💎

https://jakearchibald.com/2016/link-in-body/

[snuggs]

I'd like to do some homework to round up other folks' existing examples of how to approach this functionality @brandondees

Homework complete! (See updated description)

[snuggs]

@brandondees What do we think about

<include- src=/foo/bar.html>

[brandondees]

I'm still firmly straddling the fence on the use of - as a prefix or suffix in one-word custom tag names... I think it slightly undermines the intention of the - rule and may be error prone.

I went with <include-html> as a starting point because I imagine it's likely for there to be other formats that can be included using a similar mechanism, such as xhtml, xml, csv (include spreadsheet file, get data table embedded), svg, pdf (PDF.JS), with each providing sensible default patterns for how to inline such content into a parent document. Hypothetically I would expect to grow a collection of these components that can then be alphabetically sorted into the family grouping, e.g.

• <include-html>
• <include-svg>
• <include-xhtml>
• <include-csv>
• etc.

[grepsedawk]

I don't like using leading and trailing tacks to follow the custom element rules. I also am not sure the content type needs to have split tags (would be another attribute like "type". That said I don't have a better solution for now, and I dislike the lead/trail tack more, so I like @dees solution.

…

On Sun, Jul 16, 2017, 6:36 PM Brandon Dees ***@***.***> wrote: I'm still firmly straddling the fence on the use of - as a prefix or suffix in one-word custom tag names... I think it slightly undermines the intention of the - rule and may be error prone. I went with <include-html> as a starting point because I imagine it's likely for there to be other formats that can be included using a similar mechanism, such as xhtml, xml, csv (include spreadsheet file, get data table embedded), svg, pdf (PDF.JS), with each providing sensible default patterns for how to inline such content into a parent document. Hypothetically I would expect to grow a collection of these components that can then be alphabetically sorted into the family grouping, e.g. - <include-html> - <include-svg> - <include-xhtml> - <include-csv> - etc. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGaPS8sXIky7JOPhdC2f2HzH0mGGM-Aeks5sOp5ggaJpZM4OZJV9> .

[snuggs]

I'm still firmly straddling the fence on the use of - as a prefix or suffix

@pachonk @brandondees lemme help you out. MUST start with alphanumeric. Please see #86 for a full synopsis. Description is current.

[brandondees]

yeah i was thinking less about mime type / content negotiation and more about different methods of page inclusion, but it's a good point to consider... maybe just a more generic `<include-content>`? On Sun, Jul 16, 2017 at 7:07 PM Alex Piechowski <[email protected]> wrote:

…

I don't like using leading and trailing tacks to follow the custom element rules. I also am not sure the content type needs to have split tags (would be another attribute like "type". That said I don't have a better solution for now, and I dislike the lead/trail tack more, so I like @dees solution. On Sun, Jul 16, 2017, 6:36 PM Brandon Dees ***@***.***> wrote: > I'm still firmly straddling the fence on the use of - as a prefix or > suffix in one-word custom tag names... I think it slightly undermines the > intention of the - rule and may be error prone. > > I went with <include-html> as a starting point because I imagine it's > likely for there to be other formats that can be included using a similar > mechanism, such as xhtml, xml, csv (include spreadsheet file, get data > table embedded), svg, pdf (PDF.JS), with each providing sensible default > patterns for how to inline such content into a parent document. > Hypothetically I would expect to grow a collection of these components that > can then be alphabetically sorted into the family grouping, e.g. > > - <include-html> > - <include-svg> > - <include-xhtml> > - <include-csv> > - etc. > > — > You are receiving this because your review was requested. > Reply to this email directly, view it on GitHub > <#109 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AGaPS8sXIky7JOPhdC2f2HzH0mGGM-Aeks5sOp5ggaJpZM4OZJV9 > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALVhE-lXkTCqB5PQzN9Ho__XfJNLEWbks5sOqXCgaJpZM4OZJV9> .

[grepsedawk]

All good, then change my statement to postfix. I would be okay with include-content. Quick note, what if this tag works for inclusion of is and css as well? Then you don't need to memorize style and script include tags.

…

On Sun, Jul 16, 2017, 7:15 PM snuggs ***@***.***> wrote: I'm still firmly straddling the fence on the use of - as a prefix or suffix @pachonk <https://github.com/pachonk> @brandondees <https://github.com/brandondees> lemme help you out. MUST start with alphanumeric. Please see #86 <#86> for a full synopsis. Description is current. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#109 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGaPS_WSc-TMjeKa9sB3ru3YTxU28he5ks5sOqeigaJpZM4OZJV9> .

[snuggs]

And it's a shitty lean at that @brandondees @kurtcagle. We are def gonna want to not use webcomponentsjs polyfill (was great while it lasted) but possibly this polyfill site. The polyfill is making errors we didn't create #78

P.S. @brandondees rebased as we are dependent on a test script right now for WHATWG HTML.

[snuggs]

@brandondees @kurtcagle found a pretty good proposal layout format for future reference. github.com/whatwg/dom/issues/477

[tomalec]

Sorry for interrupting. But looking at the implementation in this PR, the behavior is closer to juicy-html.
imported-template uses HTML Imports instead of XHR and the behavior regarding <style>s and <script>s is also applied according to HTML Imports spec.

Personally, I suggest the latter approach. It gives clear, standardized way to handle scripts and styles, de-duping, dependency chains, etc.. But what is even more important, allow to keep dependencies in the partial, then execute/bootstrap them once, even though partial itself is stamped multiple times.

[snuggs]

@tomalec no need to apologize! We've been waiting for your input 😄 interesting approach! Care to elaborate? We can get this one merged in ASAP as this sounds pretty kick ass. If you could just provide some guidance i'll take care of the hard stuff😎. The day we can stop thinking about this can't come soon enough. And the webcomponentsjs polyfill is JANKY AF to say the least which is a whole 'nother headache. /cc @brandondees @pachonk

[tomalec]

@snuggs do you need something more elaborate than https://starcounter.io/html-partialsincludes-webcomponents-way/ ?

If so please shoot with questions/issues here or at https://github.com/Juicy/imported-template/issues :)

[snuggs]

@brandondees DEFINITELY an interesting project. Will definitely have to 🎩👌 tip the cap to @tomalec in "Getting Started" section for includes! Can keep <include- src=...> for tracking progress with HTML Module imports as we are using element- (element name (-) hyphen) format for experimental elements.

Quick question. Why go through all the trouble of using the janky Range instead of creating a bonafied DocumentFragment @tomalec ? At least two better options than that IMHO. Was there specific reasoning? Just curious as I know the pains of dealing with Ranges from contenteditable on a project with @robcole and clearly you are experiencing with Safari. I wonder why there is that inconsistency. 🤔 will need to check with whatwg/dom and webkit teams to see why that is. There should be consistency within that API. Have any reference links where you uncovered this 🐛 ? Seems like it was discovered in Juicy/juicy-html#12, Juicy/imported-template#13, & Juicy/juicy-html#14 and patched in Juicy/juicy-html@2b799a7.

I'd probably remove the safari check and always select this as the spec documentation seems to head (always) nod in this direction irrelevant of vendor implementation.

Going off the Range.contextualFragment Specification the net net outcome is a DocumentFragment. Which can then be inserted using the ParentNode.insertBefore (fragment, parent.firstChild) API.

[tomalec]

Thanks! :)

The only reason we get into all that trouble was to make it work in Safari, I'm not sure if it relevant any longer. Unfortunately, I don't have any reference for webkit bug. This was one of "We need it solve now!" issues ;) If (document.createDocumentFragment()).innerHTML works in Safari, I would really love it instead.

[snuggs]

@tomalec not only works with safari. But also has worked with Safari since forever ago ;-). Pretty ancient API. Introduced in DOM in 2005 (DOM 2 I believe)

Shall we champion a PR for you?