/* Property of Sistema THEAD. All rights reserved. */
/* =====================================================================
   BLOCKLY CANVAS — highlight and focus styling.

   Loads after tokens.css. The canvas has ONE highlight, drawn by
   assets/js/blockly/tj-selection.js for taps and the keyboard alike: a
   dashed line around the silhouette of the highlighted block (or the
   whole sequence, after a tap on its green flag), with a faint glow. The
   geometry — thickness, dash, gap, glow reach — lives in that file's LOOK,
   in workspace units, so it scales with the blocks. Only colour is here.

   Everything Blockly would draw on its own is suppressed below: our
   blocks are artwork over a transparent hit path, and Blockly's
   outlines, focus rings and selection strokes all fight it.
   ===================================================================== */

:root {
    --tj-sel-color: var(--keyboard-nav-highlight);
    /* The workspace ring (section 2) shares the app's keyboard colour. */
    --tj-a11y-focus-color: var(--keyboard-nav-highlight);
}

/* ---------------------------------------------------------------------
   1. Suppress Blockly's own block outlines.

   !important is load-bearing here, not laziness. Blockly injects its
   stylesheet at the TOP of <head> at inject() time, so ordering already
   favours us, but its selectors are theme- and renderer-scoped and carry
   four classes:

       .thrasos-renderer.classic-theme .blocklySelected > .blocklyPath
       .blocklyKeyboardNavigation .blocklyActiveFocus:is(.blocklyPath, ...)

   Matching that specificity would mean hardcoding the renderer and theme
   names into our sheet, which breaks the moment either is swapped.
   --------------------------------------------------------------------- */
.blocklyPath.blocklyActiveFocus,
.blocklyPath.blocklyPassiveFocus,
.blocklySelected > .blocklyPath,
.blocklyHighlightedConnectionPath,
.blocklyFocusRing {
    stroke: none !important;
    stroke-width: 0 !important;
    stroke-dasharray: none !important;
    outline: none !important;
}

/* The connection highlight is a separate element in some versions. */
.blocklyHighlightedConnectionPathVisible {
    stroke: none !important;
}


/* ---------------------------------------------------------------------
   2. The canvas focus ring — one ring, our colour, our corners.

   Blockly draws TWO concentric rects on a focused workspace, from two
   different concepts:

       .blocklyWorkspaceFocusRing      "this tree has focus"
           stroke: var(--blockly-active-tree-color)   #1379f6  blue
           stroke-width: calc(var(--blockly-selection-width) * 2)  6px

       .blocklyWorkspaceSelectionRing  "this node is selected"
           stroke: var(--blockly-active-node-color)   #fc3     yellow
           stroke-width: var(--blockly-selection-width)         3px

   For this app both mean the same thing — the child is on the canvas —
   so drawing both produced a blue ring with a yellow ring nested 5px
   inside it, in two stock Blockly colours, neither of which is the
   app's own focus colour (--brand-orange). Reported from the iOS build as
   "this weird double border blue + orange".

   Worse, neither rect carries rx/ry, while #blockly-canvas has
   border-radius: 20px — so square corners were being drawn over a
   rounded box.

   Fix: keep ONE ring (the outer, which is flush with the canvas edge),
   paint it the same colour every other focus ring in the app uses, and
   round it to match.

   Only the `display: none` below uses !important, and only because
   Blockly's own selectors are renderer- and theme-scoped and carry more
   classes than we can match without hardcoding their names. The colour
   deliberately does NOT — see the note on the variable below; forcing
   `stroke` there is what made the ring undismissable.
   --------------------------------------------------------------------- */
/* ---------------------------------------------------------------------
   2b. The canvas ring belongs to keyboard users only.

   Blockly adds `blocklyKeyboardNavigation` on FOCUSIN and never removes it,
   so one mouse click lit a 6px ring around the whole canvas — in the orange,
   the app's own keyboard-navigation colour — and left it lit for the rest of
   the session. Measured: stroke rgb(245,156,0), 6px, over a 1072x634 canvas,
   with `html.app-a11y-keyboard` false throughout. Reported as "non-block UI
   elements remaining highlighted despite not using keyboard nav".

   WHY THIS IS CSS AND NOT JAVASCRIPT. I first tried removing the class on
   pointerdown, and it did nothing, for a reason worth recording: tj-a11y's
   own mark/unmark operates on `markKeyboardNavigation.div`, which is the
   INJECTION DIV — while the class that actually drives the ring sits on
   `.tj-blockly-canvas`, the host, where Blockly puts it. The JavaScript was
   toggling a class on an element that never had it. Measured:
   `blocklyKbdClass: false` on the injection div, and simultaneously
   `.tj-blockly-canvas blocklyKeyboardNavigation` present.

   Gating on the app's own `html.app-a11y-keyboard` instead means one source
   of truth for "is this person using a keyboard" — accessibility.js already
   sets it on a navigation keypress and clears it on
   mousedown/touchstart/pointerdown — and nothing has to win a race with
   Blockly over who owns a class.
   --------------------------------------------------------------------- */
html:not(.app-a11y-keyboard) .tj-blockly-canvas .blocklyWorkspaceFocusRing {
    stroke: none !important;
}

.tj-blockly-canvas .blocklyWorkspaceSelectionRing {
    /* Redundant with the focus ring here; it is the inner of the two. */
    display: none !important;
}

/* Recolour through Blockly's OWN variables rather than forcing `stroke` on the
   ring.

   The first version of this rule set `stroke: ... !important` directly, and
   that was a real bug, not a style nit: Blockly strokes this ring only under
   `.blocklyKeyboardNavigation … .blocklyActiveFocus`, and defaults it to
   `stroke: none`. An unconditional !important override beat that default, so
   the ring drew on a canvas that had never been focused and could not be
   dismissed — reported as "impossible to unfocus the canvas now no matter where
   I tap, even when I go to the settings page and come back".

   Setting the variable instead leaves Blockly's own conditions in charge of
   WHEN the ring appears, and only changes what colour it is when it does.

   It has to land on .injectionDiv specifically. Blockly declares the variable
   there — INSIDE .tj-blockly-canvas — so setting it on the outer host is
   shadowed by Blockly's own declaration on the way down, and the ring stays
   #1379f6. Measured that way round first. `.tj-blockly-canvas .injectionDiv`
   is two classes to Blockly's one, so it wins on specificity with no
   !important. */
.tj-blockly-canvas .injectionDiv {
    --blockly-active-tree-color: var(--tj-a11y-focus-color);
}

.tj-blockly-canvas .blocklyWorkspaceFocusRing {
    fill: none;
    /* Follows the canvas's own radius rather than repeating it. The canvas is
       28px normally and 20px in landscape (index/80-responsive.css), so a
       literal here would be wrong at one of the two — which is precisely how
       this shipped square in the first place. SVG geometry properties are
       settable in CSS; verified on the iOS build below. */
    rx: var(--tj-canvas-radius, 28px);
    ry: var(--tj-canvas-radius, 28px);
}


/* ---------------------------------------------------------------------
   3. THE HIGHLIGHT.

   tj-selection.js builds this layer once, in Blockly's bubble layer
   (above every block, inside the workspace transform). The line and the
   glow are wide strokes under a mask that cuts out the blocks themselves,
   so only a band just outside the artwork survives: constant thickness,
   never painted over the highlighted art, and no line along the joints
   inside a highlighted sequence.

   Colour only. Widths and the dash pattern are presentation attributes
   set from one table (LOOK) in tj-selection.js.
   --------------------------------------------------------------------- */
.tj-sel-layer {
    pointer-events: none;
}

.tj-sel-line path,
.tj-sel-glow path {
    stroke: var(--tj-sel-color);
}

@media (forced-colors: active) {
    .tj-sel-line path {
        stroke: Highlight;
    }

    .tj-sel-glow {
        display: none;
    }
}


/* ---------------------------------------------------------------------
   4. ORPHANED BLOCKS — the dimming the legacy editor had and this one lost.

   `compileProgram()` greys every block NOT reachable from the green flag:
   `.block-wrapper.inactive { opacity: .4; filter: grayscale(.5) opacity(.5) }`
   (index/60-blocks.css). It reads `#blocks-container`, so on the Blockly canvas
   it dimmed nothing and a child had no way to see that a block they knocked
   loose had stopped being part of their program. Reported as "blocks dont lose
   opcaity when they are orphaned".

   Same numbers as the legacy rule, so the two editors look alike during the
   migration. Applied by tjSyncBlocklyOrphanDimming() on every workspace change.

   A selected loose block is shown at full strength: a child who taps one
   should see it light up, not stay greyed. (The highlight itself is drawn
   in its own layer, so the dimming never reaches it.)
   --------------------------------------------------------------------- */
.tj-blockly-canvas .tj-orphan image.tj-art,
.tj-blockly-canvas .tj-orphan > path.blocklyPath {
    opacity: 0.4;
    filter: grayscale(0.5) opacity(0.5);
}

/* A SELECTED orphan is at full strength. */
.tj-blockly-canvas .tj-orphan.tj-sel-single image.tj-art,
.tj-blockly-canvas .tj-orphan.tj-sel-seq image.tj-art,
.tj-blockly-canvas .tj-orphan.tj-sel-single > path.blocklyPath,
.tj-blockly-canvas .tj-orphan.tj-sel-seq > path.blocklyPath {
    opacity: 1;
    filter: none;
}