chore(docs): advanced usage of Slot, visibleTask

packages/docs/src/routes/docs/(qwik)/components/context/index.mdx

@@ -120,6 +120,7 @@ export const Parent = component$(() => {
 ### Caveats
 
 - The provided value will not be globally available across the whole render tree, but only to descendant components in the tree.
+- If the context isn't used during SSR, it will not be serialized. So if you want to have the context available in the client even though you don't use it during SSR, you can call `useContext()` in the parent component to force it to be serialized.
 
 ## `useContext()`
 

packages/docs/src/routes/docs/(qwik)/components/slots/index.mdx

@@ -235,3 +235,11 @@ The two approaches can best be described as declarative vs imperative. They both
 Qwik uses the declarative projection approach. The reason for this is that Qwik needs to be able to render parent/children components independently from each other. With an imperative (`children`) approach, the child component can modify the `children` in countless ways. If a child component relied on `children`, it would be forced to re-render whenever a parent component would re-render to reapply the imperative transformation to the `children`. The extra rendering goes explicitly against the goals of Qwik components rendering in isolation.
 
 > **Note**: Due to Slots being declarative in Qwik, projection with `<Slot>` will only work if the parent component is wrapped in `component$()`. If parent component is not wrapped in `component$()`, it is considered an [inline component](/docs/components/overview/#inline-components) and `<Slot>` will not work.
+
+### Advanced: Slots and Context
+
+Slotted components have access to the [Context](../context/) of their parent component, even while they aren't being projected. Furthermore, if the parent is projecting the `<Slot />` inside another component, the slotted components will also have access to the Contexts of that deeper component.
+
+However, if a component hasn't been projected yet because the `<Slot />` are rendered conditionally, it's impossible to know about the deeper Context, and then the slotted component will only see the Context of the immediate parent.
+
+As such, it's safest to avoid these situations; if you are providing Contexts, don't conditionally render your `<Slot />`.

packages/docs/src/routes/docs/(qwik)/components/tasks/index.mdx

@@ -438,6 +438,20 @@ const Clock = component$<{ isRunning: Signal<boolean> }>(({ isRunning }) => {
 
 > In this example the clock starts running immediately on the browser regardless of whether it is visible or not.
 
+### Advanced: Time of running, and managing visibility with CSS
+
+Internally, `useVisibleTask$` is implemented by adding an attribute on the first rendered component (either the returned component or in case of a Fragment, its first child).  With the standard `eagerness`, this means that if the first rendered component is hidden, the task will not run.
+
+This means that you can use CSS to influence when the task runs. For example, if the task should only run on a mobile device, you can return a `<div class="md:invisible" />` (in the case of Tailwind CSS).
+
+This also means you cannot unhide a component using a visible task; for that you can return a Fragment:
+
+```tsx
+return (<>
+  <div />
+  <MyHiddenComponent hidden={!showSignal.value} />
+</>)
+```
 
 ## Use Hook Rules