Open mcdurdin opened 3 years ago
Note: #7387 should be tackled either before this issue or at the same time; isolating the stylesheet within an OSK-wrapping shadow root will prevent page elements from receiving appropriate font-styling unless they're spun off to a separate, non-shadowed stylesheet.
Refer to https://github.com/keymanapp/keyman/pull/7694#discussion_r1021025837 for an isolated implementation of the shadow-DOM pattern as it would apply to the OSK. In particular, note that we must re-link the OSK's CSS sheet within the shadow root for it to properly receive its default formatting.
For ease of revisiting a complication with sil_euro_latin
: https://github.com/keymanapp/keyman/pull/5430#discussion_r665015352
With #10274, KMW's main build output now targets ES6. Full ES6 support for Chrome landed in v51, while Element.attachShadow()
support landed in v53.
References:
It might be worth considering this for 18.0; we're currently considering making ES6 a minimum requirement in 18.0, with this a minimal shift over the minimal requirements for ES6 as far as the Android app is concerned.
It may be notable that there's a stronger difference for Firefox:
As far as our iOS support is concerned, we're fine - Safari for iOS 10 is enough, and we already have a higher minimum requirement there.
Triaged for review in 18.0
While maintaining some things related to our documentation-keyboard functionality, I discovered another limitation possibly of note.
Some keyboards, such as sil_cameroon_azerty
, have :root
CSS rules. This only works in the main document, for the document.body
element. For Shadow DOM, the :host
selector is available instead.
For sil_cameroon_azerty
, this results in the tri-color key not receiving the tri-color effect when using Shadow DOM, as that effect is specified on :root
but not :host
.
Some keyboards, such as
sil_cameroon_azerty
, have:root
CSS rules. This only works in the main document, for thedocument.body
element. For Shadow DOM, the:host
selector is available instead.
I think we are going to have to accept that some of these keyboards have done things that we can't possibly maintain forward-compatibility for. Those keyboards will need to be updated to match new CSS rule restrictions in order to work sensibly with a theming model (and I think that is when we will look at incorporating shadow dom also). Some difficult discussions coming up.
Is your feature request related to a problem? Please describe.
https://caniuse.com/?search=shadow%20dom https://developers.google.com/web/fundamentals/web-components/shadowdom
The shadow dom is a method of establishing and maintaining functional boundaries between DOM trees and how these trees interact with each other within a document, thus enabling better functional encapsulation within the DOM & CSS. KeymanWeb's OSK could certainly benefit from this.
KeymanWeb: