[Questions] - later added elements into the DOM: to be or not to be

[thednp]

For those who work with DOM manipulations and use the library or have any experience with JavaScript driven dynamic content, please reply:

• Do you think we would need some tools and/or polyfills to enable our library to go LIVE (initialize proper BSN component for every new element added to the DOM) ?

• If yes, what would you suggest? (I am currently experimenting with CustomEvent, MutationEvent and MutationObserver, working on a kind of polyfill for IE8)

• About an IE8 polyfill, do you (or your scripts and tools) use mostly Element.prototype.appendChild, Element.prototype.innerHTML, both, or other methods?

To the most frequent contributors (please forgive me for tagging you)
@mathieuleclaire, @troyk, @mgiulio, @janpanschab, @RyanZim, @HelloGravity, @Jeff17Robbins, @DGT41, @oliseviche, @thewisenerd, @alzalabany, @kuus, @malexdev, @crcastle, @Aspie96, @CamWiseOwl, @antoligy, @zandaqo

AND anybody reading this page, please share your opinion.

[kuus]

Do you think we would need some tools and/or polyfills to enable our library to go LIVE (initialize proper BSN component for every new element added to the DOM) ?

I am not sure if bootstrap native uses event delegation but I seem to remember it does not, I think that could be enough. If I have to work with really dynamic pages I prefer using more robust frameworks.

About an IE8 polyfill, do you (or your scripts and tools) use mostly Element.prototype.appendChild, Element.prototype.innerHTML, both, or other methods?

Both

is out of topic but I would suggest to implement a modular es6 structure to the project (if I'll have time I'll try to work on that)

[thednp]

is out of topic but I would suggest to implement a modular es6 structure to the project (if I'll have time I'll try to work on that)

We will work on bootstrap.native for Bootstrap 4 with this in mind, based on the code of my future commits.

The future BSN release will feature bootstrap original events, 24Kb minimized, a ton of improvements and new features. It would be something to consider, especially if I manage to get it done with the new features I have in mind.

[Jeff17Robbins]

I would like a way to add one or more BSN component at "runtime" (after the page load time upgrading process has already initialized the elements originally on the page.) So, yes to question no1. I noticed that Bootstrap 4 is apparently dropping IE8 and IE9 support. From https://v4-alpha.getbootstrap.com/migration/#browser-support:

- Dropped IE8, IE9, and iOS 6 support. v4 is now only IE10+ and iOS 7+. For sites needing either of those, use v3.

So, one way we could support dynamic BSN initialization would be to make optional custom elements which know how to initialize automatically when they get attached to the DOM. If you ignore the very cool "Shadow DOM" (see below), webcomponentsjs (https://github.com/WebComponents/webcomponentsjs) has a nice polyfill for custom elements that works nicely on IE10+. Chrome supports custom elements natively, and I believe Firefox and Safari do too. The polyfill only needs to be loaded on browsers like IE10+ that don't support custom elements. The polyfill uses MutationObserver to notice new custom elements and upgrade them. Chrome notices via a built-in process, so you don't have the overhead of instrumenting the DOM with a MutationObserver, which makes this idea probably more performant and in the spirit of ditching jQuery and going native as much as possible. We'd have to create custom elements, e.g. `<bootstrap-modal>` or whatever you want to call it, which would come with implementation in its "attached" callback that runs the right initialization JavaScript that would have happened at page loadtime had the element been present then. When I say "attached" callback, I'm referring to the webcomponents V0 spec. The spec has moved to V1 this article https://component.kitchen/blog/posts/our-experience-upgrading-web-components-from-shadow-domcustom-elements-v0-to-v1 discusses the changes. But the polyfill for V1 isn't quite ready, but I'm imagining we could target (V1)[developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements], in which case the "attached" callback has been renamed to the "connectedCallback", a function on your custom element which gets called when you element is added to the DOM. Roughly the same idea with a new name. In that function, we'd initialize the modal. Any cleanup could happen in the "disconnectedCallback" (like removing event listeners.) By publishing custom elements, we would make things like "modal" much more modular and object-oriented. By optionally using a polyfill on IE10+. we'd be clean on browsers supporting the V1 spec, and only take the MutationObserver hit on non-conformant browsers. Note on ShadowDOM -- ShadowDOM is very cool because it creates a DOM island for your custom element that is essentially private, so that you can style it with your own CSS and not have to worry about other CSS rules bleeding through onto it. I don't think we need a ShadowDOM in our custom elements, because we want them to be styled by global Bootstrap and its theme. It is easier to create a custom element without ShadowDOM, and we can always add it later if we need to. But ShadowDOM is dicey in the polyfill, and there's been lots of churn around it in projects like Polymer, so I think we could ignore it for the time being.

…

-Jeff

[thednp]

I am working on an CustomEvent for BSN for BS3 update.bs.dom, works in IE8+

document.addEventListener('update.bs.dom', function(e){
  // e.target is document

  // e.relatedTarget is the new/removed element

  // OR

  // e.boundElements [Array] IE8 with a newly added/removed element and it's children 
  // this event is only triggered when appendChild/removeChild methods are used
}, false)

When the event fires, there could be a handler to apply a proper BSN component via DATA API or something. This is probably suitable for BSN for BS3, but what do you think?

Indeed the ShadowDOM spec sounds very interesting.

[Aspie96]

I have been building a modified version of bootstrap.native that works even if you modify the DOM (without calling extra functions), but it is missing some elements.

Would it help if I published it on GitHub?

[thednp]

@Aspie96 I believe it's an IE9+ solution?

[Aspie96]

I made it a while ago, but it should be IE8+.
I haven't tested it on actual IE8, though (the latest version of IE contains a simulator of older versions, I used that one).

[thednp]

@Aspie96 please go for a fork of the current master and start applying your changes, I am curious if there could be something better than my current development.

Again, the BSN 1.5 series coming soon will have major code changes, for sure your version will not be mergeable with that, but at least we can all have an idea.

@Jeff17Robbins reading more into your input I can now say that everything you talk about is likely doable for the BSN for BS4, in combination with what @kuus was talking about. I am also interested in how you would want this to be implemented.

[Aspie96]

Forking is exactly what I did, but I cannot publish the project right now since I am not at home.

It is actuallyn quite a bit different from yours, but it is fully based on yours.

As I said, some controls are missing.

Maybe, before pushing on GitHub, I will paste the code on PasteBin (to fix a few things before pushing, like… the manual XD).
I hope you don't mind if I do so.

Thank you for using a free license such as MIT.

[Jeff17Robbins]

Here's a very crude, but working, example of packaging BSN Modal as a custom element. You need Chrome to see it run, because I didn't load the webcomponents polyfill.

https://jsfiddle.net/w1cmLc0g/

I call it 'crude' because it doesn't encapsulate everything about Modal, and it hasn't hidden the Modal's dialog contents in Shadow DOM, but it does define the toplevel aria and other attributes for you, showing how encapsulation can reduce user boilerplate.

<bsn-modal id="myModal">
  <div class="modal-dialog">
    <div class="modal-content">
      some content
    </div>
  </div>
</bsn-modal>

It takes care of that boilerplate plus instancing the BSN object in its connectedCallback:

  connectedCallback() {
    this.classList.add('modal');
    this.classList.add('fade');
    this.tabIndex = -1;
    this.setAttribute('role', 'dialog');
    this.setAttribute('aria-labelledby', 'myModalLabel');
    this.setAttribute('aria-hidden', 'true');
  
    this.modal = new Modal(this, {
      backdrop: 'true'
    });
    this.open = false;
  }

A fancier version would place the Modal's template in a <template> element, and use the <slot> element to parameterize the content of <bsn-modal>.

[thednp]

As much as I like your example, it's too outer space for me, maybe you can shed some light for me: do the customElements behave like they are under MutationObserver, or something to enable dynamic content...

NO NO, let me ask you this: is there anything you can explain to me who I just heard of customElements and MutationObserver what is BEST to do, WHERE is BEST to go forth?

Thanks :)

[Jeff17Robbins]

I don't understand your question, sorry. The beauty of a custom element is that it is a first class citizen of the browser. Rather than hijacking div s to make them be a modal, you can have a true bsn-modal element. Why is that outer space?

…

On Tue, Jan 17, 2017, 11:16 AM thednp ***@***.***> wrote: As much as I like your example, it's too outer space for me, maybe you can shed some light for me: do the customElements behave like they are under MutationObserver, or something to enable dynamic content... NO NO, let me ask you this: is there anything you can explain to me who I just heard of customElements and MutationObserver what is BEST to do, WHERE is BEST to go forth? Thanks :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAWhz0H1Qm-XtC4sRBtIScgmIvXmX7iks5rTOk_gaJpZM4Lj-Tp> .