-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/add shadow dom test #625
Conversation
a272b47
to
24538c3
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
24538c3
to
3c042ec
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
3c042ec
to
b8facae
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
b8facae
to
26eb1ce
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
26eb1ce
to
dc5ae93
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
which currently is only able to detect light dom and attribute changes
dc5ae93
to
56197f3
Compare
Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: diba1013.
|
Before submission, please check that ...
you updated the changelog.(not necessary)Description
The example is custom build, using guides from google developers. It features open, closed and nested shadow elements through the use of custom elements. Furthermore, it makes use of both true shadow DOM and light DOM.
The differences are introduced with a click of a button. These are designed to introduce changes to all aspects of the shadow DOM. It modifies the attributes of custom elements, light elements and through this, indirectly has effect on the shadow DOM (because of data binding).
This test does not use templates for rendering the shadow DOM, because templates might be a separate thing that we need to consider at some time in the future.
All in all, this test should suffice for most scenarios when working with shadow DOMs. Of course, almost everything is possible with the web, and we will see, if it does.
The test uses its own temp directory, because we are only interested in the actual changes, as we have no use for the generated Golden Masters right now. Secondly, it references its own filter instead of the global
recheck.ignore
to the test report all differences as expected, without changes in therecheck.ignore
having an side-effect on this test.To have a more representable example, this uses some minor bootstrap CSS, mostly the reboot and button elements. As this introduces an external dependency, I am not sure how this might affect the elements. However, we could decide to include this as a local stylesheet.
State of shadow DOM
As the introduced test shows, we currently only gather changes on the custom elements as well as the light DOM. The actual changes that happen in the shadow DOM are currently not tracked.
Based on small initial tests, it should be fairly easy™ to implement a working solution that works for open shadow roots. However, we will potentially need to discuss how we want to handle light DOM, as, although it is physically moved inside the shadow DOM, it is still accessible from the outside.
State of this PR
Due to changes that introduced pseudo-elements #623, the test does not currently have the expected result. This is only the case for the "change" button, which gets disabled once clicked. However, the Alignment gets confused by this and lists it as
inserted-deleted
element. Right now, the test shows the expected output, which differ from the actual output because of this. This can be addressed the following ways:My opinion: The test already shows that the basics are working and the bug is outside the scope of this PR. However, it would introduce a dirty commit history (i.e. a commit that has to be reverted) and since this PR is not critical, we could just leave it as a draft until scenario 2 is done.
I will add documentation so that it is clear to what extend this is working right now, as I don't see that we will implement a proper working solution for this release.
Additional Context
I would like to add this to our assets website as an example, so that it can be referenced throughout our documentation and other articles. This would allow us to remove the website from this repo and only reference it in the test.
This does not work with IE11.