add isVisible explainer/review (#216)

* add isVisible explainer/review

Co-authored-by: Chris Harrelson <[email protected]>
Co-authored-by: Joey Arhar <[email protected]>

explainers/isvisible.md

@@ -0,0 +1,44 @@
+# Element.isVisible explainer
+
+The web features several ways that content can be hidden. Each of the ways may
+have distinct characteristics and are used for different purposes:
+
+* `visibility: hidden`: this hides the element visually but keeps its layout box and allows for the descendant to
+  make itself visible. In other words, this property doesn't affect the subtree,
+  with the exception of providing the `visibility` value to be inherited by
+  descendant styles.
+* `opacity: 0`: this hides the element and its subtree visually but keeps its layout box and allows for animations
+  that fade content in or out.
+* `display: none`: this hides the element and its subtree, it also destroys
+  rendering state (removes its layout box) and makes the DOM subtree not take up any time while
+  processing rendering.
+* `content-visibility: hidden`: this hides the subtree of an element, without
+  destroying the rendering state (i.e. its layout box is preserved). It also makes the DOM subtree not take up any
+  time while processing rendering, but allows for the possibility for such
+  rendering state to be forced (e.g. via calls to getBoundingClientRect). It
+  also allows the element's subtree to be shown again quicker than `display:
+  none` would allow, since `content-visibility: hidden` would preserve rendering
+  state.
+
+There are times when script wants to determine whether an element is visible to
+the user, or would be visible if it was in the viewport. This can be used for a
+variety of reasons, such as general state tracking of visibility.
+
+This can be hard to compute correctly, since the script author needs to remember to
+check all the necessary methods by which content can be hidden (including
+accounting for the fact that new methods could be added). It also is hard to do
+efficiently, since for example access into the subtree hidden by
+`content-visibility: hidden` may cause rendering work to be updated.
+
+Additionally, checking if an element is hidden by a closed shadow tree, such as
+the case with `<details>` element is difficult, if not impossible
+
+For this reason, we propose to add Element.isVisible function to compute the
+values, so that script authors may use this as a correct and efficient way to
+determine the necessary visibility. This also returns a correct value for
+elements slotted inside closed shadow trees.
+
+The spec draft for the function can be found
+[here](https://drafts.csswg.org/cssom-view/#dom-element-isvisible). Note that
+the options specified to isVisible call allow developers to customize the check
+they would like to make.

privacy-assessments/isvisible.md

@@ -0,0 +1,84 @@
+# Element.isVisible Privacy and Security Self-Review.
+
+* What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
+
+For the most part, this function exposes information that is already available
+to the page, and is retrievable by other means. The exception to this case is
+getting the value from a closed shadow tree. Specifically, if a light DOM
+element is not visible because of the structure of a closed shadow tree, this
+function would be able to return the correct result, but this result is not
+easily retrieved by other means.
+
+It is being exposed, because it is difficult to efficiently and correctly
+compute this value. The function is provided as a useful and efficient convenience. 
+
+* Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
+Yes.
+
+* How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
+The feature does not deal with such information.
+
+* How do the features in your specification deal with sensitive information?
+
+The feature does not deal with such information.
+
+* Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
+No.
+
+* Do the features in your specification expose information about the underlying platform to origins?
+
+No.
+
+* Does this specification allow an origin to send data to the underlying platform?
+
+No.
+
+* Do features in this specification enable access to device sensors?
+
+No.
+
+* Do features in this specification enable new script execution/loading mechanisms?
+
+No.
+
+* Do features in this specification allow an origin to access other devices?
+
+No.
+
+* Do features in this specification allow an origin some measure of control over a user agent's native UI?
+
+No.
+
+* What temporary identifiers do the features in this specification create or expose to the web?
+
+None.
+
+* How does this specification distinguish between behavior in first-party and third-party contexts?
+
+This feature does not make a distinction between contexts, it acts on DOM state
+already available to the page, including closed shadow trees.
+
+* How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
+This feature does not make a distinction between regular or private browsing
+contexts.
+
+* Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
+No.
+
+* Do features in your specification enable origins to downgrade default security protections?
+
+No.
+
+* How does your feature handle non-"fully active" documents?
+
+This feature does not make a dinstinction between fully active or non-fully
+active documents.
+
+* What should this questionnaire have asked?
+
+It asked all the necessary questions.