profile
viewpoint

gregwhitworth/scrollWidthPolyfill 15

Polyfill for scroll width

gregwhitworth/Facebook-Photos 3

This is an addon for Expression Engine to allow you to use your Facebook Photos on your site.

gregwhitworth/pipvid 1

A basic extension that allow pip support to HTML 5 video elements even if the site doesn't leverage it.

gregwhitworth/wiki-companies 1

This provides ready to utilize lists of companies scraped from Wikipedia.

gregwhitworth/2019-conferences 0

A list of 2019 web development conferences.

gregwhitworth/actsofempathy 0

A simple site that shows acts of random acts of empathy that you can choose to do

gregwhitworth/bikeshed 0

:bike: A preprocessor for anyone writing specifications that converts source files into actual specs.

gregwhitworth/caniuse 0

Raw browser/feature support data from caniuse.com

gregwhitworth/crbug-query-count-ado 0

Allows a dashboard tile to link to a crbug query which will return the total bugs listed

gregwhitworth/csswg-test 0

CSS WG test repository (mirrored at https://hg.csswg.org/test/)

Pull request review commentsalesforce/lwc-rfcs

Virtual Script Container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/39+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using light DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++To ensure we can solve the problem while continuing to guarantee the benefits that are provided by the synthetic-shadow polyfill for all other components, we are currently proposing the following characteristics for the secure-script design:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>

The secure script container does not have access to globals defined by other scripts. i.e. extra-globals does not define globals to keep in sync between the outer window and the secure script container. Rather it should copy any globals defined to the outer window.

I think this should be defined in the spec, at least as a note.

Yes, the point here was just to illustrate the global being referenced across script containers, both virtual and standard.

Does this negate @pmdartus point that due to not being able to access other globals that GA won't work?

tedconn

comment created time in 31 minutes

Pull request review commentsalesforce/lwc-rfcs

Virtual Script Container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD

I'm hesitant to allow this to be a free-for-all due to this statement in your RFC

We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt Shadow DOM semantics.

I would prefer for us to leverage the top libs identified and give them access to this for Phase 1 and when the need for synthetic shadow is removed we can update the <n> libs to leverage Phase 2.

Is this a large request outside of these large products?

tedconn

comment created time in 36 minutes

issue openedwhatwg/html

Meta discussion: Coordination/specing of overlap content between Open UI & WHATWG

Issue #5791 requests an addition of the open state based on research and agreement in Open UI in order to create a spec for the <select> control (anatomy, behaviors, states and events that transition based on behaviors). I would like to discuss, possibly over call or here on how best to coordinate possible overlap to ensure that UAs can implement according to Open UI specifications. I have now met with the CSSWG & ARIAWG regarding this work and there is general agreement to the pain points that Open UI aims to solve and I'd like to facilitate a similar discussion with those here.

To kick things off, I'd like to propose the following:

  • WHATWG will define new elements, attributes and DOM APIs that hang off of control
  • Open UI pull in content as necessary for the web platform or component library authors to effectively implement the control/component and user interactions and the impacts on the parts
  • Open UI will file issues against WHATWG with gaps (such as the open attribute, focus stops for the file input, etc) found but defined within Open UI that need to be brought back to the HTML specification

Let me know if you think a phone call for me to present the content and kick off this discussion further. Thanks!

created time in an hour

issue openedwhatwg/html

Add open state to <select>

In Open UI we have decided for a need to have an open state for the <select> element when the listbox part is visible. Would you like me to open a PR for this? This attribute will allow styling aspects of the select parts based on the state of the <select>.

https://open-ui.org/components/select#open

created time in an hour

issue commentMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>` customizability

Opened it here: https://github.com/whatwg/html/issues/5791 @dandclark can you close this out?

dandclark

comment created time in an hour

issue commentwhatwg/html

Opt-in for `<select>` customizability

Bringing in my comment from the MSEdgeExplainer repo:

From the beginning I've been in favor of having new elements for the new controls as it also allows us to keep some native ones and specific needs for certain capabilities (window escape, etc). As we discussed in our explainer I'm also a fan of the built-in parts, while maybe leveraging WC parts under the hood being elements themselves as well so it is 100% apparent what is standard/ships with the UA and what is user land code.

gregwhitworth

comment created time in an hour

issue openedwhatwg/html

Opt-in for `<select>` customizability

@dandclark opened this issue on the repo that contains the explainer for this. For context, we released an explainer that attempts to explain a web platform control definition for defining components going forward. This requires HTML modifications across the WHATWG but to keep this one scoped. Here is the outline from Dan in the initial issue:

It's necessary that control customizability be opt-in rather than on by default in order to not break compatibility with older > sites and to avoid issues where capabilities of the customizable controls be limited, e.g. the customizable <select> must > not escape the bounds of windows due to security concerns.

Opt-in for custom control behavior for <input> type like <input type="range"> will be done by introducing new elements, > e.g. <range>, for the customizable version, while <input> will remain the same.

For <select>, since unlike <input> the parser does not prevent it from being parsed with child DOM nodes, we've proposed that it's not necessary to create a new element for it and we could instead do opt-in through an attribute like <select custom="">.

There are downsides to relying on an attribute though:

@mfreed7 pointed out that we'd need to deal with the fact that the custom attribute could be added/removed dynamically, which adds complexity. Parsing is particularly concerning here, since the attribute would change the parsing rules for the subtree of the <select>. Is there any scenario where a <select> could have script change it to custom when we're in the middle of parsing its subtree?

@travisleithead raised this specific concern about the dynamic case: consider a dynamically-created <select> (via document.createElement()), when the custom attribute must be set using setAttribute(). When should the transition to the custom behavior be applied? Applying it at the point of setAttribute() would be inconsistent with how other elements like <input type="range"> work when created dynamically; typically the transformation would occur when the element was appended to the DOM. But, this means that for a dynamically created <select>, the developer would have to wait until the <select> is appended to the DOM before calling attachShadow(), since attachShadow() throws for a non-custom <select>.

If we're minting new elements for all the customizable <input> types then it seems odd to do something different just for <select>.

On the other hand there are downsides to adding a new element for <select>:

What would we name it? @mfreed7 suggested <selectmenu>, I don't have any other ideas at the moment. @gregwhitworth pointed out that some might be opposed to a new element that is almost 1:1 with the current one but had more capabilities.

Overall, introducing a new element and thereby sidestepping the problems of dynamic opt-in seems better to me.

created time in an hour

issue commentMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>` customizability

Awesome, I'll spin up an issue for this - much appreciated.

dandclark

comment created time in an hour

issue commentMicrosoftEdge/MSEdgeExplainers

<select> anatomy seems Windows-centric

Thanks @othermaciej - ultimately I think this should be resolved over at Open UI as this isn't necessarily true:

cases which are generally rendered as a straight listbox

There are already a few issues open to explore the multiply attribute to determine the anatomy and path forward for definition from this and a11y perspective. I'll continue the discussion, and welcome your feedback, there: https://github.com/WICG/open-ui/issues/142

@dandclark I recommend closing this issue

othermaciej

comment created time in an hour

PR merged WICG/open-ui

Reviewers
Add light dismiss to listbox controller

Per the discussion in #137, implementing light dismiss for the <select> listbox is not trivial because relying on focusout causes the listbox to be collapsed when non-focusable content inside a listbox is clicked. However, for our current set of examples this behavior doesn't come up except in for the split-button example, where there is a non-focusable divider. It turns out that this closes the listbox in the real Bootstrap split-button though, so it seems fine to match that behavior.

Aside from that issue, adding light dismiss makes the examples behave a lot more like "real" <select>s.

Note that this doesn't affect the filter example because it implements its own dropdown and prevents event propagation, so it would need to implement its own light dismiss.

+63 -7

1 comment

5 changed files

dandclark

pr closed time in a day

push eventWICG/open-ui

Daniel Clark

commit sha 327422e16ff41e8a38b61b551cf6c6980471c674

Add simple light dismiss behavior to controller

view details

Daniel Clark

commit sha c134a5e75597112c3e09f72d83850969149b24c4

Update 'Gap' for light dismiss

view details

Greg Whitworth

commit sha 0ffd7ce3e9341f75fdb64865eddc176e38077de1

Merge of changes

view details

Greg Whitworth

commit sha 9c88d555bf75cf3eb7aabd68aba6661f9f604eda

Merge in light dismiss

view details

Greg Whitworth

commit sha bb0311965d32aa9d3348eab814aec59d0150a9a4

Merge branch 'dandclark-dandclark/components-select-listbox-blur' into components

view details

push time in a day

push eventWICG/open-ui

Melanie Richards

commit sha 9ba0290c61921f221a8a5bc80383b118f97bdfae

Add information for 2020.07.30 telcon (#147)

view details

push time in a day

PR merged WICG/open-ui

Reviewers
Add information for 2020.07.30 telcon
+30 -4

0 comment

1 changed file

melanierichards

pr closed time in a day

pull request commentWICG/open-ui

feat(concept): allow to collapse concepts sections

@assuncaocharles ok, so now I can expand/collapse them all but I'd expect to be able to collapse them all and then upon click of a single title it would expand that one. Currently the only way to see one I have to expand all of them.

assuncaocharles

comment created time in a day

pull request commentWICG/open-ui

feat(concept): allow to collapse concepts sections

Sorry for the delay Charles I'm on holiday visiting family. I'll take a look at this later this week. Thanks.

Sent via the Samsung Galaxy S10+, an AT&T 5G Evolution capable smartphone Get Outlook for Androidhttps://aka.ms/ghei36


From: Charles Assunção notifications@github.com Sent: Sunday, August 2, 2020 11:41:12 PM To: WICG/open-ui open-ui@noreply.github.com Cc: Greg Whitworth gregwhitworth@outlook.com; Mention mention@noreply.github.com Subject: Re: [WICG/open-ui] feat(concept): allow to collapse concepts sections (#144)

Does it work for you @gregwhitworthhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgregwhitworth&data=02|01||95bede44ef9e42d7700708d837809834|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637320372724779412&sdata=TtdwssgOYWD6YCaeo8075nWD1%2BqwWivmpVNBu1nhcXE%3D&reserved=0 ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Fopen-ui%2Fpull%2F144%23issuecomment-667862588&data=02|01||95bede44ef9e42d7700708d837809834|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637320372724789417&sdata=kjn3sO%2ByKMd7XzeeDkuyFYIPi7KZv7%2FgjDCQZTc32g8%3D&reserved=0, or unsubscribehttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAGTHXGAEBVB5UBSTW4KOSLR6ZSZRANCNFSM4PHT3LQQ&data=02|01||95bede44ef9e42d7700708d837809834|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637320372724799399&sdata=jzsCeI%2F5hTUwBaargh%2FidyefNsQGFjTJvW0%2BU9g%2FMPM%3D&reserved=0.

assuncaocharles

comment created time in 2 days

push eventWICG/open-ui

Melanie Richards

commit sha 0166d1a34f9ef7056373c8c3968dfaf1c2b99166

Update historical attendee data (#146)

view details

push time in 7 days

PR merged WICG/open-ui

Reviewers
Update historical attendee data

Adding myself as an attendee for the past couple telcons, mostly for my own reference. Apologies, this is a bit goofy of a PR!

+2 -0

0 comment

2 changed files

melanierichards

pr closed time in 7 days

issue commentMicrosoftEdge/MSEdgeExplainers

Opt-in for `<select>` customizability

From the beginning I've been in favor of having new elements for the new controls as it also allows us to keep some native ones and specific needs for certain capabilities (window escape, etc). As we discussed in our explainer I'm also a fan of the built-in parts, while maybe leveraging WC parts under the hood being elements themselves as well so it is 100% apparent what is standard/ships with the UA and what is user land code.

I think this is a good discussion for WHATWG as I want to raise the open state discussion as well and that should only hang off the element that is decided here? Is there a reason this discussion should remain here @dandclark ?

dandclark

comment created time in 7 days

issue commentMicrosoftEdge/MSEdgeExplainers

<select> anatomy seems Windows-centric

@othermaciej I agree that Open UI we should re-litigate the anatomy part name, that said we're doing it across all platforms, component libraries, etc - not just OS nor browser vendors. Also, the anatomy can support the scroll wheel because that is a behavior and style applied to the listbox (insert your preferred name here) but doesn't change the model nor actually the anatomy. I actually built a demo today to show tomorrow that had the list wheel but didn't have time to put in the touch items but again it's feasible given the shown window is effectively a fixed position window with the list of options in the scroll wheel.

othermaciej

comment created time in 7 days

push eventWICG/open-ui

Greg Whitworth

commit sha fa12444589f2c0e242d5acf42bc1412cf356d5b4

Added radial display example

view details

push time in 7 days

push eventWICG/open-ui

Greg Whitworth

commit sha aee81c59c29472d0eb90c8ca16addd448de7b613

Clarified vision statement (#135)

view details

push time in 7 days

delete branch WICG/open-ui

delete branch : gwhit-vision-clarification

delete time in 7 days

PR merged WICG/open-ui

Reviewers
Clarified vision statement

Based on our discussion, I have created a PR that tries to provide clarity for Open UI.

+13 -46

1 comment

1 changed file

gregwhitworth

pr closed time in 7 days

pull request commentWICG/open-ui

Clarified vision statement

I'm going to land this since this keeps the spirt of the current vision but is simplified down and Levi has provided feedback offline.

gregwhitworth

comment created time in 7 days

pull request commentWICG/open-ui

Add light dismiss to listbox controller

this will be discussed in this weeks telecon, I'll finish review following that call

dandclark

comment created time in 8 days

pull request commentWICG/open-ui

feat(concept): allow to collapse concepts sections

@assuncaocharles thank you so much for taking the time to do this. Can you make it so that they are hidden by default or have a collapse/expand all as well?

assuncaocharles

comment created time in 8 days

issue commentWICG/open-ui

Should <select> anatomy include type-to-search?

@dandclark this was discussed in 104 and there was agreement to do this as every solution does this in some way. I'd recommend a concrete proposal for the default type ahead (this may need to be UA defined).

Also, I'd recommend also resolving that the anatomy should have an input since it takes user keyboard input. So I think the proposal would be:

  1. Concrete proposal for default type ahead (eg: does it filter by default, if not how will that be done?)
  2. Input should be in the anatomy rather than a button alone (given research)
dandclark

comment created time in 8 days

push eventWICG/open-ui

Greg Whitworth

commit sha 842694d85b079719d4d1a4820555db56498d5e58

Create chair-meeting.md

view details

push time in 8 days

push eventWICG/open-ui

Greg Whitworth

commit sha 530b0e1cbcea4bcfc9b933fce65372df5331b5fe

Create 2020-07-30.md

view details

push time in 8 days

issue commentLeaVerou/css-almanac

[meta] Value utilization

When was this code written? How does it handle custom properties?

Oh goodness, I started writing it years ago and then @fremy came in and gave it some well needed re-factoring . I started writing it roughly 5 years ago I supposed. And yeah, some of the more complex prop/value types have custom methods so conic gradient probably got eaten up by that. There is no perfect solution to this unfortunately. This is why unit testing was added because we'd fix one part of the parser and then break another.

Custom prop support was added but I believe it will only capture the var() utilization for the property that it is attached to. Custom property authoring was itself was not given any special treatment.

gregwhitworth

comment created time in 12 days

issue commentLeaVerou/css-almanac

Value utilization

It's to normalize values but ALL of them generically following the syntax spec (more or less). While looking through some of the issues there are one off investigations into specifics about a specific value type; which is fine but it would be good to have a general rundown as well as often you don't know the specific question to ask up front but they do arise (eg: are percentages used in margin-left on top websites?). You then can have custom ones that you want to pivot on for certain props but it gives you a good starting point for all props rather than the specifics of only a few. The site is no longer up but this is similar to what we shipped for CSS Usage, you can see it briefly here at minute 10 detailing how we determined which -webkit-appearance values to implement: https://noti.st/gregwhitworth/videos/s4O7wk

Once we had that then other questions came up, such as - is this property used inside of a keyframe? Which you can then tie together as that will build off of the above.

The source for that is here: https://raw.githubusercontent.com/MicrosoftEdge/css-usage/master/cssUsage.src.js

You can take that, paste it into your console and upon completion look at window.CSSUsageResults JSON object to understand how CSS was used on that page. For example, here is your home page: https://gist.github.com/gregwhitworth/6cf0db21b0d63468a40192b5be9fc742

If you then aggregate that across http-archive you're able to have a solid understanding of what is being used without actually having a specific question to ask yet but may be surprised to see (eg: -moz such and such is growing over time, maybe we should consider standardizing that, etc). Some things that are in that script but weren't surfaced on the site (due to not having time) are at-rules and normalized selectors. The next item we were going to tackle was HTML attributes and combining those with styles (which was a common investigation for a11y).

Hope that helps :/

gregwhitworth

comment created time in 14 days

issue openedLeaVerou/css-almanac

Value utilization

While it may be obvious, I've historically found value utilization valuable in a normalized manner for browser vendors, interested web devs as well as standards folks. What I mean by normalization is to remove down to the unit. Francois and myself did a lot of work here because many people report on say the utilization of a property (eg: Chromestatus) but we found a lot of value in the value. So we would normalize them to parans, units, keywords. So for color you would see something like this:

  • system color (you may want to break this down but initially just this keyword is of value)
  • hex
  • rgba()
  • rgb()
  • hsl()
  • custom property

The units become valuable, say for example percentages used in the margin and padding properties :)

created time in 14 days

issue commentw3c/csswg-drafts

[META] Presentation regarding Open UI

Placing it initially on Thursday, I'd like to do it first thing in the morning as I'll be visiting with family.

gregwhitworth

comment created time in 14 days

issue openedw3c/csswg-drafts

[META] Presentation regarding Open UI

Opening an issue so it can be tracked for the virtual F2F. Based on this recent issue #5187 as well as this discussion regarding Microsoft's password reveal proposal.

I'd like to present on behalf of the Open UI CG with our planned approach on improving the form control story on the web.

Given how packed these meetings normally are I'll probably give a blazing fast run through and then leave 30 minutes for questions/comments.

I probably should have given this presentation earlier as I did with the Aria WG to illuminate the mission and best manner to engage between the groups as there will be impact on one another.

created time in 14 days

push eventWICG/open-ui

Charles Assunção

commit sha 69c3c33661fc3aba03376877412d70f18ae389a7

feat(research): add skeleton research (#131) * feat(research): add skeleton research * fix(layout): conditionally frontmatter access * feat(skeleton): fix image src

view details

push time in 15 days

PR merged WICG/open-ui

Reviewers
feat(research): add skeleton research

Add Skeleton research page

+111 -4

1 comment

26 changed files

assuncaocharles

pr closed time in 15 days

issue commentw3c/csswg-drafts

Allow specifying the "accent color" of a form control element

I went ahead and glanced at component libs across the web as well and here are the results.

Every single one that I can find allows some type of complete theme change. This is somewhat similar to prefers-color-scheme in the platform but it allows you to denote specific ones (primary, secondary, danger, etc). There are a few that allow you to pass in specific params or even select a custom color to override the where that color is used in the component (similar to accent color above) but only Material has the color helpers to ensure color contrast. Based on what I've seen from the component libraries and how the themes work you select a single color and the control adjusts accordingly while ensuring contrast. This aligns with what @heycam proposes with regards to specifying it in a way that the UA will do the color math based on the accent color as that is what the author is going to desire.

Now, designers commonly don't desire true black or white and so I can see them wanting to be able to control the foreground color. If it isn't a lot of additional impact on implementation I would specify something like for both foreground and background.

If accent-color-foreground computes to auto and accent-color-background computes to a CSS color then the user agent MUST use a color that meets the WCAG minimum contrast requirements of 4:5:1

This will achieve what @heycam denotes above while also allowing designers that want to still adhere to the WCAG but possibly in their own way do so.

chrishtr

comment created time in 15 days

issue commentWICG/open-ui

Make <select> change to closed state when focus leaves listbox

@dandclark out of curiosity is there a need for a blur type event that bubbles? Should we possibly propose one to WHATWG?

dandclark

comment created time in 15 days

issue commentWICG/open-ui

Create better landing page

@levithomason from the beginning have had a desire to be able usable by anyone (whether they work in web or not). Currently however all content is web focused we want to leave the door open for potential contributions to make specs tailored to folks that may be building out controls/components on other platforms. So let's make the subheading be:

The missing industry standard definition of UI

As I noted in the Figma item, I'd like to see this comp initially show how it helps designers vs developers. Maybe this could be two button type toggle that is on each component and mirrored on the sub page specs.

The difference between the components under analysis and proposals is that analysis is solely research that has been collated for the component. As the component moves to proposal this moves up to the right hand side of the proposal to allow someone to still get at this research but alleviate confusion on their being to components with the same name just under different categories.

Overall it looks great, thanks taking this on.

gregwhitworth

comment created time in 15 days

issue commentWICG/open-ui

Create better landing page

@ststimac it got sucked in by a rule :) Thanks

gregwhitworth

comment created time in 15 days

issue commentWICG/open-ui

Create better landing page

@ststimac hey what's the update on this?

Also, @levithomason and I were chatting and as you've seen regarding the Figma comps there are more than one demo that are beginning to reference Open UI. Right now the specs are heavily leaning towards developers (whether FE, component authors, or browser implementers) but it would be good for the landing page to call attention to the various benefits Open UI brings to each.

  • Developer: "Some fancy words about how it's the definitive solution blah blah"
  • Designer: "Leverage design tool kits to design alongside your developers with the same expectation of states, terminology, bla blah"

This could change the overall design of the specification itself to be more designer friendly rather than a bunch of events it could focus on the anatomy, use cases, and links to figma/sketch, etc. It would be good to be able to toggle this on the spec page as well.

gregwhitworth

comment created time in 15 days

issue commentWICG/open-ui

Concepts component should collapse and expand the examples

@assuncaocharles any chance you might be able to take a look at fixing this? You seem pretty knowledgeable with react.

gregwhitworth

comment created time in 15 days

issue commentWICG/open-ui

Updating component definitions

Awesome, assigning over to you then @janechu

janechu

comment created time in 15 days

issue commentWICG/open-ui

Make <select> change to closed state when focus leaves listbox

I think it would be better to consider this a blocker for Open UI, as a matter of accessibility w/r/t mobility (e.g. someone intended to click on a focusable descendent and missed the target)

I think this issue should be two fold:

  1. Should the select change the open state when a non-focusable element is invoked in the list-box subtree?
  2. If it's a 'no' for number 1, then how do we express this?

Native light-dismiss for the listbox popup should make all this "just work", but there is still the question of how to describe this behavior in the <select> anatomy tables if this is not straightforwardly possible to implement terms of JS events.

My proposal for item 2 would be to give this a name (light dismiss seems a fine strawman to me) and then define in the Open UI select spec. This will allow you to denote it simply as other JS events but link to the full definition which will probably have numerous events and how to collect the elements in the subtree of listbox.

As we know, many different specifications will take advantage of behavior definitions of popups so it may be worth having a page devoted to popups (shocker, I know 😃). Until that time comes however, we can start the definition in select.

dandclark

comment created time in 15 days

issue commentWICG/open-ui

Make <select> change to closed state when focus leaves listbox

I think it would be better to consider this a blocker for Open UI, as a matter of accessibility w/r/t mobility (e.g. someone intended to click on a focusable descendent and missed the target)

I think this issue should be two fold:

  1. Should the select change the open state when a non-focusable element is invoked in the list-box subtree?
  2. If it's a 'no' for number 1, then how do we express this?

Native light-dismiss for the listbox popup should make all this "just work", but there is still the question of how to describe this behavior in the <select> anatomy tables if this is not straightforwardly possible to implement in terms of JS events.

My proposal for item 2 would be to give this a name (light dismiss seems a fine strawman to me) and then define in the select spec. This will allow you to denote it simply as other JS events but link to the full definition which will probably have numerous events and how to collect the elements in the subtree of listbox.

As we know, many different specifications will take advantage of behavior definitions of popups so it may be worth having a page devoted to popups (shocker, I know 😃). Until that time comes however, we can start the definition in select.

dandclark

comment created time in 15 days

Pull request review commentWICG/open-ui

feat(research): add skeleton research

     },     {       "name": "Shimmer",-      "url": "https://developer.microsoft.com/en-us/fabric#/controls/web/shimmer"+      "openUIName": "Skeleton",+      "url": "https://developer.microsoft.com/en-us/fabric#/controls/web/shimmer",+      "concepts": [+        {+          "name": "default",+          "image": "fabric-shimmer-basic.png"+        },+        {+          "name": "default",+          "image": "fabric-shimmer-basic-elements.png"+        },+        {+          "name": "variations",+          "image": "fabric-shimmer-basic-variations.png"

this one is rendering broken due to being undefined:

An image of the variations concept on a Skeleton component in UI Fabric.

assuncaocharles

comment created time in 15 days

push eventWICG/open-ui

Makoto Morimoto

commit sha 986567c2759793c6c4b3b2056e664989254d3ece

Fixing component name matrix regex to correctly group items that end with 'e' or 'er'. (#128)

view details

push time in 15 days

PR merged WICG/open-ui

Reviewers
Fixing component name matrix regex to correctly group items that end with 'e' or 'er'

Components whose names ended with "e" or "er" where not grouped together with their plural counterpants because of an error in the regex. This PR fixes that issue.

Before:

image

image

After:

image

image

+5 -5

0 comment

1 changed file

khmakoto

pr closed time in 15 days

push eventWICG/open-ui

Charles Assunção

commit sha 2174a6c7fa52c90a0ef7db374fbba7eab5f08305

fix(image): fix property typo (#130)

view details

push time in 15 days

PR merged WICG/open-ui

Reviewers
fix(image): fix property typo

property srcset throws console error since the expected property is srcSet

Screenshot 2020-07-17 at 09 35 01

+1 -1

1 comment

1 changed file

assuncaocharles

pr closed time in 15 days

push eventWICG/open-ui

Greg Whitworth

commit sha b75e622c97234e97f3576671e1c60f84957d033f

Update CODEOWNERS Updating based on project blending together.

view details

push time in 15 days

push eventWICG/open-ui

Esteban Munoz

commit sha 48c29df4c288dfdc96de2c4941f49852558219f8

Updating Bootstrap and Primer documentation to include their use of Flex (#124) * updating Flex for bootstrap and primer * adding description

view details

push time in 15 days

PR merged WICG/open-ui

Reviewers
Updating Bootstrap and Primer documentation to include their use of Flex

Updates Bootstrap and Primer to show the Flex component.

+10 -1

1 comment

2 changed files

sopranopillow

pr closed time in 15 days

push eventWICG/open-ui

Makoto Morimoto

commit sha 36b676576b1508c28291ee52eaba39e1273a1e55

Adding research page for the Card component (#134) * Adding card research page and updating Ant Design's card information. * Updating Bootstrap's card information. * Updating Fast DNA's card information. * Updating Lightning's card information. * Updating Material's card information. * Updating Semantic UI's card information. * Updating Stardust's card information. Co-authored-by: Greg Whitworth <865244+gregwhitworth@users.noreply.github.com>

view details

push time in 15 days

PR merged WICG/open-ui

Reviewers
Adding research page for the Card component

This PR adds a research page for the Card component with images/examples from all the libraries that support such a component.

+397 -34

0 comment

97 changed files

khmakoto

pr closed time in 15 days

push eventkhmakoto/open-ui

Chris Holt

commit sha 126c6b489fdfa97ac7607774c83c7d6cd9cbd039

feat: update FAST to reference latest web components (#136)

view details

Greg Whitworth

commit sha 1b0a82114cccd7ccad88f769ec6f24a67cc2bb66

Merge branch 'master' into cardResearch

view details

push time in 15 days

push eventWICG/open-ui

Chris Holt

commit sha 126c6b489fdfa97ac7607774c83c7d6cd9cbd039

feat: update FAST to reference latest web components (#136)

view details

push time in 15 days

delete branch WICG/open-ui

delete branch : users/chhol/update-fast-references

delete time in 15 days

PR merged WICG/open-ui

Reviewers
feat(research): update FAST to reference latest web components

This PR updates the FAST controls to reference and illustrate the latest FAST design system and changes instances of FAST-DNA to FAST. As some controls are either incomplete or no longer exist, I have removed those from the component name matrix. As those controls are completed, we'll include them again as part of the research.

+29 -221

2 comments

16 changed files

chrisdholt

pr closed time in 15 days

pull request commentWICG/open-ui

feat(research): update FAST to reference latest web components

As you know due to our offline discussion, but for anyone else that may stumble across this PR - please join the WICG and have your AC rep approve cc: @travisleithead

chrisdholt

comment created time in 15 days

issue closedWICG/open-ui

Page title element missing from the Open UI website

<head> section of the HTML documents on the open-ui.org website lacks <title> element.

Even while seo.js component has a title={title} in it, for some reason it does not get rendered to the HTML output.

        return (
          <Helmet
            htmlAttributes={{
              lang,
            }}
            title={title}  // NOTE: this element is missing

In any case, rest of the sites feels fast & usable. 👍

closed time in 16 days

d2s

issue commentWICG/open-ui

Page title element missing from the Open UI website

This is done, thanks for filing

d2s

comment created time in 16 days

issue closedWICG/open-ui

Pages on https://open-ui.org/ are missing titles

View source on https://open-ui.org/

Actual: <title data-react-helmet="true"></title> Expected: <title data-react-helmet="true">Open UI</title>

All of the pages on the Open UI website seem to have this problem.

closed time in 16 days

dfabulich

issue commentWICG/open-ui

Pages on https://open-ui.org/ are missing titles

This is completed.

dfabulich

comment created time in 16 days

PR opened WICG/open-ui

Reviewers
Clarified vision statement

Based on our discussion, I have created a PR that tries to provide clarity for Open UI.

+13 -46

0 comment

1 changed file

pr created time in 16 days

push eventWICG/open-ui

Greg Whitworth

commit sha bd5eb6a3ff39f6c68dd34b928a9c5e0853bbeba0

Clarified vision statement

view details

push time in 16 days

create barnchWICG/open-ui

branch : gwhit-vision-clarification

created branch time in 16 days

push eventWICG/open-ui

Charles Assuncao

commit sha 236ea555454e401255549d04eb8884ecc0a7ef96

fix(layout): conditionally frontmatter access

view details

Greg Whitworth

commit sha b8ae6b649567f54113d6a22e3d0d50185a0f85f7

Merge branch 'assuncaocharles-fix/layout'

view details

push time in 16 days

PR merged WICG/open-ui

Reviewers
fix(layout): conditionally frontmatter access

Page 404 there's no frontmatter what is breaking the build in master and the access to the custom 404 page.

+1 -1

1 comment

1 changed file

assuncaocharles

pr closed time in 16 days

issue commentWICG/open-ui

Add some new component libraries?

@melanierichards while we're focusing on web tech, we often do look at native platforms and we've heard folks from Windows are beginning to use this. When we get to the events and states we'll probably have to be specific to web libraries but I think if any native component library is able to be ingested that would be valuable as well. Also, I'd like to see Ionic included as well.

melanierichards

comment created time in 19 days

issue commentmicrosoft/fast

Selects in Modals do not escape Dialog

@melanierichards

connorjsmith

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD++## How we teach this++TBD++## Unresolved questions++- Do we want to support all the existing `script` tag attributes like `type`, `async` and `defer`?

are there any downsides to doing this? I'd prefer to not have to go implement any of what you just outlined and given that this is effectively a privileged script tag I can see authors adding in those attr thinking they'll work.

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:

I think this paragraph could be re-worded. You ask two questions and then follow it with bullets. Would something like this work?

To ensure we can solve the problem while continuing to guarantee the benefits that are provided by the synthetic-shadow polyfill for all other components, we are currently proposing the following characteristics for the secure-script design:

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps

How are we ensuring that the scripts are indeed secure? If we aren't doing anything to secure the script (eg: an allow list of approved scripts) then we should possibly make this <lwc-script> or something similar?

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD

Is the expectation that the admin will click an application/extension for their site to add Google Analytics (for example) and it will be added by us into the secure-script? Or will the admins/devs place secure-script themselves and it may happen to be Google Analytics, Evergage,etc.

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD++## How we teach this++TBD

I'll have more opinions on this following the answer to my question on adoption strategy

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

Secure script container

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.

mis-spelling: ligh -> light

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD++## How we teach this++TBD

I'll have more opinions on this following the answer to my question on adoption strategy

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD

Is the expectation that the admin will click an application/extension for their site to add Google Analytics (for example) and it will be added by us into the secure-script? Or will the admins/devs place secure-script themselves and it may happen to be Google Analytics, Evergage,etc.

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps

How are we ensuring that the scripts are indeed secure? If we aren't doing anything to secure the script (eg: an allow list of approved scripts) then we should possibly make this <lwc-script> or something similar?

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:

I think this paragraph could be re-worded. You ask two questions and then follow it with bullets. Would something like this work?

To ensure we can solve the problem while continuing to guarantee the benefits that are provided by the synthetic-shadow polyfill for all other components, we are currently proposing the following characteristics for the secure-script design:

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.

mis-spelling: ligh -> light

tedconn

comment created time in 21 days

Pull request review commentsalesforce/lwc-rfcs

feat: secure script container RFC

+---+title: Secure Script Container+status: DRAFTED+created_at: 2020-07-15+pr: https://github.com/salesforce/lwc-rfcs/pull/38+champion: Caridy Patiño, Ted Conn+---++# Secure Script Container for LWC Apps++## Summary++We need a way for application developers to integrate common third-party libraries into their LWC applications. These libraries, such as Google Analytics, are severely hindered by the shadow DOM which prevents global interaction with any element on the page.++By providing a secure container for scripts to run, see, and interact with all the shadow DOM trees as if it were the light DOM, application developers can continue to run their existing integrations until these libraries support shadow DOM semantics natively.++## Basic example++```html+<secure-script src="//cdn.optimizely.com/js/12345678.js"></secure-script>+```++`secure-script` is a custom element which acts the same as the `script` tag, but any code which is evaluated inside this container is able to traverse the entire shadow tree using ligh DOM semantics. So if the above script runs `document.querySelectorAll('button')`, it will return all button elements regardless if they are in the shadow or not.++```html+<secure-script>+    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){+    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),+    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)+    })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');++    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</secure-script>+```++Inline scripting would also be supported, such as the above example which uses script injection to fetch its required resources.++## Motivation++Web component applications need the ability to integrate with third party libraries. Because+web components rely on the shadow DOM for encapsulation, this development paradigm does not work+with libraries who are expecting to interact with the application globally. Before there was+component encapsulation via shadow DOM it was possible for library authors to:++- Listen for events and know who fired them+- Define global styling rules that would get applied on every element+- Query the entire document for any element on the page++These libraries are typically added as global scripts to the document root rather than deeper +integrations into the components themselves. When every component's root element is a shadow+root, there is no light DOM for them to work with, and their functionality is severely crippled.++Some examples of these libraries are:++- **Analytics tools**: Google Tag Manager / Google Analytics, Pendo+- **Personalization platforms**: Optimizely, Evergage, Google Optimize+- **Instrumentation tools**: New Relic, Sentry.io++In addition, developers are finding that this model is not compatible with their **design systems** and **testing frameworks**.++The goal of this proposal is to provide a way for application developers to continue to use their existing integrations until library authors can support web component based applications.++## Design++`secure-script` will solve for the synthetic shadow and subsequently the native shadow.++### Synthetic Shadow+Many LWC applications apply the [synthetic-shadow polyfill](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/). This polyfill emulates the native shadow behavior while still allowing global styles to cascade into the shadow trees. Synthetic shadow currently [patches](https://github.com/salesforce/lwc/tree/master/packages/%40lwc/synthetic-shadow/src/polyfills/document-shadow) the `document.querySelector` and `document.querySelectorAll` APIs which is what prevents developers from penetrating the shadow DOM boundaries either in their LWC components or any other scripts added to the document. We only want to solve for the latter scenario.++Ok, so what if we store a reference to the original, unpatched APIs before they get patched by our polyfill? And we let *only* our "secure scripts" access those APIs? That's the premise of this approach for synthetic shadow:++* Create a secure JS sandbox which doesn’t allow its object graph to be extended using [`Object.preventExtensions`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/preventExtensions)+  * The sandbox is created using a same-domain iframe provided by Locker v.Next+  * This has to be done before the synthetic shadow is imported++* Run or include the third party library script inside this sandbox+  * This allows the code to run in a non-patched environment, while the rest of the document is running synthetic shadow+* Package the above functionality in a web component which semantically matches the `<script>` tag.+++### Native Shadow++For applications which are using the native shadow, the underlying implementation will be different. There are two approaches we can choose from:++1. Virtualize every shadow DOM tree in the outer window into a single DOM structure which this container would see as the default DOM.+2. Implement a `document.querySelector` API which traverses the shadow DOM naturally.++### Globals++Some scripts define globals which are meant to be used by the rest of the application. Let's take this example of Google Analytics:++```html+<!-- Google Analytics -->+<script>+    window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;+    ga('create', 'UA-XXXXX-Y', 'auto');+    ga('send', 'pageview');+</script>+<script async src='https://www.google-analytics.com/analytics.js'></script>+<!-- End Google Analytics -->+```++If we included the above snippet inside our secure-script container, then `ga` will only be available to the *inner* `window`, i.e. the secure container's window. So `ga` will not be usable by anyone else in the entire application. We can however, allow for globals to be created inside our secure container, and redefined in any additional application sandboxes created by Locker (or the global outer window).++A syntax like the following could be provided:++```html+<secure-script extra-globals="ga"></secure-script>+```++### Known Limitations++* Currently there is an outstanding issue with synthetic shadow in that the Event object patching happens lazily, so we are unable to prevent its patching at the time of creating the secure container, which means that events are still retargeted. [See LWC PR #1569](https://github.com/salesforce/lwc/pull/1569).+++### Testing++We will want to gather the top 20 common libraries and implement their behavior inside of `secure-script` to ensure that we are prooperly accounting for all these libraries' use cases. This will be our integration test suite. ++### Prototype Code++```js+import createSecureEnvironment from '@caridy/sjs/lib/browser-realm';++// creating the new sandbox with all global endowments+const evaluate = createSecureEnvironment(+    undefined,+    window,+);++evaluate(`+    // This initialization will prevent any of these APIs to be polyfilled+    // on the blue realm that can affect this sandbox.+    const pE = Object.preventExtensions;+    pE(HTMLElement.prototype);+    pE(Element.prototype);+    pE(Node.prototype);+    pE(Event.prototype);+    pE(Document.prototype);+    pE(EventTarget.prototype);+    pE(MutationObserver.prototype);+    pE(HTMLCollection.prototype);+    pE(NodeList.prototype);+    pE(ShadowRoot.prototype);+    pE(HTMLSlotElement.prototype);+    pE(Text.prototype);+`);++class SecureScript extends HTMLElement {+    connectedCallback() {+        const src = this.textContent;+        if (src) {+            evaluate(src);+        }+    }+}++customElements.define('secure-script', SecureScript);+```++## Drawbacks++- We are potentially prolonging the life of our synthetic shadow dom polyfill, instead of encouraging community library authors to adopt shadow DOM semantics.+- The element may end up being anywhere from 5kb - 20kb.++## Alternatives++- **Allow shadow DOM to be toggled at a more granular level.** There is a forthcoming RFC for allowing component authors to decide if they want to opt in to shadow DOM or not. This would mean we can keep top-level elements and layout components in the light DOM, but base components or managed components can choose to safeguard their internals. Until we allow this, `secure-script` serves as a mitigation for application developers looking to add third party libraries to their apps.+- Do not apply the shadow DOM polyfill at all: this would allow component authors to violate shadow DOM encapsulation which is not an option.+- If we don't do this, then companies / websites building on our platform will not be able to integrate with common third party libraries.++## Adoption strategy++TBD++## How we teach this++TBD++## Unresolved questions++- Do we want to maintain parity with the `script` element including supporting attributes like `type`, `async` and `defer`? If so can we just extend [`HTMLScriptElement`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement)? 

are there any downsides to doing this? I'd prefer to not have to go implement any of what you just outlined and given that this is effectively a privileged script tag I can see authors adding in those attr thinking they'll work.

tedconn

comment created time in 21 days

push eventWICG/open-ui

Dan Clark

commit sha 7c82a29bcde0c6daaf2913580788e203be937baf

Update sync split-button example with changes in Explainer doc (#125) * Move part='button' to the arrow element, add slot/part to listbox, fix typo in CSS class * Move button keypress and click handlers from the slot to the button part. With this change, the split-button no longer needs to preventDefault to make only the arrow section of the button open the listbox. * Change split-button listbox style so that the current option is highlighted instead of watching for checked. This way there's a visual indicator when using up/down arrows to select a value. * Move listbox controller code from the listbox-container slot to the listbox part. Refactor so that the same functions are used to apply controller code to both the default parts and the user-supplied parts, to ensure that these remain consistent. * Use single quotes to be consistent with the surrounding code * Make the text half of the button focusable, and update the focus ring style to match behavior at https://getbootstrap.com/docs/4.0/components/dropdowns/#split-button-dropdowns

view details

push time in 22 days

PR merged WICG/open-ui

Reviewers
Update sync split-button example with changes in Explainer doc

Update select implementation so that the controller code is applied to the button and listbox parts directly, rather than using the <slot>s.

Refactor so that the same code adds controller functionality to both the default parts and to the user-replaced parts, which should make it easier to keep these in-sync.

In the split-button example:

  • Remove the preventDefault that was keeping mouse clicks from working on the left half of the button, and achieve this functionality instead by moving `part='button' to the arrow element.
  • Add slot/part to listbox.
  • Fix typo in CSS class.
+1060 -1001

0 comment

8 changed files

dandclark

pr closed time in 22 days

issue commentWICG/open-ui

Pages on https://open-ui.org/ are missing titles

I've pushed a commit for this but for some reason it's not showing up, hopefully @levithomason can shed some light on this but it will get addressed shortly.

dfabulich

comment created time in 24 days

IssuesEvent

push eventWICG/open-ui

Greg Whitworth

commit sha 75f67ddb7e0e74a5cb648e5a9ad33955a40aecac

Removed console.log

view details

push time in 24 days

push eventWICG/open-ui

Greg Whitworth

commit sha 2cca48ae7ba632222a90a80ae739fcac9698f57c

Added title to pages. Fixes #120

view details

push time in 24 days

issue closedWICG/open-ui

Pages on https://open-ui.org/ are missing titles

View source on https://open-ui.org/

Actual: <title data-react-helmet="true"></title> Expected: <title data-react-helmet="true">Open UI</title>

All of the pages on the Open UI website seem to have this problem.

closed time in 24 days

dfabulich

issue commentWICG/open-ui

Updating component definitions

This sounds like a great idea! Our JSON schema is in the repo, any chance you can submit a PR for the documentation. We can start having the active Open UI group participants prepare their libs.

janechu

comment created time in 24 days

issue closedWICG/open-ui

testing sync

I'm trying to sync with my kamban board. I'll close this shortly.

┆Issue is synchronized with this Trello card by Unito

closed time in 24 days

gregwhitworth

Pull request review commentWICG/open-ui

Update sync split-button example with changes in Explainer doc

 <h1>Select - Open UI Bootstrap Split Button Styles</h1>        support for the option parts.</p>          <oui-select>-            <div slot="button-container" part="button">+            <div slot="button-container">               <div class="select-label">Primary</div>-              <div class="arrow" aria-label="toggle dropdown"></div>+              <div class="arrow" part="button"></div>

By moving this here - this results in the part="button" receiving focus which breaks the focus ring solution of the slot=button-container working as expected. This is where things can get interesting because you'll want focus to land on the container and this will invoke the popup which applied the focus styles. So it the container behaves with keyboard/focus as part="button" but the text is not clickable. This is why I had the slot being the part="button". You can see the example dropdown here: https://getbootstrap.com/docs/4.0/components/dropdowns/

It's about halfway down and blue with the work primary. I think you'll need to add the script code back and move part back to the slot.

dandclark

comment created time in 24 days

issue commentmicrosoft/fast

Selects in Modals do not escape Dialog

@chrisdholt we're actively working on an explainer for this. This isn't an Open UI issue but a CSSWG one. The explainer's are being iterated on it will introduce a new stacking context. Still things to flush out - but yes this is being worked on. When the explainer goes public I'll post it here for feedback.

connorjsmith

comment created time in a month

issue commentmicrosoft/fast

Selects in Modals do not escape Dialog

@robpaveza is this within an iframe or is one of the ancestors set to overflow: hidden?

connorjsmith

comment created time in a month

issue commentWICG/open-ui

testing sync

testing now that I'm back to member

gregwhitworth

comment created time in a month

issue openedWICG/open-ui

testing sync

I'm trying to sync with my kamban board. I'll close this shortly.

created time in a month

push eventWICG/open-ui

Greg Whitworth

commit sha 84db5f34b57b5ec57efaf12f184e3d6abb9be79b

Fixed open attr issue

view details

push time in a month

issue openedw3c/csswg-drafts

Define a way to have a dialogue anchored to an element

<dael> TabAtkins: If we ever do want to attach to an element some mech is the thing being used to position non-anchor dialogs. If we switch non-anchor to fixedpos we have to figure out how to do it for non-anchored.

<dael> iank_: I think a different solution for anchoring down the road

I think we should open a separate issue for this because authors do want this capability outside of the specific <dialog> need (eg: tooltips, dropdown menus, etc). So this should be thought about sooner rather than later. In the research that @annevk shared there are many examples that are not centered and are anchored to an element. While I get the implementation concerns I'm also curious of making the dialog itself the scroller via overflow behavior is the right way. Most of the scenarios that come to mind however normally don't fit in what seems to be the primary definition (based on what is shipping) as a <dialogue>.

cc: @melanierichards

Originally posted by @gregwhitworth in https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-655847121

created time in a month

more