Anchoring and context

When someone pins a thread, Skyelight saves an anchor so it can show the thread on the same element later. It can also save page context and a screenshot, so a developer or an agent can see what the page showed without reopening it.

How a pin finds its element again

When someone pins an element, Skyelight saves:

• a CSS selector for the element;
• where on the element they clicked, as a percentage of its width and height, so the marker lands in the same spot at any screen size;
• the viewport size, the element’s visible text, and any text they selected;
• for elements inside menus, drawers and dialogs, the control that opens them, so the marker can show on that control until the element is visible.

On sites built with Skyelight Build, elements carry a stable id that survives added wrappers and reordering. Skyelight looks for that id first and falls back to the selector.

When a pin loses its element

If an element is removed or rebuilt, its pin can show as detached. The thread and its replies stay. The thread’s author or a workspace admin can drag the marker onto the right element, and the thread notes that its screenshot and page context predate the move.

Page context

Page context is a snapshot of the markup around the pinned element. It includes the element, up to six levels of parent elements, two levels of child elements, nearby text, and the styles that apply. If the site uses Skyelight Build, the thread also records the source file, line and commit from those elements.

Page context is on by default. The browser redacts it before anything is sent:

• No value from any input, text area or select is included.
• Password and payment fields are dropped entirely, along with their labels.
• Anything inside an element marked data-skyelight-redact is left out.

To keep a region out of page context and screenshots, add the attribute to it:

<!-- customer-details.html -->
<section data-skyelight-redact>
  <!-- Customer details: never in page context or screenshots -->
</section>

Screenshots

Screenshots are off by default. When a workspace owner or admin turns them on, each new thread gets an image of the visible area around the pinned element, with the pin’s position marked. Replies never capture a screenshot.

• The image covers only the visible part of the page, never the full scrolling page, other tabs or other windows.
• Skyelight hides its own interface before capture.
• Form fields and anything marked data-skyelight-redact are covered with solid blocks before the image is cropped or stored. If masking fails, Skyelight doesn’t keep the screenshot.

The Chrome extension and the review badge take screenshots differently. The extension asks the browser for an image of the tab. The review badge redraws the page from its own content, so it never asks anyone to share their screen. In a badge screenshot, cross-origin images without CORS, iframes, canvases and video appear blank.

Who can see screenshots and page context

Everyone in the workspace can see a thread’s screenshot and page context, at any role. A reviewer using the review badge can reach only the project that site belongs to. Slack posts never include screenshots.

How long screenshots and page context are kept

Skyelight keeps screenshots and page context for 12 months from capture, or 30 days on the Free plan. The web app has no setting to change this.

A daily job deletes evidence when its time is up. It deletes the screenshot file from storage and the page context with it. The thread, its text, its anchor and its address stay, and the thread shows that its evidence expired.

Turning off screenshots and page context

Workspace owners and admins control both in Configure Pins & Comments, with the Screenshot and Page context switches. Threads work with both off, but people and agents have less information to work from.