Move makeup-web-components packages into makeup-js. Archive makeup-web-components project.

[ianmcburnie]

No description provided.

[patricknelson]

I'd almost suggest just archiving it and not moving; at least for now.

Architecturally, it may not fit well with our desired approach to use progressive enhancement. We won't be using shadow DOM (at least in the first version) nor the style/templating. Not sure about the skeleton, since with PE we'll just be upgrading the HTML/styles already present with added JS interactivity. 🤔

[patricknelson]

By the way, quick proof of concept using the makeup-switch UI as an example (which is the only element in the repo right now)

<makeup-switch control="switch__control">
  <span class="switch">
    <span
      class="switch__control"
      role="switch"
      tabindex="0"
      aria-checked="false"
      aria-labelledby="label-1"
    ></span>
    <span class="switch__button"></span>
  </span>
  <span id="label-1">Enabled Switch</span>
</makeup-switch>

Note that the redundant control="switch__control" is here just for demonstration only, since that's the only real option exposed by the underlying MakeupSwitch UI/widget/model (still need to hammer down that nomenclature). Anyway, the wrapper element should just "progressively enhances" the underlying switch "bones"

💀 Bones styled by 😎 Skin, powered by 💄 Makeup with accessibility in 🧠 MIND.

That said (and for the record): I'm super down for DSD (declarative shadow DOM), eventually. That would be an awesome feature that I think could build upon this. It would just require a lot of extra thought about how we'd leverage it (particularly with regard to templating, reactivity and if that template is then optional and etc). IMHO, that could take the form of Bones itself getting components, e.g.

<bones-switch label="Enabled Switch" checked="false">
  <!-- Optional (implicit if omitted). -->
  <template shadowrootmode="open">
    <makeup-switch control="switch__control">
      <link rel="stylesheet" href="path/to/ebay/skin.css" type="text/css">
      <span class="switch">
        <span
          class="switch__control"
          role="switch"
          tabindex="0"
          aria-checked="false"
          aria-labelledby="label-1"
        ></span>
        <span class="switch__button"></span>
      </span>
      <span id="label-1">Enabled Switch</span>
    </makeup-switch>
  </template>
</bones-switch>

... but I've digressed bigtime on that one.

[ianmcburnie]

Not sure about the skeleton

Yeah, skeleton was only for pure client side web component only. You are right in that we would no longer need it if not supporting pure CSR use case.

Also, just for comparison (for anybody following along) here is what we currently have:

SSR (declarative shadow root)

<span id="label1">makeup-switch 1</span>
<makeup-switch labelledby="label1">
    <template shadowrootmode="open">
        <link href="makeup-switch-element.css" rel="stylesheet" />
        <span class="switch">
            <span class="switch__control" role="switch" tabindex="0"></span>
            <span class="switch__button"></span>
        </span>
    </template>
</makeup-switch>

Pure CSR

<span id="label5">makeup-switch 5</span>
<makeup-switch labelledby="label5" skeleton="true"></makeup-switch>

I'll try and quickly build one more in this manner in the existing web-components repo, just so I get a better feel for shadow root vs lightdom.

[patricknelson]

If you do, you might appreciate ElementInternals as well:

• https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/attachInternals
• https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals#instance_properties_included_from_aria

It has a bunch of Aria properties on it. It’s also good for form validation (since forms and fields are still fully veiled by the shadow boundary).

[ianmcburnie]

@patricknelson Going back to this comment: #168 (comment)

Would that approach mean no support for CSR scenario? Such as this:

<span id="foo">foo</span>
<makeup-switch labelledby="foo" skeleton="true"></makeup-switch>

[patricknelson]

Hey, sorry for the late reply.

Conceptually, that second code sample provided (the one with <bones-switch>, if that's the one you're referring to) is theoretically agnostic to the light/shadow DOM implementation. 🤔 I say that since, while yes the API varies when inside vs. outside of the shadow DOM (e.g. document.getElementById() vs. shadowRoot.getElementById()), it's possible to detect if the custom element is itself in a shadow DOM or not, so that can be abstracted away.

In quick hack code (just to speed things up a bit)

<!-- Can itself be in a shadow DOM or in the light DOM, it is adjacent (and
       therefore accessible) to the <makeup-switch> element -->
<span id="foo">foo</span>
<makeup-switch labelledby="foo" skeleton="true"
  <!-- Can build light or shadow DOM inside, and if in shadow, leverage element internals -->
</makeup-switch>

And if <makeup-switch> needs to find #foo it can do so via either method above depending on if element.getRootNode() instanceof ShadowRoot returns. Sorry if this is too quick but let me know if that' make sense. 😅

[patricknelson]

Also to clarify that a bit more:

1. If you use light DOM, everything can access everything else
2. If you use shadow DOM, everything can access everything else in the same document root (e.g. adjacent siblings like <makeup-switch> and the given #foo span, since both have the same parent). Obviously #foo is locked away from <makeup-switch>'s shadow DOM, but the two (#foo and the <makeup-switch> host element) can interact with each other just fine. It's up to the host element to decide how to manage its internals.
3. You're free to abstract away as needed using either light DOM or shadow DOM as you dive deeper, e.g. <makeup-switch> may, or may not, want to lock away its internals via shadow root and, if so, can still expose form capabilities as needed using element internals

[ianmcburnie]

Sorry I wasn't clear, I was referring to this: https://github.com/makeup/makeup-web-components/blob/master/docs/makeup-switch-element/index.html#L72

And this: https://github.com/makeup/makeup-web-components/blob/master/packages/makeup-switch-element/src/index.js#L50

For fully CSR SPA case (i.e. developer not needing to care about progressive enhancement), everything locked away as much as possible. No exposed template or slots. Although yes, switch is a very simple widget, so it can easily be this way.