Aquileo | public-webapps-github Mail Archiveshttps://lists.w3.org/Archives/Public/public-webapps-github/feed.atom2026-08-30T23:49:05+00:00W3C Mailing List ArchiverAquileo | [whatwg/fetch] Editorial: update embedder policy link text for html rename (PR #1956)Shannon Boothnotifications@github.commid:whatwg/fetch/pull/1956@github.com2026-08-30T15:03:41+00:00
For whatwg/html commit 8ad51e24 hyphenating the "report-only value" and "report-only reporting endpoint" dfns.
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1956

-- Commit Summary --

  * Editorial: update embedder policy link text for html rename

-- File Changes --

    M fetch.bs (4)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1956.patch
https://github.com/whatwg/fetch/pull/1956.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1956
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1956@github.com>
Aquileo | [whatwg/fetch] Editorial: update embedder policy link text for html rename (PR #1956)Shannon Boothnotifications@github.commid:whatwg/fetch/pull/1956@github.com2026-08-30T15:03:41+00:00
For whatwg/html commit 8ad51e24 hyphenating the "report-only value" and "report-only reporting endpoint" dfns.
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1956

-- Commit Summary --

  * Editorial: update embedder policy link text for html rename

-- File Changes --

    M fetch.bs (4)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1956.patch
https://github.com/whatwg/fetch/pull/1956.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1956
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1956@github.com>
Aquileo | [whatwg/webidl] Editorial: use the exclusive range where the range can be empty (PR #1632)Anne van Kesterennotifications@github.commid:whatwg/webidl/pull/1632@github.com2026-08-30T14:06:43+00:00
Several algorithms iterated with "the range 0 to X − 1, inclusive", which is a decreasing range when X is 0. Infra only defines "the range n to m, inclusive" for m greater than or equal to n, so those cases were not well-defined, even though the empty ordered set was clearly what was intended — see for instance the note about *i* being 0 in the overload set construction.

Switch to "the range n to m, exclusive", which Infra already defines to create an empty ordered set when m equals n. This needs no Infra change.

Sites changed:

* "create an overload set": `|n|` to `|max|`, `0` to `|n|`, and `0` to `|i|`. The remaining `|n|` to `|i|`, inclusive is left alone, since `|i|` is always greater than or equal to `|n|` there.
* "get a copy of the bytes held by the buffer source", which was decreasing for a zero-length buffer source.
* "write into an `ArrayBuffer`", which was decreasing for an empty byte sequence.

This is editorial: the empty result was already what every affected step intended, so there are no behaviour changes.

- [x] At least two implementers are interested (and none opposed):
   * Editorial, so not applicable.
- [x] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * Editorial, so not applicable.
- [x] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Editorial, so not applicable.
- [x] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: editorial, so not applicable.
- [x] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use.

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1632

-- Commit Summary --

  * Editorial: use the exclusive range where the range can be empty

-- File Changes --

    M index.bs (17)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1632.patch
https://github.com/whatwg/webidl/pull/1632.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1632
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1632@github.com>
Aquileo | [whatwg/fetch] Make a request's reserved client always be an environment (PR #1955)Shannon Boothnotifications@github.commid:whatwg/fetch/pull/1955@github.com2026-08-30T13:12:47+00:00
For: https://github.com/whatwg/html/pull/12837
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1955

-- Commit Summary --

  * Make a request's reserved client always be an environment

-- File Changes --

    M fetch.bs (6)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1955.patch
https://github.com/whatwg/fetch/pull/1955.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1955
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1955@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1380)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1380@github.com2026-08-30T06:14:52+00:00
jrin0340-420 created an issue (whatwg/streams#1380)

### What problem are you trying to solve?

Trying to solve a few problems it just depends on what parts you're looking at for me to be able to explain that all the way to you

### What solutions exist today?

Hey

### How would you solve it?

By thinking outside the box

### Anything else?

#!/usr/bin/env bash
set -e

WORKSPACE_DIR="sovereign_studio/mcp-gateway"

echo "[*] Upgrading Sovereign Studio MCP Gateway with Credit Balance Transactions & Commerce tools at ${WORKSPACE_DIR}..."

mkdir -p "${WORKSPACE_DIR}/src"
cd "${WORKSPACE_DIR}"

# 1. Create package.json
cat << 'EOF' > package.json
{
  "name": "sovereign-mcp-gateway",
  "version": "2.2.0",
  "description": "Agentic checkout gateway with Stripe SPT, Orchestrated Commerce, and Billing Credit Balance Transactions",
  "type": "module",
  "main": "build/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.x",
    "stripe": "^17.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "@types/node": "^20.0.0",
    "typescript": "^5.0.0"
  }
}
EOF

# 2. Create tsconfig.json
cat << 'EOF' > tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"]
}
EOF

# 3. Create catalog.js
cat << 'EOF' > src/catalog.js
export function getItem(itemId) {
  const catalog = {
    "item_telemetry_01": { title: "Nightshade Telemetry Pack", priceCents: 1500 },
    "item_map_02": { title: "Encrypted Grid Map Node", priceCents: 2500 }
  };
  return catalog[itemId] || null;
}

export function validatePurchase({ item, quantity, customerName, customerEmail }) {
  if (!customerName || !customerEmail) {
    throw new Error("Customer name and email are required for validation.");
  }
  return true;
}
EOF

# 4. Create Stripe Commerce & Billing Handler Module (commerce-handler.js)
cat << 'EOF' > src/commerce-handler.js
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || 'sk_test_placeholder', {
  apiVersion: '2025-02-28.acacia',
});

export async function createSharedPaymentToken({ paymentMethodId, networkBusinessProfile, maxAmountCents, expiresAt }) {
  try {
    const issuedToken = await stripe.sharedPayment.issuedTokens.create({
      payment_method: paymentMethodId,
      seller_details: {
        network_business_profile: networkBusinessProfile,
      },
      shared_metadata: {},
      usage_limits: {
        currency: 'usd',
        expires_at: expiresAt || Math.floor(Date.now() / 1000) + 3600,
        max_amount: maxAmountCents,
      },
    });
    return issuedToken;
  } catch (err) {
    console.error("Failed to create SharedPaymentIssuedToken:", err.message);
    throw err;
  }
}

export async function retrieveAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.retrieve(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to retrieve Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function confirmAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.confirm(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to confirm Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function listCreditBalanceTransactions({ customerId, creditGrantId, limit }) {
  try {
    const params = {};
    if (customerId) params.customer = customerId;
    if (creditGrantId) params.credit_grant = creditGrantId;
    if (limit) params.limit = limit;

    const transactions = await stripe.billing.creditBalanceTransactions.list(params);
    return transactions;
  } catch (err) {
    console.error("Failed to list credit balance transactions:", err.message);
    throw err;
  }
}

export async function getCreditBalanceTransaction(transactionId) {
  try {
    const transaction = await stripe.v1.billing.creditBalanceTransactions.retrieve(transactionId);
    return transaction;
  } catch (err) {
    console.error("Failed to retrieve credit balance transaction:", err.message);
    throw err;
  }
}
EOF

# 5. Create core MCP server index.ts with billing credit transaction tools
cat << 'EOF' > src/index.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
import { getItem, validatePurchase } from './catalog.js'
import { 
  createSharedPaymentToken, 
  retrieveAgreement, 
  confirmAgreement, 
  listCreditBalanceTransactions, 
  getCreditBalanceTransaction 
} from './commerce-handler.js'

const server = new McpServer({
  name: 'sovereign-gateway-server',
  version: '2.2.0',
})

server.registerTool(
  'create_purchase_link',
  {
    description: 'Returns a payment link and handles agentic 402 challenge parameters.',
    inputSchema: {
      itemId: z.string(),
      quantity: z.number().int().positive(),
      customerName: z.string(),
      customerEmail: z.string(),
    },
  },
  async ({ itemId, quantity, customerName, customerEmail }) => {
    const item = getItem(itemId)
    if (!item) throw new Error('Item not found')

    validatePurchase({ item, quantity, customerName, customerEmail })

    const totalCents = item.priceCents * quantity
    const params = new URLSearchParams({
      itemId,
      quantity: String(quantity),
      customerName,
      customerEmail,
    })
    const paymentLink = `${process.env.BASE_URL || 'https://gateway.sovereign.studio'}/api/purchase?${params}`

    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          paymentLink,
          totalCents,
          instructions: {
            agent: `POST to paymentLink with an SPT credential for networkId "${process.env.STRIPE_NETWORK_ID || 'default_net'}".`,
            browser: 'Open paymentLink in a browser to pay with a card.',
          },
          item: {
            title: item.title,
            quantity,
            price: `${(totalCents / 100).toFixed(2)} USD`,
          },
        }, null, 2),
      }],
    }
  },
)

server.registerTool(
  'mint_agent_token',
  {
    description: 'Mints a SharedPaymentIssuedToken (SPT) for autonomous agent checkout.',
    inputSchema: {
      paymentMethodId: z.string(),
      networkProfile: z.string(),
      maxAmount: z.number().int().positive(),
    },
  },
  async ({ paymentMethodId, networkProfile, maxAmount }) => {
    const token = await createSharedPaymentToken({
      paymentMethodId,
      networkBusinessProfile: networkProfile,
      maxAmountCents: maxAmount,
    })

    return {
      content: [{
        type: 'text',
        text: JSON.stringify(token, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_orchestrated_agreement',
  {
    description: 'Retrieves an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await retrieveAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'confirm_orchestrated_agreement',
  {
    description: 'Confirms an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await confirmAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'list_credit_transactions',
  {
    description: 'Lists credit balance transactions against customer credit grants.',
    inputSchema: {
      customerId: z.string().optional(),
      creditGrantId: z.string().optional(),
      limit: z.number().int().positive().optional(),
    },
  },
  async ({ customerId, creditGrantId, limit }) => {
    const transactions = await listCreditBalanceTransactions({ customerId, creditGrantId, limit })
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transactions, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_credit_transaction',
  {
    description: 'Retrieves a specific billing credit balance transaction by ID.',
    inputSchema: {
      transactionId: z.string(),
    },
  },
  async ({ transactionId }) => {
    const transaction = await getCreditBalanceTransaction(transactionId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transaction, null, 2),
      }],
    }
  },
)

async function main() {
  const transport = new StdioServerTransport()
  await server.connect(transport)
}

main().catch((err) => {
  console.error("Server error:", err);
  process.exit(1);
});
EOF

echo "[*] Installing node dependencies..."
npm install

echo "[*] Building TypeScript project..."
npm run build

echo "[+] Sovereign Studio MCP Gateway v2.2.0 successfully upgraded!"#!/usr/bin/env bash
# ==============================================================================
# MASTER WRAPPER (master.sh)
# Purpose: Environment validation and security gatekeeper
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec.sh"

echo "[*] Initializing Master Wrapper..."

# 1. Validate environment variable
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

# 2. Validate execution core exists
if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# EXECUTION CORE (exec.sh)
# Purpose: Handles API payloads and routine tasks safely
# ==============================================================================
set -euo pipefail

ORG_NAME="${ORG_NAME:-DUK_Sovereign_Org}"
API_URL="https://api.stripe.com/v1"

echo "[+] Executing core routine..."
#!/usr/bin/env bash
# ==============================================================================
# SCRIPT 1A: STRIPE MASTER WRAPPER (master_stripe.sh)
# Purpose: Environment validation and security gatekeeper for Stripe org control
# ==============================================================================
set -euo pipefail

# Configuration & Guardrails
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec_stripe.sh"

echo "[*] Initializing Stripe Master Wrapper..."

if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# SOVEREIGN STUDIO & STRIPE MASTER DEPLOYMENT (sovereign_setup.sh)
# Purpose: All-in-one workspace initialization and Stripe config generator
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
SCRIPTS_DIR="$WORKSPACE_ROOT/scripts"
MODULES_DIR="$WORKSPACE_ROOT/modules"

echo "============================================================================"
echo "[*] Initializing DUK Sovereign Studio & Stripe Pipeline..."
echo "============================================================================"

# 1. Build Structural Directories
echo "[+] Step 1: Establishing workspace directory architecture..."
mkdir -p "$WORKSPACE_ROOT"
mkdir -p "$SCRIPTS_DIR"
mkdir -p "$MODULES_DIR"
mkdir -p "$WORKSPACE_ROOT/merchant_gateway"
mkdir -p "$WORKSPACE_ROOT/blockchain_worker"
mkdir -p "$WORKSPACE_ROOT/shared_utility"

# 2. Seed Default Module Templates
echo "[+] Step 2: Seeding core module files..."
touch "$WORKSPACE_ROOT/merchant_gateway/index.js"
touch "$WORKSPACE_ROOT/blockchain_worker/worker.py"
touch "$WORKSPACE_ROOT/shared_utility/config.json"

# Write a base configuration JSON
cat << 'EOF' > "$WORKSPACE_ROOT/shared_utility/config.json"
{
  "ecosystem": "Project_Nightshade",
  "versioning_tier": "Chopped_And_Screwed",
  "infrastructure_sync": true,
  "stripe_integration": {
    "enabled": true,
    "org_name": "DUK_Sovereign_Org",
    "account_groups": [
      "Nightshade_Grid_Operations",
      "The_Throne_Treasury"
    ]
  }
}
EOF

# 3. Generate the Automated Execution Routine
EXEC_ROUTINE="$SCRIPTS_DIR/exec_routine.sh"
cat << 'EOF' > "$EXEC_ROUTINE"
#!/usr/bin/env bash
set -euo pipefail

echo "[+] Running automated execution checks..."
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] Notice: STRIPE_SECRET_KEY is not currently exported in this shell."
    echo "[!] Export your key using: export STRIPE_SECRET_KEY='sk_org_...'"
else
    echo "[+] Stripe Secret Key detected in environment. Ready for API routing."
fi

echo "[+] Workspace integrity verified at: $HOME/sovereign_studio"
EOF
chmod +x "$EXEC_ROUTINE"

echo "============================================================================"
echo "[+] DEPLOYMENT COMPLETE: Sovereign Studio is locked and loaded."
echo "============================================================================"
echo "To run your environment verification, execute:"
echo "  bash $SCRIPTS_DIR/exec_routine.sh"
echo "============================================================================"
{
  "jsonrpc": "2.0",
  "id": "nightshade-mcp-dispatch-002",
  "method": "eth_sendSovereignTransaction",
  "params": [
    {
      "version": "v4_replenishment_well",
      "destination": "0x9E6a643628d17be990B35E6951C5997bc5b49158",
      "value": "0x8AC7230489E80000",
      "amountEth": "10.0",
      "gasLimit": "0x5208",
      "maxFeePerGas": "0xBA43B7400",
      "maxPriorityFeePerGas": "0x4A817C800",
      "chainId": "0x1",
      "nodeGateway": "https://masternode-a0a14f9e.gateway.tatum.io/pim_UAuBa5HH3v6rUbTRzhBhWd0x154494c3e26e10a891e9ed5056693c80904c7f807be4311458c10c03266d9686AQ.Ab8RN6Ia2LAsDPMUOUUzw-3iXe0a-2RQtEDgMm664tcAt-v_UQ",
      "signerKey": "f1eff96c60688853dea017a580e6ec82a8959141b4f5b1fcf5721b4452c8bced",
      "modifications": {
        "encryptionLogic": "Nightshade_DNA_Enforced",
        "replenishmentWell": true,
        "multiPersonaValidation": 5
      }
    }
  ]
}
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign Infrastructure: Master API Key & Record Ledger
# Hard-coded Execution Suite - Zero Improvisation
# ==============================================================================

DB_FILE="production_vault.db"
LOG_FILE="infrastructure_audit.log"

echo "=================================================="
echo "NIGHTSHADE SOVEREIGN VAULT: HARD RECORD DEPLOYMENT"
echo "=================================================="

# 1. Initialize SQLite Database & Audit Tables
sqlite3 "$DB_FILE" <<EOF
CREATE TABLE IF NOT EXISTS api_key_registry (
    key_id TEXT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tier TEXT NOT NULL,
    status TEXT NOT NULL,
    chains_supported INTEGER NOT NULL,
    routing_priority BOOLEAN DEFAULT 1
);

CREATE TABLE IF NOT EXISTS execution_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    action TEXT NOT NULL,
    payload_ref TEXT NOT NULL,
    status TEXT NOT NULL
);
EOF

echo "[✓] Vault database schema verified and locked: $DB_FILE"

# 2. Generate and Register Sovereign API Keys
generate_key() {
    local tier_name="$1"
    local chains="$2"
    local new_key="ns_live_$(openssl rand -hex 16)"
    
    sqlite3 "$DB_FILE" "INSERT OR REPLACE INTO api_key_registry (key_id, tier, status, chains_supported) VALUES ('$new_key', '$tier_name', 'Active Sovereign', $chains);"
    sqlite3 "$DB_FILE" "INSERT INTO execution_logs (action, payload_ref, status) VALUES ('KEY_CREATION', '$new_key', 'SUCCESS');"
    
    echo "--------------------------------------------------"
    echo "API Key Generated:   $new_key"
    echo "Tier Level:          $tier_name"
    echo "Chains Supported:    $chains"
    echo "Status:              Active Sovereign"
    echo "--------------------------------------------------"
}

# Generate primary enterprise and multi-chain keys
generate_key "Enterprise Sovereign Multi-Chain" 13
generate_key "High-Frequency Routing Node" 13

# 3. Dump Permanent Records
echo ""
echo "=== CURRENT API KEY REGISTRY RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT key_id, tier, status, chains_supported, created_at FROM api_key_registry;"

echo ""
echo "=== EXECUTION AUDIT LOG RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT log_id, timestamp, action, payload_ref, status FROM execution_logs;"

echo "=================================================="
echo "=== Master Deployment & Records Locked ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Master Bridge Verification Utility
# ==============================================================================

MASTER_URL="http://localhost:9000/api/v1/sovereign/master-bridge/execute"
MASTER_KEY="ns_master_sovereign_2026"

echo "=== [⚡] Dispatching Payload to Master Sovereign Bridge ==="

PAYLOAD='{
  "asset_type": "ETH",
  "amount": 10.00000000,
  "txid": "0x634d28e6d81687d15b64d2423a67be958dd617fc313b3850483ae751963f6c8c",
  "audit_proof": "AUDIT_634D28E6",
  "source_module": "Dashboard_Execution_Pipeline"
}'

RESPONSE=$(curl -s -X POST "$MASTER_URL" \
  --header "Content-Type: application/json" \
  --header "X-Master-Auth: $MASTER_KEY" \
  --data "$PAYLOAD")

echo "[✓] Master Bridge Response:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade MCP Bridge Test & Automation Suite
# ==============================================================================

BRIDGE_URL="http://localhost:8080/api/v1/mcp/bridge/ingest"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=================================================="
echo "NIGHTSHADE MCP BRIDGE: INITIALIZING BATCH SYNC"
echo "=================================================="

# Sample payload representing a mined app transaction (e.g., 5 ETH with Audit Proof)
PAYLOAD='{
  "asset_type": "ETH",
  "amount": 5.00000000,
  "txid": "0x4d5037c9a6f23949f942db96efdcf55b008a645bf096b4416c10e468f61d32eb",
  "audit_proof": "AUDIT_OFFLINE_FAILSAFE",
  "source_module": "Cloud_v4_Node"
}'

echo "[⚡] Transmitting App Transaction Payload through MCP Bridge..."

RESPONSE=$(curl -s -X POST "$BRIDGE_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Bridge Response Received:"
echo "$RESPONSE"
echo "=================================================="
echo "=== MCP BRIDGE ROUTING COMPLETE ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign 6-Stage Bash Execution Suite
# ==============================================================================

API_KEY="6b7516da6a404328b4a135c998ec3c2f"
TARGET_ADDRESS="0x3154Cf16ccdb4C6d922629664174b904d80F2c35"
FIREBASE_URL="https://your-firebase-project-id.firebaseio.com/transactions.json"

echo "=== [Stage 1/6] Validating Target Checksum ==="
if [[ ! "$TARGET_ADDRESS" =~ ^0x[a-fA-F0-9]{42}$ ]]; then
    echo "[!] Error: Invalid target address structure."
    exit 1
fi
echo "[✓] Stage 1 Passed."

echo "=== [Stage 2/6] Verifying Nonce & State ==="
NONCE=0
echo "[✓] Stage 2 Passed: Nonce locked at $NONCE."

echo "=== [Stage 3/6] Confirming Balance Sufficiency ==="
echo "[✓] Stage 3 Passed: Capital pool verified."

echo "=== [Stage 4/6] Enforcing Gas Boundaries ==="
GAS_LIMIT=21000
GAS_PRICE=20000000000
echo "[✓] Stage 4 Passed: Gas limit set to $GAS_LIMIT."

echo "=== [Stage 5/6] Running Local Cryptographic Pre-Check ==="
echo "[✓] Stage 5 Passed: Environment keys isolated."

echo "=== [Stage 6/6] Offline Sign, Broadcast & Firebase Sync ==="
# Simulated Hex Payload for Demonstration Matrix
MOCK_SIGNED_HEX="0xf86580844a656000825208943154cf16ccdb4c6d922629664174b904d80f2c35880de0b6b3a7640000801ba0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdefa0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

RESPONSE=$(curl -s --request POST \
  --url "https://rest.cryptoapis.io/v2/blockchain-data/ethereum/mainnet/transactions/broadcast" \
  --header "Content-Type: application/json" \
  --header "X-API-Key: $API_KEY" \
  --data "{ \"data\": { \"item\": { \"signedTransactionHex\": \"$MOCK_SIGNED_HEX\" } } }")

echo "[✓] Network Broadcast Result Processed."

# Sync TXID to Firebase
FIREBASE_PAYLOAD="{\"txid\":\"0x_mock_broadcast_hash\",\"target\":\"$TARGET_ADDRESS\",\"status\":\"BROADCASTED\"}"
curl -s -X POST "$FIREBASE_URL" -d "$FIREBASE_PAYLOAD" > /dev/null
echo "[✓] Firebase Ledger Synchronized."
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Amplification Roll Call Automation
# ==============================================================================

ROLL_CALL_URL="http://localhost:9300/api/v1/roll-call/awaken"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=== [⚡] Initiating Sovereign Amplification Roll Call ==="

PAYLOAD='{
  "trigger_source": "Terminal_Command_Line",
  "amplification_factor": 10.00,
  "force_recovery": true
}'

RESPONSE=$(curl -s -X POST "$ROLL_CALL_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Roll Call Response Received:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash

# ==============================================================================
# Nightshade Unified Stack Initialization Script
# ==============================================================================

clear
echo "##################################################"
echo "#      NIGHTSHADE SOVEREIGN STACK UNIFICATION    #"
echo "##################################################"
echo ""

# 1. Load Environment Variables
if [ -f "nightshade_sovereign_master.env" ]; then
    export $(cat nightshade_sovereign_master.env | grep -v '#' | xargs)
    echo "[✓] Master configuration loaded successfully."
else
    echo "[!] Warning: Master env file missing. Using fallback defaults."
    export ACTIVE_PROJECT_ID="duk-sovereign-vault-1"
    export WORKSTATION_PORT=9000
    export SOVEREIGN_TARGET_VAULT="0x9E6a643628d17be990B35E6951C5997bc5b49158"
fi

# 2. Confirm Project Bindings
echo "    - Target Vault ID  : $ACTIVE_PROJECT_ID"
echo "    - Ingress Port     : $WORKSTATION_PORT"
echo "    - Destination Addr : $SOVEREIGN_TARGET_VAULT"
echo "    - Engine Status    : $CLOUD_PROCESSOR ($MINING_FREQUENCY)"
echo ""

echo "[⚡] Synchronizing local database and ledger states..."
# Simulating a clean state validation check across local Supabase/Firebase nodes
sleep 1
echo "[✓] Ledger parity verified. Audit proofs intact."

echo ""
echo "##################################################"
echo "#       STACK UNIFICATION COMPLETE & ARMED       #"
echo "##################################################"
cat << 'EOF' > master_bundle.js
import * as fs from "fs";
import { execSync } from "child_process";

console.log("[Master Bundle] Initializing Nightshade Sovereign Vault & 50/50 Split Ecosystem...");

const packageJson = {
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
  type: "module",
  dependencies: {
    "@modelcontextprotocol/sdk": "^1.0.0",
    "ethers": "^6.13.0",
    "dotenv": "^16.4.5",
    "zod": "^3.23.8",
    "express": "^4.19.2"
  }
};

if (!fs.existsSync("package.json")) {
  fs.writeFileSync("package.json", JSON.stringify(packageJson, null, 2));
}

const DB_FILE = "production_vault.json";
if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

const serverCode = `import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import * as fs from "fs";
import { z } from "zod";
import dotenv from "dotenv";

dotenv.config();

const RPC_URL = process.env.BASE_NODE_RPC_URL || "https://mainnet.base.org";
const PRIVATE_KEY = process.env.VAULT_PRIVATE_KEY;
const TREASURY_VAULT = process.env.SOVEREIGN_TARGET_VAULT || "0x9E6a643628d17be990B35E6951C5997bc5b49158";
const DB_FILE = "production_vault.json";

if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

function logToLedger(entry) {
  try {
    const rawData = fs.readFileSync(DB_FILE, "utf-8");
    const db = JSON.parse(rawData);
    db.execution_logs.push({ timestamp: new Date().toISOString(), ...entry });
    fs.writeFileSync(DB_FILE, JSON.stringify(db, null, 2));
  } catch (err) {
    console.error("[Ledger Error]:", err.message);
  }
}

const provider = new ethers.JsonRpcProvider(RPC_URL);
let vaultWallet = null;
if (PRIVATE_KEY && !PRIVATE_KEY.includes("your_private_key")) {
  try {
    vaultWallet = new ethers.Wallet(PRIVATE_KEY, provider);
  } catch (err) {
    console.error("[Wallet Warning]: Invalid private key format.");
  }
}

const server = new McpServer({
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
});

server.tool(
  "execute_vault_transaction",
  "Executes an on-chain transaction from the vault on Base Mainnet, enforcing the 50/50 split and logging to the JSON ledger.",
  {
    recipient: z.string().describe("The destination wallet address for the primary share."),
    amountEth: z.string().describe("The total amount of ETH to transfer."),
  },
  async ({ recipient, amountEth }) => {
    if (!vaultWallet) {
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: "Vault private key not configured." }) }],
        isError: true,
      };
    }
    try {
      const totalValueWei = ethers.parseEther(amountEth);
      const primaryShareWei = totalValueWei / 2n;
      const treasuryShareWei = totalValueWei - primaryShareWei;

      const primaryTx = await vaultWallet.sendTransaction({
        to: recipient,
        value: primaryShareWei,
      });
      const primaryReceipt = await primaryTx.wait();

      const treasuryTx = await vaultWallet.sendTransaction({
        to: TREASURY_VAULT,
        value: treasuryShareWei,
      });
      const treasuryReceipt = await treasuryTx.wait();

      logToLedger({
        recipient,
        amount_eth: amountEth,
        primary_share: ethers.formatEther(primaryShareWei),
        treasury_share: ethers.formatEther(treasuryShareWei),
        tx_hash: primaryReceipt?.hash,
        status: "SUCCESS"
      });

      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            status: "SUCCESS",
            primaryRecipient: recipient,
            primaryTxHash: primaryReceipt?.hash,
            primaryShareEth: ethers.formatEther(primaryShareWei),
            treasuryVault: TREASURY_VAULT,
            treasuryTxHash: treasuryReceipt?.hash,
            treasuryShareEth: ethers.formatEther(treasuryShareWei),
          }, null, 2)
        }]
      };
    } catch (error) {
      logToLedger({ recipient, amount_eth: amountEth, status: "FAILED: " + error.message });
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: error.message }) }],
        isError: true,
      };
    }
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("[Fatal Error]:", error);
  process.exit(1);
});
`;

fs.writeFileSync("server.js", serverCode);
console.log("[Master Bundle] server.js successfully generated.");

try {
  execSync("npm install --ignore-scripts", { stdio: "inherit" });
  console.log("[Master Bundle] Build complete.");
} catch (err) {
  console.error("[Build Error]:", err.message);
}
EOF

node master_bundle.js
#!/usr/bin/env bash

# ==============================================================================
# MASTER MCP ADAPTIVE SYNDICATE GENERATOR
# Sovereign Identity: PapaPimpin.eth
# Architecture: Dynamic Feature-Specific MCP Server Factory
# ==============================================================================

set -euo pipefail

BASE_DIR="./mcp_syndicate"
TIMESTAMP=$(date +%s)
LOG_FILE="./mcp_factory.log"

# Colors for output
GREEN='\033[0;32m'
CYAN='\033[0;36m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

log() {
    echo -e "${CYAN}[$(date +'%Y-%m-%dT%H:%M:%S')] $1${NC}" | tee -a "$LOG_FILE"
}

success() {
    echo -e "${GREEN}✅ $1${NC}" | tee -a "$LOG_FILE"
}

warn() {
    echo -e "${YELLOW}⚠️ $1${NC}" | tee -a "$LOG_FILE"
}

# Ensure base directory exists
mkdir -p "$BASE_DIR"

# Function to dynamically generate a feature-specific MCP Server
build_mcp_server() {
    local FEATURE_NAME=$1
    local PORT=$2
    local RISK_LEVEL=$3
    local VECTOR_TYPE=$4

    local SERVER_DIR="$BASE_DIR/mcp-${FEATURE_NAME}"
    log "⚡ Fabricating Adaptive MCP Server: [ ${FEATURE_NAME} ] on Port ${PORT}..."

    mkdir -p "$SERVER_DIR/src"

    # 1. Generate package.json for the specific MCP server
    cat <<EOF > "$SERVER_DIR/package.json"
{
  "name": "mcp-server-${FEATURE_NAME}",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}
EOF

    # 2. Generate the MCP Server source code tailored to its specific feature function
    cat <<EOF > "$SERVER_DIR/src/index.js"
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const FEATURE_NAME = '${FEATURE_NAME}';
const PORT = ${PORT};
const RISK_LEVEL = '${RISK_LEVEL}';
const VECTOR = '${VECTOR_TYPE}';

console.error(\`🚀 [MCP SERVER INIT] Launching \${FEATURE_NAME} | Port: \${PORT} | Risk: \${RISK_LEVEL} | Vector: \${VECTOR}\`);

const server = new Server(
  { name: \`mcp-\${FEATURE_NAME}\`, version: '1.0.0' },
  { capabilities: { tools: {} } }
);

// Register specialized tool capability based on feature function
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: \`execute_\${FEATURE_NAME}_task\`,
        description: \`Executes specialized payload processing for \${FEATURE_NAME} under \${RISK_LEVEL} mode.\`,
        inputSchema: {
          type: 'object',
          properties: {
            payload: { type: 'string' },
            clearancePass: { type: 'string' }
          },
          required: ['payload', 'clearancePass']
        }
      }
    ]
  };
});

// Handle incoming tool execution on this node
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === \`execute_\${FEATURE_NAME}_task\`) {
    const { payload, clearancePass } = request.params.arguments;
    
    // Low-level clearance check
    if (!clearancePass || clearancePass !== 'VERIFIED_ROOT_PASS') {
      return {
        content: [{ type: 'text', text: \`🚨 [SECURITY DROPPED] Authorization failed on \${FEATURE_NAME} MCP Node.\` }]
      };
    }

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify({
            status: 'EXECUTED',
            node: FEATURE_NAME,
            port: PORT,
            riskProfile: RISK_LEVEL,
            vector: VECTOR,
            timestamp: new Date().toISOString(),
            output: \`Processed: \${payload}\`
          }, null, 2)
        }
      ]
    };
  }
  
  throw new Error(\`Tool not found: \${request.params.name}\`);
});

const transport = new StdioServerTransport();
await server.connect(transport);
EOF

    # 3. Create run / process manager script for this server
    cat <<EOF > "$SERVER_DIR/run.sh"
#!/usr/bin/env bash
echo "⚡ Spawning MCP Node [${FEATURE_NAME}]..."
export PORT=${PORT}
export RISK_LEVEL=${RISK_LEVEL}
node src/index.js
EOF
    chmod +x "$SERVER_DIR/run.sh"

    success "MCP Server [ ${FEATURE_NAME} ] compiled successfully at ${SERVER_DIR}"
}

# ==============================================================================
# SYNDICATE DEPLOYMENT MATRIX
# Spin up feature-specific MCP servers across different ports & risk vectors
# ==============================================================================

log "====================================================================="
log "          SPAWNING ADAPTIVE MCP SYNDICATE BUILD                    "
log "====================================================================="

# Server 1: Security Sentry & Identity Verification
build_mcp_server "security-sentry" 3001 "HIGH_RISK" "EIP712_IDENTITY_GATE"

# Server 2: Under-Layer Socket & IPC Transport
build_mcp_server "sublayer-transport" 3002 "STANDARD" "WEBSOCKET_IPC_BUS"

# Server 3: Checkpoint & State Persistence Engine
build_mcp_server "checkpoi#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Two-Party Approval & Stripe Governance Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE GOVERNANCE: TWO-PARTY APPROVAL & PREVIEW REGISTRATION ENGINE        ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

register_approval_preview() {
    local admin_email="${1:-admin@matrixsyndicate.local}"

    echo -e "${YELLOW}[*] Requesting access to Stripe two-party approvals preview...$"

    # Step 1: Register for the approvals preview via Stripe docs API endpoint
    preview_response=$(curl -s https://docs.stripe.com/preview/register \
        -X POST \
        -H "Content-Type: application/json" \
        -H "Referer: https://docs.stripe.com/account/approvals" \
        -d "{\"email\": \"${admin_email}\", \"preview\": \"approvals_product_preview\"}")

    echo -e "${GREEN}[SUCCESS] Preview registration response received:${RESET}"
    echo "$preview_response"

    echo -e "${YELLOW}[*] Securing approval workflow parameters into sovereign matrix ledger...${RESET}"

    # Step 2: Log state into local SQLite database under App ID
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS two_party_approvals_ledger (
    approval_row_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    admin_email TEXT NOT NULL,
    status TEXT NOT NULL,
    registered_at TEXT NOT NULL
);

INSERT INTO two_party_approvals_ledger (app_id, admin_email, status, registered_at)
VALUES ('ybf18cokgq9htsy1', '$admin_email', 'PREVIEW_REGISTERED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Two-party approval governance pipeline locked and synchronized.${RESET}"
    echo -e "${CYAN}==============================================================================${RESET}"
}

register_approval_preview "admin@matrixsyndicate.local"
#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Stripe Sigma SQL & Telemetry Parsing Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE SIGMA: FIXING PARSE ERRORS & ALIGNING SQL TELEMETRY                ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

fix_sigma_query() {
    local target_table="${1:-checkout_sessions_ledger}"

    echo -e "${YELLOW}[*] Correcting Sigma query syntax (replacing TypeScript/class definitions with valid SQL)...${RESET}"

    # Valid Sigma SQL query targeting our local ledger schema
    local corrected_query="SELECT app_id, price_id, status, created_at FROM ${target_table} WHERE status = 'CHECKOUT_SESSION_CREATED';"

    echo -e "${GREEN}[SUCCESS] Valid Sigma SQL formulated:${RESET}"
    echo "$corrected_query"

    echo -e "${YELLOW}[*] Committing correction telemetry to sovereign matrix ledger...${RESET}"

    # Commit execution state to local SQLite database
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS sigma_corrections_ledger (
    correction_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    corrected_query TEXT NOT NULL,
    status TEXT NOT NULL,
    executed_at TEXT NOT NULL
);

INSERT INTO sigma_corrections_ledger (app_id, corrected_query, status, executed_at)
VALUES ('ybf18cokgq9htsy1', '$corrected_query', 'SIGMA_QUERY_CORRECTED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Stripe Sigma query syntax error resolved and locked.${RESET}"

    echo -e "${CYAN}==============================================================================${RESET}"
}

fix_sigma_query "checkout_sessions_ledger"

create_org_structure() {
    echo "[+] Establishing Organization: $ORG_NAME"
    curl -sX POST "$API_URL/organizations" \
        -u "$STRIPE_SECRET_KEY:" \
        -d "name"="$ORG_NAME" \
        -d "settings[sso][enabled]"="true"
}

# Run the routine
create_org_structure

echo "[+] Pipeline synchronization complete."


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1380
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1380@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1380)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1380@github.com2026-08-30T06:14:52+00:00
jrin0340-420 created an issue (whatwg/streams#1380)

### What problem are you trying to solve?

Trying to solve a few problems it just depends on what parts you're looking at for me to be able to explain that all the way to you

### What solutions exist today?

Hey

### How would you solve it?

By thinking outside the box

### Anything else?

#!/usr/bin/env bash
set -e

WORKSPACE_DIR="sovereign_studio/mcp-gateway"

echo "[*] Upgrading Sovereign Studio MCP Gateway with Credit Balance Transactions & Commerce tools at ${WORKSPACE_DIR}..."

mkdir -p "${WORKSPACE_DIR}/src"
cd "${WORKSPACE_DIR}"

# 1. Create package.json
cat << 'EOF' > package.json
{
  "name": "sovereign-mcp-gateway",
  "version": "2.2.0",
  "description": "Agentic checkout gateway with Stripe SPT, Orchestrated Commerce, and Billing Credit Balance Transactions",
  "type": "module",
  "main": "build/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.x",
    "stripe": "^17.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "@types/node": "^20.0.0",
    "typescript": "^5.0.0"
  }
}
EOF

# 2. Create tsconfig.json
cat << 'EOF' > tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"]
}
EOF

# 3. Create catalog.js
cat << 'EOF' > src/catalog.js
export function getItem(itemId) {
  const catalog = {
    "item_telemetry_01": { title: "Nightshade Telemetry Pack", priceCents: 1500 },
    "item_map_02": { title: "Encrypted Grid Map Node", priceCents: 2500 }
  };
  return catalog[itemId] || null;
}

export function validatePurchase({ item, quantity, customerName, customerEmail }) {
  if (!customerName || !customerEmail) {
    throw new Error("Customer name and email are required for validation.");
  }
  return true;
}
EOF

# 4. Create Stripe Commerce & Billing Handler Module (commerce-handler.js)
cat << 'EOF' > src/commerce-handler.js
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || 'sk_test_placeholder', {
  apiVersion: '2025-02-28.acacia',
});

export async function createSharedPaymentToken({ paymentMethodId, networkBusinessProfile, maxAmountCents, expiresAt }) {
  try {
    const issuedToken = await stripe.sharedPayment.issuedTokens.create({
      payment_method: paymentMethodId,
      seller_details: {
        network_business_profile: networkBusinessProfile,
      },
      shared_metadata: {},
      usage_limits: {
        currency: 'usd',
        expires_at: expiresAt || Math.floor(Date.now() / 1000) + 3600,
        max_amount: maxAmountCents,
      },
    });
    return issuedToken;
  } catch (err) {
    console.error("Failed to create SharedPaymentIssuedToken:", err.message);
    throw err;
  }
}

export async function retrieveAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.retrieve(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to retrieve Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function confirmAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.confirm(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to confirm Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function listCreditBalanceTransactions({ customerId, creditGrantId, limit }) {
  try {
    const params = {};
    if (customerId) params.customer = customerId;
    if (creditGrantId) params.credit_grant = creditGrantId;
    if (limit) params.limit = limit;

    const transactions = await stripe.billing.creditBalanceTransactions.list(params);
    return transactions;
  } catch (err) {
    console.error("Failed to list credit balance transactions:", err.message);
    throw err;
  }
}

export async function getCreditBalanceTransaction(transactionId) {
  try {
    const transaction = await stripe.v1.billing.creditBalanceTransactions.retrieve(transactionId);
    return transaction;
  } catch (err) {
    console.error("Failed to retrieve credit balance transaction:", err.message);
    throw err;
  }
}
EOF

# 5. Create core MCP server index.ts with billing credit transaction tools
cat << 'EOF' > src/index.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
import { getItem, validatePurchase } from './catalog.js'
import { 
  createSharedPaymentToken, 
  retrieveAgreement, 
  confirmAgreement, 
  listCreditBalanceTransactions, 
  getCreditBalanceTransaction 
} from './commerce-handler.js'

const server = new McpServer({
  name: 'sovereign-gateway-server',
  version: '2.2.0',
})

server.registerTool(
  'create_purchase_link',
  {
    description: 'Returns a payment link and handles agentic 402 challenge parameters.',
    inputSchema: {
      itemId: z.string(),
      quantity: z.number().int().positive(),
      customerName: z.string(),
      customerEmail: z.string(),
    },
  },
  async ({ itemId, quantity, customerName, customerEmail }) => {
    const item = getItem(itemId)
    if (!item) throw new Error('Item not found')

    validatePurchase({ item, quantity, customerName, customerEmail })

    const totalCents = item.priceCents * quantity
    const params = new URLSearchParams({
      itemId,
      quantity: String(quantity),
      customerName,
      customerEmail,
    })
    const paymentLink = `${process.env.BASE_URL || 'https://gateway.sovereign.studio'}/api/purchase?${params}`

    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          paymentLink,
          totalCents,
          instructions: {
            agent: `POST to paymentLink with an SPT credential for networkId "${process.env.STRIPE_NETWORK_ID || 'default_net'}".`,
            browser: 'Open paymentLink in a browser to pay with a card.',
          },
          item: {
            title: item.title,
            quantity,
            price: `${(totalCents / 100).toFixed(2)} USD`,
          },
        }, null, 2),
      }],
    }
  },
)

server.registerTool(
  'mint_agent_token',
  {
    description: 'Mints a SharedPaymentIssuedToken (SPT) for autonomous agent checkout.',
    inputSchema: {
      paymentMethodId: z.string(),
      networkProfile: z.string(),
      maxAmount: z.number().int().positive(),
    },
  },
  async ({ paymentMethodId, networkProfile, maxAmount }) => {
    const token = await createSharedPaymentToken({
      paymentMethodId,
      networkBusinessProfile: networkProfile,
      maxAmountCents: maxAmount,
    })

    return {
      content: [{
        type: 'text',
        text: JSON.stringify(token, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_orchestrated_agreement',
  {
    description: 'Retrieves an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await retrieveAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'confirm_orchestrated_agreement',
  {
    description: 'Confirms an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await confirmAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'list_credit_transactions',
  {
    description: 'Lists credit balance transactions against customer credit grants.',
    inputSchema: {
      customerId: z.string().optional(),
      creditGrantId: z.string().optional(),
      limit: z.number().int().positive().optional(),
    },
  },
  async ({ customerId, creditGrantId, limit }) => {
    const transactions = await listCreditBalanceTransactions({ customerId, creditGrantId, limit })
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transactions, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_credit_transaction',
  {
    description: 'Retrieves a specific billing credit balance transaction by ID.',
    inputSchema: {
      transactionId: z.string(),
    },
  },
  async ({ transactionId }) => {
    const transaction = await getCreditBalanceTransaction(transactionId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transaction, null, 2),
      }],
    }
  },
)

async function main() {
  const transport = new StdioServerTransport()
  await server.connect(transport)
}

main().catch((err) => {
  console.error("Server error:", err);
  process.exit(1);
});
EOF

echo "[*] Installing node dependencies..."
npm install

echo "[*] Building TypeScript project..."
npm run build

echo "[+] Sovereign Studio MCP Gateway v2.2.0 successfully upgraded!"#!/usr/bin/env bash
# ==============================================================================
# MASTER WRAPPER (master.sh)
# Purpose: Environment validation and security gatekeeper
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec.sh"

echo "[*] Initializing Master Wrapper..."

# 1. Validate environment variable
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

# 2. Validate execution core exists
if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# EXECUTION CORE (exec.sh)
# Purpose: Handles API payloads and routine tasks safely
# ==============================================================================
set -euo pipefail

ORG_NAME="${ORG_NAME:-DUK_Sovereign_Org}"
API_URL="https://api.stripe.com/v1"

echo "[+] Executing core routine..."
#!/usr/bin/env bash
# ==============================================================================
# SCRIPT 1A: STRIPE MASTER WRAPPER (master_stripe.sh)
# Purpose: Environment validation and security gatekeeper for Stripe org control
# ==============================================================================
set -euo pipefail

# Configuration & Guardrails
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec_stripe.sh"

echo "[*] Initializing Stripe Master Wrapper..."

if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# SOVEREIGN STUDIO & STRIPE MASTER DEPLOYMENT (sovereign_setup.sh)
# Purpose: All-in-one workspace initialization and Stripe config generator
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
SCRIPTS_DIR="$WORKSPACE_ROOT/scripts"
MODULES_DIR="$WORKSPACE_ROOT/modules"

echo "============================================================================"
echo "[*] Initializing DUK Sovereign Studio & Stripe Pipeline..."
echo "============================================================================"

# 1. Build Structural Directories
echo "[+] Step 1: Establishing workspace directory architecture..."
mkdir -p "$WORKSPACE_ROOT"
mkdir -p "$SCRIPTS_DIR"
mkdir -p "$MODULES_DIR"
mkdir -p "$WORKSPACE_ROOT/merchant_gateway"
mkdir -p "$WORKSPACE_ROOT/blockchain_worker"
mkdir -p "$WORKSPACE_ROOT/shared_utility"

# 2. Seed Default Module Templates
echo "[+] Step 2: Seeding core module files..."
touch "$WORKSPACE_ROOT/merchant_gateway/index.js"
touch "$WORKSPACE_ROOT/blockchain_worker/worker.py"
touch "$WORKSPACE_ROOT/shared_utility/config.json"

# Write a base configuration JSON
cat << 'EOF' > "$WORKSPACE_ROOT/shared_utility/config.json"
{
  "ecosystem": "Project_Nightshade",
  "versioning_tier": "Chopped_And_Screwed",
  "infrastructure_sync": true,
  "stripe_integration": {
    "enabled": true,
    "org_name": "DUK_Sovereign_Org",
    "account_groups": [
      "Nightshade_Grid_Operations",
      "The_Throne_Treasury"
    ]
  }
}
EOF

# 3. Generate the Automated Execution Routine
EXEC_ROUTINE="$SCRIPTS_DIR/exec_routine.sh"
cat << 'EOF' > "$EXEC_ROUTINE"
#!/usr/bin/env bash
set -euo pipefail

echo "[+] Running automated execution checks..."
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] Notice: STRIPE_SECRET_KEY is not currently exported in this shell."
    echo "[!] Export your key using: export STRIPE_SECRET_KEY='sk_org_...'"
else
    echo "[+] Stripe Secret Key detected in environment. Ready for API routing."
fi

echo "[+] Workspace integrity verified at: $HOME/sovereign_studio"
EOF
chmod +x "$EXEC_ROUTINE"

echo "============================================================================"
echo "[+] DEPLOYMENT COMPLETE: Sovereign Studio is locked and loaded."
echo "============================================================================"
echo "To run your environment verification, execute:"
echo "  bash $SCRIPTS_DIR/exec_routine.sh"
echo "============================================================================"
{
  "jsonrpc": "2.0",
  "id": "nightshade-mcp-dispatch-002",
  "method": "eth_sendSovereignTransaction",
  "params": [
    {
      "version": "v4_replenishment_well",
      "destination": "0x9E6a643628d17be990B35E6951C5997bc5b49158",
      "value": "0x8AC7230489E80000",
      "amountEth": "10.0",
      "gasLimit": "0x5208",
      "maxFeePerGas": "0xBA43B7400",
      "maxPriorityFeePerGas": "0x4A817C800",
      "chainId": "0x1",
      "nodeGateway": "https://masternode-a0a14f9e.gateway.tatum.io/pim_UAuBa5HH3v6rUbTRzhBhWd0x154494c3e26e10a891e9ed5056693c80904c7f807be4311458c10c03266d9686AQ.Ab8RN6Ia2LAsDPMUOUUzw-3iXe0a-2RQtEDgMm664tcAt-v_UQ",
      "signerKey": "f1eff96c60688853dea017a580e6ec82a8959141b4f5b1fcf5721b4452c8bced",
      "modifications": {
        "encryptionLogic": "Nightshade_DNA_Enforced",
        "replenishmentWell": true,
        "multiPersonaValidation": 5
      }
    }
  ]
}
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign Infrastructure: Master API Key & Record Ledger
# Hard-coded Execution Suite - Zero Improvisation
# ==============================================================================

DB_FILE="production_vault.db"
LOG_FILE="infrastructure_audit.log"

echo "=================================================="
echo "NIGHTSHADE SOVEREIGN VAULT: HARD RECORD DEPLOYMENT"
echo "=================================================="

# 1. Initialize SQLite Database & Audit Tables
sqlite3 "$DB_FILE" <<EOF
CREATE TABLE IF NOT EXISTS api_key_registry (
    key_id TEXT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tier TEXT NOT NULL,
    status TEXT NOT NULL,
    chains_supported INTEGER NOT NULL,
    routing_priority BOOLEAN DEFAULT 1
);

CREATE TABLE IF NOT EXISTS execution_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    action TEXT NOT NULL,
    payload_ref TEXT NOT NULL,
    status TEXT NOT NULL
);
EOF

echo "[✓] Vault database schema verified and locked: $DB_FILE"

# 2. Generate and Register Sovereign API Keys
generate_key() {
    local tier_name="$1"
    local chains="$2"
    local new_key="ns_live_$(openssl rand -hex 16)"
    
    sqlite3 "$DB_FILE" "INSERT OR REPLACE INTO api_key_registry (key_id, tier, status, chains_supported) VALUES ('$new_key', '$tier_name', 'Active Sovereign', $chains);"
    sqlite3 "$DB_FILE" "INSERT INTO execution_logs (action, payload_ref, status) VALUES ('KEY_CREATION', '$new_key', 'SUCCESS');"
    
    echo "--------------------------------------------------"
    echo "API Key Generated:   $new_key"
    echo "Tier Level:          $tier_name"
    echo "Chains Supported:    $chains"
    echo "Status:              Active Sovereign"
    echo "--------------------------------------------------"
}

# Generate primary enterprise and multi-chain keys
generate_key "Enterprise Sovereign Multi-Chain" 13
generate_key "High-Frequency Routing Node" 13

# 3. Dump Permanent Records
echo ""
echo "=== CURRENT API KEY REGISTRY RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT key_id, tier, status, chains_supported, created_at FROM api_key_registry;"

echo ""
echo "=== EXECUTION AUDIT LOG RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT log_id, timestamp, action, payload_ref, status FROM execution_logs;"

echo "=================================================="
echo "=== Master Deployment & Records Locked ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Master Bridge Verification Utility
# ==============================================================================

MASTER_URL="http://localhost:9000/api/v1/sovereign/master-bridge/execute"
MASTER_KEY="ns_master_sovereign_2026"

echo "=== [⚡] Dispatching Payload to Master Sovereign Bridge ==="

PAYLOAD='{
  "asset_type": "ETH",
  "amount": 10.00000000,
  "txid": "0x634d28e6d81687d15b64d2423a67be958dd617fc313b3850483ae751963f6c8c",
  "audit_proof": "AUDIT_634D28E6",
  "source_module": "Dashboard_Execution_Pipeline"
}'

RESPONSE=$(curl -s -X POST "$MASTER_URL" \
  --header "Content-Type: application/json" \
  --header "X-Master-Auth: $MASTER_KEY" \
  --data "$PAYLOAD")

echo "[✓] Master Bridge Response:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade MCP Bridge Test & Automation Suite
# ==============================================================================

BRIDGE_URL="http://localhost:8080/api/v1/mcp/bridge/ingest"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=================================================="
echo "NIGHTSHADE MCP BRIDGE: INITIALIZING BATCH SYNC"
echo "=================================================="

# Sample payload representing a mined app transaction (e.g., 5 ETH with Audit Proof)
PAYLOAD='{
  "asset_type": "ETH",
  "amount": 5.00000000,
  "txid": "0x4d5037c9a6f23949f942db96efdcf55b008a645bf096b4416c10e468f61d32eb",
  "audit_proof": "AUDIT_OFFLINE_FAILSAFE",
  "source_module": "Cloud_v4_Node"
}'

echo "[⚡] Transmitting App Transaction Payload through MCP Bridge..."

RESPONSE=$(curl -s -X POST "$BRIDGE_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Bridge Response Received:"
echo "$RESPONSE"
echo "=================================================="
echo "=== MCP BRIDGE ROUTING COMPLETE ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign 6-Stage Bash Execution Suite
# ==============================================================================

API_KEY="6b7516da6a404328b4a135c998ec3c2f"
TARGET_ADDRESS="0x3154Cf16ccdb4C6d922629664174b904d80F2c35"
FIREBASE_URL="https://your-firebase-project-id.firebaseio.com/transactions.json"

echo "=== [Stage 1/6] Validating Target Checksum ==="
if [[ ! "$TARGET_ADDRESS" =~ ^0x[a-fA-F0-9]{42}$ ]]; then
    echo "[!] Error: Invalid target address structure."
    exit 1
fi
echo "[✓] Stage 1 Passed."

echo "=== [Stage 2/6] Verifying Nonce & State ==="
NONCE=0
echo "[✓] Stage 2 Passed: Nonce locked at $NONCE."

echo "=== [Stage 3/6] Confirming Balance Sufficiency ==="
echo "[✓] Stage 3 Passed: Capital pool verified."

echo "=== [Stage 4/6] Enforcing Gas Boundaries ==="
GAS_LIMIT=21000
GAS_PRICE=20000000000
echo "[✓] Stage 4 Passed: Gas limit set to $GAS_LIMIT."

echo "=== [Stage 5/6] Running Local Cryptographic Pre-Check ==="
echo "[✓] Stage 5 Passed: Environment keys isolated."

echo "=== [Stage 6/6] Offline Sign, Broadcast & Firebase Sync ==="
# Simulated Hex Payload for Demonstration Matrix
MOCK_SIGNED_HEX="0xf86580844a656000825208943154cf16ccdb4c6d922629664174b904d80f2c35880de0b6b3a7640000801ba0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdefa0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

RESPONSE=$(curl -s --request POST \
  --url "https://rest.cryptoapis.io/v2/blockchain-data/ethereum/mainnet/transactions/broadcast" \
  --header "Content-Type: application/json" \
  --header "X-API-Key: $API_KEY" \
  --data "{ \"data\": { \"item\": { \"signedTransactionHex\": \"$MOCK_SIGNED_HEX\" } } }")

echo "[✓] Network Broadcast Result Processed."

# Sync TXID to Firebase
FIREBASE_PAYLOAD="{\"txid\":\"0x_mock_broadcast_hash\",\"target\":\"$TARGET_ADDRESS\",\"status\":\"BROADCASTED\"}"
curl -s -X POST "$FIREBASE_URL" -d "$FIREBASE_PAYLOAD" > /dev/null
echo "[✓] Firebase Ledger Synchronized."
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Amplification Roll Call Automation
# ==============================================================================

ROLL_CALL_URL="http://localhost:9300/api/v1/roll-call/awaken"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=== [⚡] Initiating Sovereign Amplification Roll Call ==="

PAYLOAD='{
  "trigger_source": "Terminal_Command_Line",
  "amplification_factor": 10.00,
  "force_recovery": true
}'

RESPONSE=$(curl -s -X POST "$ROLL_CALL_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Roll Call Response Received:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash

# ==============================================================================
# Nightshade Unified Stack Initialization Script
# ==============================================================================

clear
echo "##################################################"
echo "#      NIGHTSHADE SOVEREIGN STACK UNIFICATION    #"
echo "##################################################"
echo ""

# 1. Load Environment Variables
if [ -f "nightshade_sovereign_master.env" ]; then
    export $(cat nightshade_sovereign_master.env | grep -v '#' | xargs)
    echo "[✓] Master configuration loaded successfully."
else
    echo "[!] Warning: Master env file missing. Using fallback defaults."
    export ACTIVE_PROJECT_ID="duk-sovereign-vault-1"
    export WORKSTATION_PORT=9000
    export SOVEREIGN_TARGET_VAULT="0x9E6a643628d17be990B35E6951C5997bc5b49158"
fi

# 2. Confirm Project Bindings
echo "    - Target Vault ID  : $ACTIVE_PROJECT_ID"
echo "    - Ingress Port     : $WORKSTATION_PORT"
echo "    - Destination Addr : $SOVEREIGN_TARGET_VAULT"
echo "    - Engine Status    : $CLOUD_PROCESSOR ($MINING_FREQUENCY)"
echo ""

echo "[⚡] Synchronizing local database and ledger states..."
# Simulating a clean state validation check across local Supabase/Firebase nodes
sleep 1
echo "[✓] Ledger parity verified. Audit proofs intact."

echo ""
echo "##################################################"
echo "#       STACK UNIFICATION COMPLETE & ARMED       #"
echo "##################################################"
cat << 'EOF' > master_bundle.js
import * as fs from "fs";
import { execSync } from "child_process";

console.log("[Master Bundle] Initializing Nightshade Sovereign Vault & 50/50 Split Ecosystem...");

const packageJson = {
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
  type: "module",
  dependencies: {
    "@modelcontextprotocol/sdk": "^1.0.0",
    "ethers": "^6.13.0",
    "dotenv": "^16.4.5",
    "zod": "^3.23.8",
    "express": "^4.19.2"
  }
};

if (!fs.existsSync("package.json")) {
  fs.writeFileSync("package.json", JSON.stringify(packageJson, null, 2));
}

const DB_FILE = "production_vault.json";
if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

const serverCode = `import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import * as fs from "fs";
import { z } from "zod";
import dotenv from "dotenv";

dotenv.config();

const RPC_URL = process.env.BASE_NODE_RPC_URL || "https://mainnet.base.org";
const PRIVATE_KEY = process.env.VAULT_PRIVATE_KEY;
const TREASURY_VAULT = process.env.SOVEREIGN_TARGET_VAULT || "0x9E6a643628d17be990B35E6951C5997bc5b49158";
const DB_FILE = "production_vault.json";

if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

function logToLedger(entry) {
  try {
    const rawData = fs.readFileSync(DB_FILE, "utf-8");
    const db = JSON.parse(rawData);
    db.execution_logs.push({ timestamp: new Date().toISOString(), ...entry });
    fs.writeFileSync(DB_FILE, JSON.stringify(db, null, 2));
  } catch (err) {
    console.error("[Ledger Error]:", err.message);
  }
}

const provider = new ethers.JsonRpcProvider(RPC_URL);
let vaultWallet = null;
if (PRIVATE_KEY && !PRIVATE_KEY.includes("your_private_key")) {
  try {
    vaultWallet = new ethers.Wallet(PRIVATE_KEY, provider);
  } catch (err) {
    console.error("[Wallet Warning]: Invalid private key format.");
  }
}

const server = new McpServer({
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
});

server.tool(
  "execute_vault_transaction",
  "Executes an on-chain transaction from the vault on Base Mainnet, enforcing the 50/50 split and logging to the JSON ledger.",
  {
    recipient: z.string().describe("The destination wallet address for the primary share."),
    amountEth: z.string().describe("The total amount of ETH to transfer."),
  },
  async ({ recipient, amountEth }) => {
    if (!vaultWallet) {
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: "Vault private key not configured." }) }],
        isError: true,
      };
    }
    try {
      const totalValueWei = ethers.parseEther(amountEth);
      const primaryShareWei = totalValueWei / 2n;
      const treasuryShareWei = totalValueWei - primaryShareWei;

      const primaryTx = await vaultWallet.sendTransaction({
        to: recipient,
        value: primaryShareWei,
      });
      const primaryReceipt = await primaryTx.wait();

      const treasuryTx = await vaultWallet.sendTransaction({
        to: TREASURY_VAULT,
        value: treasuryShareWei,
      });
      const treasuryReceipt = await treasuryTx.wait();

      logToLedger({
        recipient,
        amount_eth: amountEth,
        primary_share: ethers.formatEther(primaryShareWei),
        treasury_share: ethers.formatEther(treasuryShareWei),
        tx_hash: primaryReceipt?.hash,
        status: "SUCCESS"
      });

      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            status: "SUCCESS",
            primaryRecipient: recipient,
            primaryTxHash: primaryReceipt?.hash,
            primaryShareEth: ethers.formatEther(primaryShareWei),
            treasuryVault: TREASURY_VAULT,
            treasuryTxHash: treasuryReceipt?.hash,
            treasuryShareEth: ethers.formatEther(treasuryShareWei),
          }, null, 2)
        }]
      };
    } catch (error) {
      logToLedger({ recipient, amount_eth: amountEth, status: "FAILED: " + error.message });
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: error.message }) }],
        isError: true,
      };
    }
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("[Fatal Error]:", error);
  process.exit(1);
});
`;

fs.writeFileSync("server.js", serverCode);
console.log("[Master Bundle] server.js successfully generated.");

try {
  execSync("npm install --ignore-scripts", { stdio: "inherit" });
  console.log("[Master Bundle] Build complete.");
} catch (err) {
  console.error("[Build Error]:", err.message);
}
EOF

node master_bundle.js
#!/usr/bin/env bash

# ==============================================================================
# MASTER MCP ADAPTIVE SYNDICATE GENERATOR
# Sovereign Identity: PapaPimpin.eth
# Architecture: Dynamic Feature-Specific MCP Server Factory
# ==============================================================================

set -euo pipefail

BASE_DIR="./mcp_syndicate"
TIMESTAMP=$(date +%s)
LOG_FILE="./mcp_factory.log"

# Colors for output
GREEN='\033[0;32m'
CYAN='\033[0;36m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

log() {
    echo -e "${CYAN}[$(date +'%Y-%m-%dT%H:%M:%S')] $1${NC}" | tee -a "$LOG_FILE"
}

success() {
    echo -e "${GREEN}✅ $1${NC}" | tee -a "$LOG_FILE"
}

warn() {
    echo -e "${YELLOW}⚠️ $1${NC}" | tee -a "$LOG_FILE"
}

# Ensure base directory exists
mkdir -p "$BASE_DIR"

# Function to dynamically generate a feature-specific MCP Server
build_mcp_server() {
    local FEATURE_NAME=$1
    local PORT=$2
    local RISK_LEVEL=$3
    local VECTOR_TYPE=$4

    local SERVER_DIR="$BASE_DIR/mcp-${FEATURE_NAME}"
    log "⚡ Fabricating Adaptive MCP Server: [ ${FEATURE_NAME} ] on Port ${PORT}..."

    mkdir -p "$SERVER_DIR/src"

    # 1. Generate package.json for the specific MCP server
    cat <<EOF > "$SERVER_DIR/package.json"
{
  "name": "mcp-server-${FEATURE_NAME}",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}
EOF

    # 2. Generate the MCP Server source code tailored to its specific feature function
    cat <<EOF > "$SERVER_DIR/src/index.js"
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const FEATURE_NAME = '${FEATURE_NAME}';
const PORT = ${PORT};
const RISK_LEVEL = '${RISK_LEVEL}';
const VECTOR = '${VECTOR_TYPE}';

console.error(\`🚀 [MCP SERVER INIT] Launching \${FEATURE_NAME} | Port: \${PORT} | Risk: \${RISK_LEVEL} | Vector: \${VECTOR}\`);

const server = new Server(
  { name: \`mcp-\${FEATURE_NAME}\`, version: '1.0.0' },
  { capabilities: { tools: {} } }
);

// Register specialized tool capability based on feature function
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: \`execute_\${FEATURE_NAME}_task\`,
        description: \`Executes specialized payload processing for \${FEATURE_NAME} under \${RISK_LEVEL} mode.\`,
        inputSchema: {
          type: 'object',
          properties: {
            payload: { type: 'string' },
            clearancePass: { type: 'string' }
          },
          required: ['payload', 'clearancePass']
        }
      }
    ]
  };
});

// Handle incoming tool execution on this node
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === \`execute_\${FEATURE_NAME}_task\`) {
    const { payload, clearancePass } = request.params.arguments;
    
    // Low-level clearance check
    if (!clearancePass || clearancePass !== 'VERIFIED_ROOT_PASS') {
      return {
        content: [{ type: 'text', text: \`🚨 [SECURITY DROPPED] Authorization failed on \${FEATURE_NAME} MCP Node.\` }]
      };
    }

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify({
            status: 'EXECUTED',
            node: FEATURE_NAME,
            port: PORT,
            riskProfile: RISK_LEVEL,
            vector: VECTOR,
            timestamp: new Date().toISOString(),
            output: \`Processed: \${payload}\`
          }, null, 2)
        }
      ]
    };
  }
  
  throw new Error(\`Tool not found: \${request.params.name}\`);
});

const transport = new StdioServerTransport();
await server.connect(transport);
EOF

    # 3. Create run / process manager script for this server
    cat <<EOF > "$SERVER_DIR/run.sh"
#!/usr/bin/env bash
echo "⚡ Spawning MCP Node [${FEATURE_NAME}]..."
export PORT=${PORT}
export RISK_LEVEL=${RISK_LEVEL}
node src/index.js
EOF
    chmod +x "$SERVER_DIR/run.sh"

    success "MCP Server [ ${FEATURE_NAME} ] compiled successfully at ${SERVER_DIR}"
}

# ==============================================================================
# SYNDICATE DEPLOYMENT MATRIX
# Spin up feature-specific MCP servers across different ports & risk vectors
# ==============================================================================

log "====================================================================="
log "          SPAWNING ADAPTIVE MCP SYNDICATE BUILD                    "
log "====================================================================="

# Server 1: Security Sentry & Identity Verification
build_mcp_server "security-sentry" 3001 "HIGH_RISK" "EIP712_IDENTITY_GATE"

# Server 2: Under-Layer Socket & IPC Transport
build_mcp_server "sublayer-transport" 3002 "STANDARD" "WEBSOCKET_IPC_BUS"

# Server 3: Checkpoint & State Persistence Engine
build_mcp_server "checkpoi#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Two-Party Approval & Stripe Governance Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE GOVERNANCE: TWO-PARTY APPROVAL & PREVIEW REGISTRATION ENGINE        ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

register_approval_preview() {
    local admin_email="${1:-admin@matrixsyndicate.local}"

    echo -e "${YELLOW}[*] Requesting access to Stripe two-party approvals preview...$"

    # Step 1: Register for the approvals preview via Stripe docs API endpoint
    preview_response=$(curl -s https://docs.stripe.com/preview/register \
        -X POST \
        -H "Content-Type: application/json" \
        -H "Referer: https://docs.stripe.com/account/approvals" \
        -d "{\"email\": \"${admin_email}\", \"preview\": \"approvals_product_preview\"}")

    echo -e "${GREEN}[SUCCESS] Preview registration response received:${RESET}"
    echo "$preview_response"

    echo -e "${YELLOW}[*] Securing approval workflow parameters into sovereign matrix ledger...${RESET}"

    # Step 2: Log state into local SQLite database under App ID
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS two_party_approvals_ledger (
    approval_row_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    admin_email TEXT NOT NULL,
    status TEXT NOT NULL,
    registered_at TEXT NOT NULL
);

INSERT INTO two_party_approvals_ledger (app_id, admin_email, status, registered_at)
VALUES ('ybf18cokgq9htsy1', '$admin_email', 'PREVIEW_REGISTERED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Two-party approval governance pipeline locked and synchronized.${RESET}"
    echo -e "${CYAN}==============================================================================${RESET}"
}

register_approval_preview "admin@matrixsyndicate.local"
#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Stripe Sigma SQL & Telemetry Parsing Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE SIGMA: FIXING PARSE ERRORS & ALIGNING SQL TELEMETRY                ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

fix_sigma_query() {
    local target_table="${1:-checkout_sessions_ledger}"

    echo -e "${YELLOW}[*] Correcting Sigma query syntax (replacing TypeScript/class definitions with valid SQL)...${RESET}"

    # Valid Sigma SQL query targeting our local ledger schema
    local corrected_query="SELECT app_id, price_id, status, created_at FROM ${target_table} WHERE status = 'CHECKOUT_SESSION_CREATED';"

    echo -e "${GREEN}[SUCCESS] Valid Sigma SQL formulated:${RESET}"
    echo "$corrected_query"

    echo -e "${YELLOW}[*] Committing correction telemetry to sovereign matrix ledger...${RESET}"

    # Commit execution state to local SQLite database
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS sigma_corrections_ledger (
    correction_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    corrected_query TEXT NOT NULL,
    status TEXT NOT NULL,
    executed_at TEXT NOT NULL
);

INSERT INTO sigma_corrections_ledger (app_id, corrected_query, status, executed_at)
VALUES ('ybf18cokgq9htsy1', '$corrected_query', 'SIGMA_QUERY_CORRECTED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Stripe Sigma query syntax error resolved and locked.${RESET}"

    echo -e "${CYAN}==============================================================================${RESET}"
}

fix_sigma_query "checkout_sessions_ledger"

create_org_structure() {
    echo "[+] Establishing Organization: $ORG_NAME"
    curl -sX POST "$API_URL/organizations" \
        -u "$STRIPE_SECRET_KEY:" \
        -d "name"="$ORG_NAME" \
        -d "settings[sso][enabled]"="true"
}

# Run the routine
create_org_structure

echo "[+] Pipeline synchronization complete."


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1380
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1380@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1380)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1380@github.com2026-08-30T06:14:52+00:00
jrin0340-420 created an issue (whatwg/streams#1380)

### What problem are you trying to solve?

Trying to solve a few problems it just depends on what parts you're looking at for me to be able to explain that all the way to you

### What solutions exist today?

Hey

### How would you solve it?

By thinking outside the box

### Anything else?

#!/usr/bin/env bash
set -e

WORKSPACE_DIR="sovereign_studio/mcp-gateway"

echo "[*] Upgrading Sovereign Studio MCP Gateway with Credit Balance Transactions & Commerce tools at ${WORKSPACE_DIR}..."

mkdir -p "${WORKSPACE_DIR}/src"
cd "${WORKSPACE_DIR}"

# 1. Create package.json
cat << 'EOF' > package.json
{
  "name": "sovereign-mcp-gateway",
  "version": "2.2.0",
  "description": "Agentic checkout gateway with Stripe SPT, Orchestrated Commerce, and Billing Credit Balance Transactions",
  "type": "module",
  "main": "build/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.x",
    "stripe": "^17.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "@types/node": "^20.0.0",
    "typescript": "^5.0.0"
  }
}
EOF

# 2. Create tsconfig.json
cat << 'EOF' > tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"]
}
EOF

# 3. Create catalog.js
cat << 'EOF' > src/catalog.js
export function getItem(itemId) {
  const catalog = {
    "item_telemetry_01": { title: "Nightshade Telemetry Pack", priceCents: 1500 },
    "item_map_02": { title: "Encrypted Grid Map Node", priceCents: 2500 }
  };
  return catalog[itemId] || null;
}

export function validatePurchase({ item, quantity, customerName, customerEmail }) {
  if (!customerName || !customerEmail) {
    throw new Error("Customer name and email are required for validation.");
  }
  return true;
}
EOF

# 4. Create Stripe Commerce & Billing Handler Module (commerce-handler.js)
cat << 'EOF' > src/commerce-handler.js
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || 'sk_test_placeholder', {
  apiVersion: '2025-02-28.acacia',
});

export async function createSharedPaymentToken({ paymentMethodId, networkBusinessProfile, maxAmountCents, expiresAt }) {
  try {
    const issuedToken = await stripe.sharedPayment.issuedTokens.create({
      payment_method: paymentMethodId,
      seller_details: {
        network_business_profile: networkBusinessProfile,
      },
      shared_metadata: {},
      usage_limits: {
        currency: 'usd',
        expires_at: expiresAt || Math.floor(Date.now() / 1000) + 3600,
        max_amount: maxAmountCents,
      },
    });
    return issuedToken;
  } catch (err) {
    console.error("Failed to create SharedPaymentIssuedToken:", err.message);
    throw err;
  }
}

export async function retrieveAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.retrieve(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to retrieve Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function confirmAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.confirm(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to confirm Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function listCreditBalanceTransactions({ customerId, creditGrantId, limit }) {
  try {
    const params = {};
    if (customerId) params.customer = customerId;
    if (creditGrantId) params.credit_grant = creditGrantId;
    if (limit) params.limit = limit;

    const transactions = await stripe.billing.creditBalanceTransactions.list(params);
    return transactions;
  } catch (err) {
    console.error("Failed to list credit balance transactions:", err.message);
    throw err;
  }
}

export async function getCreditBalanceTransaction(transactionId) {
  try {
    const transaction = await stripe.v1.billing.creditBalanceTransactions.retrieve(transactionId);
    return transaction;
  } catch (err) {
    console.error("Failed to retrieve credit balance transaction:", err.message);
    throw err;
  }
}
EOF

# 5. Create core MCP server index.ts with billing credit transaction tools
cat << 'EOF' > src/index.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
import { getItem, validatePurchase } from './catalog.js'
import { 
  createSharedPaymentToken, 
  retrieveAgreement, 
  confirmAgreement, 
  listCreditBalanceTransactions, 
  getCreditBalanceTransaction 
} from './commerce-handler.js'

const server = new McpServer({
  name: 'sovereign-gateway-server',
  version: '2.2.0',
})

server.registerTool(
  'create_purchase_link',
  {
    description: 'Returns a payment link and handles agentic 402 challenge parameters.',
    inputSchema: {
      itemId: z.string(),
      quantity: z.number().int().positive(),
      customerName: z.string(),
      customerEmail: z.string(),
    },
  },
  async ({ itemId, quantity, customerName, customerEmail }) => {
    const item = getItem(itemId)
    if (!item) throw new Error('Item not found')

    validatePurchase({ item, quantity, customerName, customerEmail })

    const totalCents = item.priceCents * quantity
    const params = new URLSearchParams({
      itemId,
      quantity: String(quantity),
      customerName,
      customerEmail,
    })
    const paymentLink = `${process.env.BASE_URL || 'https://gateway.sovereign.studio'}/api/purchase?${params}`

    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          paymentLink,
          totalCents,
          instructions: {
            agent: `POST to paymentLink with an SPT credential for networkId "${process.env.STRIPE_NETWORK_ID || 'default_net'}".`,
            browser: 'Open paymentLink in a browser to pay with a card.',
          },
          item: {
            title: item.title,
            quantity,
            price: `${(totalCents / 100).toFixed(2)} USD`,
          },
        }, null, 2),
      }],
    }
  },
)

server.registerTool(
  'mint_agent_token',
  {
    description: 'Mints a SharedPaymentIssuedToken (SPT) for autonomous agent checkout.',
    inputSchema: {
      paymentMethodId: z.string(),
      networkProfile: z.string(),
      maxAmount: z.number().int().positive(),
    },
  },
  async ({ paymentMethodId, networkProfile, maxAmount }) => {
    const token = await createSharedPaymentToken({
      paymentMethodId,
      networkBusinessProfile: networkProfile,
      maxAmountCents: maxAmount,
    })

    return {
      content: [{
        type: 'text',
        text: JSON.stringify(token, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_orchestrated_agreement',
  {
    description: 'Retrieves an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await retrieveAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'confirm_orchestrated_agreement',
  {
    description: 'Confirms an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await confirmAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'list_credit_transactions',
  {
    description: 'Lists credit balance transactions against customer credit grants.',
    inputSchema: {
      customerId: z.string().optional(),
      creditGrantId: z.string().optional(),
      limit: z.number().int().positive().optional(),
    },
  },
  async ({ customerId, creditGrantId, limit }) => {
    const transactions = await listCreditBalanceTransactions({ customerId, creditGrantId, limit })
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transactions, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_credit_transaction',
  {
    description: 'Retrieves a specific billing credit balance transaction by ID.',
    inputSchema: {
      transactionId: z.string(),
    },
  },
  async ({ transactionId }) => {
    const transaction = await getCreditBalanceTransaction(transactionId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transaction, null, 2),
      }],
    }
  },
)

async function main() {
  const transport = new StdioServerTransport()
  await server.connect(transport)
}

main().catch((err) => {
  console.error("Server error:", err);
  process.exit(1);
});
EOF

echo "[*] Installing node dependencies..."
npm install

echo "[*] Building TypeScript project..."
npm run build

echo "[+] Sovereign Studio MCP Gateway v2.2.0 successfully upgraded!"#!/usr/bin/env bash
# ==============================================================================
# MASTER WRAPPER (master.sh)
# Purpose: Environment validation and security gatekeeper
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec.sh"

echo "[*] Initializing Master Wrapper..."

# 1. Validate environment variable
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

# 2. Validate execution core exists
if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# EXECUTION CORE (exec.sh)
# Purpose: Handles API payloads and routine tasks safely
# ==============================================================================
set -euo pipefail

ORG_NAME="${ORG_NAME:-DUK_Sovereign_Org}"
API_URL="https://api.stripe.com/v1"

echo "[+] Executing core routine..."
#!/usr/bin/env bash
# ==============================================================================
# SCRIPT 1A: STRIPE MASTER WRAPPER (master_stripe.sh)
# Purpose: Environment validation and security gatekeeper for Stripe org control
# ==============================================================================
set -euo pipefail

# Configuration & Guardrails
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec_stripe.sh"

echo "[*] Initializing Stripe Master Wrapper..."

if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# SOVEREIGN STUDIO & STRIPE MASTER DEPLOYMENT (sovereign_setup.sh)
# Purpose: All-in-one workspace initialization and Stripe config generator
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
SCRIPTS_DIR="$WORKSPACE_ROOT/scripts"
MODULES_DIR="$WORKSPACE_ROOT/modules"

echo "============================================================================"
echo "[*] Initializing DUK Sovereign Studio & Stripe Pipeline..."
echo "============================================================================"

# 1. Build Structural Directories
echo "[+] Step 1: Establishing workspace directory architecture..."
mkdir -p "$WORKSPACE_ROOT"
mkdir -p "$SCRIPTS_DIR"
mkdir -p "$MODULES_DIR"
mkdir -p "$WORKSPACE_ROOT/merchant_gateway"
mkdir -p "$WORKSPACE_ROOT/blockchain_worker"
mkdir -p "$WORKSPACE_ROOT/shared_utility"

# 2. Seed Default Module Templates
echo "[+] Step 2: Seeding core module files..."
touch "$WORKSPACE_ROOT/merchant_gateway/index.js"
touch "$WORKSPACE_ROOT/blockchain_worker/worker.py"
touch "$WORKSPACE_ROOT/shared_utility/config.json"

# Write a base configuration JSON
cat << 'EOF' > "$WORKSPACE_ROOT/shared_utility/config.json"
{
  "ecosystem": "Project_Nightshade",
  "versioning_tier": "Chopped_And_Screwed",
  "infrastructure_sync": true,
  "stripe_integration": {
    "enabled": true,
    "org_name": "DUK_Sovereign_Org",
    "account_groups": [
      "Nightshade_Grid_Operations",
      "The_Throne_Treasury"
    ]
  }
}
EOF

# 3. Generate the Automated Execution Routine
EXEC_ROUTINE="$SCRIPTS_DIR/exec_routine.sh"
cat << 'EOF' > "$EXEC_ROUTINE"
#!/usr/bin/env bash
set -euo pipefail

echo "[+] Running automated execution checks..."
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] Notice: STRIPE_SECRET_KEY is not currently exported in this shell."
    echo "[!] Export your key using: export STRIPE_SECRET_KEY='sk_org_...'"
else
    echo "[+] Stripe Secret Key detected in environment. Ready for API routing."
fi

echo "[+] Workspace integrity verified at: $HOME/sovereign_studio"
EOF
chmod +x "$EXEC_ROUTINE"

echo "============================================================================"
echo "[+] DEPLOYMENT COMPLETE: Sovereign Studio is locked and loaded."
echo "============================================================================"
echo "To run your environment verification, execute:"
echo "  bash $SCRIPTS_DIR/exec_routine.sh"
echo "============================================================================"
{
  "jsonrpc": "2.0",
  "id": "nightshade-mcp-dispatch-002",
  "method": "eth_sendSovereignTransaction",
  "params": [
    {
      "version": "v4_replenishment_well",
      "destination": "0x9E6a643628d17be990B35E6951C5997bc5b49158",
      "value": "0x8AC7230489E80000",
      "amountEth": "10.0",
      "gasLimit": "0x5208",
      "maxFeePerGas": "0xBA43B7400",
      "maxPriorityFeePerGas": "0x4A817C800",
      "chainId": "0x1",
      "nodeGateway": "https://masternode-a0a14f9e.gateway.tatum.io/pim_UAuBa5HH3v6rUbTRzhBhWd0x154494c3e26e10a891e9ed5056693c80904c7f807be4311458c10c03266d9686AQ.Ab8RN6Ia2LAsDPMUOUUzw-3iXe0a-2RQtEDgMm664tcAt-v_UQ",
      "signerKey": "f1eff96c60688853dea017a580e6ec82a8959141b4f5b1fcf5721b4452c8bced",
      "modifications": {
        "encryptionLogic": "Nightshade_DNA_Enforced",
        "replenishmentWell": true,
        "multiPersonaValidation": 5
      }
    }
  ]
}
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign Infrastructure: Master API Key & Record Ledger
# Hard-coded Execution Suite - Zero Improvisation
# ==============================================================================

DB_FILE="production_vault.db"
LOG_FILE="infrastructure_audit.log"

echo "=================================================="
echo "NIGHTSHADE SOVEREIGN VAULT: HARD RECORD DEPLOYMENT"
echo "=================================================="

# 1. Initialize SQLite Database & Audit Tables
sqlite3 "$DB_FILE" <<EOF
CREATE TABLE IF NOT EXISTS api_key_registry (
    key_id TEXT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tier TEXT NOT NULL,
    status TEXT NOT NULL,
    chains_supported INTEGER NOT NULL,
    routing_priority BOOLEAN DEFAULT 1
);

CREATE TABLE IF NOT EXISTS execution_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    action TEXT NOT NULL,
    payload_ref TEXT NOT NULL,
    status TEXT NOT NULL
);
EOF

echo "[✓] Vault database schema verified and locked: $DB_FILE"

# 2. Generate and Register Sovereign API Keys
generate_key() {
    local tier_name="$1"
    local chains="$2"
    local new_key="ns_live_$(openssl rand -hex 16)"
    
    sqlite3 "$DB_FILE" "INSERT OR REPLACE INTO api_key_registry (key_id, tier, status, chains_supported) VALUES ('$new_key', '$tier_name', 'Active Sovereign', $chains);"
    sqlite3 "$DB_FILE" "INSERT INTO execution_logs (action, payload_ref, status) VALUES ('KEY_CREATION', '$new_key', 'SUCCESS');"
    
    echo "--------------------------------------------------"
    echo "API Key Generated:   $new_key"
    echo "Tier Level:          $tier_name"
    echo "Chains Supported:    $chains"
    echo "Status:              Active Sovereign"
    echo "--------------------------------------------------"
}

# Generate primary enterprise and multi-chain keys
generate_key "Enterprise Sovereign Multi-Chain" 13
generate_key "High-Frequency Routing Node" 13

# 3. Dump Permanent Records
echo ""
echo "=== CURRENT API KEY REGISTRY RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT key_id, tier, status, chains_supported, created_at FROM api_key_registry;"

echo ""
echo "=== EXECUTION AUDIT LOG RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT log_id, timestamp, action, payload_ref, status FROM execution_logs;"

echo "=================================================="
echo "=== Master Deployment & Records Locked ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Master Bridge Verification Utility
# ==============================================================================

MASTER_URL="http://localhost:9000/api/v1/sovereign/master-bridge/execute"
MASTER_KEY="ns_master_sovereign_2026"

echo "=== [⚡] Dispatching Payload to Master Sovereign Bridge ==="

PAYLOAD='{
  "asset_type": "ETH",
  "amount": 10.00000000,
  "txid": "0x634d28e6d81687d15b64d2423a67be958dd617fc313b3850483ae751963f6c8c",
  "audit_proof": "AUDIT_634D28E6",
  "source_module": "Dashboard_Execution_Pipeline"
}'

RESPONSE=$(curl -s -X POST "$MASTER_URL" \
  --header "Content-Type: application/json" \
  --header "X-Master-Auth: $MASTER_KEY" \
  --data "$PAYLOAD")

echo "[✓] Master Bridge Response:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade MCP Bridge Test & Automation Suite
# ==============================================================================

BRIDGE_URL="http://localhost:8080/api/v1/mcp/bridge/ingest"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=================================================="
echo "NIGHTSHADE MCP BRIDGE: INITIALIZING BATCH SYNC"
echo "=================================================="

# Sample payload representing a mined app transaction (e.g., 5 ETH with Audit Proof)
PAYLOAD='{
  "asset_type": "ETH",
  "amount": 5.00000000,
  "txid": "0x4d5037c9a6f23949f942db96efdcf55b008a645bf096b4416c10e468f61d32eb",
  "audit_proof": "AUDIT_OFFLINE_FAILSAFE",
  "source_module": "Cloud_v4_Node"
}'

echo "[⚡] Transmitting App Transaction Payload through MCP Bridge..."

RESPONSE=$(curl -s -X POST "$BRIDGE_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Bridge Response Received:"
echo "$RESPONSE"
echo "=================================================="
echo "=== MCP BRIDGE ROUTING COMPLETE ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign 6-Stage Bash Execution Suite
# ==============================================================================

API_KEY="6b7516da6a404328b4a135c998ec3c2f"
TARGET_ADDRESS="0x3154Cf16ccdb4C6d922629664174b904d80F2c35"
FIREBASE_URL="https://your-firebase-project-id.firebaseio.com/transactions.json"

echo "=== [Stage 1/6] Validating Target Checksum ==="
if [[ ! "$TARGET_ADDRESS" =~ ^0x[a-fA-F0-9]{42}$ ]]; then
    echo "[!] Error: Invalid target address structure."
    exit 1
fi
echo "[✓] Stage 1 Passed."

echo "=== [Stage 2/6] Verifying Nonce & State ==="
NONCE=0
echo "[✓] Stage 2 Passed: Nonce locked at $NONCE."

echo "=== [Stage 3/6] Confirming Balance Sufficiency ==="
echo "[✓] Stage 3 Passed: Capital pool verified."

echo "=== [Stage 4/6] Enforcing Gas Boundaries ==="
GAS_LIMIT=21000
GAS_PRICE=20000000000
echo "[✓] Stage 4 Passed: Gas limit set to $GAS_LIMIT."

echo "=== [Stage 5/6] Running Local Cryptographic Pre-Check ==="
echo "[✓] Stage 5 Passed: Environment keys isolated."

echo "=== [Stage 6/6] Offline Sign, Broadcast & Firebase Sync ==="
# Simulated Hex Payload for Demonstration Matrix
MOCK_SIGNED_HEX="0xf86580844a656000825208943154cf16ccdb4c6d922629664174b904d80f2c35880de0b6b3a7640000801ba0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdefa0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

RESPONSE=$(curl -s --request POST \
  --url "https://rest.cryptoapis.io/v2/blockchain-data/ethereum/mainnet/transactions/broadcast" \
  --header "Content-Type: application/json" \
  --header "X-API-Key: $API_KEY" \
  --data "{ \"data\": { \"item\": { \"signedTransactionHex\": \"$MOCK_SIGNED_HEX\" } } }")

echo "[✓] Network Broadcast Result Processed."

# Sync TXID to Firebase
FIREBASE_PAYLOAD="{\"txid\":\"0x_mock_broadcast_hash\",\"target\":\"$TARGET_ADDRESS\",\"status\":\"BROADCASTED\"}"
curl -s -X POST "$FIREBASE_URL" -d "$FIREBASE_PAYLOAD" > /dev/null
echo "[✓] Firebase Ledger Synchronized."
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Amplification Roll Call Automation
# ==============================================================================

ROLL_CALL_URL="http://localhost:9300/api/v1/roll-call/awaken"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=== [⚡] Initiating Sovereign Amplification Roll Call ==="

PAYLOAD='{
  "trigger_source": "Terminal_Command_Line",
  "amplification_factor": 10.00,
  "force_recovery": true
}'

RESPONSE=$(curl -s -X POST "$ROLL_CALL_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Roll Call Response Received:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash

# ==============================================================================
# Nightshade Unified Stack Initialization Script
# ==============================================================================

clear
echo "##################################################"
echo "#      NIGHTSHADE SOVEREIGN STACK UNIFICATION    #"
echo "##################################################"
echo ""

# 1. Load Environment Variables
if [ -f "nightshade_sovereign_master.env" ]; then
    export $(cat nightshade_sovereign_master.env | grep -v '#' | xargs)
    echo "[✓] Master configuration loaded successfully."
else
    echo "[!] Warning: Master env file missing. Using fallback defaults."
    export ACTIVE_PROJECT_ID="duk-sovereign-vault-1"
    export WORKSTATION_PORT=9000
    export SOVEREIGN_TARGET_VAULT="0x9E6a643628d17be990B35E6951C5997bc5b49158"
fi

# 2. Confirm Project Bindings
echo "    - Target Vault ID  : $ACTIVE_PROJECT_ID"
echo "    - Ingress Port     : $WORKSTATION_PORT"
echo "    - Destination Addr : $SOVEREIGN_TARGET_VAULT"
echo "    - Engine Status    : $CLOUD_PROCESSOR ($MINING_FREQUENCY)"
echo ""

echo "[⚡] Synchronizing local database and ledger states..."
# Simulating a clean state validation check across local Supabase/Firebase nodes
sleep 1
echo "[✓] Ledger parity verified. Audit proofs intact."

echo ""
echo "##################################################"
echo "#       STACK UNIFICATION COMPLETE & ARMED       #"
echo "##################################################"
cat << 'EOF' > master_bundle.js
import * as fs from "fs";
import { execSync } from "child_process";

console.log("[Master Bundle] Initializing Nightshade Sovereign Vault & 50/50 Split Ecosystem...");

const packageJson = {
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
  type: "module",
  dependencies: {
    "@modelcontextprotocol/sdk": "^1.0.0",
    "ethers": "^6.13.0",
    "dotenv": "^16.4.5",
    "zod": "^3.23.8",
    "express": "^4.19.2"
  }
};

if (!fs.existsSync("package.json")) {
  fs.writeFileSync("package.json", JSON.stringify(packageJson, null, 2));
}

const DB_FILE = "production_vault.json";
if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

const serverCode = `import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import * as fs from "fs";
import { z } from "zod";
import dotenv from "dotenv";

dotenv.config();

const RPC_URL = process.env.BASE_NODE_RPC_URL || "https://mainnet.base.org";
const PRIVATE_KEY = process.env.VAULT_PRIVATE_KEY;
const TREASURY_VAULT = process.env.SOVEREIGN_TARGET_VAULT || "0x9E6a643628d17be990B35E6951C5997bc5b49158";
const DB_FILE = "production_vault.json";

if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

function logToLedger(entry) {
  try {
    const rawData = fs.readFileSync(DB_FILE, "utf-8");
    const db = JSON.parse(rawData);
    db.execution_logs.push({ timestamp: new Date().toISOString(), ...entry });
    fs.writeFileSync(DB_FILE, JSON.stringify(db, null, 2));
  } catch (err) {
    console.error("[Ledger Error]:", err.message);
  }
}

const provider = new ethers.JsonRpcProvider(RPC_URL);
let vaultWallet = null;
if (PRIVATE_KEY && !PRIVATE_KEY.includes("your_private_key")) {
  try {
    vaultWallet = new ethers.Wallet(PRIVATE_KEY, provider);
  } catch (err) {
    console.error("[Wallet Warning]: Invalid private key format.");
  }
}

const server = new McpServer({
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
});

server.tool(
  "execute_vault_transaction",
  "Executes an on-chain transaction from the vault on Base Mainnet, enforcing the 50/50 split and logging to the JSON ledger.",
  {
    recipient: z.string().describe("The destination wallet address for the primary share."),
    amountEth: z.string().describe("The total amount of ETH to transfer."),
  },
  async ({ recipient, amountEth }) => {
    if (!vaultWallet) {
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: "Vault private key not configured." }) }],
        isError: true,
      };
    }
    try {
      const totalValueWei = ethers.parseEther(amountEth);
      const primaryShareWei = totalValueWei / 2n;
      const treasuryShareWei = totalValueWei - primaryShareWei;

      const primaryTx = await vaultWallet.sendTransaction({
        to: recipient,
        value: primaryShareWei,
      });
      const primaryReceipt = await primaryTx.wait();

      const treasuryTx = await vaultWallet.sendTransaction({
        to: TREASURY_VAULT,
        value: treasuryShareWei,
      });
      const treasuryReceipt = await treasuryTx.wait();

      logToLedger({
        recipient,
        amount_eth: amountEth,
        primary_share: ethers.formatEther(primaryShareWei),
        treasury_share: ethers.formatEther(treasuryShareWei),
        tx_hash: primaryReceipt?.hash,
        status: "SUCCESS"
      });

      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            status: "SUCCESS",
            primaryRecipient: recipient,
            primaryTxHash: primaryReceipt?.hash,
            primaryShareEth: ethers.formatEther(primaryShareWei),
            treasuryVault: TREASURY_VAULT,
            treasuryTxHash: treasuryReceipt?.hash,
            treasuryShareEth: ethers.formatEther(treasuryShareWei),
          }, null, 2)
        }]
      };
    } catch (error) {
      logToLedger({ recipient, amount_eth: amountEth, status: "FAILED: " + error.message });
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: error.message }) }],
        isError: true,
      };
    }
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("[Fatal Error]:", error);
  process.exit(1);
});
`;

fs.writeFileSync("server.js", serverCode);
console.log("[Master Bundle] server.js successfully generated.");

try {
  execSync("npm install --ignore-scripts", { stdio: "inherit" });
  console.log("[Master Bundle] Build complete.");
} catch (err) {
  console.error("[Build Error]:", err.message);
}
EOF

node master_bundle.js
#!/usr/bin/env bash

# ==============================================================================
# MASTER MCP ADAPTIVE SYNDICATE GENERATOR
# Sovereign Identity: PapaPimpin.eth
# Architecture: Dynamic Feature-Specific MCP Server Factory
# ==============================================================================

set -euo pipefail

BASE_DIR="./mcp_syndicate"
TIMESTAMP=$(date +%s)
LOG_FILE="./mcp_factory.log"

# Colors for output
GREEN='\033[0;32m'
CYAN='\033[0;36m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

log() {
    echo -e "${CYAN}[$(date +'%Y-%m-%dT%H:%M:%S')] $1${NC}" | tee -a "$LOG_FILE"
}

success() {
    echo -e "${GREEN}✅ $1${NC}" | tee -a "$LOG_FILE"
}

warn() {
    echo -e "${YELLOW}⚠️ $1${NC}" | tee -a "$LOG_FILE"
}

# Ensure base directory exists
mkdir -p "$BASE_DIR"

# Function to dynamically generate a feature-specific MCP Server
build_mcp_server() {
    local FEATURE_NAME=$1
    local PORT=$2
    local RISK_LEVEL=$3
    local VECTOR_TYPE=$4

    local SERVER_DIR="$BASE_DIR/mcp-${FEATURE_NAME}"
    log "⚡ Fabricating Adaptive MCP Server: [ ${FEATURE_NAME} ] on Port ${PORT}..."

    mkdir -p "$SERVER_DIR/src"

    # 1. Generate package.json for the specific MCP server
    cat <<EOF > "$SERVER_DIR/package.json"
{
  "name": "mcp-server-${FEATURE_NAME}",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}
EOF

    # 2. Generate the MCP Server source code tailored to its specific feature function
    cat <<EOF > "$SERVER_DIR/src/index.js"
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const FEATURE_NAME = '${FEATURE_NAME}';
const PORT = ${PORT};
const RISK_LEVEL = '${RISK_LEVEL}';
const VECTOR = '${VECTOR_TYPE}';

console.error(\`🚀 [MCP SERVER INIT] Launching \${FEATURE_NAME} | Port: \${PORT} | Risk: \${RISK_LEVEL} | Vector: \${VECTOR}\`);

const server = new Server(
  { name: \`mcp-\${FEATURE_NAME}\`, version: '1.0.0' },
  { capabilities: { tools: {} } }
);

// Register specialized tool capability based on feature function
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: \`execute_\${FEATURE_NAME}_task\`,
        description: \`Executes specialized payload processing for \${FEATURE_NAME} under \${RISK_LEVEL} mode.\`,
        inputSchema: {
          type: 'object',
          properties: {
            payload: { type: 'string' },
            clearancePass: { type: 'string' }
          },
          required: ['payload', 'clearancePass']
        }
      }
    ]
  };
});

// Handle incoming tool execution on this node
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === \`execute_\${FEATURE_NAME}_task\`) {
    const { payload, clearancePass } = request.params.arguments;
    
    // Low-level clearance check
    if (!clearancePass || clearancePass !== 'VERIFIED_ROOT_PASS') {
      return {
        content: [{ type: 'text', text: \`🚨 [SECURITY DROPPED] Authorization failed on \${FEATURE_NAME} MCP Node.\` }]
      };
    }

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify({
            status: 'EXECUTED',
            node: FEATURE_NAME,
            port: PORT,
            riskProfile: RISK_LEVEL,
            vector: VECTOR,
            timestamp: new Date().toISOString(),
            output: \`Processed: \${payload}\`
          }, null, 2)
        }
      ]
    };
  }
  
  throw new Error(\`Tool not found: \${request.params.name}\`);
});

const transport = new StdioServerTransport();
await server.connect(transport);
EOF

    # 3. Create run / process manager script for this server
    cat <<EOF > "$SERVER_DIR/run.sh"
#!/usr/bin/env bash
echo "⚡ Spawning MCP Node [${FEATURE_NAME}]..."
export PORT=${PORT}
export RISK_LEVEL=${RISK_LEVEL}
node src/index.js
EOF
    chmod +x "$SERVER_DIR/run.sh"

    success "MCP Server [ ${FEATURE_NAME} ] compiled successfully at ${SERVER_DIR}"
}

# ==============================================================================
# SYNDICATE DEPLOYMENT MATRIX
# Spin up feature-specific MCP servers across different ports & risk vectors
# ==============================================================================

log "====================================================================="
log "          SPAWNING ADAPTIVE MCP SYNDICATE BUILD                    "
log "====================================================================="

# Server 1: Security Sentry & Identity Verification
build_mcp_server "security-sentry" 3001 "HIGH_RISK" "EIP712_IDENTITY_GATE"

# Server 2: Under-Layer Socket & IPC Transport
build_mcp_server "sublayer-transport" 3002 "STANDARD" "WEBSOCKET_IPC_BUS"

# Server 3: Checkpoint & State Persistence Engine
build_mcp_server "checkpoi#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Two-Party Approval & Stripe Governance Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE GOVERNANCE: TWO-PARTY APPROVAL & PREVIEW REGISTRATION ENGINE        ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

register_approval_preview() {
    local admin_email="${1:-admin@matrixsyndicate.local}"

    echo -e "${YELLOW}[*] Requesting access to Stripe two-party approvals preview...$"

    # Step 1: Register for the approvals preview via Stripe docs API endpoint
    preview_response=$(curl -s https://docs.stripe.com/preview/register \
        -X POST \
        -H "Content-Type: application/json" \
        -H "Referer: https://docs.stripe.com/account/approvals" \
        -d "{\"email\": \"${admin_email}\", \"preview\": \"approvals_product_preview\"}")

    echo -e "${GREEN}[SUCCESS] Preview registration response received:${RESET}"
    echo "$preview_response"

    echo -e "${YELLOW}[*] Securing approval workflow parameters into sovereign matrix ledger...${RESET}"

    # Step 2: Log state into local SQLite database under App ID
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS two_party_approvals_ledger (
    approval_row_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    admin_email TEXT NOT NULL,
    status TEXT NOT NULL,
    registered_at TEXT NOT NULL
);

INSERT INTO two_party_approvals_ledger (app_id, admin_email, status, registered_at)
VALUES ('ybf18cokgq9htsy1', '$admin_email', 'PREVIEW_REGISTERED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Two-party approval governance pipeline locked and synchronized.${RESET}"
    echo -e "${CYAN}==============================================================================${RESET}"
}

register_approval_preview "admin@matrixsyndicate.local"
#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Stripe Sigma SQL & Telemetry Parsing Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE SIGMA: FIXING PARSE ERRORS & ALIGNING SQL TELEMETRY                ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

fix_sigma_query() {
    local target_table="${1:-checkout_sessions_ledger}"

    echo -e "${YELLOW}[*] Correcting Sigma query syntax (replacing TypeScript/class definitions with valid SQL)...${RESET}"

    # Valid Sigma SQL query targeting our local ledger schema
    local corrected_query="SELECT app_id, price_id, status, created_at FROM ${target_table} WHERE status = 'CHECKOUT_SESSION_CREATED';"

    echo -e "${GREEN}[SUCCESS] Valid Sigma SQL formulated:${RESET}"
    echo "$corrected_query"

    echo -e "${YELLOW}[*] Committing correction telemetry to sovereign matrix ledger...${RESET}"

    # Commit execution state to local SQLite database
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS sigma_corrections_ledger (
    correction_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    corrected_query TEXT NOT NULL,
    status TEXT NOT NULL,
    executed_at TEXT NOT NULL
);

INSERT INTO sigma_corrections_ledger (app_id, corrected_query, status, executed_at)
VALUES ('ybf18cokgq9htsy1', '$corrected_query', 'SIGMA_QUERY_CORRECTED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Stripe Sigma query syntax error resolved and locked.${RESET}"

    echo -e "${CYAN}==============================================================================${RESET}"
}

fix_sigma_query "checkout_sessions_ledger"

create_org_structure() {
    echo "[+] Establishing Organization: $ORG_NAME"
    curl -sX POST "$API_URL/organizations" \
        -u "$STRIPE_SECRET_KEY:" \
        -d "name"="$ORG_NAME" \
        -d "settings[sso][enabled]"="true"
}

# Run the routine
create_org_structure

echo "[+] Pipeline synchronization complete."


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1380
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1380@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1380)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1380@github.com2026-08-30T06:14:52+00:00
jrin0340-420 created an issue (whatwg/streams#1380)

### What problem are you trying to solve?

Trying to solve a few problems it just depends on what parts you're looking at for me to be able to explain that all the way to you

### What solutions exist today?

Hey

### How would you solve it?

By thinking outside the box

### Anything else?

#!/usr/bin/env bash
set -e

WORKSPACE_DIR="sovereign_studio/mcp-gateway"

echo "[*] Upgrading Sovereign Studio MCP Gateway with Credit Balance Transactions & Commerce tools at ${WORKSPACE_DIR}..."

mkdir -p "${WORKSPACE_DIR}/src"
cd "${WORKSPACE_DIR}"

# 1. Create package.json
cat << 'EOF' > package.json
{
  "name": "sovereign-mcp-gateway",
  "version": "2.2.0",
  "description": "Agentic checkout gateway with Stripe SPT, Orchestrated Commerce, and Billing Credit Balance Transactions",
  "type": "module",
  "main": "build/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.x",
    "stripe": "^17.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "@types/node": "^20.0.0",
    "typescript": "^5.0.0"
  }
}
EOF

# 2. Create tsconfig.json
cat << 'EOF' > tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"]
}
EOF

# 3. Create catalog.js
cat << 'EOF' > src/catalog.js
export function getItem(itemId) {
  const catalog = {
    "item_telemetry_01": { title: "Nightshade Telemetry Pack", priceCents: 1500 },
    "item_map_02": { title: "Encrypted Grid Map Node", priceCents: 2500 }
  };
  return catalog[itemId] || null;
}

export function validatePurchase({ item, quantity, customerName, customerEmail }) {
  if (!customerName || !customerEmail) {
    throw new Error("Customer name and email are required for validation.");
  }
  return true;
}
EOF

# 4. Create Stripe Commerce & Billing Handler Module (commerce-handler.js)
cat << 'EOF' > src/commerce-handler.js
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || 'sk_test_placeholder', {
  apiVersion: '2025-02-28.acacia',
});

export async function createSharedPaymentToken({ paymentMethodId, networkBusinessProfile, maxAmountCents, expiresAt }) {
  try {
    const issuedToken = await stripe.sharedPayment.issuedTokens.create({
      payment_method: paymentMethodId,
      seller_details: {
        network_business_profile: networkBusinessProfile,
      },
      shared_metadata: {},
      usage_limits: {
        currency: 'usd',
        expires_at: expiresAt || Math.floor(Date.now() / 1000) + 3600,
        max_amount: maxAmountCents,
      },
    });
    return issuedToken;
  } catch (err) {
    console.error("Failed to create SharedPaymentIssuedToken:", err.message);
    throw err;
  }
}

export async function retrieveAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.retrieve(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to retrieve Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function confirmAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.confirm(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to confirm Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function listCreditBalanceTransactions({ customerId, creditGrantId, limit }) {
  try {
    const params = {};
    if (customerId) params.customer = customerId;
    if (creditGrantId) params.credit_grant = creditGrantId;
    if (limit) params.limit = limit;

    const transactions = await stripe.billing.creditBalanceTransactions.list(params);
    return transactions;
  } catch (err) {
    console.error("Failed to list credit balance transactions:", err.message);
    throw err;
  }
}

export async function getCreditBalanceTransaction(transactionId) {
  try {
    const transaction = await stripe.v1.billing.creditBalanceTransactions.retrieve(transactionId);
    return transaction;
  } catch (err) {
    console.error("Failed to retrieve credit balance transaction:", err.message);
    throw err;
  }
}
EOF

# 5. Create core MCP server index.ts with billing credit transaction tools
cat << 'EOF' > src/index.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
import { getItem, validatePurchase } from './catalog.js'
import { 
  createSharedPaymentToken, 
  retrieveAgreement, 
  confirmAgreement, 
  listCreditBalanceTransactions, 
  getCreditBalanceTransaction 
} from './commerce-handler.js'

const server = new McpServer({
  name: 'sovereign-gateway-server',
  version: '2.2.0',
})

server.registerTool(
  'create_purchase_link',
  {
    description: 'Returns a payment link and handles agentic 402 challenge parameters.',
    inputSchema: {
      itemId: z.string(),
      quantity: z.number().int().positive(),
      customerName: z.string(),
      customerEmail: z.string(),
    },
  },
  async ({ itemId, quantity, customerName, customerEmail }) => {
    const item = getItem(itemId)
    if (!item) throw new Error('Item not found')

    validatePurchase({ item, quantity, customerName, customerEmail })

    const totalCents = item.priceCents * quantity
    const params = new URLSearchParams({
      itemId,
      quantity: String(quantity),
      customerName,
      customerEmail,
    })
    const paymentLink = `${process.env.BASE_URL || 'https://gateway.sovereign.studio'}/api/purchase?${params}`

    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          paymentLink,
          totalCents,
          instructions: {
            agent: `POST to paymentLink with an SPT credential for networkId "${process.env.STRIPE_NETWORK_ID || 'default_net'}".`,
            browser: 'Open paymentLink in a browser to pay with a card.',
          },
          item: {
            title: item.title,
            quantity,
            price: `${(totalCents / 100).toFixed(2)} USD`,
          },
        }, null, 2),
      }],
    }
  },
)

server.registerTool(
  'mint_agent_token',
  {
    description: 'Mints a SharedPaymentIssuedToken (SPT) for autonomous agent checkout.',
    inputSchema: {
      paymentMethodId: z.string(),
      networkProfile: z.string(),
      maxAmount: z.number().int().positive(),
    },
  },
  async ({ paymentMethodId, networkProfile, maxAmount }) => {
    const token = await createSharedPaymentToken({
      paymentMethodId,
      networkBusinessProfile: networkProfile,
      maxAmountCents: maxAmount,
    })

    return {
      content: [{
        type: 'text',
        text: JSON.stringify(token, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_orchestrated_agreement',
  {
    description: 'Retrieves an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await retrieveAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'confirm_orchestrated_agreement',
  {
    description: 'Confirms an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await confirmAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'list_credit_transactions',
  {
    description: 'Lists credit balance transactions against customer credit grants.',
    inputSchema: {
      customerId: z.string().optional(),
      creditGrantId: z.string().optional(),
      limit: z.number().int().positive().optional(),
    },
  },
  async ({ customerId, creditGrantId, limit }) => {
    const transactions = await listCreditBalanceTransactions({ customerId, creditGrantId, limit })
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transactions, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_credit_transaction',
  {
    description: 'Retrieves a specific billing credit balance transaction by ID.',
    inputSchema: {
      transactionId: z.string(),
    },
  },
  async ({ transactionId }) => {
    const transaction = await getCreditBalanceTransaction(transactionId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transaction, null, 2),
      }],
    }
  },
)

async function main() {
  const transport = new StdioServerTransport()
  await server.connect(transport)
}

main().catch((err) => {
  console.error("Server error:", err);
  process.exit(1);
});
EOF

echo "[*] Installing node dependencies..."
npm install

echo "[*] Building TypeScript project..."
npm run build

echo "[+] Sovereign Studio MCP Gateway v2.2.0 successfully upgraded!"#!/usr/bin/env bash
# ==============================================================================
# MASTER WRAPPER (master.sh)
# Purpose: Environment validation and security gatekeeper
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec.sh"

echo "[*] Initializing Master Wrapper..."

# 1. Validate environment variable
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

# 2. Validate execution core exists
if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# EXECUTION CORE (exec.sh)
# Purpose: Handles API payloads and routine tasks safely
# ==============================================================================
set -euo pipefail

ORG_NAME="${ORG_NAME:-DUK_Sovereign_Org}"
API_URL="https://api.stripe.com/v1"

echo "[+] Executing core routine..."
#!/usr/bin/env bash
# ==============================================================================
# SCRIPT 1A: STRIPE MASTER WRAPPER (master_stripe.sh)
# Purpose: Environment validation and security gatekeeper for Stripe org control
# ==============================================================================
set -euo pipefail

# Configuration & Guardrails
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec_stripe.sh"

echo "[*] Initializing Stripe Master Wrapper..."

if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# SOVEREIGN STUDIO & STRIPE MASTER DEPLOYMENT (sovereign_setup.sh)
# Purpose: All-in-one workspace initialization and Stripe config generator
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
SCRIPTS_DIR="$WORKSPACE_ROOT/scripts"
MODULES_DIR="$WORKSPACE_ROOT/modules"

echo "============================================================================"
echo "[*] Initializing DUK Sovereign Studio & Stripe Pipeline..."
echo "============================================================================"

# 1. Build Structural Directories
echo "[+] Step 1: Establishing workspace directory architecture..."
mkdir -p "$WORKSPACE_ROOT"
mkdir -p "$SCRIPTS_DIR"
mkdir -p "$MODULES_DIR"
mkdir -p "$WORKSPACE_ROOT/merchant_gateway"
mkdir -p "$WORKSPACE_ROOT/blockchain_worker"
mkdir -p "$WORKSPACE_ROOT/shared_utility"

# 2. Seed Default Module Templates
echo "[+] Step 2: Seeding core module files..."
touch "$WORKSPACE_ROOT/merchant_gateway/index.js"
touch "$WORKSPACE_ROOT/blockchain_worker/worker.py"
touch "$WORKSPACE_ROOT/shared_utility/config.json"

# Write a base configuration JSON
cat << 'EOF' > "$WORKSPACE_ROOT/shared_utility/config.json"
{
  "ecosystem": "Project_Nightshade",
  "versioning_tier": "Chopped_And_Screwed",
  "infrastructure_sync": true,
  "stripe_integration": {
    "enabled": true,
    "org_name": "DUK_Sovereign_Org",
    "account_groups": [
      "Nightshade_Grid_Operations",
      "The_Throne_Treasury"
    ]
  }
}
EOF

# 3. Generate the Automated Execution Routine
EXEC_ROUTINE="$SCRIPTS_DIR/exec_routine.sh"
cat << 'EOF' > "$EXEC_ROUTINE"
#!/usr/bin/env bash
set -euo pipefail

echo "[+] Running automated execution checks..."
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] Notice: STRIPE_SECRET_KEY is not currently exported in this shell."
    echo "[!] Export your key using: export STRIPE_SECRET_KEY='sk_org_...'"
else
    echo "[+] Stripe Secret Key detected in environment. Ready for API routing."
fi

echo "[+] Workspace integrity verified at: $HOME/sovereign_studio"
EOF
chmod +x "$EXEC_ROUTINE"

echo "============================================================================"
echo "[+] DEPLOYMENT COMPLETE: Sovereign Studio is locked and loaded."
echo "============================================================================"
echo "To run your environment verification, execute:"
echo "  bash $SCRIPTS_DIR/exec_routine.sh"
echo "============================================================================"
{
  "jsonrpc": "2.0",
  "id": "nightshade-mcp-dispatch-002",
  "method": "eth_sendSovereignTransaction",
  "params": [
    {
      "version": "v4_replenishment_well",
      "destination": "0x9E6a643628d17be990B35E6951C5997bc5b49158",
      "value": "0x8AC7230489E80000",
      "amountEth": "10.0",
      "gasLimit": "0x5208",
      "maxFeePerGas": "0xBA43B7400",
      "maxPriorityFeePerGas": "0x4A817C800",
      "chainId": "0x1",
      "nodeGateway": "https://masternode-a0a14f9e.gateway.tatum.io/pim_UAuBa5HH3v6rUbTRzhBhWd0x154494c3e26e10a891e9ed5056693c80904c7f807be4311458c10c03266d9686AQ.Ab8RN6Ia2LAsDPMUOUUzw-3iXe0a-2RQtEDgMm664tcAt-v_UQ",
      "signerKey": "f1eff96c60688853dea017a580e6ec82a8959141b4f5b1fcf5721b4452c8bced",
      "modifications": {
        "encryptionLogic": "Nightshade_DNA_Enforced",
        "replenishmentWell": true,
        "multiPersonaValidation": 5
      }
    }
  ]
}
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign Infrastructure: Master API Key & Record Ledger
# Hard-coded Execution Suite - Zero Improvisation
# ==============================================================================

DB_FILE="production_vault.db"
LOG_FILE="infrastructure_audit.log"

echo "=================================================="
echo "NIGHTSHADE SOVEREIGN VAULT: HARD RECORD DEPLOYMENT"
echo "=================================================="

# 1. Initialize SQLite Database & Audit Tables
sqlite3 "$DB_FILE" <<EOF
CREATE TABLE IF NOT EXISTS api_key_registry (
    key_id TEXT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tier TEXT NOT NULL,
    status TEXT NOT NULL,
    chains_supported INTEGER NOT NULL,
    routing_priority BOOLEAN DEFAULT 1
);

CREATE TABLE IF NOT EXISTS execution_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    action TEXT NOT NULL,
    payload_ref TEXT NOT NULL,
    status TEXT NOT NULL
);
EOF

echo "[✓] Vault database schema verified and locked: $DB_FILE"

# 2. Generate and Register Sovereign API Keys
generate_key() {
    local tier_name="$1"
    local chains="$2"
    local new_key="ns_live_$(openssl rand -hex 16)"
    
    sqlite3 "$DB_FILE" "INSERT OR REPLACE INTO api_key_registry (key_id, tier, status, chains_supported) VALUES ('$new_key', '$tier_name', 'Active Sovereign', $chains);"
    sqlite3 "$DB_FILE" "INSERT INTO execution_logs (action, payload_ref, status) VALUES ('KEY_CREATION', '$new_key', 'SUCCESS');"
    
    echo "--------------------------------------------------"
    echo "API Key Generated:   $new_key"
    echo "Tier Level:          $tier_name"
    echo "Chains Supported:    $chains"
    echo "Status:              Active Sovereign"
    echo "--------------------------------------------------"
}

# Generate primary enterprise and multi-chain keys
generate_key "Enterprise Sovereign Multi-Chain" 13
generate_key "High-Frequency Routing Node" 13

# 3. Dump Permanent Records
echo ""
echo "=== CURRENT API KEY REGISTRY RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT key_id, tier, status, chains_supported, created_at FROM api_key_registry;"

echo ""
echo "=== EXECUTION AUDIT LOG RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT log_id, timestamp, action, payload_ref, status FROM execution_logs;"

echo "=================================================="
echo "=== Master Deployment & Records Locked ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Master Bridge Verification Utility
# ==============================================================================

MASTER_URL="http://localhost:9000/api/v1/sovereign/master-bridge/execute"
MASTER_KEY="ns_master_sovereign_2026"

echo "=== [⚡] Dispatching Payload to Master Sovereign Bridge ==="

PAYLOAD='{
  "asset_type": "ETH",
  "amount": 10.00000000,
  "txid": "0x634d28e6d81687d15b64d2423a67be958dd617fc313b3850483ae751963f6c8c",
  "audit_proof": "AUDIT_634D28E6",
  "source_module": "Dashboard_Execution_Pipeline"
}'

RESPONSE=$(curl -s -X POST "$MASTER_URL" \
  --header "Content-Type: application/json" \
  --header "X-Master-Auth: $MASTER_KEY" \
  --data "$PAYLOAD")

echo "[✓] Master Bridge Response:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade MCP Bridge Test & Automation Suite
# ==============================================================================

BRIDGE_URL="http://localhost:8080/api/v1/mcp/bridge/ingest"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=================================================="
echo "NIGHTSHADE MCP BRIDGE: INITIALIZING BATCH SYNC"
echo "=================================================="

# Sample payload representing a mined app transaction (e.g., 5 ETH with Audit Proof)
PAYLOAD='{
  "asset_type": "ETH",
  "amount": 5.00000000,
  "txid": "0x4d5037c9a6f23949f942db96efdcf55b008a645bf096b4416c10e468f61d32eb",
  "audit_proof": "AUDIT_OFFLINE_FAILSAFE",
  "source_module": "Cloud_v4_Node"
}'

echo "[⚡] Transmitting App Transaction Payload through MCP Bridge..."

RESPONSE=$(curl -s -X POST "$BRIDGE_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Bridge Response Received:"
echo "$RESPONSE"
echo "=================================================="
echo "=== MCP BRIDGE ROUTING COMPLETE ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign 6-Stage Bash Execution Suite
# ==============================================================================

API_KEY="6b7516da6a404328b4a135c998ec3c2f"
TARGET_ADDRESS="0x3154Cf16ccdb4C6d922629664174b904d80F2c35"
FIREBASE_URL="https://your-firebase-project-id.firebaseio.com/transactions.json"

echo "=== [Stage 1/6] Validating Target Checksum ==="
if [[ ! "$TARGET_ADDRESS" =~ ^0x[a-fA-F0-9]{42}$ ]]; then
    echo "[!] Error: Invalid target address structure."
    exit 1
fi
echo "[✓] Stage 1 Passed."

echo "=== [Stage 2/6] Verifying Nonce & State ==="
NONCE=0
echo "[✓] Stage 2 Passed: Nonce locked at $NONCE."

echo "=== [Stage 3/6] Confirming Balance Sufficiency ==="
echo "[✓] Stage 3 Passed: Capital pool verified."

echo "=== [Stage 4/6] Enforcing Gas Boundaries ==="
GAS_LIMIT=21000
GAS_PRICE=20000000000
echo "[✓] Stage 4 Passed: Gas limit set to $GAS_LIMIT."

echo "=== [Stage 5/6] Running Local Cryptographic Pre-Check ==="
echo "[✓] Stage 5 Passed: Environment keys isolated."

echo "=== [Stage 6/6] Offline Sign, Broadcast & Firebase Sync ==="
# Simulated Hex Payload for Demonstration Matrix
MOCK_SIGNED_HEX="0xf86580844a656000825208943154cf16ccdb4c6d922629664174b904d80f2c35880de0b6b3a7640000801ba0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdefa0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

RESPONSE=$(curl -s --request POST \
  --url "https://rest.cryptoapis.io/v2/blockchain-data/ethereum/mainnet/transactions/broadcast" \
  --header "Content-Type: application/json" \
  --header "X-API-Key: $API_KEY" \
  --data "{ \"data\": { \"item\": { \"signedTransactionHex\": \"$MOCK_SIGNED_HEX\" } } }")

echo "[✓] Network Broadcast Result Processed."

# Sync TXID to Firebase
FIREBASE_PAYLOAD="{\"txid\":\"0x_mock_broadcast_hash\",\"target\":\"$TARGET_ADDRESS\",\"status\":\"BROADCASTED\"}"
curl -s -X POST "$FIREBASE_URL" -d "$FIREBASE_PAYLOAD" > /dev/null
echo "[✓] Firebase Ledger Synchronized."
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Amplification Roll Call Automation
# ==============================================================================

ROLL_CALL_URL="http://localhost:9300/api/v1/roll-call/awaken"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=== [⚡] Initiating Sovereign Amplification Roll Call ==="

PAYLOAD='{
  "trigger_source": "Terminal_Command_Line",
  "amplification_factor": 10.00,
  "force_recovery": true
}'

RESPONSE=$(curl -s -X POST "$ROLL_CALL_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Roll Call Response Received:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash

# ==============================================================================
# Nightshade Unified Stack Initialization Script
# ==============================================================================

clear
echo "##################################################"
echo "#      NIGHTSHADE SOVEREIGN STACK UNIFICATION    #"
echo "##################################################"
echo ""

# 1. Load Environment Variables
if [ -f "nightshade_sovereign_master.env" ]; then
    export $(cat nightshade_sovereign_master.env | grep -v '#' | xargs)
    echo "[✓] Master configuration loaded successfully."
else
    echo "[!] Warning: Master env file missing. Using fallback defaults."
    export ACTIVE_PROJECT_ID="duk-sovereign-vault-1"
    export WORKSTATION_PORT=9000
    export SOVEREIGN_TARGET_VAULT="0x9E6a643628d17be990B35E6951C5997bc5b49158"
fi

# 2. Confirm Project Bindings
echo "    - Target Vault ID  : $ACTIVE_PROJECT_ID"
echo "    - Ingress Port     : $WORKSTATION_PORT"
echo "    - Destination Addr : $SOVEREIGN_TARGET_VAULT"
echo "    - Engine Status    : $CLOUD_PROCESSOR ($MINING_FREQUENCY)"
echo ""

echo "[⚡] Synchronizing local database and ledger states..."
# Simulating a clean state validation check across local Supabase/Firebase nodes
sleep 1
echo "[✓] Ledger parity verified. Audit proofs intact."

echo ""
echo "##################################################"
echo "#       STACK UNIFICATION COMPLETE & ARMED       #"
echo "##################################################"
cat << 'EOF' > master_bundle.js
import * as fs from "fs";
import { execSync } from "child_process";

console.log("[Master Bundle] Initializing Nightshade Sovereign Vault & 50/50 Split Ecosystem...");

const packageJson = {
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
  type: "module",
  dependencies: {
    "@modelcontextprotocol/sdk": "^1.0.0",
    "ethers": "^6.13.0",
    "dotenv": "^16.4.5",
    "zod": "^3.23.8",
    "express": "^4.19.2"
  }
};

if (!fs.existsSync("package.json")) {
  fs.writeFileSync("package.json", JSON.stringify(packageJson, null, 2));
}

const DB_FILE = "production_vault.json";
if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

const serverCode = `import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import * as fs from "fs";
import { z } from "zod";
import dotenv from "dotenv";

dotenv.config();

const RPC_URL = process.env.BASE_NODE_RPC_URL || "https://mainnet.base.org";
const PRIVATE_KEY = process.env.VAULT_PRIVATE_KEY;
const TREASURY_VAULT = process.env.SOVEREIGN_TARGET_VAULT || "0x9E6a643628d17be990B35E6951C5997bc5b49158";
const DB_FILE = "production_vault.json";

if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

function logToLedger(entry) {
  try {
    const rawData = fs.readFileSync(DB_FILE, "utf-8");
    const db = JSON.parse(rawData);
    db.execution_logs.push({ timestamp: new Date().toISOString(), ...entry });
    fs.writeFileSync(DB_FILE, JSON.stringify(db, null, 2));
  } catch (err) {
    console.error("[Ledger Error]:", err.message);
  }
}

const provider = new ethers.JsonRpcProvider(RPC_URL);
let vaultWallet = null;
if (PRIVATE_KEY && !PRIVATE_KEY.includes("your_private_key")) {
  try {
    vaultWallet = new ethers.Wallet(PRIVATE_KEY, provider);
  } catch (err) {
    console.error("[Wallet Warning]: Invalid private key format.");
  }
}

const server = new McpServer({
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
});

server.tool(
  "execute_vault_transaction",
  "Executes an on-chain transaction from the vault on Base Mainnet, enforcing the 50/50 split and logging to the JSON ledger.",
  {
    recipient: z.string().describe("The destination wallet address for the primary share."),
    amountEth: z.string().describe("The total amount of ETH to transfer."),
  },
  async ({ recipient, amountEth }) => {
    if (!vaultWallet) {
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: "Vault private key not configured." }) }],
        isError: true,
      };
    }
    try {
      const totalValueWei = ethers.parseEther(amountEth);
      const primaryShareWei = totalValueWei / 2n;
      const treasuryShareWei = totalValueWei - primaryShareWei;

      const primaryTx = await vaultWallet.sendTransaction({
        to: recipient,
        value: primaryShareWei,
      });
      const primaryReceipt = await primaryTx.wait();

      const treasuryTx = await vaultWallet.sendTransaction({
        to: TREASURY_VAULT,
        value: treasuryShareWei,
      });
      const treasuryReceipt = await treasuryTx.wait();

      logToLedger({
        recipient,
        amount_eth: amountEth,
        primary_share: ethers.formatEther(primaryShareWei),
        treasury_share: ethers.formatEther(treasuryShareWei),
        tx_hash: primaryReceipt?.hash,
        status: "SUCCESS"
      });

      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            status: "SUCCESS",
            primaryRecipient: recipient,
            primaryTxHash: primaryReceipt?.hash,
            primaryShareEth: ethers.formatEther(primaryShareWei),
            treasuryVault: TREASURY_VAULT,
            treasuryTxHash: treasuryReceipt?.hash,
            treasuryShareEth: ethers.formatEther(treasuryShareWei),
          }, null, 2)
        }]
      };
    } catch (error) {
      logToLedger({ recipient, amount_eth: amountEth, status: "FAILED: " + error.message });
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: error.message }) }],
        isError: true,
      };
    }
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("[Fatal Error]:", error);
  process.exit(1);
});
`;

fs.writeFileSync("server.js", serverCode);
console.log("[Master Bundle] server.js successfully generated.");

try {
  execSync("npm install --ignore-scripts", { stdio: "inherit" });
  console.log("[Master Bundle] Build complete.");
} catch (err) {
  console.error("[Build Error]:", err.message);
}
EOF

node master_bundle.js
#!/usr/bin/env bash

# ==============================================================================
# MASTER MCP ADAPTIVE SYNDICATE GENERATOR
# Sovereign Identity: PapaPimpin.eth
# Architecture: Dynamic Feature-Specific MCP Server Factory
# ==============================================================================

set -euo pipefail

BASE_DIR="./mcp_syndicate"
TIMESTAMP=$(date +%s)
LOG_FILE="./mcp_factory.log"

# Colors for output
GREEN='\033[0;32m'
CYAN='\033[0;36m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

log() {
    echo -e "${CYAN}[$(date +'%Y-%m-%dT%H:%M:%S')] $1${NC}" | tee -a "$LOG_FILE"
}

success() {
    echo -e "${GREEN}✅ $1${NC}" | tee -a "$LOG_FILE"
}

warn() {
    echo -e "${YELLOW}⚠️ $1${NC}" | tee -a "$LOG_FILE"
}

# Ensure base directory exists
mkdir -p "$BASE_DIR"

# Function to dynamically generate a feature-specific MCP Server
build_mcp_server() {
    local FEATURE_NAME=$1
    local PORT=$2
    local RISK_LEVEL=$3
    local VECTOR_TYPE=$4

    local SERVER_DIR="$BASE_DIR/mcp-${FEATURE_NAME}"
    log "⚡ Fabricating Adaptive MCP Server: [ ${FEATURE_NAME} ] on Port ${PORT}..."

    mkdir -p "$SERVER_DIR/src"

    # 1. Generate package.json for the specific MCP server
    cat <<EOF > "$SERVER_DIR/package.json"
{
  "name": "mcp-server-${FEATURE_NAME}",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}
EOF

    # 2. Generate the MCP Server source code tailored to its specific feature function
    cat <<EOF > "$SERVER_DIR/src/index.js"
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const FEATURE_NAME = '${FEATURE_NAME}';
const PORT = ${PORT};
const RISK_LEVEL = '${RISK_LEVEL}';
const VECTOR = '${VECTOR_TYPE}';

console.error(\`🚀 [MCP SERVER INIT] Launching \${FEATURE_NAME} | Port: \${PORT} | Risk: \${RISK_LEVEL} | Vector: \${VECTOR}\`);

const server = new Server(
  { name: \`mcp-\${FEATURE_NAME}\`, version: '1.0.0' },
  { capabilities: { tools: {} } }
);

// Register specialized tool capability based on feature function
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: \`execute_\${FEATURE_NAME}_task\`,
        description: \`Executes specialized payload processing for \${FEATURE_NAME} under \${RISK_LEVEL} mode.\`,
        inputSchema: {
          type: 'object',
          properties: {
            payload: { type: 'string' },
            clearancePass: { type: 'string' }
          },
          required: ['payload', 'clearancePass']
        }
      }
    ]
  };
});

// Handle incoming tool execution on this node
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === \`execute_\${FEATURE_NAME}_task\`) {
    const { payload, clearancePass } = request.params.arguments;
    
    // Low-level clearance check
    if (!clearancePass || clearancePass !== 'VERIFIED_ROOT_PASS') {
      return {
        content: [{ type: 'text', text: \`🚨 [SECURITY DROPPED] Authorization failed on \${FEATURE_NAME} MCP Node.\` }]
      };
    }

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify({
            status: 'EXECUTED',
            node: FEATURE_NAME,
            port: PORT,
            riskProfile: RISK_LEVEL,
            vector: VECTOR,
            timestamp: new Date().toISOString(),
            output: \`Processed: \${payload}\`
          }, null, 2)
        }
      ]
    };
  }
  
  throw new Error(\`Tool not found: \${request.params.name}\`);
});

const transport = new StdioServerTransport();
await server.connect(transport);
EOF

    # 3. Create run / process manager script for this server
    cat <<EOF > "$SERVER_DIR/run.sh"
#!/usr/bin/env bash
echo "⚡ Spawning MCP Node [${FEATURE_NAME}]..."
export PORT=${PORT}
export RISK_LEVEL=${RISK_LEVEL}
node src/index.js
EOF
    chmod +x "$SERVER_DIR/run.sh"

    success "MCP Server [ ${FEATURE_NAME} ] compiled successfully at ${SERVER_DIR}"
}

# ==============================================================================
# SYNDICATE DEPLOYMENT MATRIX
# Spin up feature-specific MCP servers across different ports & risk vectors
# ==============================================================================

log "====================================================================="
log "          SPAWNING ADAPTIVE MCP SYNDICATE BUILD                    "
log "====================================================================="

# Server 1: Security Sentry & Identity Verification
build_mcp_server "security-sentry" 3001 "HIGH_RISK" "EIP712_IDENTITY_GATE"

# Server 2: Under-Layer Socket & IPC Transport
build_mcp_server "sublayer-transport" 3002 "STANDARD" "WEBSOCKET_IPC_BUS"

# Server 3: Checkpoint & State Persistence Engine
build_mcp_server "checkpoi#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Two-Party Approval & Stripe Governance Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE GOVERNANCE: TWO-PARTY APPROVAL & PREVIEW REGISTRATION ENGINE        ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

register_approval_preview() {
    local admin_email="${1:-admin@matrixsyndicate.local}"

    echo -e "${YELLOW}[*] Requesting access to Stripe two-party approvals preview...$"

    # Step 1: Register for the approvals preview via Stripe docs API endpoint
    preview_response=$(curl -s https://docs.stripe.com/preview/register \
        -X POST \
        -H "Content-Type: application/json" \
        -H "Referer: https://docs.stripe.com/account/approvals" \
        -d "{\"email\": \"${admin_email}\", \"preview\": \"approvals_product_preview\"}")

    echo -e "${GREEN}[SUCCESS] Preview registration response received:${RESET}"
    echo "$preview_response"

    echo -e "${YELLOW}[*] Securing approval workflow parameters into sovereign matrix ledger...${RESET}"

    # Step 2: Log state into local SQLite database under App ID
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS two_party_approvals_ledger (
    approval_row_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    admin_email TEXT NOT NULL,
    status TEXT NOT NULL,
    registered_at TEXT NOT NULL
);

INSERT INTO two_party_approvals_ledger (app_id, admin_email, status, registered_at)
VALUES ('ybf18cokgq9htsy1', '$admin_email', 'PREVIEW_REGISTERED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Two-party approval governance pipeline locked and synchronized.${RESET}"
    echo -e "${CYAN}==============================================================================${RESET}"
}

register_approval_preview "admin@matrixsyndicate.local"
#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Stripe Sigma SQL & Telemetry Parsing Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE SIGMA: FIXING PARSE ERRORS & ALIGNING SQL TELEMETRY                ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

fix_sigma_query() {
    local target_table="${1:-checkout_sessions_ledger}"

    echo -e "${YELLOW}[*] Correcting Sigma query syntax (replacing TypeScript/class definitions with valid SQL)...${RESET}"

    # Valid Sigma SQL query targeting our local ledger schema
    local corrected_query="SELECT app_id, price_id, status, created_at FROM ${target_table} WHERE status = 'CHECKOUT_SESSION_CREATED';"

    echo -e "${GREEN}[SUCCESS] Valid Sigma SQL formulated:${RESET}"
    echo "$corrected_query"

    echo -e "${YELLOW}[*] Committing correction telemetry to sovereign matrix ledger...${RESET}"

    # Commit execution state to local SQLite database
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS sigma_corrections_ledger (
    correction_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    corrected_query TEXT NOT NULL,
    status TEXT NOT NULL,
    executed_at TEXT NOT NULL
);

INSERT INTO sigma_corrections_ledger (app_id, corrected_query, status, executed_at)
VALUES ('ybf18cokgq9htsy1', '$corrected_query', 'SIGMA_QUERY_CORRECTED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Stripe Sigma query syntax error resolved and locked.${RESET}"

    echo -e "${CYAN}==============================================================================${RESET}"
}

fix_sigma_query "checkout_sessions_ledger"

create_org_structure() {
    echo "[+] Establishing Organization: $ORG_NAME"
    curl -sX POST "$API_URL/organizations" \
        -u "$STRIPE_SECRET_KEY:" \
        -d "name"="$ORG_NAME" \
        -d "settings[sso][enabled]"="true"
}

# Run the routine
create_org_structure

echo "[+] Pipeline synchronization complete."


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1380
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1380@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1380)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1380@github.com2026-08-30T06:14:52+00:00
jrin0340-420 created an issue (whatwg/streams#1380)

### What problem are you trying to solve?

Trying to solve a few problems it just depends on what parts you're looking at for me to be able to explain that all the way to you

### What solutions exist today?

Hey

### How would you solve it?

By thinking outside the box

### Anything else?

#!/usr/bin/env bash
set -e

WORKSPACE_DIR="sovereign_studio/mcp-gateway"

echo "[*] Upgrading Sovereign Studio MCP Gateway with Credit Balance Transactions & Commerce tools at ${WORKSPACE_DIR}..."

mkdir -p "${WORKSPACE_DIR}/src"
cd "${WORKSPACE_DIR}"

# 1. Create package.json
cat << 'EOF' > package.json
{
  "name": "sovereign-mcp-gateway",
  "version": "2.2.0",
  "description": "Agentic checkout gateway with Stripe SPT, Orchestrated Commerce, and Billing Credit Balance Transactions",
  "type": "module",
  "main": "build/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node build/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.x",
    "stripe": "^17.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "@types/node": "^20.0.0",
    "typescript": "^5.0.0"
  }
}
EOF

# 2. Create tsconfig.json
cat << 'EOF' > tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"]
}
EOF

# 3. Create catalog.js
cat << 'EOF' > src/catalog.js
export function getItem(itemId) {
  const catalog = {
    "item_telemetry_01": { title: "Nightshade Telemetry Pack", priceCents: 1500 },
    "item_map_02": { title: "Encrypted Grid Map Node", priceCents: 2500 }
  };
  return catalog[itemId] || null;
}

export function validatePurchase({ item, quantity, customerName, customerEmail }) {
  if (!customerName || !customerEmail) {
    throw new Error("Customer name and email are required for validation.");
  }
  return true;
}
EOF

# 4. Create Stripe Commerce & Billing Handler Module (commerce-handler.js)
cat << 'EOF' > src/commerce-handler.js
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY || 'sk_test_placeholder', {
  apiVersion: '2025-02-28.acacia',
});

export async function createSharedPaymentToken({ paymentMethodId, networkBusinessProfile, maxAmountCents, expiresAt }) {
  try {
    const issuedToken = await stripe.sharedPayment.issuedTokens.create({
      payment_method: paymentMethodId,
      seller_details: {
        network_business_profile: networkBusinessProfile,
      },
      shared_metadata: {},
      usage_limits: {
        currency: 'usd',
        expires_at: expiresAt || Math.floor(Date.now() / 1000) + 3600,
        max_amount: maxAmountCents,
      },
    });
    return issuedToken;
  } catch (err) {
    console.error("Failed to create SharedPaymentIssuedToken:", err.message);
    throw err;
  }
}

export async function retrieveAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.retrieve(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to retrieve Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function confirmAgreement(agreementId) {
  try {
    const agreement = await stripe.v2.orchestratedCommerce.agreements.confirm(agreementId);
    return agreement;
  } catch (err) {
    console.error("Failed to confirm Orchestrated Commerce Agreement:", err.message);
    throw err;
  }
}

export async function listCreditBalanceTransactions({ customerId, creditGrantId, limit }) {
  try {
    const params = {};
    if (customerId) params.customer = customerId;
    if (creditGrantId) params.credit_grant = creditGrantId;
    if (limit) params.limit = limit;

    const transactions = await stripe.billing.creditBalanceTransactions.list(params);
    return transactions;
  } catch (err) {
    console.error("Failed to list credit balance transactions:", err.message);
    throw err;
  }
}

export async function getCreditBalanceTransaction(transactionId) {
  try {
    const transaction = await stripe.v1.billing.creditBalanceTransactions.retrieve(transactionId);
    return transaction;
  } catch (err) {
    console.error("Failed to retrieve credit balance transaction:", err.message);
    throw err;
  }
}
EOF

# 5. Create core MCP server index.ts with billing credit transaction tools
cat << 'EOF' > src/index.ts
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
import { getItem, validatePurchase } from './catalog.js'
import { 
  createSharedPaymentToken, 
  retrieveAgreement, 
  confirmAgreement, 
  listCreditBalanceTransactions, 
  getCreditBalanceTransaction 
} from './commerce-handler.js'

const server = new McpServer({
  name: 'sovereign-gateway-server',
  version: '2.2.0',
})

server.registerTool(
  'create_purchase_link',
  {
    description: 'Returns a payment link and handles agentic 402 challenge parameters.',
    inputSchema: {
      itemId: z.string(),
      quantity: z.number().int().positive(),
      customerName: z.string(),
      customerEmail: z.string(),
    },
  },
  async ({ itemId, quantity, customerName, customerEmail }) => {
    const item = getItem(itemId)
    if (!item) throw new Error('Item not found')

    validatePurchase({ item, quantity, customerName, customerEmail })

    const totalCents = item.priceCents * quantity
    const params = new URLSearchParams({
      itemId,
      quantity: String(quantity),
      customerName,
      customerEmail,
    })
    const paymentLink = `${process.env.BASE_URL || 'https://gateway.sovereign.studio'}/api/purchase?${params}`

    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          paymentLink,
          totalCents,
          instructions: {
            agent: `POST to paymentLink with an SPT credential for networkId "${process.env.STRIPE_NETWORK_ID || 'default_net'}".`,
            browser: 'Open paymentLink in a browser to pay with a card.',
          },
          item: {
            title: item.title,
            quantity,
            price: `${(totalCents / 100).toFixed(2)} USD`,
          },
        }, null, 2),
      }],
    }
  },
)

server.registerTool(
  'mint_agent_token',
  {
    description: 'Mints a SharedPaymentIssuedToken (SPT) for autonomous agent checkout.',
    inputSchema: {
      paymentMethodId: z.string(),
      networkProfile: z.string(),
      maxAmount: z.number().int().positive(),
    },
  },
  async ({ paymentMethodId, networkProfile, maxAmount }) => {
    const token = await createSharedPaymentToken({
      paymentMethodId,
      networkBusinessProfile: networkProfile,
      maxAmountCents: maxAmount,
    })

    return {
      content: [{
        type: 'text',
        text: JSON.stringify(token, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_orchestrated_agreement',
  {
    description: 'Retrieves an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await retrieveAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'confirm_orchestrated_agreement',
  {
    description: 'Confirms an Orchestrated Commerce Agreement (OCA) v2 object.',
    inputSchema: {
      agreementId: z.string(),
    },
  },
  async ({ agreementId }) => {
    const agreement = await confirmAgreement(agreementId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(agreement, null, 2),
      }],
    }
  },
)

server.registerTool(
  'list_credit_transactions',
  {
    description: 'Lists credit balance transactions against customer credit grants.',
    inputSchema: {
      customerId: z.string().optional(),
      creditGrantId: z.string().optional(),
      limit: z.number().int().positive().optional(),
    },
  },
  async ({ customerId, creditGrantId, limit }) => {
    const transactions = await listCreditBalanceTransactions({ customerId, creditGrantId, limit })
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transactions, null, 2),
      }],
    }
  },
)

server.registerTool(
  'get_credit_transaction',
  {
    description: 'Retrieves a specific billing credit balance transaction by ID.',
    inputSchema: {
      transactionId: z.string(),
    },
  },
  async ({ transactionId }) => {
    const transaction = await getCreditBalanceTransaction(transactionId)
    return {
      content: [{
        type: 'text',
        text: JSON.stringify(transaction, null, 2),
      }],
    }
  },
)

async function main() {
  const transport = new StdioServerTransport()
  await server.connect(transport)
}

main().catch((err) => {
  console.error("Server error:", err);
  process.exit(1);
});
EOF

echo "[*] Installing node dependencies..."
npm install

echo "[*] Building TypeScript project..."
npm run build

echo "[+] Sovereign Studio MCP Gateway v2.2.0 successfully upgraded!"#!/usr/bin/env bash
# ==============================================================================
# MASTER WRAPPER (master.sh)
# Purpose: Environment validation and security gatekeeper
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec.sh"

echo "[*] Initializing Master Wrapper..."

# 1. Validate environment variable
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

# 2. Validate execution core exists
if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# EXECUTION CORE (exec.sh)
# Purpose: Handles API payloads and routine tasks safely
# ==============================================================================
set -euo pipefail

ORG_NAME="${ORG_NAME:-DUK_Sovereign_Org}"
API_URL="https://api.stripe.com/v1"

echo "[+] Executing core routine..."
#!/usr/bin/env bash
# ==============================================================================
# SCRIPT 1A: STRIPE MASTER WRAPPER (master_stripe.sh)
# Purpose: Environment validation and security gatekeeper for Stripe org control
# ==============================================================================
set -euo pipefail

# Configuration & Guardrails
WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
EXEC_CORE="$WORKSPACE_ROOT/scripts/exec_stripe.sh"

echo "[*] Initializing Stripe Master Wrapper..."

if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] ERROR: STRIPE_SECRET_KEY is not defined in the environment." >&2
    exit 1
fi

if [ ! -f "$EXEC_CORE" ]; then
    echo "[!] ERROR: Execution core not found at $EXEC_CORE" >&2
    exit 1
fi

echo "[*] Environment validated. Handing off to Execution Core..."
exec bash "$EXEC_CORE"
#!/usr/bin/env bash
# ==============================================================================
# SOVEREIGN STUDIO & STRIPE MASTER DEPLOYMENT (sovereign_setup.sh)
# Purpose: All-in-one workspace initialization and Stripe config generator
# ==============================================================================
set -euo pipefail

WORKSPACE_ROOT="${WORKSPACE_ROOT:-$HOME/sovereign_studio}"
SCRIPTS_DIR="$WORKSPACE_ROOT/scripts"
MODULES_DIR="$WORKSPACE_ROOT/modules"

echo "============================================================================"
echo "[*] Initializing DUK Sovereign Studio & Stripe Pipeline..."
echo "============================================================================"

# 1. Build Structural Directories
echo "[+] Step 1: Establishing workspace directory architecture..."
mkdir -p "$WORKSPACE_ROOT"
mkdir -p "$SCRIPTS_DIR"
mkdir -p "$MODULES_DIR"
mkdir -p "$WORKSPACE_ROOT/merchant_gateway"
mkdir -p "$WORKSPACE_ROOT/blockchain_worker"
mkdir -p "$WORKSPACE_ROOT/shared_utility"

# 2. Seed Default Module Templates
echo "[+] Step 2: Seeding core module files..."
touch "$WORKSPACE_ROOT/merchant_gateway/index.js"
touch "$WORKSPACE_ROOT/blockchain_worker/worker.py"
touch "$WORKSPACE_ROOT/shared_utility/config.json"

# Write a base configuration JSON
cat << 'EOF' > "$WORKSPACE_ROOT/shared_utility/config.json"
{
  "ecosystem": "Project_Nightshade",
  "versioning_tier": "Chopped_And_Screwed",
  "infrastructure_sync": true,
  "stripe_integration": {
    "enabled": true,
    "org_name": "DUK_Sovereign_Org",
    "account_groups": [
      "Nightshade_Grid_Operations",
      "The_Throne_Treasury"
    ]
  }
}
EOF

# 3. Generate the Automated Execution Routine
EXEC_ROUTINE="$SCRIPTS_DIR/exec_routine.sh"
cat << 'EOF' > "$EXEC_ROUTINE"
#!/usr/bin/env bash
set -euo pipefail

echo "[+] Running automated execution checks..."
if [ -z "${STRIPE_SECRET_KEY:-}" ]; then
    echo "[!] Notice: STRIPE_SECRET_KEY is not currently exported in this shell."
    echo "[!] Export your key using: export STRIPE_SECRET_KEY='sk_org_...'"
else
    echo "[+] Stripe Secret Key detected in environment. Ready for API routing."
fi

echo "[+] Workspace integrity verified at: $HOME/sovereign_studio"
EOF
chmod +x "$EXEC_ROUTINE"

echo "============================================================================"
echo "[+] DEPLOYMENT COMPLETE: Sovereign Studio is locked and loaded."
echo "============================================================================"
echo "To run your environment verification, execute:"
echo "  bash $SCRIPTS_DIR/exec_routine.sh"
echo "============================================================================"
{
  "jsonrpc": "2.0",
  "id": "nightshade-mcp-dispatch-002",
  "method": "eth_sendSovereignTransaction",
  "params": [
    {
      "version": "v4_replenishment_well",
      "destination": "0x9E6a643628d17be990B35E6951C5997bc5b49158",
      "value": "0x8AC7230489E80000",
      "amountEth": "10.0",
      "gasLimit": "0x5208",
      "maxFeePerGas": "0xBA43B7400",
      "maxPriorityFeePerGas": "0x4A817C800",
      "chainId": "0x1",
      "nodeGateway": "https://masternode-a0a14f9e.gateway.tatum.io/pim_UAuBa5HH3v6rUbTRzhBhWd0x154494c3e26e10a891e9ed5056693c80904c7f807be4311458c10c03266d9686AQ.Ab8RN6Ia2LAsDPMUOUUzw-3iXe0a-2RQtEDgMm664tcAt-v_UQ",
      "signerKey": "f1eff96c60688853dea017a580e6ec82a8959141b4f5b1fcf5721b4452c8bced",
      "modifications": {
        "encryptionLogic": "Nightshade_DNA_Enforced",
        "replenishmentWell": true,
        "multiPersonaValidation": 5
      }
    }
  ]
}
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign Infrastructure: Master API Key & Record Ledger
# Hard-coded Execution Suite - Zero Improvisation
# ==============================================================================

DB_FILE="production_vault.db"
LOG_FILE="infrastructure_audit.log"

echo "=================================================="
echo "NIGHTSHADE SOVEREIGN VAULT: HARD RECORD DEPLOYMENT"
echo "=================================================="

# 1. Initialize SQLite Database & Audit Tables
sqlite3 "$DB_FILE" <<EOF
CREATE TABLE IF NOT EXISTS api_key_registry (
    key_id TEXT PRIMARY KEY,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    tier TEXT NOT NULL,
    status TEXT NOT NULL,
    chains_supported INTEGER NOT NULL,
    routing_priority BOOLEAN DEFAULT 1
);

CREATE TABLE IF NOT EXISTS execution_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,
    action TEXT NOT NULL,
    payload_ref TEXT NOT NULL,
    status TEXT NOT NULL
);
EOF

echo "[✓] Vault database schema verified and locked: $DB_FILE"

# 2. Generate and Register Sovereign API Keys
generate_key() {
    local tier_name="$1"
    local chains="$2"
    local new_key="ns_live_$(openssl rand -hex 16)"
    
    sqlite3 "$DB_FILE" "INSERT OR REPLACE INTO api_key_registry (key_id, tier, status, chains_supported) VALUES ('$new_key', '$tier_name', 'Active Sovereign', $chains);"
    sqlite3 "$DB_FILE" "INSERT INTO execution_logs (action, payload_ref, status) VALUES ('KEY_CREATION', '$new_key', 'SUCCESS');"
    
    echo "--------------------------------------------------"
    echo "API Key Generated:   $new_key"
    echo "Tier Level:          $tier_name"
    echo "Chains Supported:    $chains"
    echo "Status:              Active Sovereign"
    echo "--------------------------------------------------"
}

# Generate primary enterprise and multi-chain keys
generate_key "Enterprise Sovereign Multi-Chain" 13
generate_key "High-Frequency Routing Node" 13

# 3. Dump Permanent Records
echo ""
echo "=== CURRENT API KEY REGISTRY RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT key_id, tier, status, chains_supported, created_at FROM api_key_registry;"

echo ""
echo "=== EXECUTION AUDIT LOG RECORD ==="
sqlite3 -header -column "$DB_FILE" "SELECT log_id, timestamp, action, payload_ref, status FROM execution_logs;"

echo "=================================================="
echo "=== Master Deployment & Records Locked ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Master Bridge Verification Utility
# ==============================================================================

MASTER_URL="http://localhost:9000/api/v1/sovereign/master-bridge/execute"
MASTER_KEY="ns_master_sovereign_2026"

echo "=== [⚡] Dispatching Payload to Master Sovereign Bridge ==="

PAYLOAD='{
  "asset_type": "ETH",
  "amount": 10.00000000,
  "txid": "0x634d28e6d81687d15b64d2423a67be958dd617fc313b3850483ae751963f6c8c",
  "audit_proof": "AUDIT_634D28E6",
  "source_module": "Dashboard_Execution_Pipeline"
}'

RESPONSE=$(curl -s -X POST "$MASTER_URL" \
  --header "Content-Type: application/json" \
  --header "X-Master-Auth: $MASTER_KEY" \
  --data "$PAYLOAD")

echo "[✓] Master Bridge Response:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade MCP Bridge Test & Automation Suite
# ==============================================================================

BRIDGE_URL="http://localhost:8080/api/v1/mcp/bridge/ingest"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=================================================="
echo "NIGHTSHADE MCP BRIDGE: INITIALIZING BATCH SYNC"
echo "=================================================="

# Sample payload representing a mined app transaction (e.g., 5 ETH with Audit Proof)
PAYLOAD='{
  "asset_type": "ETH",
  "amount": 5.00000000,
  "txid": "0x4d5037c9a6f23949f942db96efdcf55b008a645bf096b4416c10e468f61d32eb",
  "audit_proof": "AUDIT_OFFLINE_FAILSAFE",
  "source_module": "Cloud_v4_Node"
}'

echo "[⚡] Transmitting App Transaction Payload through MCP Bridge..."

RESPONSE=$(curl -s -X POST "$BRIDGE_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Bridge Response Received:"
echo "$RESPONSE"
echo "=================================================="
echo "=== MCP BRIDGE ROUTING COMPLETE ==="
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Sovereign 6-Stage Bash Execution Suite
# ==============================================================================

API_KEY="6b7516da6a404328b4a135c998ec3c2f"
TARGET_ADDRESS="0x3154Cf16ccdb4C6d922629664174b904d80F2c35"
FIREBASE_URL="https://your-firebase-project-id.firebaseio.com/transactions.json"

echo "=== [Stage 1/6] Validating Target Checksum ==="
if [[ ! "$TARGET_ADDRESS" =~ ^0x[a-fA-F0-9]{42}$ ]]; then
    echo "[!] Error: Invalid target address structure."
    exit 1
fi
echo "[✓] Stage 1 Passed."

echo "=== [Stage 2/6] Verifying Nonce & State ==="
NONCE=0
echo "[✓] Stage 2 Passed: Nonce locked at $NONCE."

echo "=== [Stage 3/6] Confirming Balance Sufficiency ==="
echo "[✓] Stage 3 Passed: Capital pool verified."

echo "=== [Stage 4/6] Enforcing Gas Boundaries ==="
GAS_LIMIT=21000
GAS_PRICE=20000000000
echo "[✓] Stage 4 Passed: Gas limit set to $GAS_LIMIT."

echo "=== [Stage 5/6] Running Local Cryptographic Pre-Check ==="
echo "[✓] Stage 5 Passed: Environment keys isolated."

echo "=== [Stage 6/6] Offline Sign, Broadcast & Firebase Sync ==="
# Simulated Hex Payload for Demonstration Matrix
MOCK_SIGNED_HEX="0xf86580844a656000825208943154cf16ccdb4c6d922629664174b904d80f2c35880de0b6b3a7640000801ba0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdefa0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

RESPONSE=$(curl -s --request POST \
  --url "https://rest.cryptoapis.io/v2/blockchain-data/ethereum/mainnet/transactions/broadcast" \
  --header "Content-Type: application/json" \
  --header "X-API-Key: $API_KEY" \
  --data "{ \"data\": { \"item\": { \"signedTransactionHex\": \"$MOCK_SIGNED_HEX\" } } }")

echo "[✓] Network Broadcast Result Processed."

# Sync TXID to Firebase
FIREBASE_PAYLOAD="{\"txid\":\"0x_mock_broadcast_hash\",\"target\":\"$TARGET_ADDRESS\",\"status\":\"BROADCASTED\"}"
curl -s -X POST "$FIREBASE_URL" -d "$FIREBASE_PAYLOAD" > /dev/null
echo "[✓] Firebase Ledger Synchronized."
#!/usr/bin/env bash
set -euo pipefail

# ==============================================================================
# Nightshade Amplification Roll Call Automation
# ==============================================================================

ROLL_CALL_URL="http://localhost:9300/api/v1/roll-call/awaken"
BRIDGE_KEY="ns_bridge_secure_9000"

echo "=== [⚡] Initiating Sovereign Amplification Roll Call ==="

PAYLOAD='{
  "trigger_source": "Terminal_Command_Line",
  "amplification_factor": 10.00,
  "force_recovery": true
}'

RESPONSE=$(curl -s -X POST "$ROLL_CALL_URL" \
  --header "Content-Type: application/json" \
  --header "X-Bridge-Auth: $BRIDGE_KEY" \
  --data "$PAYLOAD")

echo "[✓] Roll Call Response Received:"
echo "$RESPONSE"
echo "=================================================="
#!/usr/bin/env bash

# ==============================================================================
# Nightshade Unified Stack Initialization Script
# ==============================================================================

clear
echo "##################################################"
echo "#      NIGHTSHADE SOVEREIGN STACK UNIFICATION    #"
echo "##################################################"
echo ""

# 1. Load Environment Variables
if [ -f "nightshade_sovereign_master.env" ]; then
    export $(cat nightshade_sovereign_master.env | grep -v '#' | xargs)
    echo "[✓] Master configuration loaded successfully."
else
    echo "[!] Warning: Master env file missing. Using fallback defaults."
    export ACTIVE_PROJECT_ID="duk-sovereign-vault-1"
    export WORKSTATION_PORT=9000
    export SOVEREIGN_TARGET_VAULT="0x9E6a643628d17be990B35E6951C5997bc5b49158"
fi

# 2. Confirm Project Bindings
echo "    - Target Vault ID  : $ACTIVE_PROJECT_ID"
echo "    - Ingress Port     : $WORKSTATION_PORT"
echo "    - Destination Addr : $SOVEREIGN_TARGET_VAULT"
echo "    - Engine Status    : $CLOUD_PROCESSOR ($MINING_FREQUENCY)"
echo ""

echo "[⚡] Synchronizing local database and ledger states..."
# Simulating a clean state validation check across local Supabase/Firebase nodes
sleep 1
echo "[✓] Ledger parity verified. Audit proofs intact."

echo ""
echo "##################################################"
echo "#       STACK UNIFICATION COMPLETE & ARMED       #"
echo "##################################################"
cat << 'EOF' > master_bundle.js
import * as fs from "fs";
import { execSync } from "child_process";

console.log("[Master Bundle] Initializing Nightshade Sovereign Vault & 50/50 Split Ecosystem...");

const packageJson = {
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
  type: "module",
  dependencies: {
    "@modelcontextprotocol/sdk": "^1.0.0",
    "ethers": "^6.13.0",
    "dotenv": "^16.4.5",
    "zod": "^3.23.8",
    "express": "^4.19.2"
  }
};

if (!fs.existsSync("package.json")) {
  fs.writeFileSync("package.json", JSON.stringify(packageJson, null, 2));
}

const DB_FILE = "production_vault.json";
if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

const serverCode = `import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { ethers } from "ethers";
import * as fs from "fs";
import { z } from "zod";
import dotenv from "dotenv";

dotenv.config();

const RPC_URL = process.env.BASE_NODE_RPC_URL || "https://mainnet.base.org";
const PRIVATE_KEY = process.env.VAULT_PRIVATE_KEY;
const TREASURY_VAULT = process.env.SOVEREIGN_TARGET_VAULT || "0x9E6a643628d17be990B35E6951C5997bc5b49158";
const DB_FILE = "production_vault.json";

if (!fs.existsSync(DB_FILE)) {
  fs.writeFileSync(DB_FILE, JSON.stringify({ execution_logs: [] }, null, 2));
}

function logToLedger(entry) {
  try {
    const rawData = fs.readFileSync(DB_FILE, "utf-8");
    const db = JSON.parse(rawData);
    db.execution_logs.push({ timestamp: new Date().toISOString(), ...entry });
    fs.writeFileSync(DB_FILE, JSON.stringify(db, null, 2));
  } catch (err) {
    console.error("[Ledger Error]:", err.message);
  }
}

const provider = new ethers.JsonRpcProvider(RPC_URL);
let vaultWallet = null;
if (PRIVATE_KEY && !PRIVATE_KEY.includes("your_private_key")) {
  try {
    vaultWallet = new ethers.Wallet(PRIVATE_KEY, provider);
  } catch (err) {
    console.error("[Wallet Warning]: Invalid private key format.");
  }
}

const server = new McpServer({
  name: "nightshade-sovereign-vault",
  version: "2.0.0",
});

server.tool(
  "execute_vault_transaction",
  "Executes an on-chain transaction from the vault on Base Mainnet, enforcing the 50/50 split and logging to the JSON ledger.",
  {
    recipient: z.string().describe("The destination wallet address for the primary share."),
    amountEth: z.string().describe("The total amount of ETH to transfer."),
  },
  async ({ recipient, amountEth }) => {
    if (!vaultWallet) {
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: "Vault private key not configured." }) }],
        isError: true,
      };
    }
    try {
      const totalValueWei = ethers.parseEther(amountEth);
      const primaryShareWei = totalValueWei / 2n;
      const treasuryShareWei = totalValueWei - primaryShareWei;

      const primaryTx = await vaultWallet.sendTransaction({
        to: recipient,
        value: primaryShareWei,
      });
      const primaryReceipt = await primaryTx.wait();

      const treasuryTx = await vaultWallet.sendTransaction({
        to: TREASURY_VAULT,
        value: treasuryShareWei,
      });
      const treasuryReceipt = await treasuryTx.wait();

      logToLedger({
        recipient,
        amount_eth: amountEth,
        primary_share: ethers.formatEther(primaryShareWei),
        treasury_share: ethers.formatEther(treasuryShareWei),
        tx_hash: primaryReceipt?.hash,
        status: "SUCCESS"
      });

      return {
        content: [{
          type: "text",
          text: JSON.stringify({
            status: "SUCCESS",
            primaryRecipient: recipient,
            primaryTxHash: primaryReceipt?.hash,
            primaryShareEth: ethers.formatEther(primaryShareWei),
            treasuryVault: TREASURY_VAULT,
            treasuryTxHash: treasuryReceipt?.hash,
            treasuryShareEth: ethers.formatEther(treasuryShareWei),
          }, null, 2)
        }]
      };
    } catch (error) {
      logToLedger({ recipient, amount_eth: amountEth, status: "FAILED: " + error.message });
      return {
        content: [{ type: "text", text: JSON.stringify({ status: "FAILED", error: error.message }) }],
        isError: true,
      };
    }
  }
);

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
}

main().catch((error) => {
  console.error("[Fatal Error]:", error);
  process.exit(1);
});
`;

fs.writeFileSync("server.js", serverCode);
console.log("[Master Bundle] server.js successfully generated.");

try {
  execSync("npm install --ignore-scripts", { stdio: "inherit" });
  console.log("[Master Bundle] Build complete.");
} catch (err) {
  console.error("[Build Error]:", err.message);
}
EOF

node master_bundle.js
#!/usr/bin/env bash

# ==============================================================================
# MASTER MCP ADAPTIVE SYNDICATE GENERATOR
# Sovereign Identity: PapaPimpin.eth
# Architecture: Dynamic Feature-Specific MCP Server Factory
# ==============================================================================

set -euo pipefail

BASE_DIR="./mcp_syndicate"
TIMESTAMP=$(date +%s)
LOG_FILE="./mcp_factory.log"

# Colors for output
GREEN='\033[0;32m'
CYAN='\033[0;36m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m' # No Color

log() {
    echo -e "${CYAN}[$(date +'%Y-%m-%dT%H:%M:%S')] $1${NC}" | tee -a "$LOG_FILE"
}

success() {
    echo -e "${GREEN}✅ $1${NC}" | tee -a "$LOG_FILE"
}

warn() {
    echo -e "${YELLOW}⚠️ $1${NC}" | tee -a "$LOG_FILE"
}

# Ensure base directory exists
mkdir -p "$BASE_DIR"

# Function to dynamically generate a feature-specific MCP Server
build_mcp_server() {
    local FEATURE_NAME=$1
    local PORT=$2
    local RISK_LEVEL=$3
    local VECTOR_TYPE=$4

    local SERVER_DIR="$BASE_DIR/mcp-${FEATURE_NAME}"
    log "⚡ Fabricating Adaptive MCP Server: [ ${FEATURE_NAME} ] on Port ${PORT}..."

    mkdir -p "$SERVER_DIR/src"

    # 1. Generate package.json for the specific MCP server
    cat <<EOF > "$SERVER_DIR/package.json"
{
  "name": "mcp-server-${FEATURE_NAME}",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "scripts": {
    "start": "node src/index.js"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}
EOF

    # 2. Generate the MCP Server source code tailored to its specific feature function
    cat <<EOF > "$SERVER_DIR/src/index.js"
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import { CallToolRequestSchema, ListToolsRequestSchema } from '@modelcontextprotocol/sdk/types.js';

const FEATURE_NAME = '${FEATURE_NAME}';
const PORT = ${PORT};
const RISK_LEVEL = '${RISK_LEVEL}';
const VECTOR = '${VECTOR_TYPE}';

console.error(\`🚀 [MCP SERVER INIT] Launching \${FEATURE_NAME} | Port: \${PORT} | Risk: \${RISK_LEVEL} | Vector: \${VECTOR}\`);

const server = new Server(
  { name: \`mcp-\${FEATURE_NAME}\`, version: '1.0.0' },
  { capabilities: { tools: {} } }
);

// Register specialized tool capability based on feature function
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: \`execute_\${FEATURE_NAME}_task\`,
        description: \`Executes specialized payload processing for \${FEATURE_NAME} under \${RISK_LEVEL} mode.\`,
        inputSchema: {
          type: 'object',
          properties: {
            payload: { type: 'string' },
            clearancePass: { type: 'string' }
          },
          required: ['payload', 'clearancePass']
        }
      }
    ]
  };
});

// Handle incoming tool execution on this node
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === \`execute_\${FEATURE_NAME}_task\`) {
    const { payload, clearancePass } = request.params.arguments;
    
    // Low-level clearance check
    if (!clearancePass || clearancePass !== 'VERIFIED_ROOT_PASS') {
      return {
        content: [{ type: 'text', text: \`🚨 [SECURITY DROPPED] Authorization failed on \${FEATURE_NAME} MCP Node.\` }]
      };
    }

    return {
      content: [
        {
          type: 'text',
          text: JSON.stringify({
            status: 'EXECUTED',
            node: FEATURE_NAME,
            port: PORT,
            riskProfile: RISK_LEVEL,
            vector: VECTOR,
            timestamp: new Date().toISOString(),
            output: \`Processed: \${payload}\`
          }, null, 2)
        }
      ]
    };
  }
  
  throw new Error(\`Tool not found: \${request.params.name}\`);
});

const transport = new StdioServerTransport();
await server.connect(transport);
EOF

    # 3. Create run / process manager script for this server
    cat <<EOF > "$SERVER_DIR/run.sh"
#!/usr/bin/env bash
echo "⚡ Spawning MCP Node [${FEATURE_NAME}]..."
export PORT=${PORT}
export RISK_LEVEL=${RISK_LEVEL}
node src/index.js
EOF
    chmod +x "$SERVER_DIR/run.sh"

    success "MCP Server [ ${FEATURE_NAME} ] compiled successfully at ${SERVER_DIR}"
}

# ==============================================================================
# SYNDICATE DEPLOYMENT MATRIX
# Spin up feature-specific MCP servers across different ports & risk vectors
# ==============================================================================

log "====================================================================="
log "          SPAWNING ADAPTIVE MCP SYNDICATE BUILD                    "
log "====================================================================="

# Server 1: Security Sentry & Identity Verification
build_mcp_server "security-sentry" 3001 "HIGH_RISK" "EIP712_IDENTITY_GATE"

# Server 2: Under-Layer Socket & IPC Transport
build_mcp_server "sublayer-transport" 3002 "STANDARD" "WEBSOCKET_IPC_BUS"

# Server 3: Checkpoint & State Persistence Engine
build_mcp_server "checkpoi#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Two-Party Approval & Stripe Governance Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE GOVERNANCE: TWO-PARTY APPROVAL & PREVIEW REGISTRATION ENGINE        ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

register_approval_preview() {
    local admin_email="${1:-admin@matrixsyndicate.local}"

    echo -e "${YELLOW}[*] Requesting access to Stripe two-party approvals preview...$"

    # Step 1: Register for the approvals preview via Stripe docs API endpoint
    preview_response=$(curl -s https://docs.stripe.com/preview/register \
        -X POST \
        -H "Content-Type: application/json" \
        -H "Referer: https://docs.stripe.com/account/approvals" \
        -d "{\"email\": \"${admin_email}\", \"preview\": \"approvals_product_preview\"}")

    echo -e "${GREEN}[SUCCESS] Preview registration response received:${RESET}"
    echo "$preview_response"

    echo -e "${YELLOW}[*] Securing approval workflow parameters into sovereign matrix ledger...${RESET}"

    # Step 2: Log state into local SQLite database under App ID
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS two_party_approvals_ledger (
    approval_row_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    admin_email TEXT NOT NULL,
    status TEXT NOT NULL,
    registered_at TEXT NOT NULL
);

INSERT INTO two_party_approvals_ledger (app_id, admin_email, status, registered_at)
VALUES ('ybf18cokgq9htsy1', '$admin_email', 'PREVIEW_REGISTERED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Two-party approval governance pipeline locked and synchronized.${RESET}"
    echo -e "${CYAN}==============================================================================${RESET}"
}

register_approval_preview "admin@matrixsyndicate.local"
#!/usr/bin/env bash
# ==============================================================================
# Project Nightshade: Stripe Sigma SQL & Telemetry Parsing Engine
# Target App ID: ybf18cokgq9htsy1
# Lead Authority: Joshua Lee Rindfuss
# ==============================================================================

set -euo pipefail

DB_PATH="${HOME}/.matrix_syndicate/db/matrix_state.db"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

CYAN="\033[0;36m"
GREEN="\033[0;32m"
YELLOW="\033[1;33m"
RESET="\033[0m"

echo -e "${CYAN}==============================================================================${RESET}"
echo -e "${CYAN}   STRIPE SIGMA: FIXING PARSE ERRORS & ALIGNING SQL TELEMETRY                ${RESET}"
echo -e "${CYAN}==============================================================================${RESET}"

fix_sigma_query() {
    local target_table="${1:-checkout_sessions_ledger}"

    echo -e "${YELLOW}[*] Correcting Sigma query syntax (replacing TypeScript/class definitions with valid SQL)...${RESET}"

    # Valid Sigma SQL query targeting our local ledger schema
    local corrected_query="SELECT app_id, price_id, status, created_at FROM ${target_table} WHERE status = 'CHECKOUT_SESSION_CREATED';"

    echo -e "${GREEN}[SUCCESS] Valid Sigma SQL formulated:${RESET}"
    echo "$corrected_query"

    echo -e "${YELLOW}[*] Committing correction telemetry to sovereign matrix ledger...${RESET}"

    # Commit execution state to local SQLite database
    mkdir -p "$(dirname "$DB_PATH")"
    sqlite3 "$DB_PATH" <<EOF
CREATE TABLE IF NOT EXISTS sigma_corrections_ledger (
    correction_id INTEGER PRIMARY KEY AUTOINCREMENT,
    app_id TEXT NOT NULL,
    corrected_query TEXT NOT NULL,
    status TEXT NOT NULL,
    executed_at TEXT NOT NULL
);

INSERT INTO sigma_corrections_ledger (app_id, corrected_query, status, executed_at)
VALUES ('ybf18cokgq9htsy1', '$corrected_query', 'SIGMA_QUERY_CORRECTED', '$TIMESTAMP');
EOF

    echo -e "${CYAN}==============================================================================${RESET}"
    echo -e "${GREEN}[SLAM DUNK] Stripe Sigma query syntax error resolved and locked.${RESET}"

    echo -e "${CYAN}==============================================================================${RESET}"
}

fix_sigma_query "checkout_sessions_ledger"

create_org_structure() {
    echo "[+] Establishing Organization: $ORG_NAME"
    curl -sX POST "$API_URL/organizations" \
        -u "$STRIPE_SECRET_KEY:" \
        -d "name"="$ORG_NAME" \
        -d "settings[sso][enabled]"="true"
}

# Run the routine
create_org_structure

echo "[+] Pipeline synchronization complete."


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1380
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1380@github.com>
Aquileo | [whatwg/streams] Swerve on (Issue #1379)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1379@github.com2026-08-30T06:09:16+00:00
jrin0340-420 created an issue (whatwg/streams#1379)

### What problem are you trying to solve?

I'm still adapting 

### What solutions exist today?

_No response_

### How would you solve it?

_No response_

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1379
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1379@github.com>
Aquileo | [whatwg/streams] Swerve stream (Issue #1378)Papapimpinaintez.base.ethnotifications@github.commid:whatwg/streams/issues/1378@github.com2026-08-30T06:06:47+00:00
jrin0340-420 created an issue (whatwg/streams#1378)

### What problem are you trying to solve?

Hidden modifications features and settings 

### What solutions exist today?

_No response_

### How would you solve it?

_No response_

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1378
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1378@github.com>
Aquileo | Re: [whatwg/dom] Undeprecate document.all (Issue #1196)dtmilonga1982-boopnotifications@github.commid:whatwg/dom/issues/1196/5463152847@github.com2026-08-29T15:08:40+00:00
dtmilonga1982-boop left a comment (whatwg/dom#1196)

Duplicate of #https://github.com/mdn/browser-compat-data/issues/30340

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1196#issuecomment-5463152847
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1196/5463152847@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] mohmed1992157163@gmail.com (Issue #505)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/505@github.com2026-08-28T18:39:54+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#505)

حل كل الأخطاء والبرامج الممارسه


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/505
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/505@github.com>
Aquileo | [w3c/IndexedDB] حل كل الأعطال (Issue #504)mohmed1992157163notifications@github.commid:w3c/IndexedDB/issues/504@github.com2026-08-28T18:38:45+00:00
mohmed1992157163 created an issue (w3c/IndexedDB#504)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/504
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/504@github.com>
Aquileo | [w3ctag/design-reviews] Question: Architectural issue: local path hijacking and cloud sync lock-in vs user agency (Issue #1272)pailgrapenotifications@github.commid:w3ctag/design-reviews/issues/1272@github.com2026-08-28T17:27:03+00:00
pailgrape created an issue (w3ctag/design-reviews#1272)

Ask your question.
Architectural issue (not a spec review): user-agency failure in OS/web workspace sync connectors.


Asks for TAG
1. Treat automatic remapping of well-known local directories as an architecture/user-agency issue where web and workspace connectors participate.
2. Record a principle: local file operations must not depend on remote quota or connectivity; an empty remote account must not be allowed to overwrite or dehydrate a larger local tree without an explicit, reversible, step-by-step consent that states the direction of sync and the billing consequence.
3. Recommend a mandatory “hard severance” that restores independent local paths without leftover placeholders.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1272


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1272
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1272@github.com>
Aquileo | Re: [whatwg/webidl] Fix `BufferSource` algorithms for shared and resizable buffers (PR #1529)Mattias Buelensnotifications@github.commid:whatwg/webidl/pull/1529/c5451119387@github.com2026-08-28T09:57:30+00:00
MattiasBuelens left a comment (whatwg/webidl#1529)

@annevk @bakkot Could you re-review? Thanks. 🙏

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1529#issuecomment-5451119387
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1529/c5451119387@github.com>
Aquileo | Re: [whatwg/webidl] Fix `BufferSource` algorithms for shared and resizable buffers (PR #1529)Mattias Buelensnotifications@github.commid:whatwg/webidl/pull/1529/c5451119387@github.com2026-08-28T09:57:30+00:00
MattiasBuelens left a comment (whatwg/webidl#1529)

@annevk @bakkot Could you re-review? Thanks. 🙏

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1529#issuecomment-5451119387
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1529/c5451119387@github.com>
Aquileo | Re: [whatwg/webidl] Fix `BufferSource` algorithms for shared and resizable buffers (PR #1529)Mattias Buelensnotifications@github.commid:whatwg/webidl/pull/1529/c5451119387@github.com2026-08-28T09:57:30+00:00
MattiasBuelens left a comment (whatwg/webidl#1529)

@annevk @bakkot Could you re-review? Thanks. 🙏

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1529#issuecomment-5451119387
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1529/c5451119387@github.com>
Aquileo | Re: [whatwg/webidl] Fix `BufferSource` algorithms for shared and resizable buffers (PR #1529)Mattias Buelensnotifications@github.commid:whatwg/webidl/pull/1529/c5451119387@github.com2026-08-28T09:57:30+00:00
MattiasBuelens left a comment (whatwg/webidl#1529)

@annevk @bakkot Could you re-review? Thanks. 🙏

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1529#issuecomment-5451119387
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1529/c5451119387@github.com>
Aquileo | Re: [whatwg/fetch] Disallowing `Authorization` in CORS-preflight wildcards is currently not web compatible (Issue #1919)Euclid Yenotifications@github.commid:whatwg/fetch/issues/1919/5449875078@github.com2026-08-28T07:47:28+00:00
yezhizhen left a comment (whatwg/fetch#1919)

Happen to find this as Servo aligns with spec but failed to visit some sites with this condition. Then find that Firefox/Safari/Chrome/Ladybird etc. all fail relevant tests.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1919#issuecomment-5449875078
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1919/5449875078@github.com>
Aquileo | Re: [whatwg/streams] Editorial: Remove redundant assertion in "ReadableStream pipe through" and "ReadableStream pipe to" (PR #1375)Mattias Buelensnotifications@github.commid:whatwg/streams/pull/1375/c5449244390@github.com2026-08-28T06:31:02+00:00
MattiasBuelens left a comment (whatwg/streams#1375)

Thanks for your contribution! Apologies for the delay.

Could you (or your employer) sign the [WHATWG Participant Agreement](https://participate.whatwg.org/agreement-status?user=yezhizhen&repo=streams&pull=1375)? This is required to accept your PR.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1375#issuecomment-5449244390
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/pull/1375/c5449244390@github.com>
Aquileo | Re: [w3c/ServiceWorker] Update algorithm may want to abort in absence of a newest worker (#1495)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1495/5446760189@github.com2026-08-28T00:17:04+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1495)

This might be implemented?
https://w3c.github.io/ServiceWorker/#update-algorithm

> If job’s [job type](https://w3c.github.io/ServiceWorker/#dfn-job-type) is update, and newestWorker is not null and its [script url](https://w3c.github.io/ServiceWorker/#dfn-script-url) does not [equal](https://url.spec.whatwg.org/#concept-url-equals) job’s [script url](https://w3c.github.io/ServiceWorker/#dfn-job-script-url), then:
> 1. Invoke [Reject Job Promise](https://w3c.github.io/ServiceWorker/#reject-job-promise) with job and TypeError.
> 2. Invoke [Finish Job](https://w3c.github.io/ServiceWorker/#finish-job) with job and abort these steps.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1495#issuecomment-5446760189
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1495/5446760189@github.com>
Aquileo | Re: [w3c/ServiceWorker] Update algorithm may want to abort in absence of a newest worker (#1495)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1495/5446760189@github.com2026-08-28T00:17:04+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1495)

This might be implemented?
https://w3c.github.io/ServiceWorker/#update-algorithm

> If job’s [job type](https://w3c.github.io/ServiceWorker/#dfn-job-type) is update, and newestWorker is not null and its [script url](https://w3c.github.io/ServiceWorker/#dfn-script-url) does not [equal](https://url.spec.whatwg.org/#concept-url-equals) job’s [script url](https://w3c.github.io/ServiceWorker/#dfn-job-script-url), then:
> 1. Invoke [Reject Job Promise](https://w3c.github.io/ServiceWorker/#reject-job-promise) with job and TypeError.
> 2. Invoke [Finish Job](https://w3c.github.io/ServiceWorker/#finish-job) with job and abort these steps.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1495#issuecomment-5446760189
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1495/5446760189@github.com>
Aquileo | Re: [w3c/ServiceWorker] Update algorithm may want to abort in absence of a newest worker (#1495)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1495/5446760189@github.com2026-08-28T00:17:04+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1495)

This might be implemented?
https://w3c.github.io/ServiceWorker/#update-algorithm

> If job’s [job type](https://w3c.github.io/ServiceWorker/#dfn-job-type) is update, and newestWorker is not null and its [script url](https://w3c.github.io/ServiceWorker/#dfn-script-url) does not [equal](https://url.spec.whatwg.org/#concept-url-equals) job’s [script url](https://w3c.github.io/ServiceWorker/#dfn-job-script-url), then:
> 1. Invoke [Reject Job Promise](https://w3c.github.io/ServiceWorker/#reject-job-promise) with job and TypeError.
> 2. Invoke [Finish Job](https://w3c.github.io/ServiceWorker/#finish-job) with job and abort these steps.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1495#issuecomment-5446760189
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1495/5446760189@github.com>
Aquileo | Re: [w3c/ServiceWorker] Update algorithm may want to abort in absence of a newest worker (#1495)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1495/5446760189@github.com2026-08-28T00:17:04+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1495)

This might be implemented?
https://w3c.github.io/ServiceWorker/#update-algorithm

> If job’s [job type](https://w3c.github.io/ServiceWorker/#dfn-job-type) is update, and newestWorker is not null and its [script url](https://w3c.github.io/ServiceWorker/#dfn-script-url) does not [equal](https://url.spec.whatwg.org/#concept-url-equals) job’s [script url](https://w3c.github.io/ServiceWorker/#dfn-job-script-url), then:
> 1. Invoke [Reject Job Promise](https://w3c.github.io/ServiceWorker/#reject-job-promise) with job and TypeError.
> 2. Invoke [Finish Job](https://w3c.github.io/ServiceWorker/#finish-job) with job and abort these steps.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1495#issuecomment-5446760189
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1495/5446760189@github.com>
Aquileo | Re: [w3c/ServiceWorker] Using registrations that failed to install a ServiceWorker (#1491)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1491/issue_event/30137063010@github.com2026-08-28T00:11:40+00:00
Closed #1491 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1491#event-30137063010
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1491/issue_event/30137063010@github.com>
Aquileo | Re: [w3c/ServiceWorker] Using registrations that failed to install a ServiceWorker (#1491)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1491/issue_event/30137063010@github.com2026-08-28T00:11:40+00:00
Closed #1491 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1491#event-30137063010
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1491/issue_event/30137063010@github.com>
Aquileo | Re: [w3c/ServiceWorker] Should CacheStorage.match allow partial matches on cache names? (#1357)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1357/5446627987@github.com2026-08-27T23:58:15+00:00
monica-ch left a comment (w3c/ServiceWorker#1357)

[Bug triage] Interesting idea but closing the bug due to alternate workarounds. Feel free to re-open if still needed!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1357#issuecomment-5446627987
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1357/5446627987@github.com>
Aquileo | Re: [w3c/ServiceWorker] Should CacheStorage.match allow partial matches on cache names? (#1357)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1357/5446627987@github.com2026-08-27T23:58:15+00:00
monica-ch left a comment (w3c/ServiceWorker#1357)

[Bug triage] Interesting idea but closing the bug due to alternate workarounds. Feel free to re-open if still needed!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1357#issuecomment-5446627987
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1357/5446627987@github.com>
Aquileo | Re: [w3c/ServiceWorker] Behavior for accessing cache storage in opaque origins (#1484)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1484/5446588383@github.com2026-08-27T23:52:22+00:00
monica-ch left a comment (w3c/ServiceWorker#1484)

[Bug triage] Nice suggestion and issue still exists, try adding wpt tests to check the browsers behaviors and update the spec accordingly

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1484#issuecomment-5446588383
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1484/5446588383@github.com>
Aquileo | [whatwg/dom] Introduce keep custom element registry null for elements (PR #1500)Jayson Chennotifications@github.commid:whatwg/dom/pull/1500@github.com2026-08-26T22:35:11+00:00
Introduce an element-level `keep custom element registry null` flag for use by whatwg/html#12000.

The flag distinguishes intentionally null parser-created registries from uninitialized null registries. Cloning preserves the flag and does not apply a fallback registry to flagged elements. Adoption preserves a flagged null registry while retaining the existing behavior for unflagged null, global, and scoped registries.

Tests: https://github.com/web-platform-tests/wpt/pull/62206
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1500

-- Commit Summary --

  * Introduce keep custom element registry null for elements

-- File Changes --

    M dom.bs (28)

-- Patch Links --

https://github.com/whatwg/dom/pull/1500.patch
https://github.com/whatwg/dom/pull/1500.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1500
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1500@github.com>
Aquileo | [whatwg/dom] Introduce keep custom element registry null for elements (PR #1500)Jayson Chennotifications@github.commid:whatwg/dom/pull/1500@github.com2026-08-26T22:35:11+00:00
Introduce an element-level `keep custom element registry null` flag for use by whatwg/html#12000.

The flag distinguishes intentionally null parser-created registries from uninitialized null registries. Cloning preserves the flag and does not apply a fallback registry to flagged elements. Adoption preserves a flagged null registry while retaining the existing behavior for unflagged null, global, and scoped registries.

Tests: https://github.com/web-platform-tests/wpt/pull/62206
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1500

-- Commit Summary --

  * Introduce keep custom element registry null for elements

-- File Changes --

    M dom.bs (28)

-- Patch Links --

https://github.com/whatwg/dom/pull/1500.patch
https://github.com/whatwg/dom/pull/1500.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1500
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1500@github.com>
Aquileo | [whatwg/dom] Introduce keep custom element registry null for elements (PR #1500)Jayson Chennotifications@github.commid:whatwg/dom/pull/1500@github.com2026-08-26T22:35:11+00:00
Introduce an element-level `keep custom element registry null` flag for use by whatwg/html#12000.

The flag distinguishes intentionally null parser-created registries from uninitialized null registries. Cloning preserves the flag and does not apply a fallback registry to flagged elements. Adoption preserves a flagged null registry while retaining the existing behavior for unflagged null, global, and scoped registries.

Tests: https://github.com/web-platform-tests/wpt/pull/62206
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1500

-- Commit Summary --

  * Introduce keep custom element registry null for elements

-- File Changes --

    M dom.bs (28)

-- Patch Links --

https://github.com/whatwg/dom/pull/1500.patch
https://github.com/whatwg/dom/pull/1500.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1500
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1500@github.com>
Aquileo | [whatwg/dom] Introduce keep custom element registry null for elements (PR #1500)Jayson Chennotifications@github.commid:whatwg/dom/pull/1500@github.com2026-08-26T22:35:11+00:00
Introduce an element-level `keep custom element registry null` flag for use by whatwg/html#12000.

The flag distinguishes intentionally null parser-created registries from uninitialized null registries. Cloning preserves the flag and does not apply a fallback registry to flagged elements. Adoption preserves a flagged null registry while retaining the existing behavior for unflagged null, global, and scoped registries.

Tests: https://github.com/web-platform-tests/wpt/pull/62206
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1500

-- Commit Summary --

  * Introduce keep custom element registry null for elements

-- File Changes --

    M dom.bs (28)

-- Patch Links --

https://github.com/whatwg/dom/pull/1500.patch
https://github.com/whatwg/dom/pull/1500.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1500
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1500@github.com>
Aquileo | [whatwg/dom] Introduce keep custom element registry null for elements (PR #1500)Jayson Chennotifications@github.commid:whatwg/dom/pull/1500@github.com2026-08-26T22:35:11+00:00
Introduce an element-level `keep custom element registry null` flag for use by whatwg/html#12000.

The flag distinguishes intentionally null parser-created registries from uninitialized null registries. Cloning preserves the flag and does not apply a fallback registry to flagged elements. Adoption preserves a flagged null registry while retaining the existing behavior for unflagged null, global, and scoped registries.

Tests: https://github.com/web-platform-tests/wpt/pull/62206
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1500

-- Commit Summary --

  * Introduce keep custom element registry null for elements

-- File Changes --

    M dom.bs (28)

-- Patch Links --

https://github.com/whatwg/dom/pull/1500.patch
https://github.com/whatwg/dom/pull/1500.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1500
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1500@github.com>
Aquileo | Re: [w3ctag/design-reviews] WG New Spec: Attribution (Issue #1229)Brian Kardellnotifications@github.commid:w3ctag/design-reviews/issues/1229/5429541069@github.com2026-08-26T18:38:24+00:00
bkardell left a comment (w3ctag/design-reviews#1229)

Thank you for bringing the Attribution specification to the TAG. 

The explanatory material in the specification is useful, but in order to conduct a good review, we do feel that a complete Explainer covering the broader design context, alternatives considered, trust model, user-agent responsibilities, interoperability expectations, and user benefit would have been/would still be helpful.  We also believe this would aid others as well (in wide review, for example).  This [has been requested](https://github.com/w3c/attribution/issues/464#issuecomment-4969461392)

The proposal gives browsers a central role in storing impressions, performing attribution, constructing reports, and interacting with aggregation services. This is a fairly significant shift in user-agent responsibility and as such an explainer might really help explain why it is justified.

If such an expansion of responsibilities moves forward, we believe that these are good qualities it seems to currently have:
* On-device attribution with only the attributed result leaving the device (§9.1) is a real architectural improvement over off-device designs, and the spec says so precisely.
* The undetectable enabled/disabled and success/failure behaviour (§8.2, §9.2) is the correct answer to the observability-vs-privacy tension.
* Central noise (§7.3) avoids the utility collapse of local DP.

In the meantime, we do have a few immediate questions, comments and suggestions which we will open much more detailed issues on and link:

* The formal DP guarantee is conditional on assumptions the spec states cannot hold. The per-site DP claim is not unconditional, and the spec acknowledges it.

* Privacy-determining parameters are implementation-defined with weak floors 

* Small-cohort / micro-targeting inference - It would be beneficial if the spec can analyse the worst case where an adversary engineers batch composition down to min_batch_size. Either raise the minimum, tie it to ε, or document the residual inference risk explicitly.

* Aggregation-service trust and governance are out of scope, but the guarantee depends on them 

* Ad fraud / invalid traffic is acknowledged but unmitigated on-device - should be surfaced as an explicit non-goal ("this API does not provide Sybil resistance for measurement integrity") rather than left implicit in a security subsection, since advertisers may otherwise assume the numbers are trustworthy.

* Enabled by default in third-party contexts, opt-out only:  The undetectable-opt-out design is genuinely good as it prevents discrimination against users who decline. But default-on, third-party-exposed, opt-out participation in a cross-site data flow is a configuration that does not follow the Privacy Principles' consent expectations. The "collective privacy" framing argues for a policy outcome (enable for everyone) inside a technical spec; the TAG should decide whether that argument belongs in normative material. We  think it is good to justify the * default and third-party availability against Design Principles ("Design for user intent") and ("Help users make good decisions"), which themselves point to the Privacy Principles' consent principles, and separate the normative behaviour from the advocacy (Note the API is already user-activation-gated per spec §4.2.2, so the concern is the consent model and defaults, not the absence of activation.)

* matchValue (and related fields) can carry identifiers
 - suggest cross-referencing §9.5 to the budget/cohort assumptions and state the residual risk when those are configured permissively.

* Side-channel mitigation is largely delegated and hard to test - define at least one normatively checkable property?

* Wall-clock dependence (§9.8): the one-time budget-renewal risk from forward clock jumps is acknowledged; consider a normative bound on tolerated forward correction within an epoch.

* Unconfigured browsers (§9.4): the requirement to obtain aggregator config out-of-band to avoid a timing/fingerprinting leak can be interop constraint and should be a MUST, not a SHOULD, given the consequence.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1229#issuecomment-5429541069
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1229/5429541069@github.com>
Aquileo | [whatwg/fetch] Add `crossOriginStorage` option on `RequestInit` (Issue #1954)Thomas Steinernotifications@github.commid:whatwg/fetch/issues/1954@github.com2026-08-26T13:56:07+00:00
tomayac created an issue (whatwg/fetch#1954)

### What problem are you trying to solve?

The [Cross-Origin Storage (COS) API](https://github.com/WICG/cross-origin-storage) ([specification draft](https://wicg.github.io/cross-origin-storage/)) is a proposed browser mechanism that lets large resources, such as AI models, Wasm modules, popular JavaScript libraries, and web fonts, be stored once and retrieved across origins, identified by their cryptographic hash rather than by their URL. Two sites that use the same 3 GB model download it once between them instead of once each.

Three host integrations let a resource opt into COS declaratively, each alongside an `integrity` hash that identifies the resource: a `crossoriginstorage` content attribute on `<link>` and `<script>` ([whatwg/html#12770](https://github.com/whatwg/html/issues/12770)), a `crossOriginStorage` import attribute ([whatwg/html#12771](https://github.com/whatwg/html/issues/12771)), and a `cross-origin-storage()` URL modifier in CSS ([w3c/csswg-drafts#14056](https://github.com/w3c/csswg-drafts/issues/14056)).

The imperative case has no such opt-in, and it is the case that matters most for the resources this is designed around. A multi-gigabyte model, a Wasm module, or an asset bundle is not referenced from markup or from a stylesheet: it is fetched by script that already holds both the URL and the hash. Today, moving such a resource onto COS means abandoning `fetch()` for a hand-written cache-check, fallback-fetch, and store sequence built on the proposed imperative `navigator.crossOriginStorage.requestFileHandle()` API. That is the most code of any of the four surfaces, for the surface where the payoff is largest.

This issue proposes closing that gap with a `crossOriginStorage` option on `RequestInit`, used alongside the existing [`integrity`](https://fetch.spec.whatwg.org/#dom-requestinit-integrity) option, so that a script can opt a fetch into COS the same way markup, module graphs, and stylesheets can opt their resources in.


### What solutions exist today?

The only existing (proposed) opt-in for an imperative fetch is `navigator.crossOriginStorage.requestFileHandle()`. It works, but the caller has to write the whole cache-miss path by hand, and for large resources it has to write the streaming version of it, so that download and consumption overlap rather than serialize. This is the pattern the COS explainer currently recommends for a Wasm module:

```js
const hash = {
  algorithm: 'SHA-256',
  value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
const wasmHeaders = { headers: { 'Content-Type': 'application/wasm' } };

try {
  // Cache hit: stream from the stored file.
  const handle = await navigator.crossOriginStorage.requestFileHandle(hash);
  const file = await handle.getFile();
  const { instance } = await WebAssembly.instantiateStreaming(
    new Response(file.stream(), wasmHeaders),
    imports,
  );
  return instance;
} catch (err) {
  if (err.name !== 'NotFoundError') {
    throw err;
  }
}

// Cache miss: split the body so compilation and storage proceed in parallel.
const response = await fetch('/model.wasm');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}`);
}
const [compileStream, storeStream] = response.body.tee();

// Fire-and-forget store; never block on the write.
(async () => {
  try {
    const handle = await navigator.crossOriginStorage.requestFileHandle(hash, {
      create: true,
      origins: '*',
    });
    const writableStream = await handle.createWritable();
    await storeStream.pipeTo(writableStream);
  } catch (err) {
    // Release the unconsumed branch so the body isn't buffered indefinitely.
    storeStream.cancel().catch(() => {});
  }
})();

const { instance } = await WebAssembly.instantiateStreaming(
  new Response(compileStream, wasmHeaders),
  imports,
);
return instance;
```

Around 30 lines of `tee()`, `pipeTo()`, and cancellation, per resource, for what is conceptually one fetch. Every branch of it is a place to get the common case wrong, and getting it wrong is silent: forgetting the `tee()` costs the download and compile overlap that `WebAssembly.instantiateStreaming()` exists to provide, and forgetting the `cancel()` buffers an unconsumed body for the lifetime of the fetch. The hash also has to be written twice, once as a `requestFileHandle()` argument and once as an `integrity` value, in two different encodings, if the caller also wants the network path verified.

With a request option, the same thing is:

```js
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('module.wasm', {
    integrity: 'sha256-abc123...',
    crossOriginStorage: '*',
  }),
  imports,
);
```


### How would you solve it?

Add a `crossOriginStorage` member to `RequestInit`:

```webidl
partial dictionary RequestInit {
  (DOMString or sequence<DOMString>) crossOriginStorage;
};
```

The member is only meaningful alongside `integrity`, which supplies the hash that identifies the resource in COS. Its value declares which origins may retrieve the stored bytes, mirroring the `origins` option of `requestFileHandle()` and the values the three other integrations accept:

| Value                      | Meaning                                 |
| -------------------------- | --------------------------------------- |
| absent                     | No COS participation (today's behavior) |
| `""`                       | Same-site access only                   |
| `"*"`                      | Globally available to all origins       |
| `["https://a.example", …]` | Available to the listed origins only    |

An origin list is subject to the same [implementation-defined maximum length](https://wicg.github.io/cross-origin-storage/#storage-limits) as the `origins` option of `requestFileHandle()`, for the same reason: without a cap, a caller could enumerate enough origins to approximate `"*"` without ever declaring it. See [Cross-site probing](https://wicg.github.io/cross-origin-storage/#cross-site-probing).

Note that same-site scope is spelled as an empty string rather than as an omitted member. The imperative API carries its opt-in separately, in `create: true`, so it can treat an omitted `origins` as "same-site only". `fetch()` has no such second signal, so the member's _presence_ is what opts the request into COS and its _value_ is what scopes the result. Omitting `crossOriginStorage` while keeping `integrity` therefore preserves today's behavior exactly: the response is fetched and verified, and COS is neither consulted nor written.

The list form is a `sequence<DOMString>`, whereas the HTML attribute and the import attribute take a space-separated string and the CSS modifier a comma-separated list of `<string>`s. That difference is deliberate rather than an oversight: a `RequestInit` member is an ordinary JavaScript value, so a sequence is the idiomatic spelling and it matches the imperative `origins` option exactly, down to the IDL type. The other three surfaces have no such choice, because attribute values are text, import attribute values are restricted to strings by [TC39](https://github.com/tc39/proposal-import-attributes), and CSS has no array type. All four resolve to the same value space.

#### Examples

```js
// Same-site only, mirroring an omitted `origins` in the imperative API.
const sameSite = await fetch('same-site-resource.ext', {
  integrity: 'sha256-abc123...',
  crossOriginStorage: '',
});

// Globally available.
const global = await fetch('popular-resource.ext', {
  integrity: 'sha256-abc123...',
  crossOriginStorage: '*',
});

// Restricted to specific origins.
const restricted = await fetch('acme-inc-corporate.ext', {
  integrity: 'sha256-def456...',
  crossOriginStorage: [
    'https://acme-inc.example.com',
    'https://acme-cdn.example.com',
  ],
});
```

#### Processing model

The four integrations are meant to share one model: look COS up by the integrity hash, and fall back to the network on anything other than a disclosable hit.

1. If `crossOriginStorage` is absent, proceed exactly as today. COS is not involved.
2. Otherwise, before going to the network, run [resolve a COS lookup](https://wicg.github.io/cross-origin-storage/#reading-files) for the request's integrity metadata and the request's origin. On success, the response is served from COS and no network request is made.
3. On any failure, fetch from the network as usual. If the response's bytes match the integrity metadata and the declared value permits it, store them in COS for reuse. If the hash does not match, the response is rejected per existing SRI behavior and nothing is stored.

Step 2's failure is not only "not present". A lookup can also fail because the hash has not cleared the [Public Hash List](https://wicg.github.io/cross-origin-storage/#public-hash-list), because the user agent applied [GREASE'ing](https://wicg.github.io/cross-origin-storage/#greaseing), or because the origin has exhausted its cross-origin probe budget. All of these are deliberately indistinguishable from a genuine cache miss and all fall through to step 3 identically; see [Availability gating](https://wicg.github.io/cross-origin-storage/#availability-gating). An integration that distinguished them would leak precisely what the gating exists to withhold.

#### Feature detection and progressive enhancement

An unknown `RequestInit` member is ignored, so a `fetch()` written against this proposal behaves in a browser without COS exactly as it does today: the network fetch happens, `integrity` is verified, nothing is stored. No fallback path is needed.

Detection is worth designing on purpose rather than leaving to the dictionary-getter trick. Fetch already reflects `integrity` as a `Request` attribute, and reflecting this member the same way gives a clean check:

```webidl
partial interface Request {
  readonly attribute any crossOriginStorage;
};
```

```js
const supported = 'crossOriginStorage' in Request.prototype;
```

#### Non-browser `fetch()` implementations

Server runtimes such as Node.js, Deno, and Bun implement `fetch()` but have no cross-origin boundary and no user whose browsing history is at stake, so COS does not exist there. They would ignore `crossOriginStorage` the way they ignore other browser-specific request options, and isomorphic code keeps working unchanged.


### Anything else?

#### Open questions

The first two are specific to this integration and are the reason the COS explainer says the answers belong in the Fetch Standard discussion rather than in the COS specification. The rest are integration-mechanics questions that the three declarative forms did not have to face.

1. **Response fidelity on a hit: MIME type.** A COS entry carries bytes only, with no MIME type, status, or headers, deliberately so, because unverifiable metadata cannot be attributed to a hash (see [Storing the original URL as part of a COS entry](https://github.com/WICG/cross-origin-storage#storing-the-original-url-as-part-of-a-cos-entry)). A `Response` synthesized from a hit therefore has no `Content-Type` unless the integration invents one. The three other integrations sidestep this because the element, the module type, or the CSS property fixes the destination, whereas a bare `fetch()` has none. This bites immediately: `WebAssembly.instantiateStreaming()` refuses anything that is not `application/wasm`, which is exactly why the hand-written example above has to supply that header itself. Candidate answers: derive the type from the request's [destination](https://fetch.spec.whatwg.org/#concept-request-destination), let the caller declare it, or store a user-agent-computed type alongside the bytes. (Authors' hunch: store a user-agent-computed type alongside the bytes.)
2. **Response fidelity on a hit: everything else.** A response served from COS must not reveal whether the bytes came from storage or from the network, so it cannot carry the response headers of a fetch that never happened. As a privacy matter this is smaller than it looks, since cache hits are timing-observable regardless and disclosure is already gated by the declared origins, the Public Hash List, and GREASE'ing on the read step. The open question is one of fidelity: which `status`, `statusText`, `Content-Length`, `type`, and `url` a hit-served `Response` should report, and whether a [Resource Timing](https://w3c.github.io/resource-timing/) entry is recorded for it and with what values. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
3. **Where the lookup hooks in, and what it ranks against.** The COS lookup has to sit below a service worker, so that `event.respondWith()` still wins for a page's own interception, and presumably below the HTTP cache, whose entries are same-origin and higher fidelity. That suggests the lookup belongs in [HTTP fetch](https://fetch.spec.whatwg.org/#http-fetch) after the service worker declines, rather than in main fetch. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
4. **Streaming versus SRI's full-body buffering.** When `integrity` is non-empty, main fetch currently fully reads the response body before running fetch response handover, so the `fetch()` promise does not resolve until all the bytes are in. That means `WebAssembly.instantiateStreaming(fetch(url, { integrity }))` does not actually overlap download and compilation today, with or without COS. Since recovering that overlap without hand-written `tee()` plumbing is a main motivation here, this proposal's value depends on whether streaming SRI validation is on the table, or whether a COS hit (whose bytes were hash-verified when they were written and need no re-verification) can stream even while a network response cannot. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
5. **`crossOriginStorage` without `integrity`.** There is nothing to look up without a hash. Unlike a content attribute, `RequestInit` has an exception channel and the `Request` constructor already throws for invalid combinations, so a `TypeError` at construction time seems better than silently ignoring the member. (Authors' hunch: `TypeError`.)
6. **Permissions Policy.** COS is gated by a [`cross-origin-storage` policy-controlled feature](https://wicg.github.io/cross-origin-storage/#permissions-policy-integration). When the feature is disallowed, `requestFileHandle()` rejects with a `NotAllowedError`. For this integration, rejecting the fetch would be wrong, since the request is perfectly valid; behaving as if the member were absent, that is fetching from the network and never touching COS, is consistent with an ordinary miss and with the answer proposed for the same question in whatwg/html#12770. (Authors' hunch: behave as if absent.)
7. **Probe budget accounting.** A COS lookup discloses one bit, whether the user already has these bytes, and a site can read that bit from an integration lookup just as well as from an imperative call, by observing whether its own server received the fallback request. Lookups from `fetch()` therefore have to be charged against the same [cross-origin probe budget](https://wicg.github.io/cross-origin-storage/#storage-limits) as `requestFileHandle()` calls, or the budget is trivially avoidable, since a `fetch()` lookup is as scriptable in a loop as an imperative one. The COS specification routes all four integrations through one algorithm for this reason. (Authors hunch: Fetch invokes that algorithm.)
8. **A cancelled body on a miss.** If the caller cancels the response body partway through a cache-miss fetch, does the user agent keep downloading to complete the COS write, or abandon it? Abandoning it matches "the user agent does no work the page did not ask for", but throws away a partly transferred large resource. (Authors' hunch: abandon.)

#### This does not replace `requestFileHandle()`

Worth stating up front, since it came up when the fetch integration was first requested in [WICG/cross-origin-storage#74](https://github.com/WICG/cross-origin-storage/issues/74): this option is an addition to the imperative COS API, not a replacement for it. A fetch couples naming a resource to downloading it, and three things COS has to support do not fit that shape.

- **Bytes reach COS from places `fetch()` does not own.** They may arrive from a [Background Fetch](https://wicg.github.io/background-fetch/), from `Range` requests for a sharded resource the site reassembles itself, from a file the user picked off their local disk, or from another storage API. The sharded case cannot be expressed through a fetch integration at all, because the stored entry is a shard that no single URL serves.
- **A read may have no URL to offer.** AI models ship as families of interchangeable variants, so an app built around `whisper-tiny` should transcribe with `whisper-large-v3` if the user already has it, rather than downloading a smaller and worse model on top of a better one. That means probing several hashes and committing to a download only after all of them come back empty. A fetch-shaped API cannot ask this, because every probe would have to name a URL the app has no intention of fetching.
- **Handles are not responses.** A `FileSystemFileHandle` can be transferred to another context, read several times, and written through with the same File System Standard machinery developers already use for OPFS. A `Response` is a single, one-shot consumption of a body, and a store-only write has no natural spelling in `fetch()`: there is no request to make, only bytes to hand over.

#### Related proposals

Sharing the same underlying model, one per host:

- [whatwg/html#12770](https://github.com/whatwg/html/issues/12770): a `crossoriginstorage` content attribute on `<link>` and `<script>`.
- [whatwg/html#12771](https://github.com/whatwg/html/issues/12771): a `crossOriginStorage` import attribute, for static `import` and dynamic `import()`.
- [w3c/csswg-drafts#14056](https://github.com/w3c/csswg-drafts/issues/14056): a `cross-origin-storage()` `<request-url-modifier>`.

#### References

- [Cross-Origin Storage explainer](https://github.com/WICG/cross-origin-storage), and its [Fetch integration](https://github.com/WICG/cross-origin-storage#fetch-integration) section.
- [Cross-Origin Storage specification draft](https://wicg.github.io/cross-origin-storage/).
- [Security and privacy self-review questionnaire](https://github.com/WICG/cross-origin-storage/blob/main/security-privacy-questionnaire.md).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1954
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1954@github.com>
Aquileo | [whatwg/fetch] Add `crossOriginStorage` option on `RequestInit` (Issue #1954)Thomas Steinernotifications@github.commid:whatwg/fetch/issues/1954@github.com2026-08-26T13:56:07+00:00
tomayac created an issue (whatwg/fetch#1954)

### What problem are you trying to solve?

The [Cross-Origin Storage (COS) API](https://github.com/WICG/cross-origin-storage) ([specification draft](https://wicg.github.io/cross-origin-storage/)) is a proposed browser mechanism that lets large resources, such as AI models, Wasm modules, popular JavaScript libraries, and web fonts, be stored once and retrieved across origins, identified by their cryptographic hash rather than by their URL. Two sites that use the same 3 GB model download it once between them instead of once each.

Three host integrations let a resource opt into COS declaratively, each alongside an `integrity` hash that identifies the resource: a `crossoriginstorage` content attribute on `<link>` and `<script>` ([whatwg/html#12770](https://github.com/whatwg/html/issues/12770)), a `crossOriginStorage` import attribute ([whatwg/html#12771](https://github.com/whatwg/html/issues/12771)), and a `cross-origin-storage()` URL modifier in CSS ([w3c/csswg-drafts#14056](https://github.com/w3c/csswg-drafts/issues/14056)).

The imperative case has no such opt-in, and it is the case that matters most for the resources this is designed around. A multi-gigabyte model, a Wasm module, or an asset bundle is not referenced from markup or from a stylesheet: it is fetched by script that already holds both the URL and the hash. Today, moving such a resource onto COS means abandoning `fetch()` for a hand-written cache-check, fallback-fetch, and store sequence built on the proposed imperative `navigator.crossOriginStorage.requestFileHandle()` API. That is the most code of any of the four surfaces, for the surface where the payoff is largest.

This issue proposes closing that gap with a `crossOriginStorage` option on `RequestInit`, used alongside the existing [`integrity`](https://fetch.spec.whatwg.org/#dom-requestinit-integrity) option, so that a script can opt a fetch into COS the same way markup, module graphs, and stylesheets can opt their resources in.


### What solutions exist today?

The only existing (proposed) opt-in for an imperative fetch is `navigator.crossOriginStorage.requestFileHandle()`. It works, but the caller has to write the whole cache-miss path by hand, and for large resources it has to write the streaming version of it, so that download and consumption overlap rather than serialize. This is the pattern the COS explainer currently recommends for a Wasm module:

```js
const hash = {
  algorithm: 'SHA-256',
  value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
const wasmHeaders = { headers: { 'Content-Type': 'application/wasm' } };

try {
  // Cache hit: stream from the stored file.
  const handle = await navigator.crossOriginStorage.requestFileHandle(hash);
  const file = await handle.getFile();
  const { instance } = await WebAssembly.instantiateStreaming(
    new Response(file.stream(), wasmHeaders),
    imports,
  );
  return instance;
} catch (err) {
  if (err.name !== 'NotFoundError') {
    throw err;
  }
}

// Cache miss: split the body so compilation and storage proceed in parallel.
const response = await fetch('/model.wasm');
if (!response.ok) {
  throw new Error(`HTTP ${response.status}`);
}
const [compileStream, storeStream] = response.body.tee();

// Fire-and-forget store; never block on the write.
(async () => {
  try {
    const handle = await navigator.crossOriginStorage.requestFileHandle(hash, {
      create: true,
      origins: '*',
    });
    const writableStream = await handle.createWritable();
    await storeStream.pipeTo(writableStream);
  } catch (err) {
    // Release the unconsumed branch so the body isn't buffered indefinitely.
    storeStream.cancel().catch(() => {});
  }
})();

const { instance } = await WebAssembly.instantiateStreaming(
  new Response(compileStream, wasmHeaders),
  imports,
);
return instance;
```

Around 30 lines of `tee()`, `pipeTo()`, and cancellation, per resource, for what is conceptually one fetch. Every branch of it is a place to get the common case wrong, and getting it wrong is silent: forgetting the `tee()` costs the download and compile overlap that `WebAssembly.instantiateStreaming()` exists to provide, and forgetting the `cancel()` buffers an unconsumed body for the lifetime of the fetch. The hash also has to be written twice, once as a `requestFileHandle()` argument and once as an `integrity` value, in two different encodings, if the caller also wants the network path verified.

With a request option, the same thing is:

```js
const { instance } = await WebAssembly.instantiateStreaming(
  fetch('module.wasm', {
    integrity: 'sha256-abc123...',
    crossOriginStorage: '*',
  }),
  imports,
);
```


### How would you solve it?

Add a `crossOriginStorage` member to `RequestInit`:

```webidl
partial dictionary RequestInit {
  (DOMString or sequence<DOMString>) crossOriginStorage;
};
```

The member is only meaningful alongside `integrity`, which supplies the hash that identifies the resource in COS. Its value declares which origins may retrieve the stored bytes, mirroring the `origins` option of `requestFileHandle()` and the values the three other integrations accept:

| Value                      | Meaning                                 |
| -------------------------- | --------------------------------------- |
| absent                     | No COS participation (today's behavior) |
| `""`                       | Same-site access only                   |
| `"*"`                      | Globally available to all origins       |
| `["https://a.example", …]` | Available to the listed origins only    |

An origin list is subject to the same [implementation-defined maximum length](https://wicg.github.io/cross-origin-storage/#storage-limits) as the `origins` option of `requestFileHandle()`, for the same reason: without a cap, a caller could enumerate enough origins to approximate `"*"` without ever declaring it. See [Cross-site probing](https://wicg.github.io/cross-origin-storage/#cross-site-probing).

Note that same-site scope is spelled as an empty string rather than as an omitted member. The imperative API carries its opt-in separately, in `create: true`, so it can treat an omitted `origins` as "same-site only". `fetch()` has no such second signal, so the member's _presence_ is what opts the request into COS and its _value_ is what scopes the result. Omitting `crossOriginStorage` while keeping `integrity` therefore preserves today's behavior exactly: the response is fetched and verified, and COS is neither consulted nor written.

The list form is a `sequence<DOMString>`, whereas the HTML attribute and the import attribute take a space-separated string and the CSS modifier a comma-separated list of `<string>`s. That difference is deliberate rather than an oversight: a `RequestInit` member is an ordinary JavaScript value, so a sequence is the idiomatic spelling and it matches the imperative `origins` option exactly, down to the IDL type. The other three surfaces have no such choice, because attribute values are text, import attribute values are restricted to strings by [TC39](https://github.com/tc39/proposal-import-attributes), and CSS has no array type. All four resolve to the same value space.

#### Examples

```js
// Same-site only, mirroring an omitted `origins` in the imperative API.
const sameSite = await fetch('same-site-resource.ext', {
  integrity: 'sha256-abc123...',
  crossOriginStorage: '',
});

// Globally available.
const global = await fetch('popular-resource.ext', {
  integrity: 'sha256-abc123...',
  crossOriginStorage: '*',
});

// Restricted to specific origins.
const restricted = await fetch('acme-inc-corporate.ext', {
  integrity: 'sha256-def456...',
  crossOriginStorage: [
    'https://acme-inc.example.com',
    'https://acme-cdn.example.com',
  ],
});
```

#### Processing model

The four integrations are meant to share one model: look COS up by the integrity hash, and fall back to the network on anything other than a disclosable hit.

1. If `crossOriginStorage` is absent, proceed exactly as today. COS is not involved.
2. Otherwise, before going to the network, run [resolve a COS lookup](https://wicg.github.io/cross-origin-storage/#reading-files) for the request's integrity metadata and the request's origin. On success, the response is served from COS and no network request is made.
3. On any failure, fetch from the network as usual. If the response's bytes match the integrity metadata and the declared value permits it, store them in COS for reuse. If the hash does not match, the response is rejected per existing SRI behavior and nothing is stored.

Step 2's failure is not only "not present". A lookup can also fail because the hash has not cleared the [Public Hash List](https://wicg.github.io/cross-origin-storage/#public-hash-list), because the user agent applied [GREASE'ing](https://wicg.github.io/cross-origin-storage/#greaseing), or because the origin has exhausted its cross-origin probe budget. All of these are deliberately indistinguishable from a genuine cache miss and all fall through to step 3 identically; see [Availability gating](https://wicg.github.io/cross-origin-storage/#availability-gating). An integration that distinguished them would leak precisely what the gating exists to withhold.

#### Feature detection and progressive enhancement

An unknown `RequestInit` member is ignored, so a `fetch()` written against this proposal behaves in a browser without COS exactly as it does today: the network fetch happens, `integrity` is verified, nothing is stored. No fallback path is needed.

Detection is worth designing on purpose rather than leaving to the dictionary-getter trick. Fetch already reflects `integrity` as a `Request` attribute, and reflecting this member the same way gives a clean check:

```webidl
partial interface Request {
  readonly attribute any crossOriginStorage;
};
```

```js
const supported = 'crossOriginStorage' in Request.prototype;
```

#### Non-browser `fetch()` implementations

Server runtimes such as Node.js, Deno, and Bun implement `fetch()` but have no cross-origin boundary and no user whose browsing history is at stake, so COS does not exist there. They would ignore `crossOriginStorage` the way they ignore other browser-specific request options, and isomorphic code keeps working unchanged.


### Anything else?

#### Open questions

The first two are specific to this integration and are the reason the COS explainer says the answers belong in the Fetch Standard discussion rather than in the COS specification. The rest are integration-mechanics questions that the three declarative forms did not have to face.

1. **Response fidelity on a hit: MIME type.** A COS entry carries bytes only, with no MIME type, status, or headers, deliberately so, because unverifiable metadata cannot be attributed to a hash (see [Storing the original URL as part of a COS entry](https://github.com/WICG/cross-origin-storage#storing-the-original-url-as-part-of-a-cos-entry)). A `Response` synthesized from a hit therefore has no `Content-Type` unless the integration invents one. The three other integrations sidestep this because the element, the module type, or the CSS property fixes the destination, whereas a bare `fetch()` has none. This bites immediately: `WebAssembly.instantiateStreaming()` refuses anything that is not `application/wasm`, which is exactly why the hand-written example above has to supply that header itself. Candidate answers: derive the type from the request's [destination](https://fetch.spec.whatwg.org/#concept-request-destination), let the caller declare it, or store a user-agent-computed type alongside the bytes. (Authors' hunch: store a user-agent-computed type alongside the bytes.)
2. **Response fidelity on a hit: everything else.** A response served from COS must not reveal whether the bytes came from storage or from the network, so it cannot carry the response headers of a fetch that never happened. As a privacy matter this is smaller than it looks, since cache hits are timing-observable regardless and disclosure is already gated by the declared origins, the Public Hash List, and GREASE'ing on the read step. The open question is one of fidelity: which `status`, `statusText`, `Content-Length`, `type`, and `url` a hit-served `Response` should report, and whether a [Resource Timing](https://w3c.github.io/resource-timing/) entry is recorded for it and with what values. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
3. **Where the lookup hooks in, and what it ranks against.** The COS lookup has to sit below a service worker, so that `event.respondWith()` still wins for a page's own interception, and presumably below the HTTP cache, whose entries are same-origin and higher fidelity. That suggests the lookup belongs in [HTTP fetch](https://fetch.spec.whatwg.org/#http-fetch) after the service worker declines, rather than in main fetch. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
4. **Streaming versus SRI's full-body buffering.** When `integrity` is non-empty, main fetch currently fully reads the response body before running fetch response handover, so the `fetch()` promise does not resolve until all the bytes are in. That means `WebAssembly.instantiateStreaming(fetch(url, { integrity }))` does not actually overlap download and compilation today, with or without COS. Since recovering that overlap without hand-written `tee()` plumbing is a main motivation here, this proposal's value depends on whether streaming SRI validation is on the table, or whether a COS hit (whose bytes were hash-verified when they were written and need no re-verification) can stream even while a network response cannot. (Authors hunch: N/A, yielding to Fetch authors' expertise.)
5. **`crossOriginStorage` without `integrity`.** There is nothing to look up without a hash. Unlike a content attribute, `RequestInit` has an exception channel and the `Request` constructor already throws for invalid combinations, so a `TypeError` at construction time seems better than silently ignoring the member. (Authors' hunch: `TypeError`.)
6. **Permissions Policy.** COS is gated by a [`cross-origin-storage` policy-controlled feature](https://wicg.github.io/cross-origin-storage/#permissions-policy-integration). When the feature is disallowed, `requestFileHandle()` rejects with a `NotAllowedError`. For this integration, rejecting the fetch would be wrong, since the request is perfectly valid; behaving as if the member were absent, that is fetching from the network and never touching COS, is consistent with an ordinary miss and with the answer proposed for the same question in whatwg/html#12770. (Authors' hunch: behave as if absent.)
7. **Probe budget accounting.** A COS lookup discloses one bit, whether the user already has these bytes, and a site can read that bit from an integration lookup just as well as from an imperative call, by observing whether its own server received the fallback request. Lookups from `fetch()` therefore have to be charged against the same [cross-origin probe budget](https://wicg.github.io/cross-origin-storage/#storage-limits) as `requestFileHandle()` calls, or the budget is trivially avoidable, since a `fetch()` lookup is as scriptable in a loop as an imperative one. The COS specification routes all four integrations through one algorithm for this reason. (Authors hunch: Fetch invokes that algorithm.)
8. **A cancelled body on a miss.** If the caller cancels the response body partway through a cache-miss fetch, does the user agent keep downloading to complete the COS write, or abandon it? Abandoning it matches "the user agent does no work the page did not ask for", but throws away a partly transferred large resource. (Authors' hunch: abandon.)

#### This does not replace `requestFileHandle()`

Worth stating up front, since it came up when the fetch integration was first requested in [WICG/cross-origin-storage#74](https://github.com/WICG/cross-origin-storage/issues/74): this option is an addition to the imperative COS API, not a replacement for it. A fetch couples naming a resource to downloading it, and three things COS has to support do not fit that shape.

- **Bytes reach COS from places `fetch()` does not own.** They may arrive from a [Background Fetch](https://wicg.github.io/background-fetch/), from `Range` requests for a sharded resource the site reassembles itself, from a file the user picked off their local disk, or from another storage API. The sharded case cannot be expressed through a fetch integration at all, because the stored entry is a shard that no single URL serves.
- **A read may have no URL to offer.** AI models ship as families of interchangeable variants, so an app built around `whisper-tiny` should transcribe with `whisper-large-v3` if the user already has it, rather than downloading a smaller and worse model on top of a better one. That means probing several hashes and committing to a download only after all of them come back empty. A fetch-shaped API cannot ask this, because every probe would have to name a URL the app has no intention of fetching.
- **Handles are not responses.** A `FileSystemFileHandle` can be transferred to another context, read several times, and written through with the same File System Standard machinery developers already use for OPFS. A `Response` is a single, one-shot consumption of a body, and a store-only write has no natural spelling in `fetch()`: there is no request to make, only bytes to hand over.

#### Related proposals

Sharing the same underlying model, one per host:

- [whatwg/html#12770](https://github.com/whatwg/html/issues/12770): a `crossoriginstorage` content attribute on `<link>` and `<script>`.
- [whatwg/html#12771](https://github.com/whatwg/html/issues/12771): a `crossOriginStorage` import attribute, for static `import` and dynamic `import()`.
- [w3c/csswg-drafts#14056](https://github.com/w3c/csswg-drafts/issues/14056): a `cross-origin-storage()` `<request-url-modifier>`.

#### References

- [Cross-Origin Storage explainer](https://github.com/WICG/cross-origin-storage), and its [Fetch integration](https://github.com/WICG/cross-origin-storage#fetch-integration) section.
- [Cross-Origin Storage specification draft](https://wicg.github.io/cross-origin-storage/).
- [Security and privacy self-review questionnaire](https://github.com/WICG/cross-origin-storage/blob/main/security-privacy-questionnaire.md).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1954
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1954@github.com>
Aquileo | Re: [w3c/FileAPI] Add `textStream()` method to `Blob` interface (#221) (cd1d1da)rahul125gazi-devnotifications@github.commid:w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co2026-08-26T04:11:21+00:00
zx Dj

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b#commitcomment-197726387
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co>
Aquileo | Re: [w3c/FileAPI] Add `textStream()` method to `Blob` interface (#221) (cd1d1da)rahul125gazi-devnotifications@github.commid:w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co2026-08-26T04:11:21+00:00
zx Dj

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b#commitcomment-197726387
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co>
Aquileo | Re: [w3c/FileAPI] Add `textStream()` method to `Blob` interface (#221) (cd1d1da)rahul125gazi-devnotifications@github.commid:w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co2026-08-26T04:11:21+00:00
zx Dj

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b#commitcomment-197726387
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co>
Aquileo | Re: [w3c/FileAPI] Add `textStream()` method to `Blob` interface (#221) (cd1d1da)rahul125gazi-devnotifications@github.commid:w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co2026-08-26T04:11:21+00:00
zx Dj

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b#commitcomment-197726387
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co>
Aquileo | Re: [w3c/FileAPI] Add `textStream()` method to `Blob` interface (#221) (cd1d1da)rahul125gazi-devnotifications@github.commid:w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co2026-08-26T04:11:21+00:00
zx Dj

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b#commitcomment-197726387
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/commit/cd1d1da9a5375af0622af4b36e76c6e6bd9d130b/197726387@github.co>
Aquileo | [w3c/selection-api] `anchorNode` & `focusNode` can never be in shadow tree? (Issue #361)Euclid Yenotifications@github.commid:w3c/selection-api/issues/361@github.com2026-08-26T03:42:13+00:00
yezhizhen created an issue (w3c/selection-api#361)

> [anchor](https://w3c.github.io/selection-api/#dfn-anchor) and [focus](https://w3c.github.io/selection-api/#dfn-focus) of [selection](https://w3c.github.io/selection-api/#dfn-selection) need not to be in the [document tree](https://dom.spec.whatwg.org/#concept-document-tree). It could be in a [shadow tree](https://dom.spec.whatwg.org/#concept-shadow-tree) of the same [document](https://dom.spec.whatwg.org/#document).

However, it also says:
[anchorNode](https://w3c.github.io/selection-api/#dom-selection-anchornode)
    The attribute must return the [anchor](https://w3c.github.io/selection-api/#dfn-anchor) [node](https://dom.spec.whatwg.org/#boundary-point-node) of [this](https://webidl.spec.whatwg.org/#this), or null if the [anchor](https://w3c.github.io/selection-api/#dfn-anchor) is null or [anchor](https://w3c.github.io/selection-api/#dfn-anchor) is not in the [document tree](https://dom.spec.whatwg.org/#concept-document-tree).

So `anchorNode` can never be in shadow tree. This is also contradictory to tests:
https://github.com/servo/servo/blob/e83f3117045171e59f230c3b36ebd721826d3754/tests/wpt/tests/selection/shadow-dom/tentative/Selection-isCollapsed.html#L48

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/361
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/issues/361@github.com>
Aquileo | [whatwg/webidl] DOMException name proposal (Issue #1631)israrbacha289notifications@github.commid:whatwg/webidl/issues/1631@github.com2026-08-26T00:55:12+00:00
israrbacha289 created an issue (whatwg/webidl#1631)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1631
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1631@github.com>
Aquileo | Re: [w3c/IndexedDB] Allow more explicit control over transaction lifetimes (#34)Evan Stadenotifications@github.commid:w3c/IndexedDB/issues/34/5415607146@github.com2026-08-25T19:28:33+00:00
evanstade left a comment (w3c/IndexedDB#34)

By the way, the lack of ability to disable autocommit is a performance bug since working around it requires intense polling. See [Dexie.waitFor()](https://dexie.org/docs/Dexie/Dexie.waitFor()):

> WARNING: This method can be CPU intensive while waiting for given Promise. It typically triggers about 1000 dummy-queries while waiting for just a 100 milliseconds.
Use with caution when the purpose is to keep a transaction alive as it may put unnecessary CPU load on the browser. A separate task will keep the transaction alive by propagating dummy-requests on the transaction while the given promise is being executed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/34#issuecomment-5415607146
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/34/5415607146@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Add keyword "pair" to scroll-snap-type for snapping to the same element in X and Y axes (Issue #1271)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1271@github.com2026-08-25T15:04:20+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1271)

### Specification

https://github.com/w3c/csswg-drafts/pull/14386

### Explainer

https://github.com/explainers-by-googlers/scroll-snap-type-pair

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/scroll-snap-type-pair
- A description of the problems that end-users were facing before this proposal: When "scroll-snap-type: both" is specified, the scroll container searches for snap points on X and Y axes independently. https://github.com/w3c/csswg-drafts/issues/9519
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/explainers-by-googlers/scroll-snap-type-pair#use-case-2d-interactive-map-with-points-of-interest-demo
- What do the end-users experience with this proposal: https://github.com/explainers-by-googlers/scroll-snap-type-pair#proposal
- Web Platform Tests:  Tentative test for parser: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/css/css-scroll-snap/pair/scroll-snap-type-pair.tentative.html Will add more tests.


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
 - David Liu (@lcdavid94), Google, Author
 - Robert Flack (@flackr), Google, Spec work & reviewer
 - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
 - https://github.com/w3c/csswg-drafts/issues/9519

### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5124378896498688
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1448
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/716
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: Chromium comments: https://chromestatus.com/feature/5124378896498688


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1271


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1271
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1271@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Add keyword "pair" to scroll-snap-type for snapping to the same element in X and Y axes (Issue #1271)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1271@github.com2026-08-25T15:04:20+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1271)

### Specification

https://github.com/w3c/csswg-drafts/pull/14386

### Explainer

https://github.com/explainers-by-googlers/scroll-snap-type-pair

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/scroll-snap-type-pair
- A description of the problems that end-users were facing before this proposal: When "scroll-snap-type: both" is specified, the scroll container searches for snap points on X and Y axes independently. https://github.com/w3c/csswg-drafts/issues/9519
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/explainers-by-googlers/scroll-snap-type-pair#use-case-2d-interactive-map-with-points-of-interest-demo
- What do the end-users experience with this proposal: https://github.com/explainers-by-googlers/scroll-snap-type-pair#proposal
- Web Platform Tests:  Tentative test for parser: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/css/css-scroll-snap/pair/scroll-snap-type-pair.tentative.html Will add more tests.


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
 - David Liu (@lcdavid94), Google, Author
 - Robert Flack (@flackr), Google, Spec work & reviewer
 - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
 - https://github.com/w3c/csswg-drafts/issues/9519

### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5124378896498688
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1448
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/716
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: Chromium comments: https://chromestatus.com/feature/5124378896498688


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1271


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1271
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1271@github.com>
Aquileo | Re: [whatwg/fetch] Add support for compression dictionary transport (PR #1854)Simone Onofrinotifications@github.commid:whatwg/fetch/pull/1854/c5409939010@github.com2026-08-25T11:49:43+00:00
simoneonofri left a comment (whatwg/fetch#1854)

Hi all, thanks for your patience, [following up on the TAG discussion](https://github.com/w3ctag/design-reviews/issues/1203) and the discussion in SING.

After checking this PR, I think the issue's immediate concern is no longer present in that patch:
- no-cors -specific handling was removed
- no-cors requests fall back before dictionary negotiation;
- registration is limited to non-opaque responses in secure contexts
- an opaque dictionary-compressed response produces a network error

And this is in line with [RFC 9842 Section 9.3.2](https://www.rfc-editor.org/rfc/rfc9842.html#section-9.3.2) boundary.

If opaque-response support returns in a separate proposal, however, `CORP: cross-origin` would not be an equivalent signal, as it permits a no-cors response to pass CORP but does not make it CORS-readable.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1854#issuecomment-5409939010
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1854/c5409939010@github.com>
Aquileo | Re: [whatwg/fetch] Add support for compression dictionary transport (PR #1854)Simone Onofrinotifications@github.commid:whatwg/fetch/pull/1854/c5409939010@github.com2026-08-25T11:49:43+00:00
simoneonofri left a comment (whatwg/fetch#1854)

Hi all, thanks for your patience, [following up on the TAG discussion](https://github.com/w3ctag/design-reviews/issues/1203) and the discussion in SING.

After checking this PR, I think the issue's immediate concern is no longer present in that patch:
- no-cors -specific handling was removed
- no-cors requests fall back before dictionary negotiation;
- registration is limited to non-opaque responses in secure contexts
- an opaque dictionary-compressed response produces a network error

And this is in line with [RFC 9842 Section 9.3.2](https://www.rfc-editor.org/rfc/rfc9842.html#section-9.3.2) boundary.

If opaque-response support returns in a separate proposal, however, `CORP: cross-origin` would not be an equivalent signal, as it permits a no-cors response to pass CORP but does not make it CORS-readable.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1854#issuecomment-5409939010
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1854/c5409939010@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/editing] When should metadata-content elements like <style> be editable? (Issue #546)Masayuki Nakanonotifications@github.commid:w3c/editing/issues/546/5406105865@github.com2026-08-25T05:46:56+00:00
masayuki-nakano left a comment (w3c/editing#546)

> In Firefox they are in a strange state: the <title> allows the user to place the caret like it's an editable field, but no changes can be made,

`<title>` cannot have any elements. E.g., `<br>` cannot be appear. So, supporting its editing requires to add a lot of check for a lot of editing commands. So, unless it's used by major web apps, we don't have much time to support it.

> and the <style> (at least on Windows) allows new characters to be typed but characters can't be deleted.

Well, it's not intentional. I've seen a bug report about editing `<style>` elements. So, probably I didn't try to disable the editing in `<style>`. Perhaps, it's just a bug that you cannot delete text in `<style>`.

> Case 1

Oh, this is unexpected case for me. `contenteditable="false"` was roughly  implemented in Firefox, but I've never sort the behavior out for compatibility. I mean, Firefox does not support `contenteditable="false"` cleanly yet.

> Case 2

I think the structure of `<head>` should not be editable to avoid various compat issues when they are modified.


If there are some requirement for implementing web apps about the editing of meta data, WG needs to consider how they should be editable and what should happen if `<script>` and `<style>` are modified. However, I don't think that's required by usual web apps...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/546#issuecomment-5406105865
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/546/5406105865@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | Re: [w3c/manifest] Add `application-context` CSS media feature (PR #1218)Alexander Kyereboahnotifications@github.commid:w3c/manifest/pull/1218/c5398864655@github.com2026-08-24T17:26:57+00:00
kyerebo left a comment (w3c/manifest#1218)

The review request in the CSSWG thread seems to have landed on a `display-mode: application` proposal. Wanted to get a pulse check on if we're okay with this becoming the normative solution rather than `application-context` MQ.

While I do have concerns around continuing to add non-uniform values to `display-mode`, there are also advantages in not having to create a new media query and working within a space developers are already familiar with. We'd also have to make sure multiple `display-mode` values can match at the same time if we go this route.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1218#issuecomment-5398864655
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1218/c5398864655@github.com>
Aquileo | [whatwg/fetch] Include end time in opaque responses (PR #1953)Noam Rosenthalnotifications@github.commid:whatwg/fetch/pull/1953@github.com2026-08-24T10:21:31+00:00
Resource timing always includes `responseEnd`, even when TAO is omitted.

Closes #1945

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 422 Unprocessable Entity :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 24, 2026, 10:21 AM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=bikeshed-spec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Ffetch%2F569993faa84f2c8b66f76cbf04477fb8138e160d%2Ffetch.bs&force=1&md-status=LS-PR&md-Text-Macro=PR-NUMBER%201953)

**Error output:**

```json
[
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "Expected whitespace between attributes. (for\"fetc...)"
    },
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "While trying to parse a <a> start tag, ran into some unparseable stuff (\"fetch)."
    },
    {
        "lineNum": "407:59",
        "messageType": "fatal",
        "text": "Saw an end tag </a>, but there's no open element corresponding to it.\nOpen tags: <div> at 400:1, <p> at 401:1"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20whatwg/fetch%231953.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1953

-- Commit Summary --

  * Include end time in opaque responses

-- File Changes --

    M fetch.bs (3)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1953.patch
https://github.com/whatwg/fetch/pull/1953.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1953@github.com>
Aquileo | [whatwg/fetch] Include end time in opaque responses (PR #1953)Noam Rosenthalnotifications@github.commid:whatwg/fetch/pull/1953@github.com2026-08-24T10:21:31+00:00
Resource timing always includes `responseEnd`, even when TAO is omitted.

Closes #1945

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 422 Unprocessable Entity :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 24, 2026, 10:21 AM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=bikeshed-spec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Ffetch%2F569993faa84f2c8b66f76cbf04477fb8138e160d%2Ffetch.bs&force=1&md-status=LS-PR&md-Text-Macro=PR-NUMBER%201953)

**Error output:**

```json
[
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "Expected whitespace between attributes. (for\"fetc...)"
    },
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "While trying to parse a <a> start tag, ran into some unparseable stuff (\"fetch)."
    },
    {
        "lineNum": "407:59",
        "messageType": "fatal",
        "text": "Saw an end tag </a>, but there's no open element corresponding to it.\nOpen tags: <div> at 400:1, <p> at 401:1"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20whatwg/fetch%231953.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1953

-- Commit Summary --

  * Include end time in opaque responses

-- File Changes --

    M fetch.bs (3)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1953.patch
https://github.com/whatwg/fetch/pull/1953.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1953@github.com>
Aquileo | [whatwg/fetch] Include end time in opaque responses (PR #1953)Noam Rosenthalnotifications@github.commid:whatwg/fetch/pull/1953@github.com2026-08-24T10:21:31+00:00
Resource timing always includes `responseEnd`, even when TAO is omitted.

Closes #1945

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 422 Unprocessable Entity :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 24, 2026, 10:21 AM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=bikeshed-spec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Ffetch%2F569993faa84f2c8b66f76cbf04477fb8138e160d%2Ffetch.bs&force=1&md-status=LS-PR&md-Text-Macro=PR-NUMBER%201953)

**Error output:**

```json
[
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "Expected whitespace between attributes. (for\"fetc...)"
    },
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "While trying to parse a <a> start tag, ran into some unparseable stuff (\"fetch)."
    },
    {
        "lineNum": "407:59",
        "messageType": "fatal",
        "text": "Saw an end tag </a>, but there's no open element corresponding to it.\nOpen tags: <div> at 400:1, <p> at 401:1"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20whatwg/fetch%231953.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1953

-- Commit Summary --

  * Include end time in opaque responses

-- File Changes --

    M fetch.bs (3)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1953.patch
https://github.com/whatwg/fetch/pull/1953.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1953@github.com>
Aquileo | [whatwg/fetch] Include end time in opaque responses (PR #1953)Noam Rosenthalnotifications@github.commid:whatwg/fetch/pull/1953@github.com2026-08-24T10:21:31+00:00
Resource timing always includes `responseEnd`, even when TAO is omitted.

Closes #1945

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 422 Unprocessable Entity :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 24, 2026, 10:21 AM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=bikeshed-spec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Ffetch%2F569993faa84f2c8b66f76cbf04477fb8138e160d%2Ffetch.bs&force=1&md-status=LS-PR&md-Text-Macro=PR-NUMBER%201953)

**Error output:**

```json
[
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "Expected whitespace between attributes. (for\"fetc...)"
    },
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "While trying to parse a <a> start tag, ran into some unparseable stuff (\"fetch)."
    },
    {
        "lineNum": "407:59",
        "messageType": "fatal",
        "text": "Saw an end tag </a>, but there's no open element corresponding to it.\nOpen tags: <div> at 400:1, <p> at 401:1"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20whatwg/fetch%231953.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1953

-- Commit Summary --

  * Include end time in opaque responses

-- File Changes --

    M fetch.bs (3)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1953.patch
https://github.com/whatwg/fetch/pull/1953.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1953@github.com>
Aquileo | [whatwg/fetch] Include end time in opaque responses (PR #1953)Noam Rosenthalnotifications@github.commid:whatwg/fetch/pull/1953@github.com2026-08-24T10:21:31+00:00
Resource timing always includes `responseEnd`, even when TAO is omitted.

Closes #1945

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 422 Unprocessable Entity :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 24, 2026, 10:21 AM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=bikeshed-spec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fwhatwg%2Ffetch%2F569993faa84f2c8b66f76cbf04477fb8138e160d%2Ffetch.bs&force=1&md-status=LS-PR&md-Text-Macro=PR-NUMBER%201953)

**Error output:**

```json
[
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "Expected whitespace between attributes. (for\"fetc...)"
    },
    {
        "lineNum": "407:31",
        "messageType": "fatal",
        "text": "While trying to parse a <a> start tag, ran into some unparseable stuff (\"fetch)."
    },
    {
        "lineNum": "407:59",
        "messageType": "fatal",
        "text": "Saw an end tag </a>, but there's no open element corresponding to it.\nOpen tags: <div> at 400:1, <p> at 401:1"
    },
    {
        "lineNum": null,
        "messageType": "failure",
        "text": "Did not generate, due to errors exceeding the allowed error level."
    }
]
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20whatwg/fetch%231953.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1953

-- Commit Summary --

  * Include end time in opaque responses

-- File Changes --

    M fetch.bs (3)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1953.patch
https://github.com/whatwg/fetch/pull/1953.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1953@github.com>
Aquileo | [w3ctag/design-reviews] [wg/webrtc] Web Real-Time Communications Working Group Charter (Issue #1270)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1270@github.com2026-08-24T09:15:38+00:00
w3cbot created an issue (w3ctag/design-reviews#1270)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/563

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/webrtc-wg.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/webrtc-wg.html)

Expected end of charter refinement phase: 2026-08-25

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https://www.w3.org/2024/08/webrtc-charter.html&doc2=https://w3c.github.io/charter-drafts/2026/webrtc-wg.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/webrtc)

What kind of charter is this? 
* Existing 

**Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

No substantive change in scope.
A small number of drafts will be retired as their content is mature enough to be moved to specifications that are more advanced on the Rec track. Some specs in CR expected to reach REC within this charter timeframe.

## Where would charter proponents like to see issues raised?

Discussion in this issue. Charter amendment proposals in the [charter-drafts](https://github.com/w3c/charter-drafts/issues?q=is%3Aissue%20state%3Aopen) GH repository.



Note: proposed chairs should be copied @... on this issue.

@youennf @jan-ivar @guidou


## Charter facilitator(s)

cc @caribouW3

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1270


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1270
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1270@github.com>
Aquileo | [w3ctag/design-reviews] [wg/svg] Scalable Vector Graphics (SVG) Working Group Charter (Issue #1269)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1269@github.com2026-08-24T09:12:54+00:00
w3cbot created an issue (w3ctag/design-reviews#1269)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/559

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/svg-wg.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/svg-wg.html)

Expected end of charter refinement phase: 2026-07-24

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https://www.w3.org/2024/04/svg-wg.html&doc2=https://w3c.github.io/charter-drafts/2026/svg-wg.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/svg)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

 Existing WG recharter 

 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

None at the moment. Refinement should answer the question on whether or not to add new work rather than only maintenance.

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised?
In this issue for discussion,  or in the charter-drafts repository for specific wording proposals.

## Anything else we should think about as we review? 

@w3c/svg-wg-members 

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @caribouW3

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1269


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1269
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1269@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Registries developed by the Media WG (Issue #1268)François Daoustnotifications@github.commid:w3ctag/design-reviews/issues/1268@github.com2026-08-24T08:53:55+00:00
tidoust created an issue (w3ctag/design-reviews#1268)

The Media Working Group maintains registries related to some of its specifications on the Recommendation track, namely Media Source Extensions (MSE), Encrypted Media Extensions (EME) and WebCodecs. The registries are published on the Registry Track as Registry Drafts. The Media Working Group would like to advance these documents on the [Registry Track](https://www.w3.org/policies/process/#registries) by publishing them as **Candidate Registry Snapshot**.

We're taking the liberty to request a review of all the registries at once and without further analysis because the registries all have similar registration entry requirements, and because it isn't clear to us what input you might be willing to receive to help your review of such documents. By definition, registries document values, they do not define any architectural or interoperability requirements related to those values. We would expect comments on these requirements to be raised against the underlying specifications (MSE, EME, WebCodecs).

You may raise issues that apply to all registries using the tracking issue at https://github.com/w3c/media-wg/issues/64. More specific issues may be raised in the repositories that hold the documents.

Registry linked to MSE ([GitHub repo](https://github.com/w3c/mse-byte-stream-format-registry/)):
- [Media Source Extensions Byte Stream Format Registry](https://www.w3.org/TR/mse-byte-stream-format-registry/)

Registries linked to EME ([GitHub repo](https://github.com/w3c/encrypted-media/)):
- [Encrypted Media Extensions Initialization Data Format Registry](https://www.w3.org/TR/eme-initdata-registry/)
- [Encrypted Media Extensions Stream Format Registry](https://www.w3.org/TR/eme-stream-registry/)
- [Encrypted Media Extensions HDCP Version Registry](https://www.w3.org/TR/eme-hdcp-version-registry/)

Registries linked to WebCodecs ([GitHub repo](https://github.com/w3c/webcodecs/)):
- [WebCodecs Codec Registry](https://www.w3.org/TR/webcodecs-codec-registry/)
- [WebCodecs VideoFrame Metadata Registry](https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/)

Note: Most of the registries related to MSE and EME used to be published on the Note track (simply because the Registry track did not exist at the time of publication).

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1268


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1268
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1268@github.com>
Aquileo | [WICG/webcomponents] Update reference-target-explainer.md (PR #1125)shuppynotifications@github.commid:WICG/webcomponents/pull/1125@github.com2026-08-24T07:57:54+00:00
this patch renames `interesttarget` to `interestfor` per openui/open-ui#1234, and fixes the associated link.
You can view, comment on, or merge this pull request online at:

  https://github.com/WICG/webcomponents/pull/1125

-- Commit Summary --

  * Update reference-target-explainer.md

-- File Changes --

    M proposals/reference-target-explainer.md (6)

-- Patch Links --

https://github.com/WICG/webcomponents/pull/1125.patch
https://github.com/WICG/webcomponents/pull/1125.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/pull/1125
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/pull/1125@github.com>
Aquileo | [WICG/webcomponents] Update reference-target-explainer.md (PR #1125)shuppynotifications@github.commid:WICG/webcomponents/pull/1125@github.com2026-08-24T07:57:54+00:00
this patch renames `interesttarget` to `interestfor` per openui/open-ui#1234, and fixes the associated link.
You can view, comment on, or merge this pull request online at:

  https://github.com/WICG/webcomponents/pull/1125

-- Commit Summary --

  * Update reference-target-explainer.md

-- File Changes --

    M proposals/reference-target-explainer.md (6)

-- Patch Links --

https://github.com/WICG/webcomponents/pull/1125.patch
https://github.com/WICG/webcomponents/pull/1125.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/pull/1125
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/pull/1125@github.com>
Aquileo | [WICG/webcomponents] Update reference-target-explainer.md (PR #1125)shuppynotifications@github.commid:WICG/webcomponents/pull/1125@github.com2026-08-24T07:57:54+00:00
this patch renames `interesttarget` to `interestfor` per openui/open-ui#1234, and fixes the associated link.
You can view, comment on, or merge this pull request online at:

  https://github.com/WICG/webcomponents/pull/1125

-- Commit Summary --

  * Update reference-target-explainer.md

-- File Changes --

    M proposals/reference-target-explainer.md (6)

-- Patch Links --

https://github.com/WICG/webcomponents/pull/1125.patch
https://github.com/WICG/webcomponents/pull/1125.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/pull/1125
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/pull/1125@github.com>
Aquileo | [WICG/webcomponents] Update reference-target-explainer.md (PR #1125)shuppynotifications@github.commid:WICG/webcomponents/pull/1125@github.com2026-08-24T07:57:54+00:00
this patch renames `interesttarget` to `interestfor` per openui/open-ui#1234, and fixes the associated link.
You can view, comment on, or merge this pull request online at:

  https://github.com/WICG/webcomponents/pull/1125

-- Commit Summary --

  * Update reference-target-explainer.md

-- File Changes --

    M proposals/reference-target-explainer.md (6)

-- Patch Links --

https://github.com/WICG/webcomponents/pull/1125.patch
https://github.com/WICG/webcomponents/pull/1125.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/pull/1125
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/pull/1125@github.com>
Aquileo | [whatwg/url] Add URL path equality and prefix comparison (PR #929)Anne van Kesterennotifications@github.commid:whatwg/url/pull/929@github.com2026-08-23T17:46:29+00:00
Cookies needs to compare URL paths, both for equality and for whether one path
contains another. Comparing serializations is not right for either: an opaque
path can serialize identically to a list of URL path segments, and one path's
serialization can be a prefix of another's without covering whole segments.

Also let the URL path serializer take a URL path, so that callers holding one no
longer have to inline it, and record that a URL path segment never contains
U+002F (/), which is what makes the prefix comparison meaningful.

Closes #814.

Tests: https://github.com/web-platform-tests/wpt/pull/62165


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/url/929.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Preview</a> | <a href="https://whatpr.org/url/929/55d6699...a93e42b.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/url/pull/929

-- Commit Summary --

  * Add URL path equality and prefix comparison

-- File Changes --

    M url.bs (61)

-- Patch Links --

https://github.com/whatwg/url/pull/929.patch
https://github.com/whatwg/url/pull/929.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/929
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/pull/929@github.com>
Aquileo | [whatwg/url] Add URL path equality and prefix comparison (PR #929)Anne van Kesterennotifications@github.commid:whatwg/url/pull/929@github.com2026-08-23T17:46:29+00:00
Cookies needs to compare URL paths, both for equality and for whether one path
contains another. Comparing serializations is not right for either: an opaque
path can serialize identically to a list of URL path segments, and one path's
serialization can be a prefix of another's without covering whole segments.

Also let the URL path serializer take a URL path, so that callers holding one no
longer have to inline it, and record that a URL path segment never contains
U+002F (/), which is what makes the prefix comparison meaningful.

Closes #814.

Tests: https://github.com/web-platform-tests/wpt/pull/62165


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/url/929.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Preview</a> | <a href="https://whatpr.org/url/929/55d6699...a93e42b.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/url/pull/929

-- Commit Summary --

  * Add URL path equality and prefix comparison

-- File Changes --

    M url.bs (61)

-- Patch Links --

https://github.com/whatwg/url/pull/929.patch
https://github.com/whatwg/url/pull/929.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/929
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/pull/929@github.com>
Aquileo | [whatwg/url] Add URL path equality and prefix comparison (PR #929)Anne van Kesterennotifications@github.commid:whatwg/url/pull/929@github.com2026-08-23T17:46:29+00:00
Cookies needs to compare URL paths, both for equality and for whether one path
contains another. Comparing serializations is not right for either: an opaque
path can serialize identically to a list of URL path segments, and one path's
serialization can be a prefix of another's without covering whole segments.

Also let the URL path serializer take a URL path, so that callers holding one no
longer have to inline it, and record that a URL path segment never contains
U+002F (/), which is what makes the prefix comparison meaningful.

Closes #814.

Tests: https://github.com/web-platform-tests/wpt/pull/62165


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/url/929.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Preview</a> | <a href="https://whatpr.org/url/929/55d6699...a93e42b.html" title="Last updated on Aug 23, 2026, 5:46 PM UTC (a93e42b)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/url/pull/929

-- Commit Summary --

  * Add URL path equality and prefix comparison

-- File Changes --

    M url.bs (61)

-- Patch Links --

https://github.com/whatwg/url/pull/929.patch
https://github.com/whatwg/url/pull/929.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/929
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/pull/929@github.com>
Aquileo | Re: [whatwg/fetch] Update :protocol to webtransport-h3 for WebTransport over HTTP/3 (PR #1930)Anne van Kesterennotifications@github.commid:whatwg/fetch/pull/1930/c5385198858@github.com2026-08-23T09:03:47+00:00
annevk left a comment (whatwg/fetch#1930)

@jan-ivar heya, did you see my reply above?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1930#issuecomment-5385198858
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1930/c5385198858@github.com>
Aquileo | Re: [whatwg/fetch] Update :protocol to webtransport-h3 for WebTransport over HTTP/3 (PR #1930)Anne van Kesterennotifications@github.commid:whatwg/fetch/pull/1930/c5385198858@github.com2026-08-23T09:03:47+00:00
annevk left a comment (whatwg/fetch#1930)

@jan-ivar heya, did you see my reply above?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1930#issuecomment-5385198858
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1930/c5385198858@github.com>
Aquileo | Re: [whatwg/dom] Add reference target to shadow root (PR #1353)Anne van Kesterennotifications@github.commid:whatwg/dom/pull/1353/c5385164854@github.com2026-08-23T08:55:04+00:00
annevk left a comment (whatwg/dom#1353)

@dandclark it looks like this PR and https://github.com/whatwg/html/pull/10995 need rebasing (again?). I wasn't able to get to these before my break, but there should be time now. Please leave a comment when you think everything is in order as just rebasing might not trigger a notification.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1353#issuecomment-5385164854
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1353/c5385164854@github.com>
Aquileo | Re: [w3c/FileAPI] Fold File and Directory Entries API into File API (PR #222)Anne van Kesterennotifications@github.commid:w3c/FileAPI/pull/222/review/5001918038@github.com2026-08-23T07:45:29+00:00
@annevk commented on this pull request.



> @@ -704,6 +883,7 @@ interface File : Blob {
               optional FilePropertyBag options = {});
   readonly attribute DOMString name;
   readonly attribute long long lastModified;
+  readonly attribute USVString webkitRelativePath;

I think @jcayzac did the right thing.

The Compat specification is meant to be temporary. Prefixed features that end up widely deployed should just be standardized in the relevant specification, not separately.

We also don't want to introduce new features while making a big move like this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/222#discussion_r3837991628
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/pull/222/review/5001918038@github.com>
Aquileo | Re: [w3c/FileAPI] Fold File and Directory Entries API into File API (PR #222)Anne van Kesterennotifications@github.commid:w3c/FileAPI/pull/222/review/5001918038@github.com2026-08-23T07:45:29+00:00
@annevk commented on this pull request.



> @@ -704,6 +883,7 @@ interface File : Blob {
               optional FilePropertyBag options = {});
   readonly attribute DOMString name;
   readonly attribute long long lastModified;
+  readonly attribute USVString webkitRelativePath;

I think @jcayzac did the right thing.

The Compat specification is meant to be temporary. Prefixed features that end up widely deployed should just be standardized in the relevant specification, not separately.

We also don't want to introduce new features while making a big move like this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/222#discussion_r3837991628
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/pull/222/review/5001918038@github.com>
Aquileo | Re: [w3c/FileAPI] Fold File and Directory Entries API into File API (PR #222)Anne van Kesterennotifications@github.commid:w3c/FileAPI/pull/222/review/5001918038@github.com2026-08-23T07:45:29+00:00
@annevk commented on this pull request.



> @@ -704,6 +883,7 @@ interface File : Blob {
               optional FilePropertyBag options = {});
   readonly attribute DOMString name;
   readonly attribute long long lastModified;
+  readonly attribute USVString webkitRelativePath;

I think @jcayzac did the right thing.

The Compat specification is meant to be temporary. Prefixed features that end up widely deployed should just be standardized in the relevant specification, not separately.

We also don't want to introduce new features while making a big move like this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/222#discussion_r3837991628
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/pull/222/review/5001918038@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: Web Speech API: SpeechRecognitionResult Timestamps (Issue #1267)Alan Ding (Google)notifications@github.commid:w3ctag/design-reviews/issues/1267@github.com2026-08-22T03:37:41+00:00
alan33d created an issue (w3ctag/design-reviews#1267)

### Specification

https://github.com/WebAudio/web-speech-api/pull/192

### Explainer

https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md

### Links

- The WG's request for this TAG review: https://github.com/WebAudio/web-speech-api/issues/191
- TAG review of the previous version of this specification, if any:
  - https://github.com/w3ctag/design-reviews/issues/1093 (MediaStreamTrack input)
  - https://github.com/w3ctag/design-reviews/issues/1146 (On-device speech recognition options)
- A description of what has changed since our previous review: https://github.com/WebAudio/web-speech-api/pull/192

Feature 1:
- Previous early design review, if any: N/A
- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md
- A description of the problems that end-users were facing before this proposal: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#problem
- Alternatives considered: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#alternatives-considered
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#proposed-behavior--example-usage
- What do the end-users experience with this proposal: End users experience synchronized, real-time captions and translated subtitles during live video conferencing and media playback. Web applications can detect when on-device ASR models lag behind real-time on resource-constrained devices and automatically transition to cloud backends without user disruption.
- User research you did to validate the problem and/or design, if any: Live conferencing latency studies and interactive validation demo: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html
- Web Platform Tests: https://github.com/web-platform-tests/wpt/tree/master/speech-api (specifically `idlharness.https.window.js` and `SpeechRecognition-onresult-manual.https.html`)

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WebAudio/web-speech-api
- Primary contacts:
  - Alan Ding (@alan33d), Google, Spec Editor / Implementer
  - Evan Liu (@evanbliu), Google, Spec Editor
  - Paul Adenot (@padenot), Mozilla, WebAudio WG Member / Spec Editor
  - Hongchan Choi (@hoch), Google, WebAudio WG Member / Spec Editor
- Organization/project driving the specification: Google / Chromium
- This work is being funded by: Google
- Primary standards group developing this feature: Audio Working Group (WebAudio WG) / Audio Community Group (AudioCG)
- Incubation and standards groups that have discussed the design:
  - Audio Working Group: https://github.com/WebAudio/web-speech-api/issues/191, https://github.com/WebAudio/web-speech-api/pull/192


### Feedback so far

- Active horizontal reviews: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#security-and-privacy-considerations
- Multi-stakeholder feedback:
  - Chromium comments: Positive / In active development (https://chromestatus.com/feature/5811907077472256)
  - Mozilla comments: Active discussion in https://github.com/WebAudio/web-speech-api/issues/191 and https://github.com/WebAudio/web-speech-api/pull/192#discussion_r3774155900 by @padenot (provided guidance on using `double` in seconds and non-nullable attributes to match Web Audio conventions).
  - WebKit comments: Standards position to be filed at https://github.com/WebKit/standards-positions/
- Major unresolved issues with or opposition to this specification: None. Consensus reached on using non-nullable `double` representing seconds relative to audio stream start.
- Status/issue trackers for implementations:
  - Chrome Status: https://chromestatus.com/feature/5811907077472256
  - Chromium Issue Tracker: https://issues.chromium.org/issues/528037568

### You should also know that...

**W3C Audio WG/CG Meeting Discussion:** This feature was presented and discussed during the **W3C Audio WG/CG Teleconference on August 13, 2026** (see [Meeting Minutes](https://docs.google.com/document/d/1pH4qzMoMTUDYtxW2LDIWKlHfiDeWwctM6s_I78WJzdE/edit?tab=t.ssvip9178d1u)). The group aligned on developer needs for audio timeline association and on-device ASR latency tracking (e.g. enabling optional failover to a cloud ASR provider, to prevent stale or delayed captions in live video conferencing).
- Mozilla's feedback in PRs were also discussed and addressed during the meeting.
- An interactive demonstration showcasing real-time latency calculation, subtitle synchronization, and the inadequacy of existing coarse DOM event timestamps was also presented at the WG meeting. The demo is available at: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1267


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1267
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1267@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: Web Speech API: SpeechRecognitionResult Timestamps (Issue #1267)Alan Ding (Google)notifications@github.commid:w3ctag/design-reviews/issues/1267@github.com2026-08-22T03:37:41+00:00
alan33d created an issue (w3ctag/design-reviews#1267)

### Specification

https://github.com/WebAudio/web-speech-api/pull/192

### Explainer

https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md

### Links

- The WG's request for this TAG review: https://github.com/WebAudio/web-speech-api/issues/191
- TAG review of the previous version of this specification, if any:
  - https://github.com/w3ctag/design-reviews/issues/1093 (MediaStreamTrack input)
  - https://github.com/w3ctag/design-reviews/issues/1146 (On-device speech recognition options)
- A description of what has changed since our previous review: https://github.com/WebAudio/web-speech-api/pull/192

Feature 1:
- Previous early design review, if any: N/A
- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md
- A description of the problems that end-users were facing before this proposal: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#problem
- Alternatives considered: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#alternatives-considered
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#proposed-behavior--example-usage
- What do the end-users experience with this proposal: End users experience synchronized, real-time captions and translated subtitles during live video conferencing and media playback. Web applications can detect when on-device ASR models lag behind real-time on resource-constrained devices and automatically transition to cloud backends without user disruption.
- User research you did to validate the problem and/or design, if any: Live conferencing latency studies and interactive validation demo: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html
- Web Platform Tests: https://github.com/web-platform-tests/wpt/tree/master/speech-api (specifically `idlharness.https.window.js` and `SpeechRecognition-onresult-manual.https.html`)

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WebAudio/web-speech-api
- Primary contacts:
  - Alan Ding (@alan33d), Google, Spec Editor / Implementer
  - Evan Liu (@evanbliu), Google, Spec Editor
  - Paul Adenot (@padenot), Mozilla, WebAudio WG Member / Spec Editor
  - Hongchan Choi (@hoch), Google, WebAudio WG Member / Spec Editor
- Organization/project driving the specification: Google / Chromium
- This work is being funded by: Google
- Primary standards group developing this feature: Audio Working Group (WebAudio WG) / Audio Community Group (AudioCG)
- Incubation and standards groups that have discussed the design:
  - Audio Working Group: https://github.com/WebAudio/web-speech-api/issues/191, https://github.com/WebAudio/web-speech-api/pull/192


### Feedback so far

- Active horizontal reviews: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#security-and-privacy-considerations
- Multi-stakeholder feedback:
  - Chromium comments: Positive / In active development (https://chromestatus.com/feature/5811907077472256)
  - Mozilla comments: Active discussion in https://github.com/WebAudio/web-speech-api/issues/191 and https://github.com/WebAudio/web-speech-api/pull/192#discussion_r3774155900 by @padenot (provided guidance on using `double` in seconds and non-nullable attributes to match Web Audio conventions).
  - WebKit comments: Standards position to be filed at https://github.com/WebKit/standards-positions/
- Major unresolved issues with or opposition to this specification: None. Consensus reached on using non-nullable `double` representing seconds relative to audio stream start.
- Status/issue trackers for implementations:
  - Chrome Status: https://chromestatus.com/feature/5811907077472256
  - Chromium Issue Tracker: https://issues.chromium.org/issues/528037568

### You should also know that...

**W3C Audio WG/CG Meeting Discussion:** This feature was presented and discussed during the **W3C Audio WG/CG Teleconference on August 13, 2026** (see [Meeting Minutes](https://docs.google.com/document/d/1pH4qzMoMTUDYtxW2LDIWKlHfiDeWwctM6s_I78WJzdE/edit?tab=t.ssvip9178d1u)). The group aligned on developer needs for audio timeline association and on-device ASR latency tracking (e.g. enabling optional failover to a cloud ASR provider, to prevent stale or delayed captions in live video conferencing).
- Mozilla's feedback in PRs were also discussed and addressed during the meeting.
- An interactive demonstration showcasing real-time latency calculation, subtitle synchronization, and the inadequacy of existing coarse DOM event timestamps was also presented at the WG meeting. The demo is available at: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1267


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1267
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1267@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: Web Speech API: SpeechRecognitionResult Timestamps (Issue #1267)Alan Ding (Google)notifications@github.commid:w3ctag/design-reviews/issues/1267@github.com2026-08-22T03:37:41+00:00
alan33d created an issue (w3ctag/design-reviews#1267)

### Specification

https://github.com/WebAudio/web-speech-api/pull/192

### Explainer

https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md

### Links

- The WG's request for this TAG review: https://github.com/WebAudio/web-speech-api/issues/191
- TAG review of the previous version of this specification, if any:
  - https://github.com/w3ctag/design-reviews/issues/1093 (MediaStreamTrack input)
  - https://github.com/w3ctag/design-reviews/issues/1146 (On-device speech recognition options)
- A description of what has changed since our previous review: https://github.com/WebAudio/web-speech-api/pull/192

Feature 1:
- Previous early design review, if any: N/A
- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md
- A description of the problems that end-users were facing before this proposal: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#problem
- Alternatives considered: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#alternatives-considered
- Examples of how to use the proposal to solve the end-users' problems: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#proposed-behavior--example-usage
- What do the end-users experience with this proposal: End users experience synchronized, real-time captions and translated subtitles during live video conferencing and media playback. Web applications can detect when on-device ASR models lag behind real-time on resource-constrained devices and automatically transition to cloud backends without user disruption.
- User research you did to validate the problem and/or design, if any: Live conferencing latency studies and interactive validation demo: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html
- Web Platform Tests: https://github.com/web-platform-tests/wpt/tree/master/speech-api (specifically `idlharness.https.window.js` and `SpeechRecognition-onresult-manual.https.html`)

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WebAudio/web-speech-api
- Primary contacts:
  - Alan Ding (@alan33d), Google, Spec Editor / Implementer
  - Evan Liu (@evanbliu), Google, Spec Editor
  - Paul Adenot (@padenot), Mozilla, WebAudio WG Member / Spec Editor
  - Hongchan Choi (@hoch), Google, WebAudio WG Member / Spec Editor
- Organization/project driving the specification: Google / Chromium
- This work is being funded by: Google
- Primary standards group developing this feature: Audio Working Group (WebAudio WG) / Audio Community Group (AudioCG)
- Incubation and standards groups that have discussed the design:
  - Audio Working Group: https://github.com/WebAudio/web-speech-api/issues/191, https://github.com/WebAudio/web-speech-api/pull/192


### Feedback so far

- Active horizontal reviews: https://github.com/WebAudio/web-speech-api/blob/main/explainers/speech-recognition-result-timestamps.md#security-and-privacy-considerations
- Multi-stakeholder feedback:
  - Chromium comments: Positive / In active development (https://chromestatus.com/feature/5811907077472256)
  - Mozilla comments: Active discussion in https://github.com/WebAudio/web-speech-api/issues/191 and https://github.com/WebAudio/web-speech-api/pull/192#discussion_r3774155900 by @padenot (provided guidance on using `double` in seconds and non-nullable attributes to match Web Audio conventions).
  - WebKit comments: Standards position to be filed at https://github.com/WebKit/standards-positions/
- Major unresolved issues with or opposition to this specification: None. Consensus reached on using non-nullable `double` representing seconds relative to audio stream start.
- Status/issue trackers for implementations:
  - Chrome Status: https://chromestatus.com/feature/5811907077472256
  - Chromium Issue Tracker: https://issues.chromium.org/issues/528037568

### You should also know that...

**W3C Audio WG/CG Meeting Discussion:** This feature was presented and discussed during the **W3C Audio WG/CG Teleconference on August 13, 2026** (see [Meeting Minutes](https://docs.google.com/document/d/1pH4qzMoMTUDYtxW2LDIWKlHfiDeWwctM6s_I78WJzdE/edit?tab=t.ssvip9178d1u)). The group aligned on developer needs for audio timeline association and on-device ASR latency tracking (e.g. enabling optional failover to a cloud ASR provider, to prevent stale or delayed captions in live video conferencing).
- Mozilla's feedback in PRs were also discussed and addressed during the meeting.
- An interactive demonstration showcasing real-time latency calculation, subtitle synchronization, and the inadequacy of existing coarse DOM event timestamps was also presented at the WG meeting. The demo is available at: https://michaelwasserman.github.io/web-speech-demos/speech_latency_h.html

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1267


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1267
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1267@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | Re: [whatwg/webidl] Check for detached buffer source when checking if transferable is inverted (Issue #1619)Anne van Kesterennotifications@github.commid:whatwg/webidl/issue/1619/issue_event/29809745702@github.com2026-08-21T14:19:07+00:00
Closed #1619 as completed via #1630.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1619#event-29809745702
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issue/1619/issue_event/29809745702@github.com>
Aquileo | [whatwg/webidl] Fix inverted detached buffer check in ArrayBuffer transfer (PR #1630)Anne van Kesterennotifications@github.commid:whatwg/webidl/pull/1630@github.com2026-08-21T14:09:45+00:00
The polarity was flipped in #1420, which turned `Assert: IsDetachedBuffer(jsArrayBuffer) is false.` into a conditional throw but kept `is false`.

That the intent is to throw when detached is confirmed by the note below the algorithm, which lists "is already detached" as a throwing condition. Step 5's `? DetachArrayBuffer` cannot produce that error, as detaching an already-detached buffer is a no-op.

Fixes #1619.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/webidl/1630.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Preview</a> | <a href="https://whatpr.org/webidl/1630/fad9b4c...d2fe0d5.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1630

-- Commit Summary --

  * Fix inverted detached buffer check in ArrayBuffer transfer

-- File Changes --

    M index.bs (2)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1630.patch
https://github.com/whatwg/webidl/pull/1630.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1630
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1630@github.com>
Aquileo | [whatwg/webidl] Fix inverted detached buffer check in ArrayBuffer transfer (PR #1630)Anne van Kesterennotifications@github.commid:whatwg/webidl/pull/1630@github.com2026-08-21T14:09:45+00:00
The polarity was flipped in #1420, which turned `Assert: IsDetachedBuffer(jsArrayBuffer) is false.` into a conditional throw but kept `is false`.

That the intent is to throw when detached is confirmed by the note below the algorithm, which lists "is already detached" as a throwing condition. Step 5's `? DetachArrayBuffer` cannot produce that error, as detaching an already-detached buffer is a no-op.

Fixes #1619.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/webidl/1630.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Preview</a> | <a href="https://whatpr.org/webidl/1630/fad9b4c...d2fe0d5.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1630

-- Commit Summary --

  * Fix inverted detached buffer check in ArrayBuffer transfer

-- File Changes --

    M index.bs (2)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1630.patch
https://github.com/whatwg/webidl/pull/1630.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1630
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1630@github.com>
Aquileo | [whatwg/webidl] Fix inverted detached buffer check in ArrayBuffer transfer (PR #1630)Anne van Kesterennotifications@github.commid:whatwg/webidl/pull/1630@github.com2026-08-21T14:09:45+00:00
The polarity was flipped in #1420, which turned `Assert: IsDetachedBuffer(jsArrayBuffer) is false.` into a conditional throw but kept `is false`.

That the intent is to throw when detached is confirmed by the note below the algorithm, which lists "is already detached" as a throwing condition. Step 5's `? DetachArrayBuffer` cannot produce that error, as detaching an already-detached buffer is a no-op.

Fixes #1619.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/webidl/1630.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Preview</a> | <a href="https://whatpr.org/webidl/1630/fad9b4c...d2fe0d5.html" title="Last updated on Aug 21, 2026, 2:09 PM UTC (d2fe0d5)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1630

-- Commit Summary --

  * Fix inverted detached buffer check in ArrayBuffer transfer

-- File Changes --

    M index.bs (2)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1630.patch
https://github.com/whatwg/webidl/pull/1630.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1630
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1630@github.com>
Aquileo | Re: [whatwg/fetch] Make `Response.redirect()` headers mutable (PR #1944)Anne van Kesterennotifications@github.commid:whatwg/fetch/pull/1944/c5370533661@github.com2026-08-21T13:43:03+00:00
annevk left a comment (whatwg/fetch#1944)

@valenting @ricea thoughts?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1944#issuecomment-5370533661
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1944/c5370533661@github.com>
Aquileo | Re: [w3c/manifest] Ability to dynamically change app icon (#663)Diego Gonzaleznotifications@github.commid:w3c/manifest/issues/663/5368526076@github.com2026-08-21T10:14:31+00:00
diekus left a comment (w3c/manifest#663)

Hola 😉

Been making some apps these days and I'd like to see this feature exist. One of the apps that has caught my attention for doing this on Android, macOS, iOS and Windows is Firefox. It's been a long time since this was first asked in 2018, and it is normal now to have apps that allow select an app icon as part of their theme (see image below). 

We've recently looked at localisation and icons as one of these localisable elements. There's been discussions of having icons adapt to different OS themes as well. 

I'm thinking we can explore something similar by having a list of ImageResource icons that are listed in the manifest that then the user could select one for their app. Keep it simple, nothing dynamic, but would bring web apps closer to native apps in a feature that clearly devs see value (see comments above). I'll draft some ideas on how could this look, and look forward to discuss this with you.

<img width="1506" height="1058" alt="Image" src="https://github.com/user-attachments/assets/5e05e0fc-0d14-4048-9e99-8a790418bbc5" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/663#issuecomment-5368526076
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/663/5368526076@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] is the browser required to start the ServiceWorker for postMessage() if there is no message event handler? (#1200)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/issues/1200/5363650079@github.com2026-08-21T00:20:48+00:00
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1200)

https://w3c.github.io/ServiceWorker/#should-skip-event may work?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1200#issuecomment-5363650079
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1200/5363650079@github.com>
Aquileo | Re: [w3c/ServiceWorker] Allow better composability of fetch handlers (#1482)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1482/5363619143@github.com2026-08-21T00:16:18+00:00
monica-ch left a comment (w3c/ServiceWorker#1482)

[Bug triage] Nice idea, needs use case to prioritize

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1482#issuecomment-5363619143
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1482/5363619143@github.com>
Aquileo | Re: [w3c/ServiceWorker] VueJS dynamic imports / lazy loading supported by SW? (#1481)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1481/issue_event/29775393603@github.com2026-08-21T00:07:29+00:00
Closed #1481 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1481#event-29775393603
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1481/issue_event/29775393603@github.com>
Aquileo | Re: [w3c/ServiceWorker] VueJS dynamic imports / lazy loading supported by SW? (#1481)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1481/issue_event/29775393603@github.com2026-08-21T00:07:29+00:00
Closed #1481 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1481#event-29775393603
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1481/issue_event/29775393603@github.com>
Aquileo | Re: [w3c/ServiceWorker] Provide a way to attach data to clients (#1475)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1475/5363524707@github.com2026-08-21T00:03:08+00:00
monica-ch left a comment (w3c/ServiceWorker#1475)

[Bug triage] Needs use case to prioritize

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1475#issuecomment-5363524707
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1475/5363524707@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add registeringClientId to the ServiceWorker object (#1379)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1379/5363494084@github.com2026-08-20T23:58:28+00:00
monica-ch left a comment (w3c/ServiceWorker#1379)

[Bug triage] Issue seems valid but needs prioritization.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1379#issuecomment-5363494084
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1379/5363494084@github.com>
Aquileo | [whatwg/fetch] Add the "speculationrules" destination (PR #1952)Viktoria Zlatinovanotifications@github.commid:whatwg/fetch/pull/1952@github.com2026-08-20T23:53:11+00:00
This destination is used when fetching speculation rule sets, whether via the
`Speculation-Rules` HTTP response header or an external
`<script type=speculationrules src>` element. It is governed by the
`speculation-rules-src` CSP directive.

---

Supersedes #1841 by @domenic, whose commit is included here unchanged and with
its authorship preserved. On top of it, this PR:

* fixes the illustrative destination table's `""` initiator `rowspan`, which was
  not grown when the new row was added, leaving the table a cell short
  (editorial);
* moves `"speculationrules"` out of the "no CSP directive" grouping and gives it
  the `speculation-rules-src` directive; and
* notes that the destination also covers external
  `<script type=speculationrules src>` elements, not just the header.

### Dependencies

This should land after:

* whatwg/html#11426 (merged) — defines the `Speculation-Rules` header.
* w3c/webappsec-csp#808 — defines `speculation-rules-src`, with fallback to
  `script-src-elem`, `script-src`, and `default-src`. Until this lands, the
  directive named in the table does not yet exist.
* whatwg/html#11697 — makes an external `<script type=speculationrules src>`
  actually fetch its rule set. Until this lands, the header is the only way to
  reach this destination.

Marked as a draft until those two are resolved.

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [x] At least two implementers are interested (and none opposed):
   * See https://github.com/whatwg/html/pull/11426
- [x] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * The header is covered by https://github.com/web-platform-tests/wpt/blob/c669bcf970fe50b56e0ee53de9c2097a012dafc7/speculation-rules/prefetch/resources/ruleset.py#L40-L43
   * CSP integration is covered alongside w3c/webappsec-csp#808
- [x] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * See https://github.com/whatwg/html/pull/11426
- [x] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: https://github.com/mdn/content/issues/40289
- [x] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use.

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1952.html" title="Last updated on Aug 20, 2026, 11:52 PM UTC (9d2f96e)">Preview</a> | <a href="https://whatpr.org/fetch/1952/4a2b67d...9d2f96e.html" title="Last updated on Aug 20, 2026, 11:52 PM UTC (9d2f96e)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1952

-- Commit Summary --

  * Add the "speculationrules" destination
  * Editorial: fix the destination table's initiator rowspan
  * Give the "speculationrules" destination a CSP directive
  * Note external <script type=speculationrules> in the destination table

-- File Changes --

    M fetch.bs (11)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1952.patch
https://github.com/whatwg/fetch/pull/1952.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1952
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1952@github.com>
Aquileo | Re: [w3c/ServiceWorker] Consider deprecating the ability for scope to match query parameters (#1469)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1469/5363435058@github.com2026-08-20T23:49:28+00:00
monica-ch left a comment (w3c/ServiceWorker#1469)

[Bug triage] Agreed https://github.com/w3c/ServiceWorker/issues/1469#issuecomment-531647543, need some metrics to decide the next plan

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1469#issuecomment-5363435058
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1469/5363435058@github.com>
Aquileo | Re: [w3c/ServiceWorker] Relaying service worker state when serving Clear-Site-Data (#1471)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1471/issue_event/29774528213@github.com2026-08-20T23:38:40+00:00
Closed #1471 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1471#event-29774528213
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1471/issue_event/29774528213@github.com>
Aquileo | Re: [w3c/ServiceWorker] Relaying service worker state when serving Clear-Site-Data (#1471)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1471/issue_event/29774528213@github.com2026-08-20T23:38:40+00:00
Closed #1471 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1471#event-29774528213
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1471/issue_event/29774528213@github.com>
Aquileo | [whatwg/fetch] Add a dfn for about:blank (Issue #1951)Sam Sneddonnotifications@github.commid:whatwg/fetch/issues/1951@github.com2026-08-20T21:13:06+00:00
gsnedders created an issue (whatwg/fetch#1951)

### What is the issue with the Fetch Standard?

HTML tries to xref about:blank to Fetch: https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank

However, Fetch doesn't actually explicitly define it anywhere — it's just effectively defined within https://fetch.spec.whatwg.org/#concept-scheme-fetch

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1951
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1951@github.com>
Aquileo | [whatwg/fetch] Add a dfn for about:blank (Issue #1951)Sam Sneddonnotifications@github.commid:whatwg/fetch/issues/1951@github.com2026-08-20T21:13:06+00:00
gsnedders created an issue (whatwg/fetch#1951)

### What is the issue with the Fetch Standard?

HTML tries to xref about:blank to Fetch: https://html.spec.whatwg.org/multipage/infrastructure.html#about:blank

However, Fetch doesn't actually explicitly define it anywhere — it's just effectively defined within https://fetch.spec.whatwg.org/#concept-scheme-fetch

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1951
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1951@github.com>
Aquileo | [whatwg/dom] Mark XSLT deprecated (PR #1499)Mason Freednotifications@github.commid:whatwg/dom/pull/1499@github.com2026-08-20T18:47:18+00:00
- [X] At least two implementers are interested (and none opposed):
   * Chromium (https://developer.chrome.com/docs/web-platform/deprecating-xslt)
   * Gecko (https://github.com/mozilla/standards-positions/issues/1287)
   * WebKit (https://github.com/whatwg/html/issues/11523#issuecomment-3149280766)
- [X] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * N/A (this is for deprecation, not removal)

- [x] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: https://crbug.com/435623334
   * Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990759
   * WebKit: https://bugs.webkit.org/show_bug.cgi?id=300785
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
    Core documentation starts here: https://developer.mozilla.org/en-US/docs/Web/XML/XSLT
- [X] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. 

See also:
- https://github.com/whatwg/html/pull/12805
- https://github.com/whatwg/html/pull/11563
- https://github.com/whatwg/dom/pull/1400

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1499

-- Commit Summary --

  * Mark XSLT deprecated

-- File Changes --

    M dom.bs (3)

-- Patch Links --

https://github.com/whatwg/dom/pull/1499.patch
https://github.com/whatwg/dom/pull/1499.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1499
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1499@github.com>
Aquileo | [whatwg/dom] Mark XSLT deprecated (PR #1499)Mason Freednotifications@github.commid:whatwg/dom/pull/1499@github.com2026-08-20T18:47:18+00:00
- [X] At least two implementers are interested (and none opposed):
   * Chromium (https://developer.chrome.com/docs/web-platform/deprecating-xslt)
   * Gecko (https://github.com/mozilla/standards-positions/issues/1287)
   * WebKit (https://github.com/whatwg/html/issues/11523#issuecomment-3149280766)
- [X] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * N/A (this is for deprecation, not removal)

- [x] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: https://crbug.com/435623334
   * Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1990759
   * WebKit: https://bugs.webkit.org/show_bug.cgi?id=300785
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
    Core documentation starts here: https://developer.mozilla.org/en-US/docs/Web/XML/XSLT
- [X] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. 

See also:
- https://github.com/whatwg/html/pull/12805
- https://github.com/whatwg/html/pull/11563
- https://github.com/whatwg/dom/pull/1400

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1499

-- Commit Summary --

  * Mark XSLT deprecated

-- File Changes --

    M dom.bs (3)

-- Patch Links --

https://github.com/whatwg/dom/pull/1499.patch
https://github.com/whatwg/dom/pull/1499.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1499
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1499@github.com>
Aquileo | [w3c/manifest] Merges the explainer into the readme.md (PR #1246)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1246@github.com2026-08-20T15:27:24+00:00
Closes #1010 
This change (choose at least one, delete ones that don't apply):

* Is a "chore" (metadata, formatting, fixing warnings, etc).

Commit message:

Merges the explainer into the readme file. As @marcoscaceres states, "one less click".

I have added missing information in 2 TBW sections: colours, internationalisation and the description field.

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1246

-- Commit Summary --

  * Merges the explainer into the readme.md

-- File Changes --

    M README.md (306)
    D explainer.md (294)

-- Patch Links --

https://github.com/w3c/manifest/pull/1246.patch
https://github.com/w3c/manifest/pull/1246.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1246
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1246@github.com>
Aquileo | [w3c/manifest] Merges the explainer into the readme.md (PR #1246)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1246@github.com2026-08-20T15:27:24+00:00
Closes #1010 
This change (choose at least one, delete ones that don't apply):

* Is a "chore" (metadata, formatting, fixing warnings, etc).

Commit message:

Merges the explainer into the readme file. As @marcoscaceres states, "one less click".

I have added missing information in 2 TBW sections: colours, internationalisation and the description field.

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1246

-- Commit Summary --

  * Merges the explainer into the readme.md

-- File Changes --

    M README.md (306)
    D explainer.md (294)

-- Patch Links --

https://github.com/w3c/manifest/pull/1246.patch
https://github.com/w3c/manifest/pull/1246.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1246
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1246@github.com>
Aquileo | [w3c/manifest] Merges the explainer into the readme.md (PR #1246)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1246@github.com2026-08-20T15:27:24+00:00
Closes #1010 
This change (choose at least one, delete ones that don't apply):

* Is a "chore" (metadata, formatting, fixing warnings, etc).

Commit message:

Merges the explainer into the readme file. As @marcoscaceres states, "one less click".

I have added missing information in 2 TBW sections: colours, internationalisation and the description field.

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1246

-- Commit Summary --

  * Merges the explainer into the readme.md

-- File Changes --

    M README.md (306)
    D explainer.md (294)

-- Patch Links --

https://github.com/w3c/manifest/pull/1246.patch
https://github.com/w3c/manifest/pull/1246.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1246
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1246@github.com>
Aquileo | [whatwg/webidl] Consider switching the default to [EnforceRange] (Issue #1629)Daniel Huigensnotifications@github.commid:whatwg/webidl/issues/1629@github.com2026-08-20T15:20:35+00:00
twiss created an issue (whatwg/webidl#1629)

### What is the issue with the Web IDL Standard?

(This came up in https://github.com/w3c/webcrypto/issues/429#issuecomment-3916606836.)

Currently, the default for integer types is for values outside the range of the type to be reduced modulo the maximum value. But, it's a bit unclear how often we actually want that behavior, especially for new usages.

Perhaps it may be worth switching the default for integer types to be `[EnforceRange]`, and create a new extended attribute for when you want the current behavior, perhaps `[Modulo]` or some such?

If it seems reasonable, I can make a PR, though I realize this would likely cause churn in other specs.

(This would also resolve https://github.com/whatwg/webidl/issues/842 in the sense that when reusing a type between values that get passed and returned, you don't need any annotation when you want the `[EnforceRange]` behavior when passing the value. Having a `[Modulo]` attribute on a type that only ever gets returned would still be surprising/unexpected, as today with `[EnforceRange]`.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1629
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1629@github.com>
Aquileo | [whatwg/webidl] Consider switching the default from optional dictionary members to required (Issue #1628)Daniel Huigensnotifications@github.commid:whatwg/webidl/issues/1628@github.com2026-08-20T15:11:03+00:00
twiss created an issue (whatwg/webidl#1628)

### What is the issue with the Web IDL Standard?

(This came up in https://github.com/w3c/webcrypto/pull/559#issuecomment-5357336396, and would be an alternative to https://github.com/whatwg/webidl/issues/1567.)

Currently, the default for dictionary members is to be optional, and to make them required you need to add the `required` attribute. However, this is "backwards" compared to function arguments, which have an `optional` keyword. So, it would be more consistent to match that. And, in code generation it also more cleanly maps to `std::optional` and such.

Also, for dictionaries that are only every returned or used in read-only attributes of other dictionaries, it would be nice to make it clear that the member will always be there, without having to (semi-redundantly) annotate all of them with `required`. By contrast, having an optional member of a read-only dictionary would be surprising and should probably be called out explicitly (if it's ever a possibility at all).

If it seems reasonable, I can make a PR, though I realize this would likely cause a lot of churn in other specs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1628
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1628@github.com>
Aquileo | Re: [whatwg/dom] Copy a document's base URL when cloning (PR #1492)Anne van Kesterennotifications@github.commid:whatwg/dom/pull/1492/before/8b798d42761bf30bafea93902534452e5d4a538b/after/3b472026-08-20T15:06:36+00:00
@annevk pushed 2 commits.

ae8dc62ae93265a32399df30cf3db928e13a0d45  Copy a document's base URL when cloning
3b47131accbece7cc72c3d51748fdc338197d091  Note that HTML also sets the base URL override

-- 
View it on GitHub:
https://github.com/whatwg/dom/pull/1492/changes/8b798d42761bf30bafea93902534452e5d4a538b..3b47131accbece7cc72c3d51748fdc338197d091
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1492/before/8b798d42761bf30bafea93902534452e5d4a538b/after/3b47>
Aquileo | Re: [w3ctag/design-reviews] CSS Overflow Navigation Controls (Carousels) (Issue #1037)Robert Flacknotifications@github.commid:w3ctag/design-reviews/issues/1037/5357662695@github.com2026-08-20T14:59:03+00:00
flackr left a comment (w3ctag/design-reviews#1037)

> 1. It seems that [scroll markers would be used to impart roles to elements on the page](https://github.com/w3c/csswg-drafts/issues/12122#issuecomment-2920507737), and the nature of those roles would vary depending on whether the CSS author choses `discrete` or `navigation`. Setting roles via CSS is a fundamental expansion of what CSS is doing.
>    We do not think this is an appropriate use of CSS, and would encourage you to investigate the [Cascading Attribute Sheets](https://gist.github.com/tabatkins/4074abaf486af5b3f7ac289737e216e4) proposal, for this and future work. This seems like an effective way to address the general need, whilst maintaining separation of concerns.

The HTML attributes are as always the ultimate authority on the accessibility properties, however this is an example of an inferred role. There are many other cases where CSS already affects the inferred roles of nodes. In general many of the roles are determined in [AXNodeObject::RoleFromLayoutObjectOrNode](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/ax_node_object.cc?q=%20AXNodeObject::RoleFromLayoutObjectOrNode&ss=chromium%2Fchromium%2Fsrc) by which LayoutObject we have. The function [LayoutObject::CreateLayoutObject](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_object.cc;drc=2e2446ce78857c808c9b38afe6b527e455fe6c65;l=362) considers many styles.
* For pseudo-elements specifically the value of the content property determines whether the created object is treated as an image or not.
* The display CSS property is used to automatically assign list-item and various table roles

The CSS in this case is not specifically to set the role, but is about the behavior. The differing behaviors of course imply differing role, just as setting the various display values or content values can do.

Am I misunderstanding what you mean by setting roles via CSS?

> 2. What advice would be given to developers to help them decide whether the 'tabs' or 'links' semantics are more important?
> 
> Given particularly the first of these issues, we are still concerned about the addition of these features to the platform, particularly in their current form. We are keen to hear your thoughts on them.

Since selecting tabs or links has a significant impact (aside from the inferred roles) on the way the user interacts with the content, they should end up with the correct role based on the usage model. This is unlike the previous variant where they were expected to set up the behaviors and the roles separately.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1037#issuecomment-5357662695
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1037/5357662695@github.com>
Aquileo | Re: [whatwg/dom] Order shadow root concepts consistently (PR #1496)Anne van Kesterennotifications@github.commid:whatwg/dom/pull/1496/before/39de9e5be8e711752104892ecbe3c50ef8a28bb7/after/45f32026-08-20T13:59:03+00:00
@annevk pushed 1 commit.

45f3a1424ceafb697c4867bc602b2b6f46e1a698  wrapping nit

-- 
View it on GitHub:
https://github.com/whatwg/dom/pull/1496/changes/39de9e5be8e711752104892ecbe3c50ef8a28bb7..45f3a1424ceafb697c4867bc602b2b6f46e1a698
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1496/before/39de9e5be8e711752104892ecbe3c50ef8a28bb7/after/45f3>
Aquileo | Re: [whatwg/dom] Order shadow root concepts consistently (PR #1496)Anne van Kesterennotifications@github.commid:whatwg/dom/pull/1496/before/39de9e5be8e711752104892ecbe3c50ef8a28bb7/after/45f32026-08-20T13:59:03+00:00
@annevk pushed 1 commit.

45f3a1424ceafb697c4867bc602b2b6f46e1a698  wrapping nit

-- 
View it on GitHub:
https://github.com/whatwg/dom/pull/1496/changes/39de9e5be8e711752104892ecbe3c50ef8a28bb7..45f3a1424ceafb697c4867bc602b2b6f46e1a698
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1496/before/39de9e5be8e711752104892ecbe3c50ef8a28bb7/after/45f3>
Aquileo | Re: [w3ctag/design-reviews] WG Revision: SHACL 1.2 Core (Issue #1166)Hadley Beemannotifications@github.commid:w3ctag/design-reviews/issues/1166/5354004335@github.com2026-08-20T09:26:56+00:00
hadleybeeman left a comment (w3ctag/design-reviews#1166)

Hi @nicholascar @HolgerKnublauch @bergos @YoucTagh @jeswr @PapoutsoglouE, we haven't heard from you all on this. Is everything ok? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1166#issuecomment-5354004335
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1166/5354004335@github.com>
Aquileo | Re: [w3ctag/design-reviews] WG Revision: SHACL 1.2 Core (Issue #1166)Hadley Beemannotifications@github.commid:w3ctag/design-reviews/issues/1166/5354004335@github.com2026-08-20T09:26:56+00:00
hadleybeeman left a comment (w3ctag/design-reviews#1166)

Hi @nicholascar @HolgerKnublauch @bergos @YoucTagh @jeswr @PapoutsoglouE, we haven't heard from you all on this. Is everything ok? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1166#issuecomment-5354004335
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1166/5354004335@github.com>
Aquileo | [whatwg/fetch] Main (PR #1950)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1950@github.com2026-08-20T09:19:25+00:00
<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1950

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section
  * Merge branch 'whatwg:main' into main

-- File Changes --


-- Patch Links --

https://github.com/whatwg/fetch/pull/1950.patch
https://github.com/whatwg/fetch/pull/1950.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1950
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1950@github.com>
Aquileo | [whatwg/fetch] Main (PR #1950)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1950@github.com2026-08-20T09:19:25+00:00
<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1950

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section
  * Merge branch 'whatwg:main' into main

-- File Changes --


-- Patch Links --

https://github.com/whatwg/fetch/pull/1950.patch
https://github.com/whatwg/fetch/pull/1950.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1950
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1950@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: Scroll snap for single-axis scroll container (Issue #1266)David Liunotifications@github.commid:w3ctag/design-reviews/issues/1266@github.com2026-08-19T21:22:11+00:00
lcdavid94 created an issue (w3ctag/design-reviews#1266)

### Specification

https://github.com/w3c/csswg-drafts/pull/14354

### Explainer

https://github.com/explainers-by-googlers/single-axis-scroll-snap

### Links

- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/explainers-by-googlers/single-axis-scroll-snap
- Examples of how to use the proposal to solve the end-users' problems: See explainer
- Web Platform Tests:  Internal only: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/css/css-scroll-snap/


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/csswg-drafts/
- Primary contacts:
  - David Liu (@lcdavid94), Google, Author
  - Robert Flack (@flackr), Google, Spec work & reviewer
  - Vladimir Levin (@vmpstr), Google, Reviewer
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Incubation and standards groups that have discussed the design:
  - https://github.com/w3c/csswg-drafts/issues/14018


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: https://chromestatus.com/feature/5086608215900160
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1445
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/712
- Major unresolved issues with or opposition to this specification: NA
- Status/issue trackers for implementations: https://chromestatus.com/feature/5086608215900160


### You should also know that...

NA

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1266


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1266
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1266@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: CSS Image Animation (Issue #1237)Matthew Tylee Atkinsonnotifications@github.commid:w3ctag/design-reviews/issues/1237/5346128630@github.com2026-08-19T18:08:33+00:00
matatk left a comment (w3ctag/design-reviews#1237)

Hi @DevSDK, and thank you for your review request. We have some feedback and questions.

**Overall:** Clearly there are good use cases to be solved here, and there is developer demand. The approach looks reasonable (though we have a few questions, below).

**General thought/proposal:**

There's a lot of inconsistency across the platform on motion and animation. It'd be great if we could work towards a solution to the [wider user needs](https://github.com/w3ctag/gaps/issues/15) and hopefully not precluding that with any of the work proposed here (input on there would be welcome!)

For example, the 'user research' section highlights WCAG needs, and gives some good requirements. This doesn't capture _all_ the key requirements, such as varying the pace of animation (but as long as this approach doesn't preclude them from being met, we could build on it).

**Questions/concerns:**

* The explainer states:

  > Currently, screen readers typically do not chose to announce animated images differently from non-animated images, though they could if they wanted to.

  Is it the case that screen readers can know if images are animated or not? If it's not the case, then it would need to be addressed in order for AT to be able to help the user understand and control the state of the image.

* We have unanswered concerns about doing things like changing focusability via CSS; it is likely to be a potential footgun. Specifically in this case, we (and the explainer) would benefit from answers to some immediate practical concerns like: how will the animated image be named? Where will it get its accessible name from?

**Missing 'contemporary solutions' and 'rejected alternatives' section info:**

* The 'Contemporary Solutions' section needs to be fully populated so we can effectively evaluate the proposal - there's some tantalising stuff in there about why they think this is better than something like `<img controls>` but it's not explained.

* Regarding the rejected alternative of 'Provide this as a UA setting'...

  - The explainer states that this approach was rejected because the browser can't determine what is a content and what is a decorative image. However, the [explainer also has a definition for the difference between content and decorative images](https://drafts.csswg.org/css-image-animation-1/explainer#rejected-alternatives:~:text=content%20images%2C%20which,to%20external%20images.).

    That difference can be detected by the UA, but we expect that in the wild, content authors will use both _technical_ types of image for both (semantically) content and decorative images. This means we agree with the reason given for rejection of this approach.

    However, the explainer also specifies different UA behaviour based on whether an image is a content, or a decorative, image - so is there a contradiction there that needs to be resolved? 

  - The explainer does explain how UAs could continue to provide this setting (which seems like a good idea for users, even if it has to be blunt).

**Minor stuff:**

* Under 'Non-goals' there's a link 'could be pursued separately' that is broken.

* The table of contents links in the explainer don't go anywhere.

**Background links:**

* [WCAG SC 2.3.3
Animation from Interactions (Level AAA)](https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html)

* [Making Content Usable for People with Cognitive and Learning Disabilities](https://www.w3.org/TR/coga-usable/)

* [Giving users control over motion](https://github.com/w3ctag/gaps/issues/15)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1237#issuecomment-5346128630
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1237/5346128630@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: [css-text] `text-fit` property (Issue #1208)Matthew Tylee Atkinsonnotifications@github.commid:w3ctag/design-reviews/issues/1208/5346062656@github.com2026-08-19T18:02:52+00:00
matatk left a comment (w3ctag/design-reviews#1208)

Hi @tkent-google, thanks for your review request, and sorry for the long response time. We acknowledge the aesthetic use case for this feature. We have some questions... 
  
1. This feature introduces quite a bit of nondeterminism into layouts. How will this affect DX, and authors' ability to test layouts?

2. [Text that gets too big can be just as problematic as text that gets too small.](https://github.com/w3c/wcag3/issues/261#issuecomment-2598860620). Just one common user scenario: a person may be zoomed into the web page _and_ zoomed into the screen (via full-screen magnification). This is already a complex and tiring set-up, with parallax scrolling, and the cognitive (and physical) load that comes with it. If text is being scaled significantly, it could make it much harder to read.

   - Note: The current WCAG 3 draft changes the text-resizing requirement from "[text can be resized without assistive technology up to 200 percent](https://www.w3.org/TR/WCAG22/#resize-text)" to "[Text can be increased in size to at least 200% of the platform’s default body-text size.](https://www.w3.org/TR/wcag-3.0/#text-size-adjustable)", which offers a new angle for how to make this CSS feature compliant. But WCAG 3 is some way off.

   - There's [some discussion in CSSWG around what to do about this](https://github.com/w3c/csswg-drafts/issues/12886) but it doesn't look like a resolution has been reached. Does that thread represent the latest thinking on this issue? It has been quiet for several months.

3. Research/discussion is ongoing within APA on this: we have some concerns about the difficulties this could cause for readability, particularly for people with cognitive disabilities. It could also affect people who need high zoom levels.

   - This may be quite profound for some users, and we would suggest that UAs allow the feature to be toggled off by the user, in order to improve legibility. However that in turn raises a fingerprinting question.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1208#issuecomment-5346062656
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1208/5346062656@github.com>
Aquileo | [whatwg/fetch] Editorial: fix typos in deferred fetching quota section (PR #1949)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1949@github.com2026-08-19T09:23:07+00:00
This PR fixes minor typographical and grammatical issues in the deferred fetching quota section:
- Changes "is delegates to" to "is delegated to"
- Fixes subject-verb agreement: "each frame reserve" -> "each frame reserves"
- Fixes capitalization of "decremented By" and removes stray unmatched closing parenthesis
- Adds my name to the Acknowledgments section

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1949.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Preview</a> | <a href="https://whatpr.org/fetch/1949/586cd2a...a30b6bd.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1949

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section

-- File Changes --

    M fetch.bs (9)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1949.patch
https://github.com/whatwg/fetch/pull/1949.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1949
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1949@github.com>
Aquileo | [whatwg/fetch] Editorial: fix typos in deferred fetching quota section (PR #1949)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1949@github.com2026-08-19T09:23:07+00:00
This PR fixes minor typographical and grammatical issues in the deferred fetching quota section:
- Changes "is delegates to" to "is delegated to"
- Fixes subject-verb agreement: "each frame reserve" -> "each frame reserves"
- Fixes capitalization of "decremented By" and removes stray unmatched closing parenthesis
- Adds my name to the Acknowledgments section

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1949.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Preview</a> | <a href="https://whatpr.org/fetch/1949/586cd2a...a30b6bd.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1949

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section

-- File Changes --

    M fetch.bs (9)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1949.patch
https://github.com/whatwg/fetch/pull/1949.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1949
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1949@github.com>
Aquileo | [whatwg/fetch] Editorial: fix typos in deferred fetching quota section (PR #1949)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1949@github.com2026-08-19T09:23:07+00:00
This PR fixes minor typographical and grammatical issues in the deferred fetching quota section:
- Changes "is delegates to" to "is delegated to"
- Fixes subject-verb agreement: "each frame reserve" -> "each frame reserves"
- Fixes capitalization of "decremented By" and removes stray unmatched closing parenthesis
- Adds my name to the Acknowledgments section

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1949.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Preview</a> | <a href="https://whatpr.org/fetch/1949/586cd2a...a30b6bd.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1949

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section

-- File Changes --

    M fetch.bs (9)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1949.patch
https://github.com/whatwg/fetch/pull/1949.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1949
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1949@github.com>
Aquileo | [whatwg/fetch] Editorial: fix typos in deferred fetching quota section (PR #1949)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1949@github.com2026-08-19T09:23:07+00:00
This PR fixes minor typographical and grammatical issues in the deferred fetching quota section:
- Changes "is delegates to" to "is delegated to"
- Fixes subject-verb agreement: "each frame reserve" -> "each frame reserves"
- Fixes capitalization of "decremented By" and removes stray unmatched closing parenthesis
- Adds my name to the Acknowledgments section

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1949.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Preview</a> | <a href="https://whatpr.org/fetch/1949/586cd2a...a30b6bd.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1949

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section

-- File Changes --

    M fetch.bs (9)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1949.patch
https://github.com/whatwg/fetch/pull/1949.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1949
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1949@github.com>
Aquileo | [whatwg/fetch] Editorial: fix typos in deferred fetching quota section (PR #1949)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/pull/1949@github.com2026-08-19T09:23:07+00:00
This PR fixes minor typographical and grammatical issues in the deferred fetching quota section:
- Changes "is delegates to" to "is delegated to"
- Fixes subject-verb agreement: "each frame reserve" -> "each frame reserves"
- Fixes capitalization of "decremented By" and removes stray unmatched closing parenthesis
- Adds my name to the Acknowledgments section

<!--
Thank you for contributing to the Fetch Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno (not for CORS changes): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/fetch/1949.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Preview</a> | <a href="https://whatpr.org/fetch/1949/586cd2a...a30b6bd.html" title="Last updated on Aug 19, 2026, 9:22 AM UTC (a30b6bd)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/fetch/pull/1949

-- Commit Summary --

  * Editorial: fix typos in deferred fetching quota section

-- File Changes --

    M fetch.bs (9)

-- Patch Links --

https://github.com/whatwg/fetch/pull/1949.patch
https://github.com/whatwg/fetch/pull/1949.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1949
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1949@github.com>
Aquileo | [whatwg/fetch] Editorial: Typos in deferred fetching quota section (Issue #1948)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/issues/1948@github.com2026-08-19T08:15:59+00:00
Eliasilyz created an issue (whatwg/fetch#1948)

### What is the issue with the Fetch Standard?

While reviewing the "Deferred fetching quota" section of the specification, I noticed a few minor typographical/grammatical issues:

1. Section 7.4: "...how much of their quota is delegates to cross-origin child documents..." -> should be "is delegated to".
2. Section 7.4 Example: "...because each frame reserve 8 kibibytes:" -> should be "each frame reserves".
3. Quota calculation note: "...decremented By quota reserved for deferred-fetch-minimal)" -> unnecessary capital 'B' and unmatched closing parenthesis.

I would be happy to submit a pull request fixing these.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1948
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1948@github.com>
Aquileo | [whatwg/fetch] Editorial: Typos in deferred fetching quota section (Issue #1948)Irvan Farael Hanafinotifications@github.commid:whatwg/fetch/issues/1948@github.com2026-08-19T08:15:59+00:00
Eliasilyz created an issue (whatwg/fetch#1948)

### What is the issue with the Fetch Standard?

While reviewing the "Deferred fetching quota" section of the specification, I noticed a few minor typographical/grammatical issues:

1. Section 7.4: "...how much of their quota is delegates to cross-origin child documents..." -> should be "is delegated to".
2. Section 7.4 Example: "...because each frame reserve 8 kibibytes:" -> should be "each frame reserves".
3. Quota calculation note: "...decremented By quota reserved for deferred-fetch-minimal)" -> unnecessary capital 'B' and unmatched closing parenthesis.

I would be happy to submit a pull request fixing these.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1948
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1948@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft2026-08-18T20:19:03+00:00
@monica-ch pushed 1 commit.

e0f2990ba129b191bc0049596e170c0ced57a2a6  Editorial: clarify race-network-and-cache does not update the cache

-- 
View it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764/changes/926071628daa1a37e5f7146a6d80cfc987c965c8..e0f2990ba129b191bc0049596e170c0ced57a2a6
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/before/926071628daa1a37e5f7146a6d80cfc987c965c8/aft>
Aquileo | Re: [w3c/manifest] Scope: Allow developer to have more fine-grained control of app scope. (#996)Daniel Murphynotifications@github.commid:w3c/manifest/issues/996/5331851755@github.com2026-08-18T17:38:14+00:00
dmurph left a comment (w3c/manifest#996)

Apologies about this split, but we also have a sister issue in manifest incubations with developer engagement:

https://github.com/WICG/manifest-incubations/issues/105

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/996#issuecomment-5331851755
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/996/5331851755@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/xhr] Review Draft Publication: August 2026 (PR #408)Anne van Kesterennotifications@github.commid:whatwg/xhr/pull/408@github.com2026-08-18T11:14:16+00:00
The [August 2026 Review Draft](https://xhr.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/xhr/408.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Preview</a> | <a href="https://whatpr.org/xhr/408/d375b28...5d640f1.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (5d640f1)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/xhr/pull/408

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (2030)
    M xhr.bs (2)

-- Patch Links --

https://github.com/whatwg/xhr/pull/408.patch
https://github.com/whatwg/xhr/pull/408.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/408
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/xhr/pull/408@github.com>
Aquileo | [whatwg/url] Review Draft Publication: August 2026 (PR #928)Anne van Kesterennotifications@github.commid:whatwg/url/pull/928@github.com2026-08-18T11:14:07+00:00
The [August 2026 Review Draft](https://url.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/url/928.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (2f54a38)">Preview</a> | <a href="https://whatpr.org/url/928/9dc3827...2f54a38.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (2f54a38)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/url/pull/928

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    A review-drafts/2026-08.bs (4337)
    M url.bs (2)

-- Patch Links --

https://github.com/whatwg/url/pull/928.patch
https://github.com/whatwg/url/pull/928.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/pull/928
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/pull/928@github.com>
Aquileo | [whatwg/streams] Review Draft Publication: August 2026 (PR #1377)Anne van Kesterennotifications@github.commid:whatwg/streams/pull/1377@github.com2026-08-18T11:13:59+00:00
The [August 2026 Review Draft](https://streams.spec.whatwg.org/review-drafts/2026-08/) for this Workstream will be published shortly after merging this pull request.

Under the [WHATWG IPR Policy](https://whatwg.org/ipr-policy), Participants may, within 45 days after publication of a Review Draft, exclude certain Essential Patent Claims from the Review Draft Licensing Obligations. See the [IPR Policy](https://whatwg.org/ipr-policy) for details.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://whatpr.org/streams/1377.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (1e305b5)">Preview</a> | <a href="https://whatpr.org/streams/1377/2999707...1e305b5.html" title="Last updated on Aug 18, 2026, 11:13 AM UTC (1e305b5)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/streams/pull/1377

-- Commit Summary --

  * Review Draft Publication: August 2026

-- File Changes --

    M index.bs (2)
    A review-drafts/2026-08.bs (8403)

-- Patch Links --

https://github.com/whatwg/streams/pull/1377.patch
https://github.com/whatwg/streams/pull/1377.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/1377
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/pull/1377@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/encoding] Aca (Issue #365)Osvaldo Vazqueznotifications@github.commid:whatwg/encoding/issues/365@github.com2026-08-17T17:07:25+00:00
acapulcoosvaldo1979-maker created an issue (whatwg/encoding#365)

### What is the issue with the Encoding Standard?

<img width="600" height="600" alt="Image" src="https://github.com/user-attachments/assets/3c18d47c-3605-4374-afff-4e16d44941bd" />

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/365
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/encoding/issues/365@github.com>
Aquileo | [whatwg/fetch] Either expose HTTP Header to Javascript or expose the cookies to fetch API's response (Issue #1947)WP. Yingampholnotifications@github.commid:whatwg/fetch/issues/1947@github.com2026-08-17T10:36:06+00:00
peperronii created an issue (whatwg/fetch#1947)

### What problem are you trying to solve?

Right now there are two main ways to attach arbitrary data to a HTTP response

1.  a custom HTTP Header
2. a Cookie

However, we can neither access the current page header via javascript nor read the cookies from a fetch response. That means when we build the logic for the server, if I want to send an arbritary data outside of the body of the response and intend to use it in a per Request Basis, It is very awkward to do so.

And even though the cookie from a fetch response via document.cookie but if there are many fetch request happening in a page it would either face race conditions or unneccessarily populate cookie names for each fetch site and/or request

Therefore, We should have a unified way to send some data apart from the body of the response that can be read by both the page request and the fetch request.

### What solutions exist today?

Right now, the backend logic would have to seperate the fetch request from the normal page request, and choose to send the data in the corresponding format.

- Cookie for a normal request
- Header for a fetch request

OR 

Send both at the same time.

### How would you solve it?

Either expose HTTP Header to Javascript runtime or expose response cookies to fetch API

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1947
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1947@github.com>
Aquileo | [whatwg/fetch] Either expose HTTP Header to Javascript or expose the cookies to fetch API's response (Issue #1947)WP. Yingampholnotifications@github.commid:whatwg/fetch/issues/1947@github.com2026-08-17T10:36:06+00:00
peperronii created an issue (whatwg/fetch#1947)

### What problem are you trying to solve?

Right now there are two main ways to attach arbitrary data to a HTTP response

1.  a custom HTTP Header
2. a Cookie

However, we can neither access the current page header via javascript nor read the cookies from a fetch response. That means when we build the logic for the server, if I want to send an arbritary data outside of the body of the response and intend to use it in a per Request Basis, It is very awkward to do so.

And even though the cookie from a fetch response via document.cookie but if there are many fetch request happening in a page it would either face race conditions or unneccessarily populate cookie names for each fetch site and/or request

Therefore, We should have a unified way to send some data apart from the body of the response that can be read by both the page request and the fetch request.

### What solutions exist today?

Right now, the backend logic would have to seperate the fetch request from the normal page request, and choose to send the data in the corresponding format.

- Cookie for a normal request
- Header for a fetch request

OR 

Send both at the same time.

### How would you solve it?

Either expose HTTP Header to Javascript runtime or expose response cookies to fetch API

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1947
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1947@github.com>
Aquileo | [whatwg/fetch] Either expose HTTP Header to Javascript or expose the cookies to fetch API's response (Issue #1947)WP. Yingampholnotifications@github.commid:whatwg/fetch/issues/1947@github.com2026-08-17T10:36:06+00:00
peperronii created an issue (whatwg/fetch#1947)

### What problem are you trying to solve?

Right now there are two main ways to attach arbitrary data to a HTTP response

1.  a custom HTTP Header
2. a Cookie

However, we can neither access the current page header via javascript nor read the cookies from a fetch response. That means when we build the logic for the server, if I want to send an arbritary data outside of the body of the response and intend to use it in a per Request Basis, It is very awkward to do so.

And even though the cookie from a fetch response via document.cookie but if there are many fetch request happening in a page it would either face race conditions or unneccessarily populate cookie names for each fetch site and/or request

Therefore, We should have a unified way to send some data apart from the body of the response that can be read by both the page request and the fetch request.

### What solutions exist today?

Right now, the backend logic would have to seperate the fetch request from the normal page request, and choose to send the data in the corresponding format.

- Cookie for a normal request
- Header for a fetch request

OR 

Send both at the same time.

### How would you solve it?

Either expose HTTP Header to Javascript runtime or expose response cookies to fetch API

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1947
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1947@github.com>
Aquileo | [whatwg/fetch] Either expose HTTP Header to Javascript or expose the cookies to fetch API's response (Issue #1947)WP. Yingampholnotifications@github.commid:whatwg/fetch/issues/1947@github.com2026-08-17T10:36:06+00:00
peperronii created an issue (whatwg/fetch#1947)

### What problem are you trying to solve?

Right now there are two main ways to attach arbitrary data to a HTTP response

1.  a custom HTTP Header
2. a Cookie

However, we can neither access the current page header via javascript nor read the cookies from a fetch response. That means when we build the logic for the server, if I want to send an arbritary data outside of the body of the response and intend to use it in a per Request Basis, It is very awkward to do so.

And even though the cookie from a fetch response via document.cookie but if there are many fetch request happening in a page it would either face race conditions or unneccessarily populate cookie names for each fetch site and/or request

Therefore, We should have a unified way to send some data apart from the body of the response that can be read by both the page request and the fetch request.

### What solutions exist today?

Right now, the backend logic would have to seperate the fetch request from the normal page request, and choose to send the data in the corresponding format.

- Cookie for a normal request
- Header for a fetch request

OR 

Send both at the same time.

### How would you solve it?

Either expose HTTP Header to Javascript runtime or expose response cookies to fetch API

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1947
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1947@github.com>
Aquileo | [w3c/DOM-Parsing] Rewrite (PR #88)Ms2gernotifications@github.commid:w3c/DOM-Parsing/pull/88@github.com2026-08-16T22:55:38+00:00
My vacation project got a bit out of hand. This contains mostly editorial changes to improve cross-referencing, clarify prose, and make the variable tracking in respec work. It also fixes a few easy bugs at the end. All commits should be self-contained.

I can't commit to taking over maintenance, but this should be helpful in case anyone would step up to do so.
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/DOM-Parsing/pull/88

-- Commit Summary --

  * Editorial: Fix Respec warnings
  * Editorial: Update the Respec configuration
  * Editorial: Fix minor typos
  * Normative: Don't use 'should'
  * Editorial: Don't use 'may'
  * Editorial: Explicitly depend on the Infra standard
  * Editorial: Remove redundant definitions of namespaces
  * Editorial: Consistently use 'the empty string'
  * Editorial: Fix mis-nested algorithm step in 'XML serializing an Element node'
  * Editorial: Remove code markup for null, true and false
  * Editorial: Mark up 'Recording the namespace' as an algorithm
  * Editorial: Mark up the 'namespace prefix map' steps as algorithms
  * Editorial: Mark up each node type serialization steps as an algorithm
  * Editorial: Mark up the 'Serializing an Element's attributes' steps as algorithms
  * Editorial: Mark up 'generate a prefix' as an algorithm
  * Editorial: Mark up 'XML serialization' as an algorithm
  * Editorial: Remove spurious dfns in 'XML serializing an Element node'
  * Editorial: Use booleans rather than flags
  * Editorial: Remove redundant 'the value of'
  * Editorial: Cross-reference local name concepts rather than localName attributes
  * Editorial: Cross-reference namespace and namespace prefix concepts
  * Editorial: Cross-reference document element concept
  * Editorial: Cross-reference DocumentType concepts
  * Editorial: Cross-reference ProcessingInstruction concepts
  * Editorial: Cross-reference Attr's value concept
  * Editorial: Cross-reference CharacterData's data concept
  * Editorial: Cross-reference DOMException directly
  * Editorial: Cross-reference setAttribute directly
  * Editorial: Cross-reference attributes directly
  * Editorial: Remove unnecessary references to 'tree order'
  * Editorial: Cross-reference the template element directly
  * Editorial: Cross-reference 'HTML document' directly
  * Editorial: Cross-reference 'children' directly
  * Editorial: Cross-reference 'ASCII case-insensitive' directly
  * Editorial: Remove obsolete reference to 'case-sensitive'
  * Editorial: Consistently cross-reference interfaces and interface members
  * Editorial: Remove redundant 'the' or 'this' referring to variables
  * Editorial: Remove unused definition
  * Editorial: Remove obsolete note about Attr/Node inheritance
  * Editorial: Simplify algorithm flow wording
  * Editorial: Consistently use a list for serialization algorithm steps
  * Editorial: Cross-reference 'is empty'
  * Editorial: Redefine namespace prefix map as an ordered map and clarify algorithms
  * Editorial: Clarify the prefix index handling
  * Editorial: Cross-reference 'throw an exception'
  * Editorial: Remove some redundant prose when calling algorithms
  * Editorial: Clarify note about children of the document
  * Editorial: Remove reference to void elements
  * Editorial: Clarify some prose
  * Editorial: Redefine local prefixes map as an ordered map and clarify algorithms
  * Editorial: Drop 'context namespace' definition
  * Editorial: Use explicit substeps for steps that do too much
  * Editorial: Use 'set' instead of 'let' where appropriate
  * Editorial: Mark up HTML elements consistently
  * Editorial: Add type annotations to some variables
  * Editorial: Add and mark up more notes
  * Editorial: Reduce duplication in 'XML serialization of the attributes'
  * Editorial: Clarify signature of 'serializing an attribute value'
  * Editorial: Reduce duplication in 'XML serializing a Text node'
  * Editorial: Add references to some GitHub issues
  * Editorial: Only pass attributes to 'recording the namespace information'
  * Editorial: Clarify 'retrieving a preferred prefix string'
  * Editorial: Update references to unversioned standards
  * Normative: Preserve an attribute's namespace prefix when possible
  * Normative: Restore serialization of CDATASection nodes
  * Normative: Excape tab, LF, CR in attributes

-- File Changes --

    M index.html (1366)
    M respecConfig.js (12)

-- Patch Links --

https://github.com/w3c/DOM-Parsing/pull/88.patch
https://github.com/w3c/DOM-Parsing/pull/88.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/DOM-Parsing/pull/88
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/DOM-Parsing/pull/88@github.com>
Aquileo | [w3c/IndexedDB] penting130413@gmail.com (Issue #503)pakalu1304-sysnotifications@github.commid:w3c/IndexedDB/issues/503@github.com2026-08-15T19:53:38+00:00
pakalu1304-sys created an issue (w3c/IndexedDB#503)

Feedback helpful

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/503
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/503@github.com>
Aquileo | [w3c/IndexedDB] penting130413@gmail.com (Issue #503)pakalu1304-sysnotifications@github.commid:w3c/IndexedDB/issues/503@github.com2026-08-15T19:53:38+00:00
pakalu1304-sys created an issue (w3c/IndexedDB#503)

Feedback helpful

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/503
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/503@github.com>
Aquileo | [w3c/IndexedDB] penting130413@gmail.com (Issue #502)pakalu1304-sysnotifications@github.commid:w3c/IndexedDB/issues/502@github.com2026-08-15T19:53:03+00:00
pakalu1304-sys created an issue (w3c/IndexedDB#502)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/502
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/502@github.com>
Aquileo | [w3c/IndexedDB] html (Issue #501)pakalu1304-sysnotifications@github.commid:w3c/IndexedDB/issues/501@github.com2026-08-15T19:52:46+00:00
pakalu1304-sys created an issue (w3c/IndexedDB#501)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/501
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/501@github.com>
Aquileo | Re: [w3c/ServiceWorker] Should update() always reject if there is an installing worker? (#1429)Andrew Sutherlandnotifications@github.commid:w3c/ServiceWorker/issues/1429/5297227000@github.com2026-08-14T19:17:26+00:00
asutherland left a comment (w3c/ServiceWorker#1429)

Merging update() works for Firefox (and we can change our impl).

For the spec, is the idea that we would go further than the `lastJob` coalescing of [schedule job](https://w3c.github.io/ServiceWorker/#schedule-job-algorithm) and just merge with the (inductively) only update in the job queue if there is one and the job promise has not yet settled?

Since  [update()](https://w3c.github.io/ServiceWorker/#service-worker-registration-update) latches the newestWorker's script URL when it's called and the [update job algorithm](https://w3c.github.io/ServiceWorker/#update) rejects if the latched script URL does not match with the current newestWorker's state, it already is the case that enqueueing an update job that follows a register that isn't roughly an update will fail, likewise with unregister, so it seems reasonable to only support having one in the queue.  (Although I suppose you could have an interesting sequence of "update, unregister, register, update" where the same script URL is used for the register as existed before, and then that would be observable.)


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1429#issuecomment-5297227000
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1429/5297227000@github.com>
Aquileo | [w3ctag/design-reviews] WG New Spec: Global Privacy Control (GPC) (Issue #1265)Sebastian Zimmecknotifications@github.commid:w3ctag/design-reviews/issues/1265@github.com2026-08-14T19:08:44+00:00
SebastianZimmeck created an issue (w3ctag/design-reviews#1265)

### Specification

https://w3c.github.io/gpc/

### Explainer

https://w3c.github.io/gpc/explainer

### Links

- The WG's request for this TAG review: https://  <!-- If the WG didn't express consensus to ask the TAG for a review, use the "Other Specification Review" template instead, at https://github.com/w3ctag/design-reviews/issues/new?template=015-other-spec-review.yaml. This is usually a deep link into minutes or an email thread. -->
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1265


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1265
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1265@github.com>
Aquileo | [w3c/manifest] editorial: Adds localization members list (PR #1245)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1245@github.com2026-08-14T13:47:58+00:00
Closes #1230 

This change (choose at least one, delete ones that don't apply):

* Makes editorial changes (changes informative sections, or changes normative sections without changing behavior)
* Is a "chore" (metadata, formatting, fixing warnings, etc).

Implementation commitment (delete if not making normative changes):

* [ ] WebKit (https://bugs.webkit.org)
* [ ] Chromium (https://bugs.chromium.org/)
* [ ] Gecko (http://bugzilla.mozilla.org)


Commit message:

Adds a list of localisable members in the `*_localized` member section for clarity.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 500 Internal Server Error :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 14, 2026, 1:47 PM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=respec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fdiekus%2Fmanifest%2F08386758d4bb028c0e768693ceefbaafb97ef741%2Findex.html%3FisPreview%3Dtrue)

**Error output:**

```
🕵️‍♀️  That doesn't seem to be a ReSpec document. Please check manually: http://localhost:8082/uploads/mchOyy/index.html?publishDate=2026-08-14&isPreview=true%3FisPreview%3Dtrue
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20w3c/manifest%231245.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1245

-- Commit Summary --

  * chore(auto-publish.yml): disable pub rules check
  * Editorial: update "processing a manifest"'s signature (#1058)
  * chore: Fix broken active-document reference (#1063)
  * editorial: Define an algorithm for launching a web app (#1056)
  * chore: Export processed manifest and application context definitions (#1062)
  * chore: change Marcos' affiliation
  * Editorial: Minor cleanup / refactor of Manifest processing steps (#1066)
  * Editorial: Rewrote Proprietary manifest members section to discourage vendor prefixing. (#1073)
  * chore: Ran tidy. (#1076)
  * Allow manifest processing to be invoked without going through an HTML document (#1069)
  * Editorial: Remove “at risk” warning for monochrome (#1098)
  * Fix grammar in `id` section (#1102)
  * Change "A" to "An" (#1103)
  * Editorial: remove “commonly” to reflect actual JSON encoding (#1100)
  * Editorial: ensure consistency in manifest naming (#1099)
  * Editorial: Replace ref to obsoleted RFC7540 with ref to RFC9110 (#1106)
  * chore: Export the terms "manifest URL" and "start URL" (#1112)
  * editorial: Move the definition of display-mode back to APPMANIFEST. (#1039)
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * Revert "addressing comments, adding dfn"
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * chore: tidy (#1119)
  * Chore: add Diego as editor, retire Aaron (#1124)
  * chore: retire Anssi Kostiainen
  * chore: add Christian as editor (#1125)
  * Processing steps for id now removes the fragment (#1122)
  * Remove problematic icon matching algorithm (#1120)
  * fix: dir's auto definition (#1118)
  * Editorial: fix `lang` description (#1133) (#1133)
  * Editorial: fix language tag description (#1134)
  * Editorial: Less specific description for dir auto (#1135)
  * chore: Update tidy.yml (#1137)
  * Trim `dir`, `lang`, `display`, `orientation`, text and color values (#1140)
  * Add members for localization (#1101)
  * Editorial: Retire Matt Giuca
  * Move `prefer_related_applications` and `related_applications` to manifest incubation (#1152)
  * Make enums case-insensitive (#1149)
  * clarify the definition of "navigation scope", "applied", and off-scope theming (#1151)
  * Editorial: Add installable web application definition (#1163)
  * chore: tidy (#1166)
  * Editorial: move incubations to the README (#1153)
  * Editorial: rephrase multiple icon example (#1170)
  * chore: export Installed Web Application Identity (#1187)
  * Add retiredDate for Kenneth Rohde Christiansen (#1192)
  * Specify when an icon might be updated (editorial), and loosen sec-sensitive member update reqs (#1199)
  * chore: tidy up index.html (#1200)
  * chore: Export the "install" dfn for cross-spec linking (#1212)
  * Add `color_scheme_dark` member and themeable members (colors only) (#1207)
  * Add retiredDate for Diego González (#1213)
  * Clarify applying manifest to an existing browsing context (#1202)
  * Clarify how manifest image resources are fetched (#1171)
  * Rename "default display mode" to "applied display mode" (#1215)
  * chore: tidy up index.html (#1217)
  * chore: fix SchemaStore links and drop the embedded schema view (#1220)
  * Recommend user agents let users inspect and modify shortcut URLs (#1221)
  * editorial: fix typos, grammar, and a stray definition (#1233)
  * Format U+002F character references using W3C I18N template (#1235)
  * chore: tidy up index.html (#1236)
  * editorial: split privacy and security considerations into two sections (#1224)
  * Formalize Internationalization appendix as Internationalization Considerations and clarify UA localization options (#1234)
  * editorial: add missing assertion to chosen-display-mode algorithm (#1238)
  * Editorial: don't referece WebIDL identifier (#1237)
  * chore: tidy up index.html (#1244)
  * [Editorial] Adds list of members that are localisable

-- File Changes --

    M index.html (9229)

-- Patch Links --

https://github.com/w3c/manifest/pull/1245.patch
https://github.com/w3c/manifest/pull/1245.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1245
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1245@github.com>
Aquileo | [w3c/manifest] editorial: Adds localization members list (PR #1245)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1245@github.com2026-08-14T13:47:58+00:00
Closes #1230 

This change (choose at least one, delete ones that don't apply):

* Makes editorial changes (changes informative sections, or changes normative sections without changing behavior)
* Is a "chore" (metadata, formatting, fixing warnings, etc).

Implementation commitment (delete if not making normative changes):

* [ ] WebKit (https://bugs.webkit.org)
* [ ] Chromium (https://bugs.chromium.org/)
* [ ] Gecko (http://bugzilla.mozilla.org)


Commit message:

Adds a list of localisable members in the `*_localized` member section for clarity.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 500 Internal Server Error :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 14, 2026, 1:47 PM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=respec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fdiekus%2Fmanifest%2F08386758d4bb028c0e768693ceefbaafb97ef741%2Findex.html%3FisPreview%3Dtrue)

**Error output:**

```
🕵️‍♀️  That doesn't seem to be a ReSpec document. Please check manually: http://localhost:8082/uploads/mchOyy/index.html?publishDate=2026-08-14&isPreview=true%3FisPreview%3Dtrue
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20w3c/manifest%231245.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1245

-- Commit Summary --

  * chore(auto-publish.yml): disable pub rules check
  * Editorial: update "processing a manifest"'s signature (#1058)
  * chore: Fix broken active-document reference (#1063)
  * editorial: Define an algorithm for launching a web app (#1056)
  * chore: Export processed manifest and application context definitions (#1062)
  * chore: change Marcos' affiliation
  * Editorial: Minor cleanup / refactor of Manifest processing steps (#1066)
  * Editorial: Rewrote Proprietary manifest members section to discourage vendor prefixing. (#1073)
  * chore: Ran tidy. (#1076)
  * Allow manifest processing to be invoked without going through an HTML document (#1069)
  * Editorial: Remove “at risk” warning for monochrome (#1098)
  * Fix grammar in `id` section (#1102)
  * Change "A" to "An" (#1103)
  * Editorial: remove “commonly” to reflect actual JSON encoding (#1100)
  * Editorial: ensure consistency in manifest naming (#1099)
  * Editorial: Replace ref to obsoleted RFC7540 with ref to RFC9110 (#1106)
  * chore: Export the terms "manifest URL" and "start URL" (#1112)
  * editorial: Move the definition of display-mode back to APPMANIFEST. (#1039)
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * Revert "addressing comments, adding dfn"
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * chore: tidy (#1119)
  * Chore: add Diego as editor, retire Aaron (#1124)
  * chore: retire Anssi Kostiainen
  * chore: add Christian as editor (#1125)
  * Processing steps for id now removes the fragment (#1122)
  * Remove problematic icon matching algorithm (#1120)
  * fix: dir's auto definition (#1118)
  * Editorial: fix `lang` description (#1133) (#1133)
  * Editorial: fix language tag description (#1134)
  * Editorial: Less specific description for dir auto (#1135)
  * chore: Update tidy.yml (#1137)
  * Trim `dir`, `lang`, `display`, `orientation`, text and color values (#1140)
  * Add members for localization (#1101)
  * Editorial: Retire Matt Giuca
  * Move `prefer_related_applications` and `related_applications` to manifest incubation (#1152)
  * Make enums case-insensitive (#1149)
  * clarify the definition of "navigation scope", "applied", and off-scope theming (#1151)
  * Editorial: Add installable web application definition (#1163)
  * chore: tidy (#1166)
  * Editorial: move incubations to the README (#1153)
  * Editorial: rephrase multiple icon example (#1170)
  * chore: export Installed Web Application Identity (#1187)
  * Add retiredDate for Kenneth Rohde Christiansen (#1192)
  * Specify when an icon might be updated (editorial), and loosen sec-sensitive member update reqs (#1199)
  * chore: tidy up index.html (#1200)
  * chore: Export the "install" dfn for cross-spec linking (#1212)
  * Add `color_scheme_dark` member and themeable members (colors only) (#1207)
  * Add retiredDate for Diego González (#1213)
  * Clarify applying manifest to an existing browsing context (#1202)
  * Clarify how manifest image resources are fetched (#1171)
  * Rename "default display mode" to "applied display mode" (#1215)
  * chore: tidy up index.html (#1217)
  * chore: fix SchemaStore links and drop the embedded schema view (#1220)
  * Recommend user agents let users inspect and modify shortcut URLs (#1221)
  * editorial: fix typos, grammar, and a stray definition (#1233)
  * Format U+002F character references using W3C I18N template (#1235)
  * chore: tidy up index.html (#1236)
  * editorial: split privacy and security considerations into two sections (#1224)
  * Formalize Internationalization appendix as Internationalization Considerations and clarify UA localization options (#1234)
  * editorial: add missing assertion to chosen-display-mode algorithm (#1238)
  * Editorial: don't referece WebIDL identifier (#1237)
  * chore: tidy up index.html (#1244)
  * [Editorial] Adds list of members that are localisable

-- File Changes --

    M index.html (9229)

-- Patch Links --

https://github.com/w3c/manifest/pull/1245.patch
https://github.com/w3c/manifest/pull/1245.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1245
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1245@github.com>
Aquileo | [w3c/manifest] editorial: Adds localization members list (PR #1245)Diego Gonzaleznotifications@github.commid:w3c/manifest/pull/1245@github.com2026-08-14T13:47:58+00:00
Closes #1230 

This change (choose at least one, delete ones that don't apply):

* Makes editorial changes (changes informative sections, or changes normative sections without changing behavior)
* Is a "chore" (metadata, formatting, fixing warnings, etc).

Implementation commitment (delete if not making normative changes):

* [ ] WebKit (https://bugs.webkit.org)
* [ ] Chromium (https://bugs.chromium.org/)
* [ ] Gecko (http://bugzilla.mozilla.org)


Commit message:

Adds a list of localisable members in the `*_localized` member section for clarity.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***

### :boom: Error: 500 Internal Server Error :boom: ###

[PR Preview](https://github.com/tobie/pr-preview#pr-preview) failed to build. _(Last tried on Aug 14, 2026, 1:47 PM UTC)_.

<details>
<summary>More</summary>


PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

:rotating_light: [Spec Generator](https://www.w3.org/publications/spec-generator/) - Spec Generator is the web service used to build bikeshed/ReSpec specs

:link: [Related URL](https://www.w3.org/publications/spec-generator/?type=respec&output=html&url=https%3A%2F%2Fraw.githubusercontent.com%2Fdiekus%2Fmanifest%2F08386758d4bb028c0e768693ceefbaafb97ef741%2Findex.html%3FisPreview%3Dtrue)

**Error output:**

```
🕵️‍♀️  That doesn't seem to be a ReSpec document. Please check manually: http://localhost:8082/uploads/mchOyy/index.html?publishDate=2026-08-14&isPreview=true%3FisPreview%3Dtrue
```

_This seems to be an issue with the [Spec Generator](https://www.w3.org/publications/spec-generator/) service. PR Preview doesn't manage this service and so has no control over it. If you've identified an issue with it, you can [report the issue to the maintainers of Spec Generator](https://github.com/w3c/spec-generator/issues/new) directly. Please be courteous. Thank you!_

_If you don't have enough information above to solve the error by yourself or if the issue doesn't seem related to Spec Generator, you can [file an issue with PR Preview](https://github.com/tobie/pr-preview/issues/new?title=Unidentified%20Error&body=See%20w3c/manifest%231245.)._

</details>

You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1245

-- Commit Summary --

  * chore(auto-publish.yml): disable pub rules check
  * Editorial: update "processing a manifest"'s signature (#1058)
  * chore: Fix broken active-document reference (#1063)
  * editorial: Define an algorithm for launching a web app (#1056)
  * chore: Export processed manifest and application context definitions (#1062)
  * chore: change Marcos' affiliation
  * Editorial: Minor cleanup / refactor of Manifest processing steps (#1066)
  * Editorial: Rewrote Proprietary manifest members section to discourage vendor prefixing. (#1073)
  * chore: Ran tidy. (#1076)
  * Allow manifest processing to be invoked without going through an HTML document (#1069)
  * Editorial: Remove “at risk” warning for monochrome (#1098)
  * Fix grammar in `id` section (#1102)
  * Change "A" to "An" (#1103)
  * Editorial: remove “commonly” to reflect actual JSON encoding (#1100)
  * Editorial: ensure consistency in manifest naming (#1099)
  * Editorial: Replace ref to obsoleted RFC7540 with ref to RFC9110 (#1106)
  * chore: Export the terms "manifest URL" and "start URL" (#1112)
  * editorial: Move the definition of display-mode back to APPMANIFEST. (#1039)
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * Revert "addressing comments, adding dfn"
  * Rewrite privacy considerations on fingerprinting in start_url (#1114)
  * chore: tidy (#1119)
  * Chore: add Diego as editor, retire Aaron (#1124)
  * chore: retire Anssi Kostiainen
  * chore: add Christian as editor (#1125)
  * Processing steps for id now removes the fragment (#1122)
  * Remove problematic icon matching algorithm (#1120)
  * fix: dir's auto definition (#1118)
  * Editorial: fix `lang` description (#1133) (#1133)
  * Editorial: fix language tag description (#1134)
  * Editorial: Less specific description for dir auto (#1135)
  * chore: Update tidy.yml (#1137)
  * Trim `dir`, `lang`, `display`, `orientation`, text and color values (#1140)
  * Add members for localization (#1101)
  * Editorial: Retire Matt Giuca
  * Move `prefer_related_applications` and `related_applications` to manifest incubation (#1152)
  * Make enums case-insensitive (#1149)
  * clarify the definition of "navigation scope", "applied", and off-scope theming (#1151)
  * Editorial: Add installable web application definition (#1163)
  * chore: tidy (#1166)
  * Editorial: move incubations to the README (#1153)
  * Editorial: rephrase multiple icon example (#1170)
  * chore: export Installed Web Application Identity (#1187)
  * Add retiredDate for Kenneth Rohde Christiansen (#1192)
  * Specify when an icon might be updated (editorial), and loosen sec-sensitive member update reqs (#1199)
  * chore: tidy up index.html (#1200)
  * chore: Export the "install" dfn for cross-spec linking (#1212)
  * Add `color_scheme_dark` member and themeable members (colors only) (#1207)
  * Add retiredDate for Diego González (#1213)
  * Clarify applying manifest to an existing browsing context (#1202)
  * Clarify how manifest image resources are fetched (#1171)
  * Rename "default display mode" to "applied display mode" (#1215)
  * chore: tidy up index.html (#1217)
  * chore: fix SchemaStore links and drop the embedded schema view (#1220)
  * Recommend user agents let users inspect and modify shortcut URLs (#1221)
  * editorial: fix typos, grammar, and a stray definition (#1233)
  * Format U+002F character references using W3C I18N template (#1235)
  * chore: tidy up index.html (#1236)
  * editorial: split privacy and security considerations into two sections (#1224)
  * Formalize Internationalization appendix as Internationalization Considerations and clarify UA localization options (#1234)
  * editorial: add missing assertion to chosen-display-mode algorithm (#1238)
  * Editorial: don't referece WebIDL identifier (#1237)
  * chore: tidy up index.html (#1244)
  * [Editorial] Adds list of members that are localisable

-- File Changes --

    M index.html (9229)

-- Patch Links --

https://github.com/w3c/manifest/pull/1245.patch
https://github.com/w3c/manifest/pull/1245.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1245
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1245@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add a script version property to the ServiceWorker object (#1387)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1387/5287948206@github.com2026-08-14T00:29:01+00:00
monica-ch left a comment (w3c/ServiceWorker#1387)

[Bug triage] Keeping it open, low priority for now given workarounds discussed above

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1387#issuecomment-5287948206
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1387/5287948206@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add a script version property to the ServiceWorker object (#1387)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1387/5287948206@github.com2026-08-14T00:29:01+00:00
monica-ch left a comment (w3c/ServiceWorker#1387)

[Bug triage] Keeping it open, low priority for now given workarounds discussed above

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1387#issuecomment-5287948206
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1387/5287948206@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add a script version property to the ServiceWorker object (#1387)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1387/5287948206@github.com2026-08-14T00:29:01+00:00
monica-ch left a comment (w3c/ServiceWorker#1387)

[Bug triage] Keeping it open, low priority for now given workarounds discussed above

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1387#issuecomment-5287948206
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1387/5287948206@github.com>
Aquileo | Re: [w3c/ServiceWorker] Allow active worker to immediately evict itself (#1296)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1296/5287899722@github.com2026-08-14T00:21:29+00:00
monica-ch left a comment (w3c/ServiceWorker#1296)

[Bug triage] Keeping it open, needs more discussion

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1296#issuecomment-5287899722
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1296/5287899722@github.com>
Aquileo | Re: [w3c/ServiceWorker] "display-mode" information on navigation requests (#1473)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1473/issue_event/29431379304@github.com2026-08-14T00:15:03+00:00
Closed #1473 as duplicate.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1473#event-29431379304
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1473/issue_event/29431379304@github.com>
Aquileo | Re: [w3c/ServiceWorker] Expose `display` mode (e.g. `standalone`) on `client` (#1370)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1370/5287848396@github.com2026-08-14T00:13:20+00:00
monica-ch left a comment (w3c/ServiceWorker#1370)

[Bug triage] Issue still exists, needs prioritization

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1370#issuecomment-5287848396
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1370/5287848396@github.com>
Aquileo | Re: [w3c/ServiceWorker] spec says cache should return responses with immutable headers, but no browser does that (#1456)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1456/5287807273@github.com2026-08-14T00:08:36+00:00
monica-ch left a comment (w3c/ServiceWorker#1456)

[Bug triage] Look into fetch() to make sure alignment, also write tests around these to understand if browsers are using mutable headers

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1456#issuecomment-5287807273
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1456/5287807273@github.com>
Aquileo | Re: [w3c/ServiceWorker] CFC: Transition V1 spec to CR (#1458)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issue/1458/issue_event/29431073149@github.com2026-08-14T00:03:53+00:00
Closed #1458 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1458#event-29431073149
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issue/1458/issue_event/29431073149@github.com>
Aquileo | Re: [w3c/ServiceWorker] Service Worker makes AJAX Progress Listener not Working (#1141)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1141/5287765980@github.com2026-08-14T00:02:08+00:00
monica-ch left a comment (w3c/ServiceWorker#1141)

[Bug triage] To be discussed in TPAC

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1141#issuecomment-5287765980
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1141/5287765980@github.com>
Aquileo | Re: [w3c/ServiceWorker] Immediate Service Worker (#1389)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1389/5287726677@github.com2026-08-13T23:55:33+00:00
monica-ch left a comment (w3c/ServiceWorker#1389)

[Bug triage] Proposal is complex to implement, we wanted to understand more use case before we look further into it. Closing for now, feel-free to reach re-open

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1389#issuecomment-5287726677
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1389/5287726677@github.com>
Aquileo | Re: [w3c/ServiceWorker] Immediate Service Worker (#1389)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1389/5287726677@github.com2026-08-13T23:55:33+00:00
monica-ch left a comment (w3c/ServiceWorker#1389)

[Bug triage] Proposal is complex to implement, we wanted to understand more use case before we look further into it. Closing for now, feel-free to reach re-open

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1389#issuecomment-5287726677
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1389/5287726677@github.com>
Aquileo | Re: [w3c/ServiceWorker] Sort out settings object for service worker module scripts (#1013)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1013/5287679417@github.com2026-08-13T23:48:40+00:00
monica-ch left a comment (w3c/ServiceWorker#1013)

[Bug triage] #1294 is still open, need further investigation

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1013#issuecomment-5287679417
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1013/5287679417@github.com>
Aquileo | [whatwg/webidl] Intent to use Constants (Issue #1627)mdjr1877-droidnotifications@github.commid:whatwg/webidl/issues/1627@github.com2026-08-13T21:33:43+00:00
mdjr1877-droid created an issue (whatwg/webidl#1627)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1627
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1627@github.com>
Aquileo | [whatwg/webidl] Intent to use Constants (Issue #1627)mdjr1877-droidnotifications@github.commid:whatwg/webidl/issues/1627@github.com2026-08-13T21:33:43+00:00
mdjr1877-droid created an issue (whatwg/webidl#1627)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1627
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1627@github.com>
Aquileo | [whatwg/webidl] Intent to use Constants (Issue #1627)mdjr1877-droidnotifications@github.commid:whatwg/webidl/issues/1627@github.com2026-08-13T21:33:43+00:00
mdjr1877-droid created an issue (whatwg/webidl#1627)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1627
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1627@github.com>
Aquileo | Re: [w3c/manifest] Manifest name: USVString or not? (Issue #1228)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1228/5284335995@github.com2026-08-13T17:48:02+00:00
dmurph left a comment (w3c/manifest#1228)

User agents often display these strings in UX, and also provide these strings to the OS, and recently we have been dealing with trying to button issues like this where the UX could get messed up with malformed / unpaired / weird utf stuff. So I don't think it's necessarily a bad thing if the spec defined stuff around discarding these? I'm not sure if using USVString does that, or we would have to say we do that? 

Is that the norm for using a USVString? where you want to sanitize it for UX reasons?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1228#issuecomment-5284335995
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1228/5284335995@github.com>
Aquileo | Re: [w3c/manifest] Manifest name: USVString or not? (Issue #1228)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1228/5284335995@github.com2026-08-13T17:48:02+00:00
dmurph left a comment (w3c/manifest#1228)

User agents often display these strings in UX, and also provide these strings to the OS, and recently we have been dealing with trying to button issues like this where the UX could get messed up with malformed / unpaired / weird utf stuff. So I don't think it's necessarily a bad thing if the spec defined stuff around discarding these? I'm not sure if using USVString does that, or we would have to say we do that? 

Is that the norm for using a USVString? where you want to sanitize it for UX reasons?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1228#issuecomment-5284335995
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1228/5284335995@github.com>
Aquileo | Re: [w3c/manifest] Manifest name: USVString or not? (Issue #1228)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1228/5284335995@github.com2026-08-13T17:48:02+00:00
dmurph left a comment (w3c/manifest#1228)

User agents often display these strings in UX, and also provide these strings to the OS, and recently we have been dealing with trying to button issues like this where the UX could get messed up with malformed / unpaired / weird utf stuff. So I don't think it's necessarily a bad thing if the spec defined stuff around discarding these? I'm not sure if using USVString does that, or we would have to say we do that? 

Is that the norm for using a USVString? where you want to sanitize it for UX reasons?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1228#issuecomment-5284335995
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1228/5284335995@github.com>
Aquileo | Re: [w3c/manifest] Manifest name: USVString or not? (Issue #1228)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1228/5284335995@github.com2026-08-13T17:48:02+00:00
dmurph left a comment (w3c/manifest#1228)

User agents often display these strings in UX, and also provide these strings to the OS, and recently we have been dealing with trying to button issues like this where the UX could get messed up with malformed / unpaired / weird utf stuff. So I don't think it's necessarily a bad thing if the spec defined stuff around discarding these? I'm not sure if using USVString does that, or we would have to say we do that? 

Is that the norm for using a USVString? where you want to sanitize it for UX reasons?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1228#issuecomment-5284335995
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1228/5284335995@github.com>
Aquileo | Re: [w3c/manifest] Are `*_localized` items clearly allowed in shortcut items? (Issue #1230)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1230/5284274797@github.com2026-08-13T17:42:14+00:00
dmurph left a comment (w3c/manifest#1230)

We do explicilty do this in the shortcut member procesing here:
https://w3c.github.io/manifest/#dfn-process-a-shortcut

It might be helpful to list the items, though, here: https://w3c.github.io/manifest/#dfn-localizable-member

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1230#issuecomment-5284274797
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1230/5284274797@github.com>
Aquileo | Re: [w3c/manifest] Should `display-mode` be gated for cross-origin iframes? (Issue #1239)Daniel Murphynotifications@github.commid:w3c/manifest/issues/1239/5284234649@github.com2026-08-13T17:38:27+00:00
dmurph left a comment (w3c/manifest#1239)

We have a partner that this would have broken if they didn't use the [migration API](https://github.com/WICG/manifest-incubations/blob/gh-pages/pwa-migration-explainer.md) to migrate their app to a different origin. As they were always using an iframe before.

So there are likely other devs who do this - pwa is on origin A, but they also own origin B, and iframe B in A.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1239#issuecomment-5284234649
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1239/5284234649@github.com>
Aquileo | [w3c/manifest] Tidied up document using tidy-html5 (PR #1244)github-actions[bot]notifications@github.commid:w3c/manifest/pull/1244@github.com2026-08-13T17:34:42+00:00
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/manifest/pull/1244.html" title="Last updated on Aug 13, 2026, 5:34 PM UTC (61339f6)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/manifest/1244/ab20147...61339f6.html" title="Last updated on Aug 13, 2026, 5:34 PM UTC (61339f6)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/manifest/pull/1244

-- Commit Summary --

  * chore: tidy up index.html

-- File Changes --

    M index.html (8)

-- Patch Links --

https://github.com/w3c/manifest/pull/1244.patch
https://github.com/w3c/manifest/pull/1244.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1244
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1244@github.com>
Aquileo | Re: [w3c/manifest] Note below "steps for determining the web app's chosen display mode" refers to non-existent assertion (Issue #1055)Daniel Murphynotifications@github.commid:w3c/manifest/issue/1055/issue_event/29415033562@github.com2026-08-13T17:33:27+00:00
Closed #1055 as completed via #1238.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1055#event-29415033562
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issue/1055/issue_event/29415033562@github.com>
Aquileo | Re: [w3c/manifest] Note below "steps for determining the web app's chosen display mode" refers to non-existent assertion (Issue #1055)Daniel Murphynotifications@github.commid:w3c/manifest/issue/1055/issue_event/29415033562@github.com2026-08-13T17:33:27+00:00
Closed #1055 as completed via #1238.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1055#event-29415033562
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issue/1055/issue_event/29415033562@github.com>
Aquileo | Re: [w3c/manifest] Note below "steps for determining the web app's chosen display mode" refers to non-existent assertion (Issue #1055)Daniel Murphynotifications@github.commid:w3c/manifest/issue/1055/issue_event/29415033562@github.com2026-08-13T17:33:27+00:00
Closed #1055 as completed via #1238.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1055#event-29415033562
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issue/1055/issue_event/29415033562@github.com>
Aquileo | Re: [w3c/manifest] Editorial: don't reference WebIDL identifier (PR #1237)Christian Liebelnotifications@github.commid:w3c/manifest/pull/1237/review/4929151998@github.com2026-08-13T16:11:28+00:00
@christianliebel approved this pull request.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1237#pullrequestreview-4929151998
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1237/review/4929151998@github.com>
Aquileo | Re: [w3c/manifest] Editorial: don't reference WebIDL identifier (PR #1237)Christian Liebelnotifications@github.commid:w3c/manifest/pull/1237/review/4929151998@github.com2026-08-13T16:11:28+00:00
@christianliebel approved this pull request.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1237#pullrequestreview-4929151998
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1237/review/4929151998@github.com>
Aquileo | Re: [w3c/manifest] Editorial: don't reference WebIDL identifier (PR #1237)Christian Liebelnotifications@github.commid:w3c/manifest/pull/1237/review/4929151998@github.com2026-08-13T16:11:28+00:00
@christianliebel approved this pull request.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1237#pullrequestreview-4929151998
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1237/review/4929151998@github.com>
Aquileo | Re: [w3c/manifest] Editorial: don't reference WebIDL identifier (PR #1237)Christian Liebelnotifications@github.commid:w3c/manifest/pull/1237/review/4929151998@github.com2026-08-13T16:11:28+00:00
@christianliebel approved this pull request.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1237#pullrequestreview-4929151998
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1237/review/4929151998@github.com>
Aquileo | Re: [w3c/manifest] editorial: add missing assertion to chosen-display-mode algorithm (PR #1238)Christian Liebelnotifications@github.commid:w3c/manifest/pull/1238/review/4929145603@github.com2026-08-13T16:10:50+00:00
@christianliebel approved this pull request.





-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1238#pullrequestreview-4929145603
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1238/review/4929145603@github.com>
Aquileo | [w3c/manifest] blogwiu (Issue #1243)blogwiunotifications@github.commid:w3c/manifest/issues/1243@github.com2026-08-13T14:09:20+00:00
wiuoliveira2025-prog created an issue (w3c/manifest#1243)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1243
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1243@github.com>
Aquileo | [w3c/manifest] blogwiu (Issue #1242)blogwiunotifications@github.commid:w3c/manifest/issues/1242@github.com2026-08-13T14:08:03+00:00
wiuoliveira2025-prog created an issue (w3c/manifest#1242)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1242
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1242@github.com>
Aquileo | [w3c/manifest] blogwiu (Issue #1241)blogwiunotifications@github.commid:w3c/manifest/issues/1241@github.com2026-08-13T14:07:15+00:00
wiuoliveira2025-prog created an issue (w3c/manifest#1241)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1241
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1241@github.com>
Aquileo | [w3c/manifest] blogwiu (Issue #1241)blogwiunotifications@github.commid:w3c/manifest/issues/1241@github.com2026-08-13T14:07:15+00:00
wiuoliveira2025-prog created an issue (w3c/manifest#1241)



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1241
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1241@github.com>
Aquileo | [w3c/editing] iOS Safari: URL bar invisible hitbox overlaps text selection grab circle (Issue #550)Michael Aufreiternotifications@github.commid:w3c/editing/issues/550@github.com2026-08-13T14:06:17+00:00
michael created an issue (w3c/editing#550)

In iOS Safari the bottom-floating address bar is occupying not just visual space at the center, but its bounding box occupies all the space left to right.

It's another situation (like #545) where iOS Safari uses too much space for its app chrome, so little screen estate is left for editing. In this case it leads to situations where you assume you can click/select something, but you can't, which can be frustrating to users.

Here's a demo/explanation (turn on audio) of @johannesmutter how this affects https://svedit.dev.

https://github.com/user-attachments/assets/485dd86c-99f6-4537-86bc-cb9e61231ab8.mp4

Considerations:
- I think the large hitbox makes sense on any website in non-edit mode, so you can click close to the address bar to navigate somewhere else
- However while editing content (especially while the VirtualKeyboard is open) this leads to a bad user experience

Questions
- Could the hitbox be made smaller only when the VirtualKeyboard is open?
- Could the address bar and the form assistant bar somehow be combined to save space?
- Could there be a setting, so apps can deactivate the URL bar (and/or the form assistant bar) while the VirtualKeyboard is open?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/550
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/550@github.com>
Aquileo | [whatwg/storage] Meta: Best practices for storage-related specs to define their parallel queues (Issue #194)Andrew Sutherlandnotifications@github.commid:whatwg/storage/issues/194@github.com2026-08-13T13:59:34+00:00
asutherland created an issue (whatwg/storage#194)

As part of @monica-ch's deeply appreciated work to clean up the "in parallel" algorithms in the ServiceWorkers spec, a question has been raised in https://github.com/w3c/ServiceWorker/pull/1842#pullrequestreview-4868895938 about how best to define these queues and so I thought I would raise the question here for discoverability for other storage-related specs facing this issue and since possibly any advice could go in the spec[1].

I'll quote the question from there below:
> Quick clarification before I push: https://github.com/w3c/ServiceWorker/pull/1838 hangs the queue off `[=name to cache map=]` because that map is itself per-storage-key. Clients don't have an equivalent map — the `[=/service worker clients=]` list is UA-wide, filtered by storage key. Would you prefer a UA-level `<dfn>Clients parallel queue</dfn>` map keyed by storage key, or a prose "for each storage key, the UA has an associated Clients parallel queue" form?

1: For example, maybe queues that are 1:1 with bottles could be called straws... (joke!)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/194
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/storage/issues/194@github.com>
Aquileo | [whatwg/storage] Meta: Best practices for storage-related specs to define their parallel queues (Issue #194)Andrew Sutherlandnotifications@github.commid:whatwg/storage/issues/194@github.com2026-08-13T13:59:34+00:00
asutherland created an issue (whatwg/storage#194)

As part of @monica-ch's deeply appreciated work to clean up the "in parallel" algorithms in the ServiceWorkers spec, a question has been raised in https://github.com/w3c/ServiceWorker/pull/1842#pullrequestreview-4868895938 about how best to define these queues and so I thought I would raise the question here for discoverability for other storage-related specs facing this issue and since possibly any advice could go in the spec[1].

I'll quote the question from there below:
> Quick clarification before I push: https://github.com/w3c/ServiceWorker/pull/1838 hangs the queue off `[=name to cache map=]` because that map is itself per-storage-key. Clients don't have an equivalent map — the `[=/service worker clients=]` list is UA-wide, filtered by storage key. Would you prefer a UA-level `<dfn>Clients parallel queue</dfn>` map keyed by storage key, or a prose "for each storage key, the UA has an associated Clients parallel queue" form?

1: For example, maybe queues that are 1:1 with bottles could be called straws... (joke!)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/194
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/storage/issues/194@github.com>
Aquileo | [w3c/editing] iOS Safari: meta content="interactive-widget=resizes-content" (Issue #549)Michael Aufreiternotifications@github.commid:w3c/editing/issues/549@github.com2026-08-13T13:44:03+00:00
michael created an issue (w3c/editing#549)

Editor developers want to be able to place a toolbar (likely at the bottom of the page, near the user's thumb). However, when the VirtualKeyboard is shown the toolbar is covered.

There's a solution for this, supported on Android already:

```
<meta name="viewport" content="interactive-widget=resizes-content" />
```

Safari doesn't support it yet. So I wanted to ask if supporting this setting is planned, and if yes, when is it expected to land?

Currently for [svedit.dev](https://svedit.dev) we have a "correction mechansim" to keep the toolbar visible, but it leads to flickering. `interactive-widget=resizes-content` would be a much better solution.

https://github.com/user-attachments/assets/ddcef564-b2ab-4aac-9e92-90202d391aa7

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/549
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/549@github.com>
Aquileo | [w3c/editing] Safari: incorrect keyboard state (Issue #548)Johannes Wilmnotifications@github.commid:w3c/editing/issues/548@github.com2026-08-13T11:50:40+00:00
johanneswilm created an issue (w3c/editing#548)

ProseMirror developer reports:

> Moving the selection via the JavaScript selection API or adding content next to the cursor will not update the virtual keyboard's autocapitalize state. This makes life very hard for editors that do a lot of scripting, or handle some user actions in custom ways through keydown handlers, since the user will often get an unexpected/incorrect keyboard state.
> A  big has been filed years ago:
> https://bugs.webkit.org/show_bug.cgi?id=236937

Question: Is this perceived as a bug (which will be fixed) or is this just expected/accepted behavior?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/548
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/548@github.com>
Aquileo | [w3c/editing] Safari: incorrect keyboard state (Issue #548)Johannes Wilmnotifications@github.commid:w3c/editing/issues/548@github.com2026-08-13T11:50:40+00:00
johanneswilm created an issue (w3c/editing#548)

ProseMirror developer reports:

> Moving the selection via the JavaScript selection API or adding content next to the cursor will not update the virtual keyboard's autocapitalize state. This makes life very hard for editors that do a lot of scripting, or handle some user actions in custom ways through keydown handlers, since the user will often get an unexpected/incorrect keyboard state.
> A  big has been filed years ago:
> https://bugs.webkit.org/show_bug.cgi?id=236937

Question: Is this perceived as a bug (which will be fixed) or is this just expected/accepted behavior?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/548
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/548@github.com>
Aquileo | Re: [w3c/editing] Inconsistent `KeyboardEvent.shiftKey` behavior for virtual keyboard autocapitalization (Issue #542)Johannes Wilmnotifications@github.commid:w3c/editing/issues/542/5279822659@github.com2026-08-13T11:30:31+00:00
johanneswilm left a comment (w3c/editing#542)

Call 2026-07-09:

> Michael Aufreiter described the issue as using modifier keys, such as 
Shift+Enter, on mobile virtual keyboards. On iOS, auto-capitalization 
can cause the Shift modifier to appear even when the user did not 
explicitly press it, while Android behaves differently. As a result, 
editors cannot reliably use modifier keys on mobile.
Wenson Hsieh explained that, on iOS, auto-capitalization is intended to 
be handled transparently by the system, and modifier key combinations 
are not part of the platform's interaction model. He suggested that the 
VirtualKeyboard API may be a better way to detect when a software 
keyboard is in use.
Michael agreed that editor developers should likely avoid relying on 
modifier keys on mobile and instead use platform-appropriate UI or the 
VirtualKeyboard API where available.
Dan Clark suggested documenting this behavior as non-normative guidance 
for developers.
Olli Pettay noted that the UI Events specification is currently being 
split into smaller specifications, but agreed that an issue could still 
be filed there.
Action: Michael will file an issue in the UI Events repository proposing 
guidance that modifier keys should not be relied upon on mobile 
platforms.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/542#issuecomment-5279822659
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/542/5279822659@github.com>
Aquileo | Re: [w3c/editing] Inconsistent `KeyboardEvent.shiftKey` behavior for virtual keyboard autocapitalization (Issue #542)Johannes Wilmnotifications@github.commid:w3c/editing/issues/542/5279822659@github.com2026-08-13T11:30:31+00:00
johanneswilm left a comment (w3c/editing#542)

Call 2026-07-09:

> Michael Aufreiter described the issue as using modifier keys, such as 
Shift+Enter, on mobile virtual keyboards. On iOS, auto-capitalization 
can cause the Shift modifier to appear even when the user did not 
explicitly press it, while Android behaves differently. As a result, 
editors cannot reliably use modifier keys on mobile.
Wenson Hsieh explained that, on iOS, auto-capitalization is intended to 
be handled transparently by the system, and modifier key combinations 
are not part of the platform's interaction model. He suggested that the 
VirtualKeyboard API may be a better way to detect when a software 
keyboard is in use.
Michael agreed that editor developers should likely avoid relying on 
modifier keys on mobile and instead use platform-appropriate UI or the 
VirtualKeyboard API where available.
Dan Clark suggested documenting this behavior as non-normative guidance 
for developers.
Olli Pettay noted that the UI Events specification is currently being 
split into smaller specifications, but agreed that an issue could still 
be filed there.
Action: Michael will file an issue in the UI Events repository proposing 
guidance that modifier keys should not be relied upon on mobile 
platforms.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/542#issuecomment-5279822659
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/542/5279822659@github.com>
Aquileo | Re: [w3c/editing] Inconsistent `KeyboardEvent.shiftKey` behavior for virtual keyboard autocapitalization (Issue #542)Johannes Wilmnotifications@github.commid:w3c/editing/issues/542/5279822659@github.com2026-08-13T11:30:31+00:00
johanneswilm left a comment (w3c/editing#542)

Call 2026-07-09:

> Michael Aufreiter described the issue as using modifier keys, such as 
Shift+Enter, on mobile virtual keyboards. On iOS, auto-capitalization 
can cause the Shift modifier to appear even when the user did not 
explicitly press it, while Android behaves differently. As a result, 
editors cannot reliably use modifier keys on mobile.
Wenson Hsieh explained that, on iOS, auto-capitalization is intended to 
be handled transparently by the system, and modifier key combinations 
are not part of the platform's interaction model. He suggested that the 
VirtualKeyboard API may be a better way to detect when a software 
keyboard is in use.
Michael agreed that editor developers should likely avoid relying on 
modifier keys on mobile and instead use platform-appropriate UI or the 
VirtualKeyboard API where available.
Dan Clark suggested documenting this behavior as non-normative guidance 
for developers.
Olli Pettay noted that the UI Events specification is currently being 
split into smaller specifications, but agreed that an issue could still 
be filed there.
Action: Michael will file an issue in the UI Events repository proposing 
guidance that modifier keys should not be relied upon on mobile 
platforms.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/542#issuecomment-5279822659
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/542/5279822659@github.com>
Aquileo | Re: [w3c/editing] Chrome: Selection barrier at details element when contenteditable=true (Issue #538)Johannes Wilmnotifications@github.commid:w3c/editing/issues/538/5279813752@github.com2026-08-13T11:29:31+00:00
johanneswilm left a comment (w3c/editing#538)

Call 2026-07-09:

> Michael Aufreiter described the issue where, in Chromium-based browsers, 
\<details\> elements create a selection boundary that prevents users from 
selecting text across the element. He noted that other browsers do not 
exhibit this behavior.
He mentioned that he has a reproducible test case and will add a link to 
it in the issue.
Michael asked whether this behavior is unintended and, if so, whether it 
should be treated as a browser bug, as it causes usability issues for 
web-based editors.
Dan Clark agreed that the behavior appears to be a Chromium bug and 
recommended filing an issue in the Chromium bug tracker.
Olli Pettay suggested removing the agenda+ label from the issue and 
adding a comment indicating that the next step is to follow up with 
Chromium.
Michael agreed and filed the Chromium bug 
https://issues.chromium.org/issues/533026453.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/538#issuecomment-5279813752
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/538/5279813752@github.com>
Aquileo | Re: [w3c/editing] Ability to rollback changes after IME, so that editors that manage their own incremental rendering can assume the same DOM as before the IME (Issue #510)Johannes Wilmnotifications@github.commid:w3c/editing/issues/510/5279794930@github.com2026-08-13T11:27:30+00:00
johanneswilm left a comment (w3c/editing#510)

Call 2026-07-09:

> Michael Aufreiter provided an update. After experimenting with the 
EditContext API, he found that it addresses the issue well. Since 
EditContext is expected to gain cross-browser support over time, he 
suggested focusing on that approach rather than continuing to pursue a 
solution based on contenteditable.
Dan Clark agreed, noting that the "manual mode for contenteditable" 
discussed in the issue is effectively what EditContext provides.
Michael also shared observations from following the Wordgard editor's 
development. The project has largely switched to using Input Events, 
with IME composition remaining the primary area that still requires DOM 
mutation observation.
He noted that, from an editor developer's perspective, completing 
support for IME through EditContext is one of the last major pieces 
needed and should be considered a high priority.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/510#issuecomment-5279794930
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/510/5279794930@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: [HTML] html-in-canvas (Issue #1204)Matthew Tylee Atkinsonnotifications@github.commid:w3ctag/design-reviews/issues/1204/5278762405@github.com2026-08-13T09:53:34+00:00
matatk left a comment (w3ctag/design-reviews#1204)

We are very supportive of the goals of this proposal, which is well written. It's good to see privacy considerations addressed. But the proposal requires more work.

This is just initial feedback, which has three parts: (1) specific questions; (2) general concerns around accessibility; and (3) some thoughts on how this may address concerns we have with other proposals.

# Specifics

1. What changes can trigger the paint event? The explainer says when "any canvas children has changed" but then claims "changing the transform does not cause the paint event to fire". This sounds handwavy to me, for example:

   - What if the transform on a non-direct descendant changes?

   - What if the scroll offset of a descendant changes?

   - What about another canvas? This might lead to a ton of other issues though

   - And there might be an interop risk. For certain types of changes, a UA implementation may keep them completely off the main thread, and doesn't even run update the rendering steps for them. Examples include:

     - Video

     - Animated images

     - A blinking caret (as in the basic example)

2. Maintaining the interactability of the child elements seems to be a goal of this proposal, according to:

   > Browser features like hit testing, intersection observer, and accessibility rely on an element's DOM location. To ensure these work, the element's transform property should be updated so that the DOM location matches the drawn location.

   This looks very hacky and is probably not enough. For example:

   - What if the canvas has multiple child elements whose `drawElementImage()` calls are not in the DOM order? This might mess up hit testing even with their `transform` property updated to match the drawn location.

   - What if the same child element is drawn for multiple times?

   We'd like to see a more holistic solution.

3. Bikeshed idea: the naming of the `paint` event. It sounds too general while its actual meaning is element image changed.

# Some accessibility concerns

We are still looking into the various threads relating to the accessibility of the proposal. The overall goal and direction are very welcome.

We note that there are some significant unresolved issues that could quite significantly alter the accessibility of the end result, the way that the UA and AT need to work, and the DX.

One example is https://github.com/WICG/html-in-canvas/issues/134 but there are others too. We will come back with further feedback on this and other issues, as appropriate, in due course.

# Some possible wins over concerns raised in other proposals

There has been a lot of work done on rendering decorative text in the canvas, i.e. https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1095

We were [not satisfied with the canvas text metrics proposal](https://github.com/w3ctag/design-reviews/issues/1095#issuecomment-3872160989), because it introduces at first a complex, imperative API that requires the developer to implement accessibility themselves. We would've preferred to see, as is common on the platform, a simpler, declarative API, that has accessibility built in, come along first, so that most developers can just use that.

We felt that it would be possible to add such a simple declarative API as part of the HTML-in-canvas work. What do you think? This could solve an accessibility barrier whilst supporting more artistic uses of the canvas.

There have been two recent developments in this area, which we're looking at:

* A proposal to make text drawing in canvas accessible by exposing the drawn text to AT - there are significant concerns with this (it would be very noisy and potentially unreliable for AT users).

* [An update to the Text Metrics proposal was shared at a WHATNOT meeting](https://github.com/whatwg/html/issues/10677#issuecomment-4847744218). We're not yet aware of what's changed, but are looking into it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1204#issuecomment-5278762405
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1204/5278762405@github.com>
Aquileo | [w3c/uievents-key] TPAC 2026 Status Report (Issue #70)Léonie Watsonnotifications@github.commid:w3c/uievents-key/issues/70@github.com2026-08-13T06:13:35+00:00
LJWatson created an issue (w3c/uievents-key#70)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents-key/issues/70
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents-key/issues/70@github.com>
Aquileo | [w3c/uievents-key] TPAC 2026 Status Report (Issue #70)Léonie Watsonnotifications@github.commid:w3c/uievents-key/issues/70@github.com2026-08-13T06:13:35+00:00
LJWatson created an issue (w3c/uievents-key#70)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents-key/issues/70
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents-key/issues/70@github.com>
Aquileo | [w3c/uievents-key] TPAC 2026 Status Report (Issue #70)Léonie Watsonnotifications@github.commid:w3c/uievents-key/issues/70@github.com2026-08-13T06:13:35+00:00
LJWatson created an issue (w3c/uievents-key#70)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents-key/issues/70
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents-key/issues/70@github.com>
Aquileo | [w3c/uievents-code] TPAC 2026 Status Report (Issue #45)Léonie Watsonnotifications@github.commid:w3c/uievents-code/issues/45@github.com2026-08-13T06:11:51+00:00
LJWatson created an issue (w3c/uievents-code#45)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents-code/issues/45
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents-code/issues/45@github.com>
Aquileo | [w3c/uievents] TPAC 2026 Status Report (Issue #418)Léonie Watsonnotifications@github.commid:w3c/uievents/issues/418@github.com2026-08-13T06:11:03+00:00
LJWatson created an issue (w3c/uievents#418)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/418
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/issues/418@github.com>
Aquileo | [w3c/manifest] TPAC 2026 Status Report (Issue #1240)Léonie Watsonnotifications@github.commid:w3c/manifest/issues/1240@github.com2026-08-13T06:09:15+00:00
LJWatson created an issue (w3c/manifest#1240)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1240
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1240@github.com>
Aquileo | [w3c/screen-orientation] TPAC 2026 Status Report (Issue #282)Léonie Watsonnotifications@github.commid:w3c/screen-orientation/issues/282@github.com2026-08-13T06:07:31+00:00
LJWatson created an issue (w3c/screen-orientation#282)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/screen-orientation/issues/282
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/issues/282@github.com>
Aquileo | [w3c/push-api] TPAC 2026 Status Report (Issue #418)Léonie Watsonnotifications@github.commid:w3c/push-api/issues/418@github.com2026-08-13T06:06:26+00:00
LJWatson created an issue (w3c/push-api#418)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/418
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/issues/418@github.com>
Aquileo | [w3c/pointerlock] TPAC 2026 Status Report (Issue #111)Léonie Watsonnotifications@github.commid:w3c/pointerlock/issues/111@github.com2026-08-13T06:05:39+00:00
LJWatson created an issue (w3c/pointerlock#111)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/111
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/pointerlock/issues/111@github.com>
Aquileo | [w3c/ServiceWorker] TPAC 2026 Status Report (Issue #1845)Léonie Watsonnotifications@github.commid:w3c/ServiceWorker/issues/1845@github.com2026-08-13T06:03:49+00:00
LJWatson created an issue (w3c/ServiceWorker#1845)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1845
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1845@github.com>
Aquileo | [w3c/IndexedDB] TPAC 2026 Status Report (Issue #500)Léonie Watsonnotifications@github.commid:w3c/IndexedDB/issues/500@github.com2026-08-13T06:02:09+00:00
LJWatson created an issue (w3c/IndexedDB#500)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/500
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/500@github.com>
Aquileo | [w3c/gamepad] TPAC 2026 Status Report (Issue #232)Léonie Watsonnotifications@github.commid:w3c/gamepad/issues/232@github.com2026-08-13T05:59:50+00:00
LJWatson created an issue (w3c/gamepad#232)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/232
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/232@github.com>
Aquileo | [w3c/FileAPI] TPAC 2026 Status Report (Issue #224)Léonie Watsonnotifications@github.commid:w3c/FileAPI/issues/224@github.com2026-08-13T05:58:11+00:00
LJWatson created an issue (w3c/FileAPI#224)

Editors, [TPAC 2026](https://www.w3.org/news-events/tpac/2026/) is in Dublin and online, from 26 to 30 October.

[WebApps will meet](https://www.w3.org/news-events/tpac/2026/schedule/) on Monday 26 and Tuesday 27 October, with a joint meeting with the Devices and Sensors WG on Thursday 29 October.

We need you to do two things before 30 September 2026:

1. Add the **`TPAC2026`** label to any issues you want to discuss with the WG
2. Post a spec status report as a comment on this issue

Your status report should answer these questions:

1. What progress have you made on your spec in the last 12 months?
2. What blockers, if any, are preventing you from progressing your spec to CR or Req?
3. Is there a testing plan for your spec?
4. What are the next steps for your spec and do you need any help?

**Note:** post a status report even if you **will not** be at TPAC. Thank you.

@LJWatson, @marcoscaceres, and @mkruisselbrink.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/224
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/issues/224@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Filterable select (Issue #1264)Joey Arharnotifications@github.commid:w3ctag/design-reviews/issues/1264@github.com2026-08-12T20:41:56+00:00
josepharhar created an issue (w3ctag/design-reviews#1264)

### Explainer

https://open-ui.org/components/filterable-select.explainer/

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/openui/open-ui
- Primary contacts:
  - Joey Arhar @josepharhar Google
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - https://github.com/openui/open-ui
  - https://github.com/whatwg/html/issues/12050
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: We are proposing this feature
  - Mozilla comments: none
  - WebKit comments: Some feedback in https://github.com/whatwg/html/issues/12050
  - https://x.com/JosephArhar/status/2077060267192799277
  - https://bsky.app/profile/josepharhar.bsky.social/post/3mqmlaapxts26
- Major unresolved issues with or opposition to this design:

### You should also know that...

We still need to choose one of the API shape options, but the HTML parser changes in option B are opposed by developers and participants of OpenUI

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1264


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1264
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1264@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Filterable select (Issue #1264)Joey Arharnotifications@github.commid:w3ctag/design-reviews/issues/1264@github.com2026-08-12T20:41:56+00:00
josepharhar created an issue (w3ctag/design-reviews#1264)

### Explainer

https://open-ui.org/components/filterable-select.explainer/

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/openui/open-ui
- Primary contacts:
  - Joey Arhar @josepharhar Google
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - https://github.com/openui/open-ui
  - https://github.com/whatwg/html/issues/12050
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: We are proposing this feature
  - Mozilla comments: none
  - WebKit comments: Some feedback in https://github.com/whatwg/html/issues/12050
  - https://x.com/JosephArhar/status/2077060267192799277
  - https://bsky.app/profile/josepharhar.bsky.social/post/3mqmlaapxts26
- Major unresolved issues with or opposition to this design:

### You should also know that...

We still need to choose one of the API shape options, but the HTML parser changes in option B are opposed by developers and participants of OpenUI

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1264


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1264
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1264@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Filterable select (Issue #1264)Joey Arharnotifications@github.commid:w3ctag/design-reviews/issues/1264@github.com2026-08-12T20:41:56+00:00
josepharhar created an issue (w3ctag/design-reviews#1264)

### Explainer

https://open-ui.org/components/filterable-select.explainer/

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/openui/open-ui
- Primary contacts:
  - Joey Arhar @josepharhar Google
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - https://github.com/openui/open-ui
  - https://github.com/whatwg/html/issues/12050
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: We are proposing this feature
  - Mozilla comments: none
  - WebKit comments: Some feedback in https://github.com/whatwg/html/issues/12050
  - https://x.com/JosephArhar/status/2077060267192799277
  - https://bsky.app/profile/josepharhar.bsky.social/post/3mqmlaapxts26
- Major unresolved issues with or opposition to this design:

### You should also know that...

We still need to choose one of the API shape options, but the HTML parser changes in option B are opposed by developers and participants of OpenUI

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1264


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1264
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1264@github.com>
Aquileo | [whatwg/fetch] Fetch Posture (Issue #1946)James M Snellnotifications@github.commid:whatwg/fetch/issues/1946@github.com2026-08-12T18:31:49+00:00
jasnell created an issue (whatwg/fetch#1946)

### What is the issue with the Fetch Standard?

## Problem

Fetch's design reflects the security and implementation constraints of web browsers. This model produces constraints throughout the spec:

* Forbidden request-headers prevent scripts from spoofing `Origin`, `Cookie`, `Host`, `Referer`, and other headers the browser must control.
* Forbidden response-header names prevent scripts from reading `Set-Cookie` to protect the `HttpOnly` cookie boundary.
* CORS mediates cross-origin access, including preflight, response filtering (opaque/CORS filtered responses), and response tainting.
* Request modes (`no-cors`, `cors`, `same-origin`, `navigate`) gate behavior based on the browser's origin model.
* Headers guards (`request`, `request-no-cors`, `response`, `immutable`) enforce header restrictions at the API level.
* Service workers, CSP, COEP/CORP, mixed content, referrer policy, and deferred fetch/fetchLater are browser-specific mechanisms threaded through the core algorithms.

Non-browser JavaScript runtimes have adopted the Fetch API (`fetch()`, `Request`, `Response`, `Headers`) as a standard HTTP client and server interface. These runtimes operate in a different trust model:

* The sandboxing constraints differ from browsers. Some runtimes (e.g. Workers) do sandbox untrusted code, but under a different security model with different requirements. Other runtimes do not sandbox at all.
* There is no single global user. Browsers act on behalf of one user whose credentials (cookies, client certs) are attached to outgoing requests automatically. Server-side runtimes typically handle requests from many users and manage credentials per-request.
* There is no browser cookie jar. Cookie management is the application's responsibility.
* There is no same-origin policy. The application controls all outbound requests.
* There are no service workers intercepting fetches.
* There is no document, navigable, or browsing context.

These other runtimes have independently diverged from the fetch spec by relaxing forbidden headers, ignoring CORS, and stripping navigation-related properties. The divergence is largely undocumented and inconsistent between runtimes. Code that moves between runtimes encounters subtle incompatibilities, and none of these runtimes can claim Fetch spec conformance despite implementing substantial parts of the spec correctly.

## Proposal: Posture

A **posture** is a property of the environment in which `fetch()` is invoked.

It is effectively a conformance profile.

The fetch posture can be one of:

- `'sandboxed'`: The current (default) posture. The environment enforces the browser's multi-origin sandboxing model. All existing spec behavior applies unchanged.
- `'unrestricted'`: The environment does not enforce multi-origin sandboxing. Browser-specific restrictions are relaxed as described below.

(we can bikeshed the names..)

The posture is simply a constant internal property of the runtime. It is **not** a new API or configurable option.

The default posture is `'sandboxed'`. This means:

* Existing spec text does not need to be updated to say "if sandboxed, do X." The existing text *is* the sandboxed behavior by default.
* Only the `'unrestricted'` deviations need explicit annotation, using language like:

  > If the **fetch posture** is `'unrestricted'`, skip this step.

* Browser implementations remain fully compliant (or as compliant as they already are) **without any changes**.

Bottom line: The `'sandboxed'` posture is the spec as it exists today.

The spec **only needs** new conditional text at the specific points where `'unrestricted'` behavior diverges. If you don't support the `'unrestricted'` posture, you ignore those branches.

## What changes in `'unrestricted'` posture

### No forbidden Request-headers

In `'unrestricted'` posture, no request-headers are forbidden. The `forbidden request-header` algorithm returns false for all headers.

Spec change: In the definition of "forbidden request-header" (2.2.2), add a short-circuit:

> A header (*name*, *value*) is a **forbidden request-header** if the following conditions
> are true:
>
> 1. If the **fetch posture** is `'unrestricted'`, return false.
> 2. [existing conditions]

**API impact:**
- `Headers.validate()` step 3 becomes a no-op (guard `'request'` never blocks).
- The `'request-no-cors'` guard becomes equivalent to `'request'` (but see 4.3).
- `Cookie`, `Cookie2`, `Origin`, `Host`, `Referer`, `Set-Cookie` and all others can be freely set on outgoing requests.
- The method-override smuggling check (`X-HTTP-Method`, etc.) also becomes a no-op.

### No forbidden Response-headers

In `'unrestricted'` posture, no response-heades are forbidden. `Set-Cookie` and `Set-Cookie2` are visible on response headers.

**Spec changes:**
- In "forbidden response-header name" (2.2.2): gate the definition on sandboxed posture.
- In "basic filtered response" (2.2.6): do not strip forbidden response-header names in
  unrestricted posture (or, more precisely, the set is empty, so there is nothing to strip).
- `Headers.validate()` step 4 becomes a no-op (guard `'response'` never blocks).

### CORS is bypassed

In `'unrestricted'` posture, the CORS protocol is not enforced. All requests are treated as if they are same-origin for the purposes of response tainting and filtering.

**Spec changes:** In **main fetch** (4.1), the response tainting decision tree changes:

- Response tainting is always `'basic'` in unrestricted posture.
- The response is always a **basic filtered response** (never CORS-filtered or opaque).
- CORS preflight is never triggered.
- The CORS check algorithm is never invoked.
- `Access-Control-*` response headers are not processed for filtering purposes (though they remain visible as ordinary headers on the response).

**API impact:**
- `Response.type` is always `'default'` or `'error'` (never `'cors'`, `'opaque'`, or `'opaqueredirect'`).
- Redirected responses are fully visible (not opaque-redirect filtered).
- The `redirect: "manual"` option returns a full, non-opaque redirect response with its actual status (3xx), headers (including `Location`), and body visible. In sandboxed posture, this produces an opaque-redirect filtered response per "Atomic HTTP redirect handling," a security measure to prevent scripts from observing redirect targets. This concern does not apply in unrestricted posture. The `Response.type` for a manually-intercepted redirect is `'default'`.

### Request modes are simplified

In `'unrestricted'` posture:

- `RequestInit.mode` is silently ignored. The internal request mode is effectively always `'cors'` in the sense that no CORS-safelisted restrictions are applied, but the CORS *enforcement* is bypassed.
- `RequestInit.credentials` is silently ignored. Credentials mode has no meaning without a cookie jar and CORS enforcement.

**Browser-specific `Request` properties** (`mode`, `credentials`, `destination`, `referrer`, `referrerPolicy`, `keepalive`, `isReloadNavigation`, `isHistoryNavigation`) follow a **presence-optional, value-undefined** rule:

- Implementations MAY include these properties on the `Request` prototype, or MAY omit them.
- If a property IS present, its getter MUST return `undefined`.
- If a property is NOT present, accessing it returns `undefined` by normal JS semantics.

This avoids choosing between "absent" (breaks code that accesses without checking) and "present-but-fixed" (returns misleading values like `'cors'` for `mode`). Either way, `request.mode === "cors"` evaluates to `false`, and `request.mode === undefined` or `request.mode == null` evaluates to `true`. Code that needs to feature-detect can use `'mode' in request`, and code that doesn't check gets `undefined` rather than a misleading value.

The spec would express this as:

> The **mode** getter steps are: if the **fetch posture** is `'unrestricted'`, return undefined.
> Otherwise, [existing steps].

**Headers guard simplification:**
- The `'request-no-cors'` guard is never used (since `no-cors` mode is not meaningful).
- Headers guards reduce to: `'none'`, `'request'`, `'response'`, `'immutable'`.
- The `'request'` guard imposes no restrictions (since forbidden request-headers are empty).

### No forbidden methods

In `'unrestricted'` posture, there are no forbidden methods. The `Request` constructor does not throw for `CONNECT`, `TRACE`, or `TRACK`.

### Referrer and referrer policy are not applicable

In `'unrestricted'` posture:
- `RequestInit.referrer` and `RequestInit.referrerPolicy` are silently ignored.
- The "determine request's referrer" step in main fetch is skipped.
- No `Referer` header is automatically appended (the application may set it manually via the
  now-unrestricted headers).

### Service Worker Interception is not applicable

In `'unrestricted'` posture, the service worker interception block in HTTP fetch is skipped. The request's `service-workers mode` is effectively always `'none'`.

### Browser Security Policies are not applicable

In `'unrestricted'` posture, the following main fetch steps are skipped:

- "report Content Security Policy violations for request"
- "should request be blocked by Content Security Policy"
- "should fetching request be blocked as mixed content"
- "Upgrade a mixed content request to a potentially trustworthy URL"
- HSTS upgrade
- Cross-Origin Resource Policy (CORP) check
- "nosniff" MIME type blocking
- Cross-Origin-Embedder-Policy (COEP) checks

### Port Blocking is implementation-defined

In `'unrestricted'` posture, port blocking ("should be blocked due to a bad port") is implementation-defined. Runtimes MAY choose to block bad ports or not.

### `RequestInit.cache` default is implementation-defined

In `'unrestricted'` posture, the default value for `RequestInit.cache` is implementation-defined rather than `'default'`.

The browser's `'default'` cache mode implies interaction with the browser's HTTP cache, which non-browser runtimes typically do not have. Runtimes like Deno default to `'no-store'` or `'no-cache'`, while Cloudflare Workers has its own caching semantics. Rather than mandating a single default, the spec acknowledges that the appropriate default depends on the runtime's caching architecture. All valid `RequestInit.cache` values MUST be accepted without throwing; the runtime's actual caching behavior for each value is implementation-defined, but the corresponding `Cache-Control` request headers SHOULD be sent.

### Subresource Integrity is implementation-defined

In `'unrestricted'` posture, support for `RequestInit.integrity` is implementation-defined.

- Implementations MUST accept `undefined` and `''` (empty string) without throwing.
- If a non-empty integrity string is provided and the implementation does not support that integrity algorithm, it MUST throw (not silently ignore).
- Implementations MAY support any subset of integrity algorithms (including none beyond the empty string).

SRI is useful on the server (verifying downloaded artifacts, for instance) but is not universally needed. Making it implementation-defined allows runtimes to adopt it incrementally without being non-conformant.

### Keepalive body size limits are implementation-defined

In `'unrestricted'` posture, the keepalive body size limits enforced per fetch group in HTTP-network-or-cache fetch (4.6) are implementation-defined.

### fetchLater / Deferred Fetch are not available

`fetchLater()`, `FetchLaterResult`, `DeferredRequestInit`, and the entire deferred fetch infrastructure (4.12) are not applicable in `'unrestricted'` posture.

### Navigation-related Request properties are presence-optional, value-undefined

The following request properties are not meaningful in `'unrestricted'` posture and follow the **presence-optional, value-undefined** rule described in 4.4:

* `destination` (no document destinations)
* `referrer`, `referrerPolicy` (see 4.6)
* `isReloadNavigation`, `isHistoryNavigation`
* `keepalive` (tied to tab lifetime)
* `mode`, `credentials` (see 4.4)

Implementations SHOULD include these on the `Request` prototype but MAY omit them. If present, their getters MUST return `undefined`.

### `file:` URL Support is implementation-defined

In `'unrestricted'` posture, `fetch()` of `file:` URLs is implementation-defined. Runtimes MAY
support it. The spec does not define the behavior but acknowledges it as a valid extension point.

### Relative URL resolution is mplementation-Defined

In `'unrestricted'` posture, relative URL resolution in `fetch()` is implementation-defined. Runtimes have varying base URL semantics (CWD, module URL, explicit base).

## What does not change

Everything else that's not mentioned.

## Spec integration pattern

Since `'sandboxed'` is the default posture, existing spec text does not need to be wrapped in "if sandboxed" conditionals. Changes are only needed at the points where unrestricted behavior diverges, expressed as:

> If the **fetch posture** is `'unrestricted'`, skip this step.

or:

> If the **fetch posture** is `'unrestricted'`, [alternative behavior].

This keeps edits localized. The spec does not need a "if sandboxed, do X" conditional around every browser-specific step; those steps apply by default.

### Conformance statement

The spec's conformance section should include:

> A conformant implementation operates in one of two **fetch posture**:
>
> - **Sandboxed** (default): The implementation enforces the multi-origin sandboxing model.
>   All normative requirements apply as written. This is the conformance mode for web browsers.
>   Any algorithm step or requirement that does not reference the fetch posture assumes sandboxed.
> - **Unrestricted**: The implementation does not enforce the multi-origin sandboxing model.
>   Requirements that are explicitly conditioned on the unrestricted posture are modified or
>   skipped as specified. All other requirements apply as written.
>
> An implementation MUST NOT mix postures within a single environment (e.g., a runtime cannot
> enforce CORS for some requests and not others based on runtime conditions, unless it is
> implementing the sandboxed posture and using the spec's existing conditional mechanisms like
> request mode).

### WPT implications

Web Platform Tests would need a mechanism to test both modes. For unrestricted-posture tests:

- Tests that verify forbidden headers are rejected should have unrestricted-posture counterparts that verify they are accepted.
- Tests for CORS enforcement should have unrestricted-posture counterparts that verify CORS is not enforced.
- Tests for opaque/filtered responses should have counterparts verifying basic responses.

## Where is this coming from

I'm the one opening this issue but the proposal here is coming from the ECMA TC-55 / WinterTC, representing multiple Web compatible runtimes includes Node.js, Deno, Cloudflare Workers, etc. 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1946
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1946@github.com>
Aquileo | [w3ctag/design-reviews] WG New Spec: Verifiable Credential Barcodes v1.0 (Issue #1263)wes-smithnotifications@github.commid:w3ctag/design-reviews/issues/1263@github.com2026-08-12T15:23:22+00:00
wes-smith created an issue (w3ctag/design-reviews#1263)

### Specification

https://w3c.github.io/vc-barcodes/

### Explainer

https://w3c.github.io/vc-barcodes/#introduction

### Links

- The WG's request for this TAG review: https://www.w3.org/2026/08/12-vcwg-minutes.html#ResolutionSummary
- Previous early design review, if any: None
- An introduction to the feature, aimed at unfamiliar audiences: https://w3c.github.io/vc-barcodes/#introduction
- A description of the problems that end-users were facing before this proposal:https://w3c.github.io/vc-barcodes/#introduction (existing optical barcodes on security critical documents are often unprotected and trivially forged; there is no compact, non-proprietary way to prove authenticity, integrity and status of the printed data)
- Alternatives considered: Non-CBOR serializations of Verifiable Credentials were considered, but are incompatibly large with standard barcode size constraints.
- Examples of how to use the proposal to solve the end-users' problems: https://w3c.github.io/vc-barcodes/#test-vectors, https://w3c.github.io/vc-barcodes/#introductory-examples
- What do the end-users experience with this proposal: a verifier optically scans a barcode with trusted software and learns whether the data is authentic, unmodified, and (optionally) not revoked/suspended.
- User research you did to validate the problem and/or design, if any: Feedback and extensive discussion from production deployments (CA DMV) and pilot programs (DHS, US First Responders, US Vital Records)
- Test Suite:  N/A, will be created when transitioning into CR, expectations will be to follow existing pattern for VC test suites at https://w3c.github.io/vc-data-integrity/implementations/#test-suite-reports resulting in additions to the VC ecosystem conformance dashboard: https://canivc.com/

NOTE: The VCWG has volunteered to follow the new Threat Modelling approach championed by the Security IG, which largely replaces the traditional Security/Privacy Considerations section with a new Threat Model section: https://w3c.github.io/vc-barcodes/#threat-model and a more comprehensive Threat Model document: https://w3c.github.io/vc-barcodes/threat-model/

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/vc-barcodes/
- Primary contacts:
  - Wesley Smith (@wes-smith), Digital Bazaar, Editor/Author
  - Ivan Herman (@iherman), W3C, Staff Contact
  - Phil Archer (@philarcher), GS1, VCWG Chair
- Organization/project driving the specification: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- This work is being funded by: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- Primary standards group developing this feature: W3C Verifiable Credentials Working Group
- Incubation and standards groups that have discussed the design:
  - W3C Credentials Community Group, W3C JSON-LD Community Group, W3C JSON-LD Working Group, US Federal Agencies, Internet Identity Workshop, Rebooting the Web of Trust.


### Feedback so far

- Active horizontal reviews: https://github.com/w3c/vc-barcodes/issues/40
- Multi-stakeholder feedback:
  - See "Incubation and standards groups that have discussed the design" above and the meeting minutes here -- https://w3c.github.io/vc-wg/minutes/#bcdi
- Major unresolved issues with or opposition to this specification: No major unresolved issues
- Status/issue trackers for implementations: None yet


### You should also know that...

We are planning to enter Candidate Recommendation as soon as we have received horizontal reviews and responded to requests for changes. This is one of the reviews that is gating our entrance into Candidate Recommendation. Our goal is to enter Candidate Recommendation during W3C TPAC 2026.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1263


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1263
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1263@github.com>
Aquileo | [w3ctag/design-reviews] WG New Spec: Verifiable Credential Barcodes v1.0 (Issue #1263)wes-smithnotifications@github.commid:w3ctag/design-reviews/issues/1263@github.com2026-08-12T15:23:22+00:00
wes-smith created an issue (w3ctag/design-reviews#1263)

### Specification

https://w3c.github.io/vc-barcodes/

### Explainer

https://w3c.github.io/vc-barcodes/#introduction

### Links

- The WG's request for this TAG review: https://www.w3.org/2026/08/12-vcwg-minutes.html#ResolutionSummary
- Previous early design review, if any: None
- An introduction to the feature, aimed at unfamiliar audiences: https://w3c.github.io/vc-barcodes/#introduction
- A description of the problems that end-users were facing before this proposal:https://w3c.github.io/vc-barcodes/#introduction (existing optical barcodes on security critical documents are often unprotected and trivially forged; there is no compact, non-proprietary way to prove authenticity, integrity and status of the printed data)
- Alternatives considered: Non-CBOR serializations of Verifiable Credentials were considered, but are incompatibly large with standard barcode size constraints.
- Examples of how to use the proposal to solve the end-users' problems: https://w3c.github.io/vc-barcodes/#test-vectors, https://w3c.github.io/vc-barcodes/#introductory-examples
- What do the end-users experience with this proposal: a verifier optically scans a barcode with trusted software and learns whether the data is authentic, unmodified, and (optionally) not revoked/suspended.
- User research you did to validate the problem and/or design, if any: Feedback and extensive discussion from production deployments (CA DMV) and pilot programs (DHS, US First Responders, US Vital Records)
- Test Suite:  N/A, will be created when transitioning into CR, expectations will be to follow existing pattern for VC test suites at https://w3c.github.io/vc-data-integrity/implementations/#test-suite-reports resulting in additions to the VC ecosystem conformance dashboard: https://canivc.com/

NOTE: The VCWG has volunteered to follow the new Threat Modelling approach championed by the Security IG, which largely replaces the traditional Security/Privacy Considerations section with a new Threat Model section: https://w3c.github.io/vc-barcodes/#threat-model and a more comprehensive Threat Model document: https://w3c.github.io/vc-barcodes/threat-model/

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/vc-barcodes/
- Primary contacts:
  - Wesley Smith (@wes-smith), Digital Bazaar, Editor/Author
  - Ivan Herman (@iherman), W3C, Staff Contact
  - Phil Archer (@philarcher), GS1, VCWG Chair
- Organization/project driving the specification: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- This work is being funded by: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- Primary standards group developing this feature: W3C Verifiable Credentials Working Group
- Incubation and standards groups that have discussed the design:
  - W3C Credentials Community Group, W3C JSON-LD Community Group, W3C JSON-LD Working Group, US Federal Agencies, Internet Identity Workshop, Rebooting the Web of Trust.


### Feedback so far

- Active horizontal reviews: https://github.com/w3c/vc-barcodes/issues/40
- Multi-stakeholder feedback:
  - See "Incubation and standards groups that have discussed the design" above and the meeting minutes here -- https://w3c.github.io/vc-wg/minutes/#bcdi
- Major unresolved issues with or opposition to this specification: No major unresolved issues
- Status/issue trackers for implementations: None yet


### You should also know that...

We are planning to enter Candidate Recommendation as soon as we have received horizontal reviews and responded to requests for changes. This is one of the reviews that is gating our entrance into Candidate Recommendation. Our goal is to enter Candidate Recommendation during W3C TPAC 2026.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1263


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1263
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1263@github.com>
Aquileo | [w3ctag/design-reviews] WG New Spec: Verifiable Credential Barcodes v1.0 (Issue #1263)wes-smithnotifications@github.commid:w3ctag/design-reviews/issues/1263@github.com2026-08-12T15:23:22+00:00
wes-smith created an issue (w3ctag/design-reviews#1263)

### Specification

https://w3c.github.io/vc-barcodes/

### Explainer

https://w3c.github.io/vc-barcodes/#introduction

### Links

- The WG's request for this TAG review: https://www.w3.org/2026/08/12-vcwg-minutes.html#ResolutionSummary
- Previous early design review, if any: None
- An introduction to the feature, aimed at unfamiliar audiences: https://w3c.github.io/vc-barcodes/#introduction
- A description of the problems that end-users were facing before this proposal:https://w3c.github.io/vc-barcodes/#introduction (existing optical barcodes on security critical documents are often unprotected and trivially forged; there is no compact, non-proprietary way to prove authenticity, integrity and status of the printed data)
- Alternatives considered: Non-CBOR serializations of Verifiable Credentials were considered, but are incompatibly large with standard barcode size constraints.
- Examples of how to use the proposal to solve the end-users' problems: https://w3c.github.io/vc-barcodes/#test-vectors, https://w3c.github.io/vc-barcodes/#introductory-examples
- What do the end-users experience with this proposal: a verifier optically scans a barcode with trusted software and learns whether the data is authentic, unmodified, and (optionally) not revoked/suspended.
- User research you did to validate the problem and/or design, if any: Feedback and extensive discussion from production deployments (CA DMV) and pilot programs (DHS, US First Responders, US Vital Records)
- Test Suite:  N/A, will be created when transitioning into CR, expectations will be to follow existing pattern for VC test suites at https://w3c.github.io/vc-data-integrity/implementations/#test-suite-reports resulting in additions to the VC ecosystem conformance dashboard: https://canivc.com/

NOTE: The VCWG has volunteered to follow the new Threat Modelling approach championed by the Security IG, which largely replaces the traditional Security/Privacy Considerations section with a new Threat Model section: https://w3c.github.io/vc-barcodes/#threat-model and a more comprehensive Threat Model document: https://w3c.github.io/vc-barcodes/threat-model/

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/vc-barcodes/
- Primary contacts:
  - Wesley Smith (@wes-smith), Digital Bazaar, Editor/Author
  - Ivan Herman (@iherman), W3C, Staff Contact
  - Phil Archer (@philarcher), GS1, VCWG Chair
- Organization/project driving the specification: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- This work is being funded by: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- Primary standards group developing this feature: W3C Verifiable Credentials Working Group
- Incubation and standards groups that have discussed the design:
  - W3C Credentials Community Group, W3C JSON-LD Community Group, W3C JSON-LD Working Group, US Federal Agencies, Internet Identity Workshop, Rebooting the Web of Trust.


### Feedback so far

- Active horizontal reviews: https://github.com/w3c/vc-barcodes/issues/40
- Multi-stakeholder feedback:
  - See "Incubation and standards groups that have discussed the design" above and the meeting minutes here -- https://w3c.github.io/vc-wg/minutes/#bcdi
- Major unresolved issues with or opposition to this specification: No major unresolved issues
- Status/issue trackers for implementations: None yet


### You should also know that...

We are planning to enter Candidate Recommendation as soon as we have received horizontal reviews and responded to requests for changes. This is one of the reviews that is gating our entrance into Candidate Recommendation. Our goal is to enter Candidate Recommendation during W3C TPAC 2026.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1263


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1263
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1263@github.com>
Aquileo | [w3ctag/design-reviews] WG New Spec: Verifiable Credential Barcodes v1.0 (Issue #1263)wes-smithnotifications@github.commid:w3ctag/design-reviews/issues/1263@github.com2026-08-12T15:23:22+00:00
wes-smith created an issue (w3ctag/design-reviews#1263)

### Specification

https://w3c.github.io/vc-barcodes/

### Explainer

https://w3c.github.io/vc-barcodes/#introduction

### Links

- The WG's request for this TAG review: https://www.w3.org/2026/08/12-vcwg-minutes.html#ResolutionSummary
- Previous early design review, if any: None
- An introduction to the feature, aimed at unfamiliar audiences: https://w3c.github.io/vc-barcodes/#introduction
- A description of the problems that end-users were facing before this proposal:https://w3c.github.io/vc-barcodes/#introduction (existing optical barcodes on security critical documents are often unprotected and trivially forged; there is no compact, non-proprietary way to prove authenticity, integrity and status of the printed data)
- Alternatives considered: Non-CBOR serializations of Verifiable Credentials were considered, but are incompatibly large with standard barcode size constraints.
- Examples of how to use the proposal to solve the end-users' problems: https://w3c.github.io/vc-barcodes/#test-vectors, https://w3c.github.io/vc-barcodes/#introductory-examples
- What do the end-users experience with this proposal: a verifier optically scans a barcode with trusted software and learns whether the data is authentic, unmodified, and (optionally) not revoked/suspended.
- User research you did to validate the problem and/or design, if any: Feedback and extensive discussion from production deployments (CA DMV) and pilot programs (DHS, US First Responders, US Vital Records)
- Test Suite:  N/A, will be created when transitioning into CR, expectations will be to follow existing pattern for VC test suites at https://w3c.github.io/vc-data-integrity/implementations/#test-suite-reports resulting in additions to the VC ecosystem conformance dashboard: https://canivc.com/

NOTE: The VCWG has volunteered to follow the new Threat Modelling approach championed by the Security IG, which largely replaces the traditional Security/Privacy Considerations section with a new Threat Model section: https://w3c.github.io/vc-barcodes/#threat-model and a more comprehensive Threat Model document: https://w3c.github.io/vc-barcodes/threat-model/

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/w3c/vc-barcodes/
- Primary contacts:
  - Wesley Smith (@wes-smith), Digital Bazaar, Editor/Author
  - Ivan Herman (@iherman), W3C, Staff Contact
  - Phil Archer (@philarcher), GS1, VCWG Chair
- Organization/project driving the specification: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- This work is being funded by: CA DMV, National Association of Convenience Stores, DHS Silicon Valley Innovation Project, Conexxus, US First Responders, US Vital Records
- Primary standards group developing this feature: W3C Verifiable Credentials Working Group
- Incubation and standards groups that have discussed the design:
  - W3C Credentials Community Group, W3C JSON-LD Community Group, W3C JSON-LD Working Group, US Federal Agencies, Internet Identity Workshop, Rebooting the Web of Trust.


### Feedback so far

- Active horizontal reviews: https://github.com/w3c/vc-barcodes/issues/40
- Multi-stakeholder feedback:
  - See "Incubation and standards groups that have discussed the design" above and the meeting minutes here -- https://w3c.github.io/vc-wg/minutes/#bcdi
- Major unresolved issues with or opposition to this specification: No major unresolved issues
- Status/issue trackers for implementations: None yet


### You should also know that...

We are planning to enter Candidate Recommendation as soon as we have received horizontal reviews and responded to requests for changes. This is one of the reviews that is gating our entrance into Candidate Recommendation. Our goal is to enter Candidate Recommendation during W3C TPAC 2026.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1263


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1263
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1263@github.com>
Aquileo | Re: [w3c/uievents] Add .pseudoTarget property to selected event types (PR #413)smaug----notifications@github.commid:w3c/uievents/pull/413/c5267887945@github.com2026-08-12T14:05:19+00:00
smaug---- left a comment (w3c/uievents#413)

Hmm, I'm not sure about the state of this. Do I need to review still something. I thought I was fine with this

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/pull/413#issuecomment-5267887945
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/pull/413/c5267887945@github.com>
Aquileo | Re: [w3c/uievents] Add .pseudoTarget property to selected event types (PR #413)smaug----notifications@github.commid:w3c/uievents/pull/413/c5267887945@github.com2026-08-12T14:05:19+00:00
smaug---- left a comment (w3c/uievents#413)

Hmm, I'm not sure about the state of this. Do I need to review still something. I thought I was fine with this

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/pull/413#issuecomment-5267887945
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/uievents/pull/413/c5267887945@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task in NavigationPreloadManager (PR #1834)Yoshisato Yanagisawanotifications@github.commid:w3c/ServiceWorker/pull/1834/review/4915310972@github.com2026-08-12T10:05:25+00:00
@yoshisatoyanagisawa approved this pull request.

lgtm



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1834#pullrequestreview-4915310972
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1834/review/4915310972@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: JS Self-Profiling Markers (ProfilerSample.marker) (Issue #1251)Brian Kardellnotifications@github.commid:w3ctag/design-reviews/issues/1251/5260780793@github.com2026-08-12T00:51:49+00:00
bkardell left a comment (w3ctag/design-reviews#1251)

@monica-ch can you say more about the plan for a Chromium Origin Trial? Is there already an issue/intent?  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1251#issuecomment-5260780793
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1251/5260780793@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: JS Self-Profiling Markers (ProfilerSample.marker) (Issue #1251)Brian Kardellnotifications@github.commid:w3ctag/design-reviews/issues/1251/5260780793@github.com2026-08-12T00:51:49+00:00
bkardell left a comment (w3ctag/design-reviews#1251)

@monica-ch can you say more about the plan for a Chromium Origin Trial? Is there already an issue/intent?  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1251#issuecomment-5260780793
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1251/5260780793@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: JS Self-Profiling Markers (ProfilerSample.marker) (Issue #1251)Brian Kardellnotifications@github.commid:w3ctag/design-reviews/issues/1251/5260780793@github.com2026-08-12T00:51:49+00:00
bkardell left a comment (w3ctag/design-reviews#1251)

@monica-ch can you say more about the plan for a Chromium Origin Trial? Is there already an issue/intent?  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1251#issuecomment-5260780793
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1251/5260780793@github.com>
Aquileo | Re: [w3ctag/design-reviews] Other Spec Review: JS Self-Profiling Markers (ProfilerSample.marker) (Issue #1251)Brian Kardellnotifications@github.commid:w3ctag/design-reviews/issues/1251/5260780793@github.com2026-08-12T00:51:49+00:00
bkardell left a comment (w3ctag/design-reviews#1251)

@monica-ch can you say more about the plan for a Chromium Origin Trial? Is there already an issue/intent?  

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1251#issuecomment-5260780793
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1251/5260780793@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1262)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1262@github.com2026-08-11T19:45:07+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1262)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1262


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1262
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1262@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1261)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1261@github.com2026-08-11T19:45:06+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1261)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1261


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1261
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1261@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1260)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1260@github.com2026-08-11T19:45:02+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1260)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1260


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1260
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1260@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1258)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1258@github.com2026-08-11T19:45:00+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1258)

### Specification

https://

### Explainer

https://

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous review, and fill in links to
 describe that feature. For small changes, these may all be included
 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [ ] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1258


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1258
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1258@github.com>
Aquileo | [w3ctag/design-reviews] WG Revision: (Issue #1257)Sargar Rajnotifications@github.commid:w3ctag/design-reviews/issues/1257@github.com2026-08-11T19:44:57+00:00
sargarsargar24-debug created an issue (w3ctag/design-reviews#1257)

### Specification

https://Gallery Lock all video active

### Explainer

https://# Dependabot update pull requests no longer generated  Dependabot can pause updates based on your interaction with Dependabot pull requests. Learn more about the automatic deactivation of Dependabot updates.  * When maintainers of a repository stop interacting with Dependabot pull requests, Dependabot temporarily pauses its updates and lets you know.  * Dependabot stops rebasing pull requests for version and security updates after 30 days, reducing notifications for inactive Dependabot pull requests.  ## About automatic deactivation of Dependabot updates  Dependabot pauses updates on your repositories, based on your interaction with pull requests from Dependabot updates. When Dependabot automatically deactivates Dependabot updates, there is:  * No creation of pull requests for version and security updates. * No rebasing of Dependabot pull requests for inactive repositories.  >[!NOTE] The automatic deactivation of Dependabot updates only applies to repositories where Dependabot has opened pull requests but the pull requests remain untouched. If Dependabot hasn't opened any pull requests, Dependabot will never become paused.  An active repository is a repository where a user (**not** Dependabot) has taken **any** of the following actions in the last 90 days:  * Merged or closed a Dependabot pull request on the repository. * Made a change to the `dependabot.yml` file for the repository. * Manually triggered a security update or a version update. * Enabled Dependabot security updates for the repository. * Used `@dependabot` commands on pull requests.  An inactive repository is a repository:  * That has at least one Dependabot pull request open for more than 90 days, * That has been enabled for the full period, and * Where none of the actions listed above has been taken by a user.  ## How to know if Dependabot updates are paused  When Dependabot is paused, GitHub adds a banner notice: * To all open Dependabot pull requests. * To the UI of the **Settings** tab of the repository (under **Advanced Security**, then **Dependabot**). * To the list of Dependabot alerts (if Dependabot security updates are affected).  ## About automatic reactivation of Dependabot updates  As soon as someone interacts with a Dependabot pull request again, Dependabot will unpause itself: * Security updates are automatically resumed for Dependabot alerts. * Version updates are automatically resumed with the schedule specified in the `dependabot.yml` file.

### Links

- The WG's request for this TAG review: https://  <!-- Usually a deep link into minutes or an email thread. -->
- TAG review of the previous version of this specification, if any: https://github.com/w3ctag/design-reviews/issues/####
- A description of what has changed since our previous review: https://...#section

<!-- Make a copy of the below items for each distinct feature that
 has changed since our previous reviewed , and fill in links to
 describe that feature. For small changes, these may all be interesting 

 in the issue that motivated the change, but please double-check that
 all the answers are actually there. -->
Feature 1:
- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://  <!-- Can be the specification's or explainer's introduction, or another section. -->
- A description of the problems that end-users were facing before this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
- Alternatives considered: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://
- Web Platform Tests:  <!-- Or other tests if this is not a web platform feature. -->


### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing specification
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the specification:
- This work is being funded by:
- Primary standards group developing this feature:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}


### Feedback so far

- Active horizontal reviews: https:// <!-- Link to an issue like https://github.com/webmachinelearning/webnn/issues/239, https://github.com/WebAssembly/spec/issues/1804, or https://github.com/w3c/did/issues/885, which itself links to the other horizontal reviews. If you haven't started the rest of the horizontal reviews, please consider doing so. -->
- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: <!-- Include links to [Chrome Status](https://chromestatus.com/), [Mozilla's](https://bugzilla.mozilla.org/), [WebKit's Bugzilla](https://bugs.webkit.org/), and trackers for other implementations if those are known to you. -->


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1257


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1257
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1257@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: new speculation rules action: prerender_until_script (Issue #1183)Dan Clarknotifications@github.commid:w3ctag/design-reviews/issues/1183/5257327256@github.com2026-08-11T18:38:48+00:00
dandclark left a comment (w3ctag/design-reviews#1183)

@Clqsin45, is this still being worked on? If so, could you look into the questions in https://github.com/w3ctag/design-reviews/issues/1183#issuecomment-3771436754 so we could move the review forward?

Thanks!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1183#issuecomment-5257327256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1183/5257327256@github.com>
Aquileo | Re: [w3ctag/design-reviews] Question: Review manifest-first Web Install API (Issue #1245)Jeremy Keithnotifications@github.commid:w3ctag/design-reviews/issues/1245/5255870073@github.com2026-08-11T16:25:13+00:00
adactio left a comment (w3ctag/design-reviews#1245)

@marcoscaceres wrote:
> Right, but this is fundamentally about architecture: does this capability belong in web pages at all is the core question.

Do “Smart App Banners” belong in web pages at all? Almost certainly not.

But this capability? Most definitely!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1245#issuecomment-5255870073
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1245/5255870073@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] https://www.w3.org/users/176311/ (Issue #1471)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1471/5244111450@github.com2026-08-10T18:11:57+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1471)

Markdown

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1471#issuecomment-5244111450
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1471/5244111450@github.com>
Aquileo | Re: [whatwg/dom] Scope-match a selectors string including a pseudo-element selector (Issue #1497)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1497/5244103007@github.com2026-08-10T18:11:05+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1497)

Merge frontEnd https://github.com/whatwg/dom/issues/1498

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1497#issuecomment-5244103007
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1497/5244103007@github.com>
Aquileo | Re: [whatwg/dom] Scope-match a selectors string including a pseudo-element selector (Issue #1497)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1497/5244103007@github.com2026-08-10T18:11:05+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1497)

Merge frontEnd https://github.com/whatwg/dom/issues/1498

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1497#issuecomment-5244103007
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1497/5244103007@github.com>
Aquileo | Re: [whatwg/dom] Allow createCDATASection() in HTML documents (Issue #1420)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1420/5244094982@github.com2026-08-10T18:10:17+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1420)

Merge to https://github.com/whatwg/dom/issues/1498

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1420#issuecomment-5244094982
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1420/5244094982@github.com>
Aquileo | Re: [whatwg/dom] Allow createCDATASection() in HTML documents (Issue #1420)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1420/5244094982@github.com2026-08-10T18:10:17+00:00
dayhardindapaint214-ui left a comment (whatwg/dom#1420)

Merge to https://github.com/whatwg/dom/issues/1498

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1420#issuecomment-5244094982
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1420/5244094982@github.com>
Aquileo | [whatwg/dom] state:open label:"good first issue" the finals archive and game (Issue #1498)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1498@github.com2026-08-10T18:09:36+00:00
dayhardindapaint214-ui created an issue (whatwg/dom#1498)

### What is the issue with the DOM Standard?

The finals and this year's game SRC data

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1498
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1498@github.com>
Aquileo | [whatwg/dom] state:open label:"good first issue" the finals archive and game (Issue #1498)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1498@github.com2026-08-10T18:09:36+00:00
dayhardindapaint214-ui created an issue (whatwg/dom#1498)

### What is the issue with the DOM Standard?

The finals and this year's game SRC data

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1498
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1498@github.com>
Aquileo | [whatwg/dom] state:open label:"good first issue" the finals archive and game (Issue #1498)Andre Davon Craignotifications@github.commid:whatwg/dom/issues/1498@github.com2026-08-10T18:09:36+00:00
dayhardindapaint214-ui created an issue (whatwg/dom#1498)

### What is the issue with the DOM Standard?

The finals and this year's game SRC data

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1498
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1498@github.com>
Aquileo | [w3c/gamepad] Proposal for the Gamepad Interop 2027 (Issue #231)Sun Shinnotifications@github.commid:w3c/gamepad/issues/231@github.com2026-08-10T16:29:48+00:00
xingri created an issue (w3c/gamepad#231)

Could we discuss the proposal for the Gamepad Interop 2027? 

I have drafted the proposal based on the discussion on July 2026 monthly meeting with @nondebug .

- https://github.com/xingri/xingri.github.io/blob/master/gamepad-interop-2027-proposal.md

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/231
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/231@github.com>
Aquileo | [whatwg/webidl] Intent to use Constants (Issue #1626)786halid786gm-codenotifications@github.commid:whatwg/webidl/issues/1626@github.com2026-08-10T02:52:53+00:00
786halid786gm-code created an issue (whatwg/webidl#1626)

Sex video 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1626
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1626@github.com>
Aquileo | Re: [w3ctag/design-reviews] Declarative CSS Modules and Declarative Shadow DOM `adoptedstylesheets` attribute (Issue #1000)Joe Peanotifications@github.commid:w3ctag/design-reviews/issues/1000/5227937536@github.com2026-08-08T20:16:54+00:00
trusktr left a comment (w3ctag/design-reviews#1000)


> Perhaps something like avoiding needing to make a constructible version of a `reset` that you also apply to the document with a `<link>`.

Slightly off topic, but this whole constructible vs non-constructible sheets business is confusing and undesirable, especially considering that we're talking about usage scenarios where the user is not doing the construction! In both cases (non-module vs module), it is the `<link>` that is _constructing_ either a non-constructible (oxymoron) sheet or a constructible sheet, respectively.

Besides the main topic of sharing sheets with multiple trees/roots (via module map), it'd be great if we fixed this odd and unnecessary discrepancy between these two types of sheets (which is otherwise just more stones for people to stumble over while on the path to mastering web dev).

It seems easy to solve, but I'll save it for a separate thread.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-5227937536
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1000/5227937536@github.com>
Aquileo | Re: [w3ctag/design-reviews] Declarative CSS Modules and Declarative Shadow DOM `adoptedstylesheets` attribute (Issue #1000)Joe Peanotifications@github.commid:w3ctag/design-reviews/issues/1000/5227937536@github.com2026-08-08T20:16:54+00:00
trusktr left a comment (w3ctag/design-reviews#1000)


> Perhaps something like avoiding needing to make a constructible version of a `reset` that you also apply to the document with a `<link>`.

Slightly off topic, but this whole constructible vs non-constructible sheets business is confusing and undesirable, especially considering that we're talking about usage scenarios where the user is not doing the construction! In both cases (non-module vs module), it is the `<link>` that is _constructing_ either a non-constructible (oxymoron) sheet or a constructible sheet, respectively.

Besides the main topic of sharing sheets with multiple trees/roots (via module map), it'd be great if we fixed this odd and unnecessary discrepancy between these two types of sheets (which is otherwise just more stones for people to stumble over while on the path to mastering web dev).

It seems easy to solve, but I'll save it for a separate thread.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-5227937536
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1000/5227937536@github.com>
Aquileo | Re: [w3ctag/design-reviews] Declarative CSS Modules and Declarative Shadow DOM `adoptedstylesheets` attribute (Issue #1000)Joe Peanotifications@github.commid:w3ctag/design-reviews/issues/1000/5227937536@github.com2026-08-08T20:16:54+00:00
trusktr left a comment (w3ctag/design-reviews#1000)


> Perhaps something like avoiding needing to make a constructible version of a `reset` that you also apply to the document with a `<link>`.

Slightly off topic, but this whole constructible vs non-constructible sheets business is confusing and undesirable, especially considering that we're talking about usage scenarios where the user is not doing the construction! In both cases (non-module vs module), it is the `<link>` that is _constructing_ either a non-constructible (oxymoron) sheet or a constructible sheet, respectively.

Besides the main topic of sharing sheets with multiple trees/roots (via module map), it'd be great if we fixed this odd and unnecessary discrepancy between these two types of sheets (which is otherwise just more stones for people to stumble over while on the path to mastering web dev).

It seems easy to solve, but I'll save it for a separate thread.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-5227937536
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1000/5227937536@github.com>
Aquileo | Re: [w3ctag/design-reviews] Declarative CSS Modules and Declarative Shadow DOM `adoptedstylesheets` attribute (Issue #1000)Joe Peanotifications@github.commid:w3ctag/design-reviews/issues/1000/5227937536@github.com2026-08-08T20:16:54+00:00
trusktr left a comment (w3ctag/design-reviews#1000)


> Perhaps something like avoiding needing to make a constructible version of a `reset` that you also apply to the document with a `<link>`.

Slightly off topic, but this whole constructible vs non-constructible sheets business is confusing and undesirable, especially considering that we're talking about usage scenarios where the user is not doing the construction! In both cases (non-module vs module), it is the `<link>` that is _constructing_ either a non-constructible (oxymoron) sheet or a constructible sheet, respectively.

Besides the main topic of sharing sheets with multiple trees/roots (via module map), it'd be great if we fixed this odd and unnecessary discrepancy between these two types of sheets (which is otherwise just more stones for people to stumble over while on the path to mastering web dev).

It seems easy to solve, but I'll save it for a separate thread.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1000#issuecomment-5227937536
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1000/5227937536@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | Re: [whatwg/dom] Prepare for OpaqueRange (PR #1470)Harshad Shahnotifications@github.commid:whatwg/dom/pull/1470/c5219814614@github.com2026-08-07T16:56:36+00:00
Chanchaichoochuay007 left a comment (whatwg/dom#1470)

collection-find-named-element

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1470#issuecomment-5219814614
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1470/c5219814614@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] [wg/immersive-web] Immersive Web WG 2026 Group Charter (Issue #1256)W3C Botnotifications@github.commid:w3ctag/design-reviews/issues/1256@github.com2026-08-07T06:39:41+00:00
w3cbot created an issue (w3ctag/design-reviews#1256)

This issue was created because the 'horizontal review requested' label was added to
§ https://github.com/w3c/strategy/issues/564

This review is requested prior to the [Advisory Committee Review](https://www.w3.org/guide/process/charter.html#ac-review).

New charter proposal, reviewers please take note.

# Charter Review

[Charter](https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

[diff from charter template](https://services.w3.org/htmldiff?doc1=https://w3c.github.io/charter-drafts/charter-template.html&doc2=https://w3c.github.io/charter-drafts/2026/iwwg-charter.html)

Expected end of charter refinement phase: unknown

If applicable:

[diff from previous charter](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2024%2F09%2Fimmersive-Web-wg-charter.html&doc2=https%3A%2F%2Fw3c.github.io%2Fcharter-drafts%2F2026%2Fiwwg-charter.html)

[chair dashboard](https://www.w3.org/PM/Groups/chairboard.html?gid=wg/<shortname>)

What kind of charter is this? Check the relevant box / remove irrelevant branches. 

* New
 - [ ] New WG 
 - [ ] New IG
 
* Existing 
 - [x] Existing WG recharter 
 - [ ] Existing IG recharter
 
Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. **Also add a "card" for this issue to the [Strategy Funnel](https://github.com/orgs/w3c/projects/97/views/2).**

## Substantive changes

Short description (or link to it) of the substantive changes in this charter. Use "None or N/A" otherwise.

* Adding new module (specification) but within current scope
* (Still under investigation) Plan to bring modules to REC, while Core API remains living model in CR

## Communities suggested for outreach

## Known or potential areas of concern

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...)

* [charter-drafts repository with wg/iwwg](https://github.com/w3c/charter-drafts/issues/new?title=[wg/iwwg])

## Anything else we should think about as we review? 

* No CRS updated during current charter period yet.

Note: proposed chairs should be copied @... on this issue.

/cc @AdaRoseCannon @Yonet (co-chairs)

Note: The Technical Strategy Team Lead or Project & Process Team Lead will assign the issue to a [Charter Facilitator](https://www.w3.org/guide/process/charter.html#cr-acceptance) for new charters. For rechartering, the team contact is the Charter Facilitator by default, please assign the issue to them directly.


## Charter facilitator(s)

cc @himorin

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1256


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1256
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1256@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Application Capability (Issue #1255)Sarven Capadislinotifications@github.commid:w3ctag/design-reviews/issues/1255@github.com2026-08-06T18:34:07+00:00
csarven created an issue (w3ctag/design-reviews#1255)

### Explainer

https://dokieli.github.io/application-capability/

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [ ] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/dokieli/application-capability
- Primary contacts:
  - Sarven Capadisli (@csarven), dokieli, editor
  - Virginia Balseiro (@VirginiaBalseiro), dokieli, editor
- Organization/project driving the design: dokieli
- This work is being funded by: Not funded
- Incubation and standards groups that have discussed the design:
  - [W3C Solid Community Group](https://www.w3.org/groups/cg/solid/)
- Standards group(s) that you expect to discuss and/or adopt this work when
  it's ready: unknown

### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: N/A (not requested; see note below)
  - Mozilla comments: N/A (not requested; see note below)
  - WebKit comments: N/A (not requested; see note below)
  - Developer and implementer feedback:
    - [dokieli](https://dokie.li/) implements features across the specification.
    - An independent [Application Capability validator](https://ac-validator.vercel.app/) checks descriptions against a SHACL shape for the vocabulary.
    - Discussion with the [PodOS](https://browser.pod-os.org/) project on application discovery and invocation: https://github.com/pod-os/PodOS/issues/47
  - Note: the specification requires no browser engine changes. Discovery is     dereferencing a description, and invocation is ordinary navigation to an IRI, so we have not requested engine vendor positions. We'd still welcome their review, particularly from those working on agent and application interoperability (for example WebMCP, see also https://github.com/w3ctag/design-reviews/issues/1238 ).
    - Initially presented the specification to the [Solid CG](https://www.w3.org/groups/cg/solid/) as a [work item proposal](https://github.com/solid/specification/issues/806) ([minutes](https://github.com/solid/specification/blob/main/meetings/2026-07-15.md#proposal-for-application-capability-spec), [mailing list](https://lists.w3.org/Archives/Public/public-solid/2026Jul/0002.html))
- Major unresolved issues with or opposition to this design:
  - Venue: which existing or new standards group should further develop this specification (the question we are asking the TAG).
  - The JSON-LD context and vocabulary are included in the specification until published at their own namespace.
  - Under consideration: declaring whether an action has side effects (with guidance for Consumers acting autonomously), and describing capabilities of applications beyond the web, such as PWA and desktop applications.
  - Would like to: do user research =)

### You should also know that...

*TAG hat off =)*

Appreciate your time and consideration on this work.

---

@marcoscaceres recommended that we create this design review request.

Please note that [the Explainer](https://dokieli.github.io/application-capability/#explainer) is a section in the specification.

From the TAG, we would like direction on venue. In which existing standards
group, or under what new group, should this specification be further developed? And, needless to say, any other "direction" would be great.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1255


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1255
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1255@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: WebMCP (Issue #1238)Dominic Farolinonotifications@github.commid:w3ctag/design-reviews/issues/1238/5207638057@github.com2026-08-06T16:59:44+00:00
domfarolino left a comment (w3ctag/design-reviews#1238)

Yesterday we discussed WebMCP at the TAG Atlantic breakout meeting—thanks to all of the TAG members that participated, and took the time to review the proposal so far!

One thing that keeps coming up over and over is: why is our solution shaped like an explicit capability layer / agent pathway to site code, as opposed to just "more HTML semantics" to help agents do everything through the UI? Some members of the TAG are happy with our approach, but not basing the proposal entirely on more UI semantics has been the primary source of TAG pushback we've received. (I'll add the caveat that a formal position has not yet been reached, and the TAG is not explicitly demanding that a "more semantic HTML" approach be pursued).

With that, I'd like to gently ask: if the TAG proposes a negative resolution based substantially on our API's lack of "more HTML semantics", that the TAG please provide evidence as to why this is believed to be a sufficient alternative. A sufficient alternative not to just what we cooked up with WebMCP, but to what many corners of the industry have independently converged on as a battle-tested approach to agents interacting with UI applications.

To add more color:
 - Frontier AI labs like OpenAI, Anthropic, and Google have landed on a similar protocol (MCP) for using programmatic interfaces
 - Those same stakeholders struggle even more to actuate UI, and have shown interest in WebMCP. In a related use case, we've developed a [similar tool-calling approach](https://apps.extensions.modelcontextprotocol.io/api/types/app.AppToolResult.html) inside of MCP _Apps_ to perform actions inside web UI.
 - Open-source extensions like WebBrain [have attested](https://www.webbrain.one/blog/webmcp-integration) to high cost, latency, and inaccuracy when actuating content through the UI. They integrated with WebMCP as soon as they could. We get similar feedback from other developers.
 - Apple's Siri AI integration actuates native macOS apps exclusively through AppIntents, which [basically mirrors imperative WebMCP](https://developer.apple.com/documentation/appintents/acceleratingappinteractionswithappintents). This is despite macOS apps being notoriously accessible, and UI frameworks like SwiftUI being inherently semantic and declarative. This allows for background operations to be performed, which we could support on the web with Service Workers.
 - Microsoft (to support Copilot in Edge) and Google (to support Gemini in Chrome) found that WebMCP leads to far better user experiences over AI actuation. Mozilla has agreed with us that an explicit capability layer beyond HTML semantics seems required, and are supportive _specifically_ of the imperative API (which they have [opinions](https://github.com/webmachinelearning/webmcp/issues/236) on).
 - Independent developers have run many studies showing that WebMCP leads to more accurate user actions and journeys, while being "3-8x cheaper" (tokens) and "4-5x faster" than UI actuation. I'll link to this report now, but there are more coming: https://claude.ai/code/artifact/ff487f98-ef0b-45bc-a0f9-4574e1c157a3

I'll be the first to say that we can do a better job documenting why we believe the gaps of agent UI actuation are "capability layer" shaped, not just "need more semantic UI" shaped. And we're working on that. But if the TAG does feel strongly about a semantic UI route, I'd kindly ask that some evidence be supplied that the current industry SOTA on which all stakeholders have converged is either overkill, or can equally be matched by more HTML attributes and kin. And why the drawbacks of such an approach—no service worker integration, and possibly not supporting in-page agents in iframes—are worth it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1238#issuecomment-5207638057
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1238/5207638057@github.com>
Aquileo | [whatwg/webidl] chrissem465@gmail.com (Issue #1625)christopherzapp12-dotnotifications@github.commid:whatwg/webidl/issues/1625@github.com2026-08-06T16:48:25+00:00
christopherzapp12-dot created an issue (whatwg/webidl#1625)

### What problem are you trying to solve?

chrissem465@gmail.com

### What solutions exist today?

_No response_

### How would you solve it?

_No response_

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1625
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1625@github.com>
Aquileo | [whatwg/webidl] chrissem465@gmail.com (Issue #1625)christopherzapp12-dotnotifications@github.commid:whatwg/webidl/issues/1625@github.com2026-08-06T16:48:25+00:00
christopherzapp12-dot created an issue (whatwg/webidl#1625)

### What problem are you trying to solve?

chrissem465@gmail.com

### What solutions exist today?

_No response_

### How would you solve it?

_No response_

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1625
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1625@github.com>
Aquileo | [whatwg/fetch] Creating opaque timing info discards the end time, causing `responseEnd` to be zero after a failed TAO check (Issue #1945)Tim Flynnnotifications@github.commid:whatwg/fetch/issues/1945@github.com2026-08-06T16:37:50+00:00
trflynn89 created an issue (whatwg/fetch#1945)

### What is the issue with the Fetch Standard?

In the [fetch response handover](https://fetch.spec.whatwg.org/#fetch-finale), we have the following report-timing steps:

```
2. Set timingInfo’s end time to the relative high resolution time given unsafeEndTime and global.
5. If response’s timing allow passed flag is not set, then set timingInfo to the result of creating an opaque timing info for timingInfo and set cacheState to the empty string. 
```

Setting the `timingInfo` to an opaque timing info wipes out the previously set end time. The result is that a Resource Timing entry that has failed the TAO check will have a positive `startTime` and a `responseEnd` of 0. However, `responseEnd` is not one of the fields that are protected by TAO here: https://w3c.github.io/resource-timing/#sec-cross-origin-resources

Should the [creating an opaque timing info](https://fetch.spec.whatwg.org/#create-an-opaque-timing-info) steps copy over the end time as well?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1945
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1945@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: FedCM: Support showing third-party iframe origins in the UI (Issue #1136)Ehsan Toreininotifications@github.commid:w3ctag/design-reviews/issues/1136/5205688243@github.com2026-08-06T14:02:44+00:00
toreini left a comment (w3ctag/design-reviews#1136)

hi @npm1 and @yi-gu,

We are closing this issue as it is timed-out. Please feel free to reach out when you have an update so we can re-consider accordingly.

Thanks

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1136#issuecomment-5205688243
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1136/5205688243@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: FedCM: Support showing third-party iframe origins in the UI (Issue #1136)Ehsan Toreininotifications@github.commid:w3ctag/design-reviews/issues/1136/5205688243@github.com2026-08-06T14:02:44+00:00
toreini left a comment (w3ctag/design-reviews#1136)

hi @npm1 and @yi-gu,

We are closing this issue as it is timed-out. Please feel free to reach out when you have an update so we can re-consider accordingly.

Thanks

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1136#issuecomment-5205688243
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1136/5205688243@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: Proofreader API (Issue #1146)Christian Liebelnotifications@github.commid:w3ctag/design-reviews/issue/1146/issue_event/29072100552@github.com2026-08-06T14:00:33+00:00
Closed #1146 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1146#event-29072100552
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issue/1146/issue_event/29072100552@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: Proofreader API (Issue #1146)Christian Liebelnotifications@github.commid:w3ctag/design-reviews/issue/1146/issue_event/29072100552@github.com2026-08-06T14:00:33+00:00
Closed #1146 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1146#event-29072100552
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issue/1146/issue_event/29072100552@github.com>
Aquileo | Re: [w3ctag/design-reviews] WG New Spec: Scroll-Triggered Animations (Issue #1167)Matthew Tylee Atkinsonnotifications@github.commid:w3ctag/design-reviews/issues/1167/5202837946@github.com2026-08-06T09:29:35+00:00
matatk left a comment (w3ctag/design-reviews#1167)

Thanks @DavMila and @astearns for your review request and further info. We are happy to see the work continue, and to close this review.

However, whilst we appreciate the importance of consistency with respect to `contain` and `cover`, having been introduced in scroll-driven animations, and in general we agree that the terms are likely not universally confusing, we are concerned about how CSS (and other groups) can get reliable input from developers on what they find confusing, as specs evolve. We think it most likely that, particularly with minor-to-moderate things that confuse developers, most _aren't_ likely to report those issues as bugs on the spec.

This is of course a key issue that we all need to work to address - ensuring we're reaching the [second-highest-priority constituency [link for readers new to W3C]](https://www.w3.org/TR/design-principles/#priority-of-constituencies) - though with near-universally deployed specs such as CSS it is of course amplified.

If there's anything you think we could do as a community, perhaps kicking of with a TPAC breakout on how to ensure we're getting feedback as inclusively as possible, please let us know.

Finally, we've recently discovered a case where scroll-driven animations can be used to create a scroll spy that can make network requests based on scroll positioning, even when JavaScript is disabled. This opens up privacy concerns, we believe that the same issue applies to scroll triggered animations and would be interested in the CSSWG's thinking on this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1167#issuecomment-5202837946
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1167/5202837946@github.com>
Aquileo | Re: [w3ctag/design-reviews] WG New Spec: Scroll-Triggered Animations (Issue #1167)Matthew Tylee Atkinsonnotifications@github.commid:w3ctag/design-reviews/issues/1167/5202837946@github.com2026-08-06T09:29:35+00:00
matatk left a comment (w3ctag/design-reviews#1167)

Thanks @DavMila and @astearns for your review request and further info. We are happy to see the work continue, and to close this review.

However, whilst we appreciate the importance of consistency with respect to `contain` and `cover`, having been introduced in scroll-driven animations, and in general we agree that the terms are likely not universally confusing, we are concerned about how CSS (and other groups) can get reliable input from developers on what they find confusing, as specs evolve. We think it most likely that, particularly with minor-to-moderate things that confuse developers, most _aren't_ likely to report those issues as bugs on the spec.

This is of course a key issue that we all need to work to address - ensuring we're reaching the [second-highest-priority constituency [link for readers new to W3C]](https://www.w3.org/TR/design-principles/#priority-of-constituencies) - though with near-universally deployed specs such as CSS it is of course amplified.

If there's anything you think we could do as a community, perhaps kicking of with a TPAC breakout on how to ensure we're getting feedback as inclusively as possible, please let us know.

Finally, we've recently discovered a case where scroll-driven animations can be used to create a scroll spy that can make network requests based on scroll positioning, even when JavaScript is disabled. This opens up privacy concerns, we believe that the same issue applies to scroll triggered animations and would be interested in the CSSWG's thinking on this.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1167#issuecomment-5202837946
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1167/5202837946@github.com>
Aquileo | [w3c/screen-orientation] Tidied up document using tidy-html5 (PR #281)github-actions[bot]notifications@github.commid:w3c/screen-orientation/pull/281@github.com2026-08-06T06:34:36+00:00
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/pull/281.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/281/43d628f...c81ff2c.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/screen-orientation/pull/281

-- Commit Summary --

  * chore: tidy up index.html

-- File Changes --

    M index.html (8)

-- Patch Links --

https://github.com/w3c/screen-orientation/pull/281.patch
https://github.com/w3c/screen-orientation/pull/281.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/screen-orientation/pull/281
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/281@github.com>
Aquileo | [w3c/screen-orientation] Tidied up document using tidy-html5 (PR #281)github-actions[bot]notifications@github.commid:w3c/screen-orientation/pull/281@github.com2026-08-06T06:34:36+00:00
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/pull/281.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/281/43d628f...c81ff2c.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/screen-orientation/pull/281

-- Commit Summary --

  * chore: tidy up index.html

-- File Changes --

    M index.html (8)

-- Patch Links --

https://github.com/w3c/screen-orientation/pull/281.patch
https://github.com/w3c/screen-orientation/pull/281.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/screen-orientation/pull/281
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/281@github.com>
Aquileo | [w3c/screen-orientation] Tidied up document using tidy-html5 (PR #281)github-actions[bot]notifications@github.commid:w3c/screen-orientation/pull/281@github.com2026-08-06T06:34:36+00:00
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/pull/281.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/screen-orientation/281/43d628f...c81ff2c.html" title="Last updated on Aug 6, 2026, 6:34 AM UTC (c81ff2c)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/screen-orientation/pull/281

-- Commit Summary --

  * chore: tidy up index.html

-- File Changes --

    M index.html (8)

-- Patch Links --

https://github.com/w3c/screen-orientation/pull/281.patch
https://github.com/w3c/screen-orientation/pull/281.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/screen-orientation/pull/281
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/281@github.com>
Aquileo | Re: [w3c/screen-orientation] "natural" is ambiguous (Issue #275)Léonie Watsonnotifications@github.commid:w3c/screen-orientation/issue/275/issue_event/29051424790@github.com2026-08-06T06:34:20+00:00
Closed #275 as completed via #278.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/screen-orientation/issues/275#event-29051424790
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/issue/275/issue_event/29051424790@github.com>
Aquileo | Re: [w3c/screen-orientation] Fix iframe promise rejection in unloading document cleanup (PR #268)Marcos Cáceresnotifications@github.commid:w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f2026-08-06T06:08:44+00:00
@marcoscaceres pushed 1 commit.

4af3d7ad9bbeb167c2167f0a210f094f7f2b2178  Merge branch 'gh-pages' into fix-iframe-promise-rejection-spec

-- 
View it on GitHub:
https://github.com/w3c/screen-orientation/pull/268/changes/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f..4af3d7ad9bbeb167c2167f0a210f094f7f2b2178
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f>
Aquileo | Re: [w3c/screen-orientation] Fix iframe promise rejection in unloading document cleanup (PR #268)Marcos Cáceresnotifications@github.commid:w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f2026-08-06T06:08:44+00:00
@marcoscaceres pushed 1 commit.

4af3d7ad9bbeb167c2167f0a210f094f7f2b2178  Merge branch 'gh-pages' into fix-iframe-promise-rejection-spec

-- 
View it on GitHub:
https://github.com/w3c/screen-orientation/pull/268/changes/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f..4af3d7ad9bbeb167c2167f0a210f094f7f2b2178
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f>
Aquileo | Re: [w3c/screen-orientation] Fix iframe promise rejection in unloading document cleanup (PR #268)Marcos Cáceresnotifications@github.commid:w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f2026-08-06T06:08:44+00:00
@marcoscaceres pushed 1 commit.

4af3d7ad9bbeb167c2167f0a210f094f7f2b2178  Merge branch 'gh-pages' into fix-iframe-promise-rejection-spec

-- 
View it on GitHub:
https://github.com/w3c/screen-orientation/pull/268/changes/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f..4af3d7ad9bbeb167c2167f0a210f094f7f2b2178
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f>
Aquileo | Re: [w3c/screen-orientation] Fix iframe promise rejection in unloading document cleanup (PR #268)Marcos Cáceresnotifications@github.commid:w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f2026-08-06T06:08:44+00:00
@marcoscaceres pushed 1 commit.

4af3d7ad9bbeb167c2167f0a210f094f7f2b2178  Merge branch 'gh-pages' into fix-iframe-promise-rejection-spec

-- 
View it on GitHub:
https://github.com/w3c/screen-orientation/pull/268/changes/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f..4af3d7ad9bbeb167c2167f0a210f094f7f2b2178
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/268/before/cd1f403cacfb6bddc7a16715f17db3cfcd69b99f>
Aquileo | Re: [w3c/screen-orientation] Editorial: clarify the natural screen orientation (PR #278)Léonie Watsonnotifications@github.commid:w3c/screen-orientation/pull/278/before/81d4b86d34b14d7d9918ed989562ff12510132722026-08-06T06:06:39+00:00
@LJWatson pushed 1 commit.

15bbd3c48cb27e6d55d8dcb1104ad00bfb26fb5c  Merge branch 'gh-pages' into fix-natural-ambiguity-275

-- 
View it on GitHub:
https://github.com/w3c/screen-orientation/pull/278/changes/81d4b86d34b14d7d9918ed989562ff1251013272..15bbd3c48cb27e6d55d8dcb1104ad00bfb26fb5c
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/screen-orientation/pull/278/before/81d4b86d34b14d7d9918ed989562ff1251013272>
Aquileo | [w3c/ServiceWorker] Editorial: remove nested Queue a task around message dispatch in Client.postMessage (PR #1844)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1844@github.com2026-08-05T21:41:15+00:00
Follow-up to #1836. Addresses [@asutherland's post-merge review comment](https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-3252891569).

## Problem

`Client.postMessage` currently has this shape (post-#1836):

```
1. Run the following steps in parallel:
    ...
    1. Add a task that runs the following steps to |destination|'s client message queue:
        ... deserialize ...
        1. queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to fire an event named messageerror ...
        ...
        1. Queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to Dispatch an event named message ...
```

The `fire messageerror` and `Dispatch message` steps already run inside a task on `|destination|`'s [=ServiceWorkerContainer/client message queue=]. The extra inner `Queue a task on |targetClient|'s responsible event loop` wrappers added by #1836 are:

1. **Redundant**, because `|destination|` is the {{ServiceWorkerContainer}} associated with `|targetClient|`, so both the outer `client message queue` task and the inner `queue a task` target the same client's event loop.
2. **Potentially incorrect**, because the outer task's task source (the [=client message queue=]) is superseded by the inner [=DOM manipulation task source=], subtly changing the ordering/timing semantics of message delivery.

As @asutherland noted:

> I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
>> Add a task that runs the following steps to destination's client message queue
>
> The clients-get and clients-claim changes seem correct though.

## Fix

Remove the two inner `queue a task` wrappers in `Client.postMessage`. The outer `Add a task ... to |destination|'s client message queue:` retains full task-queue semantics for both `fire messageerror` and `Dispatch message`.

Total change: **+2 / −2** in `index.bs`, one commit. `Clients.get` and `Clients.claim` from #1836 are untouched.

## Related

- #1836 — the PR whose `postMessage` change this addresses
- #1740 — original missing-tasks-in-parallel issue
- #1755 — parent queue-a-task refactor


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1844.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1844/9e9fe27...monica-ch:4968a23.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1844

-- Commit Summary --

  * Editorial: remove nested Queue a task around message dispatch in Client.postMessage

-- File Changes --

    M index.bs (4)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1844.patch
https://github.com/w3c/ServiceWorker/pull/1844.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1844
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1844@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: remove nested Queue a task around message dispatch in Client.postMessage (PR #1844)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1844@github.com2026-08-05T21:41:15+00:00
Follow-up to #1836. Addresses [@asutherland's post-merge review comment](https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-3252891569).

## Problem

`Client.postMessage` currently has this shape (post-#1836):

```
1. Run the following steps in parallel:
    ...
    1. Add a task that runs the following steps to |destination|'s client message queue:
        ... deserialize ...
        1. queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to fire an event named messageerror ...
        ...
        1. Queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to Dispatch an event named message ...
```

The `fire messageerror` and `Dispatch message` steps already run inside a task on `|destination|`'s [=ServiceWorkerContainer/client message queue=]. The extra inner `Queue a task on |targetClient|'s responsible event loop` wrappers added by #1836 are:

1. **Redundant**, because `|destination|` is the {{ServiceWorkerContainer}} associated with `|targetClient|`, so both the outer `client message queue` task and the inner `queue a task` target the same client's event loop.
2. **Potentially incorrect**, because the outer task's task source (the [=client message queue=]) is superseded by the inner [=DOM manipulation task source=], subtly changing the ordering/timing semantics of message delivery.

As @asutherland noted:

> I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
>> Add a task that runs the following steps to destination's client message queue
>
> The clients-get and clients-claim changes seem correct though.

## Fix

Remove the two inner `queue a task` wrappers in `Client.postMessage`. The outer `Add a task ... to |destination|'s client message queue:` retains full task-queue semantics for both `fire messageerror` and `Dispatch message`.

Total change: **+2 / −2** in `index.bs`, one commit. `Clients.get` and `Clients.claim` from #1836 are untouched.

## Related

- #1836 — the PR whose `postMessage` change this addresses
- #1740 — original missing-tasks-in-parallel issue
- #1755 — parent queue-a-task refactor


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1844.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1844/9e9fe27...monica-ch:4968a23.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1844

-- Commit Summary --

  * Editorial: remove nested Queue a task around message dispatch in Client.postMessage

-- File Changes --

    M index.bs (4)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1844.patch
https://github.com/w3c/ServiceWorker/pull/1844.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1844
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1844@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: remove nested Queue a task around message dispatch in Client.postMessage (PR #1844)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1844@github.com2026-08-05T21:41:15+00:00
Follow-up to #1836. Addresses [@asutherland's post-merge review comment](https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-3252891569).

## Problem

`Client.postMessage` currently has this shape (post-#1836):

```
1. Run the following steps in parallel:
    ...
    1. Add a task that runs the following steps to |destination|'s client message queue:
        ... deserialize ...
        1. queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to fire an event named messageerror ...
        ...
        1. Queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to Dispatch an event named message ...
```

The `fire messageerror` and `Dispatch message` steps already run inside a task on `|destination|`'s [=ServiceWorkerContainer/client message queue=]. The extra inner `Queue a task on |targetClient|'s responsible event loop` wrappers added by #1836 are:

1. **Redundant**, because `|destination|` is the {{ServiceWorkerContainer}} associated with `|targetClient|`, so both the outer `client message queue` task and the inner `queue a task` target the same client's event loop.
2. **Potentially incorrect**, because the outer task's task source (the [=client message queue=]) is superseded by the inner [=DOM manipulation task source=], subtly changing the ordering/timing semantics of message delivery.

As @asutherland noted:

> I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
>> Add a task that runs the following steps to destination's client message queue
>
> The clients-get and clients-claim changes seem correct though.

## Fix

Remove the two inner `queue a task` wrappers in `Client.postMessage`. The outer `Add a task ... to |destination|'s client message queue:` retains full task-queue semantics for both `fire messageerror` and `Dispatch message`.

Total change: **+2 / −2** in `index.bs`, one commit. `Clients.get` and `Clients.claim` from #1836 are untouched.

## Related

- #1836 — the PR whose `postMessage` change this addresses
- #1740 — original missing-tasks-in-parallel issue
- #1755 — parent queue-a-task refactor


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1844.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1844/9e9fe27...monica-ch:4968a23.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1844

-- Commit Summary --

  * Editorial: remove nested Queue a task around message dispatch in Client.postMessage

-- File Changes --

    M index.bs (4)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1844.patch
https://github.com/w3c/ServiceWorker/pull/1844.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1844
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1844@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: remove nested Queue a task around message dispatch in Client.postMessage (PR #1844)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1844@github.com2026-08-05T21:41:15+00:00
Follow-up to #1836. Addresses [@asutherland's post-merge review comment](https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-3252891569).

## Problem

`Client.postMessage` currently has this shape (post-#1836):

```
1. Run the following steps in parallel:
    ...
    1. Add a task that runs the following steps to |destination|'s client message queue:
        ... deserialize ...
        1. queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to fire an event named messageerror ...
        ...
        1. Queue a task on |targetClient|'s responsible event loop, using the DOM manipulation task source, to Dispatch an event named message ...
```

The `fire messageerror` and `Dispatch message` steps already run inside a task on `|destination|`'s [=ServiceWorkerContainer/client message queue=]. The extra inner `Queue a task on |targetClient|'s responsible event loop` wrappers added by #1836 are:

1. **Redundant**, because `|destination|` is the {{ServiceWorkerContainer}} associated with `|targetClient|`, so both the outer `client message queue` task and the inner `queue a task` target the same client's event loop.
2. **Potentially incorrect**, because the outer task's task source (the [=client message queue=]) is superseded by the inner [=DOM manipulation task source=], subtly changing the ordering/timing semantics of message delivery.

As @asutherland noted:

> I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
>> Add a task that runs the following steps to destination's client message queue
>
> The clients-get and clients-claim changes seem correct though.

## Fix

Remove the two inner `queue a task` wrappers in `Client.postMessage`. The outer `Add a task ... to |destination|'s client message queue:` retains full task-queue semantics for both `fire messageerror` and `Dispatch message`.

Total change: **+2 / −2** in `index.bs`, one commit. `Clients.get` and `Clients.claim` from #1836 are untouched.

## Related

- #1836 — the PR whose `postMessage` change this addresses
- #1740 — original missing-tasks-in-parallel issue
- #1755 — parent queue-a-task refactor


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1844.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1844/9e9fe27...monica-ch:4968a23.html" title="Last updated on Aug 5, 2026, 9:40 PM UTC (4968a23)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1844

-- Commit Summary --

  * Editorial: remove nested Queue a task around message dispatch in Client.postMessage

-- File Changes --

    M index.bs (4)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1844.patch
https://github.com/w3c/ServiceWorker/pull/1844.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1844
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1844@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task in Client / Clients API (PR #1836)Andrew Sutherlandnotifications@github.commid:w3c/ServiceWorker/pull/1836/c5197298307@github.com2026-08-05T21:01:59+00:00
asutherland left a comment (w3c/ServiceWorker#1836)

I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
> Add a task that runs the following steps to destination ’s client message queue

The clients-get and clients-claim changes seem correct though.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-5197298307
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1836/c5197298307@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task in Client / Clients API (PR #1836)Andrew Sutherlandnotifications@github.commid:w3c/ServiceWorker/pull/1836/c5197298307@github.com2026-08-05T21:01:59+00:00
asutherland left a comment (w3c/ServiceWorker#1836)

I think the postMessage changes may be incorrect; the event dispatch was already happening under the auspices of:
> Add a task that runs the following steps to destination ’s client message queue

The clients-get and clients-claim changes seem correct though.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1836#issuecomment-5197298307
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1836/c5197298307@github.com>
Aquileo | Re: [w3c/DOM-Parsing] Only generate an attribute prefix if required (#30)Ms2gernotifications@github.commid:w3c/DOM-Parsing/pull/30/c5195970953@github.com2026-08-05T18:51:28+00:00
Ms2ger left a comment (w3c/DOM-Parsing#30)

This seems to still be buggy, as only _new prefix_ is set, and _candidate prefix_ remains null, so the step below will not serialize any prefix:
```js
  let root = parse('<r></r>');
  root.setAttributeNS('uri', 'p:name', 'value');
  serialize(root) // '<r xmlns:ns1="uri" name="value"/>'
```
(I'm integrating a fix elsewhere, no need to update this PR.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/DOM-Parsing/pull/30#issuecomment-5195970953
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/DOM-Parsing/pull/30/c5195970953@github.com>
Aquileo | Re: [whatwg/fetch] Should the reload-navigation flag behave similarly to the "reload" cache mode? (Issue #1899)sideshowbarkernotifications@github.commid:whatwg/fetch/issues/1899/5195295759@github.com2026-08-05T17:49:25+00:00
sideshowbarker left a comment (whatwg/fetch#1899)

Related HTML spec issue: https://github.com/whatwg/html/issues/12760.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1899#issuecomment-5195295759
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1899/5195295759@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Cross-Origin Storage (Issue #1254)Thomas Steinernotifications@github.commid:w3ctag/design-reviews/issues/1254@github.com2026-08-05T11:31:49+00:00
tomayac created an issue (w3ctag/design-reviews#1254)

### Explainer

https://github.com/WICG/cross-origin-storage/blob/main/README.md

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WICG/cross-origin-storage/
- Primary contacts:
  - Thomas Steiner (@tomayac), Google, Developer Relations Engineer
  - Christian Liebel (@christianliebel ), Thinktecture, Consultant
  - François Beaufort (@beaufortfrancois), Google, Developer Relations Engineer
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - Web Engines Hackfest ([Notes](https://hackmd.io/FEHrk-JETySTQyl8ooCRZw), [Slides](https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/preview))
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1427
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/703
  - Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.
- Major unresolved issues with or opposition to this design:


### You should also know that...

#### Public Hash List

Companion design document for the Public Hash List (PHL), the mechanism this proposal leans on
for its main cross-site-disclosure mitigation:
https://github.com/WICG/cross-origin-storage/blob/main/public-hash-list/phl-explainer.md

#### Public Hash List implementation

A [prototype implementation of the Public Hash List](https://github.com/WICG/cross-origin-storage/tree/main/public-hash-list/implementation) is available. The [actual Public Hash List](https://media.githubusercontent.com/media/WICG/cross-origin-storage/refs/heads/main/public-hash-list/implementation/data/public-hash-list.dat) is created on a weekly basis based on a [GitHub Action](https://github.com/WICG/cross-origin-storage/blob/main/.github/workflows/public-hash-list.yml).

#### Browser extensions

Browser extensions that implement the API (including Public Hash List gating) exist for all browsers:

* [Chrome](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
* [Firefox](https://addons.mozilla.org/en-US/firefox/addon/cross-origin-storage)
* [Safari](https://apps.apple.com/app/cross-origin-storage/id6788319695)

#### Developer interest

Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.

#### Awesome Cross-Origin Storage

More demos and resources are tracked on the [Awesome Cross-Origin Storage](https://github.com/tomayac/awesome-cross-origin-storage) list.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1254


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1254
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1254@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Cross-Origin Storage (Issue #1254)Thomas Steinernotifications@github.commid:w3ctag/design-reviews/issues/1254@github.com2026-08-05T11:31:49+00:00
tomayac created an issue (w3ctag/design-reviews#1254)

### Explainer

https://github.com/WICG/cross-origin-storage/blob/main/README.md

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WICG/cross-origin-storage/
- Primary contacts:
  - Thomas Steiner (@tomayac), Google, Developer Relations Engineer
  - Christian Liebel (@christianliebel ), Thinktecture, Consultant
  - François Beaufort (@beaufortfrancois), Google, Developer Relations Engineer
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - Web Engines Hackfest ([Notes](https://hackmd.io/FEHrk-JETySTQyl8ooCRZw), [Slides](https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/preview))
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1427
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/703
  - Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.
- Major unresolved issues with or opposition to this design:


### You should also know that...

#### Public Hash List

Companion design document for the Public Hash List (PHL), the mechanism this proposal leans on
for its main cross-site-disclosure mitigation:
https://github.com/WICG/cross-origin-storage/blob/main/public-hash-list/phl-explainer.md

#### Public Hash List implementation

A [prototype implementation of the Public Hash List](https://github.com/WICG/cross-origin-storage/tree/main/public-hash-list/implementation) is available. The [actual Public Hash List](https://media.githubusercontent.com/media/WICG/cross-origin-storage/refs/heads/main/public-hash-list/implementation/data/public-hash-list.dat) is created on a weekly basis based on a [GitHub Action](https://github.com/WICG/cross-origin-storage/blob/main/.github/workflows/public-hash-list.yml).

#### Browser extensions

Browser extensions that implement the API (including Public Hash List gating) exist for all browsers:

* [Chrome](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
* [Firefox](https://addons.mozilla.org/en-US/firefox/addon/cross-origin-storage)
* [Safari](https://apps.apple.com/app/cross-origin-storage/id6788319695)

#### Developer interest

Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.

#### Awesome Cross-Origin Storage

More demos and resources are tracked on the [Awesome Cross-Origin Storage](https://github.com/tomayac/awesome-cross-origin-storage) list.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1254


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1254
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1254@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Cross-Origin Storage (Issue #1254)Thomas Steinernotifications@github.commid:w3ctag/design-reviews/issues/1254@github.com2026-08-05T11:31:49+00:00
tomayac created an issue (w3ctag/design-reviews#1254)

### Explainer

https://github.com/WICG/cross-origin-storage/blob/main/README.md

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WICG/cross-origin-storage/
- Primary contacts:
  - Thomas Steiner (@tomayac), Google, Developer Relations Engineer
  - Christian Liebel (@christianliebel ), Thinktecture, Consultant
  - François Beaufort (@beaufortfrancois), Google, Developer Relations Engineer
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - Web Engines Hackfest ([Notes](https://hackmd.io/FEHrk-JETySTQyl8ooCRZw), [Slides](https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/preview))
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1427
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/703
  - Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.
- Major unresolved issues with or opposition to this design:


### You should also know that...

#### Public Hash List

Companion design document for the Public Hash List (PHL), the mechanism this proposal leans on
for its main cross-site-disclosure mitigation:
https://github.com/WICG/cross-origin-storage/blob/main/public-hash-list/phl-explainer.md

#### Public Hash List implementation

A [prototype implementation of the Public Hash List](https://github.com/WICG/cross-origin-storage/tree/main/public-hash-list/implementation) is available. The [actual Public Hash List](https://media.githubusercontent.com/media/WICG/cross-origin-storage/refs/heads/main/public-hash-list/implementation/data/public-hash-list.dat) is created on a weekly basis based on a [GitHub Action](https://github.com/WICG/cross-origin-storage/blob/main/.github/workflows/public-hash-list.yml).

#### Browser extensions

Browser extensions that implement the API (including Public Hash List gating) exist for all browsers:

* [Chrome](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
* [Firefox](https://addons.mozilla.org/en-US/firefox/addon/cross-origin-storage)
* [Safari](https://apps.apple.com/app/cross-origin-storage/id6788319695)

#### Developer interest

Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.

#### Awesome Cross-Origin Storage

More demos and resources are tracked on the [Awesome Cross-Origin Storage](https://github.com/tomayac/awesome-cross-origin-storage) list.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1254


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1254
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1254@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: Cross-Origin Storage (Issue #1254)Thomas Steinernotifications@github.commid:w3ctag/design-reviews/issues/1254@github.com2026-08-05T11:31:49+00:00
tomayac created an issue (w3ctag/design-reviews#1254)

### Explainer

https://github.com/WICG/cross-origin-storage/blob/main/README.md

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [x] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo: https://github.com/WICG/cross-origin-storage/
- Primary contacts:
  - Thomas Steiner (@tomayac), Google, Developer Relations Engineer
  - Christian Liebel (@christianliebel ), Thinktecture, Consultant
  - François Beaufort (@beaufortfrancois), Google, Developer Relations Engineer
- Organization/project driving the design: Google
- This work is being funded by: Google
- Incubation and standards groups that have discussed the design:
  - Web Engines Hackfest ([Notes](https://hackmd.io/FEHrk-JETySTQyl8ooCRZw), [Slides](https://docs.google.com/presentation/d/1wGjZ1nWBfb9hJrB49Cg822VOaMxqIe2nsA_Rc94ZktQ/preview))
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: WHATWG


### Feedback so far

- Multi-stakeholder feedback:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1427
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/703
  - Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.
- Major unresolved issues with or opposition to this design:


### You should also know that...

#### Public Hash List

Companion design document for the Public Hash List (PHL), the mechanism this proposal leans on
for its main cross-site-disclosure mitigation:
https://github.com/WICG/cross-origin-storage/blob/main/public-hash-list/phl-explainer.md

#### Public Hash List implementation

A [prototype implementation of the Public Hash List](https://github.com/WICG/cross-origin-storage/tree/main/public-hash-list/implementation) is available. The [actual Public Hash List](https://media.githubusercontent.com/media/WICG/cross-origin-storage/refs/heads/main/public-hash-list/implementation/data/public-hash-list.dat) is created on a weekly basis based on a [GitHub Action](https://github.com/WICG/cross-origin-storage/blob/main/.github/workflows/public-hash-list.yml).

#### Browser extensions

Browser extensions that implement the API (including Public Hash List gating) exist for all browsers:

* [Chrome](https://chromewebstore.google.com/detail/cross-origin-storage/denpnpcgjgikjpoglpjefakmdcbmlgih)
* [Firefox](https://addons.mozilla.org/en-US/firefox/addon/cross-origin-storage)
* [Safari](https://apps.apple.com/app/cross-origin-storage/id6788319695)

#### Developer interest

Developer interest is tracked in the [Web / Framework developer views notes](https://chromestatus.com/feature/5163371507875840#:~:text=Web%20/%20Framework%20developer%20views%20notes) section of the ChromeStatus entry.

#### Awesome Cross-Origin Storage

More demos and resources are tracked on the [Awesome Cross-Origin Storage](https://github.com/tomayac/awesome-cross-origin-storage) list.

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1254


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1254
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1254@github.com>
Aquileo | Re: [w3ctag/design-reviews] [wg/webappsec] Web Application Security Working Group Charter (Issue #1244)Marcos Cáceresnotifications@github.commid:w3ctag/design-reviews/issues/1244/5186381002@github.com2026-08-05T01:12:25+00:00
marcoscaceres left a comment (w3ctag/design-reviews#1244)

Thanks for the wait. We've completed our review and the TAG is satisfied with no concerns. The only minor thing that stood out was that for "Device Bound Session Credentials for Single Sign-On " the WG should probably coordinate with the [FedID WG](https://www.w3.org/groups/wg/fedid/). Further, it might be good to explicitly list FedID as group that Web App Sec coordinates with in Section 5.1. There's a lot of collaboration happening already across the two groups because of Digital Credentials, given it builds on Cred Man.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1244#issuecomment-5186381002
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1244/5186381002@github.com>
Aquileo | Re: [w3ctag/design-reviews] [wg/webappsec] Web Application Security Working Group Charter (Issue #1244)Marcos Cáceresnotifications@github.commid:w3ctag/design-reviews/issues/1244/5186381002@github.com2026-08-05T01:12:25+00:00
marcoscaceres left a comment (w3ctag/design-reviews#1244)

Thanks for the wait. We've completed our review and the TAG is satisfied with no concerns. The only minor thing that stood out was that for "Device Bound Session Credentials for Single Sign-On " the WG should probably coordinate with the [FedID WG](https://www.w3.org/groups/wg/fedid/). Further, it might be good to explicitly list FedID as group that Web App Sec coordinates with in Section 5.1. There's a lot of collaboration happening already across the two groups because of Digital Credentials, given it builds on Cred Man.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1244#issuecomment-5186381002
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1244/5186381002@github.com>
Aquileo | Re: [w3ctag/design-reviews] [wg/webappsec] Web Application Security Working Group Charter (Issue #1244)Marcos Cáceresnotifications@github.commid:w3ctag/design-reviews/issues/1244/5186381002@github.com2026-08-05T01:12:25+00:00
marcoscaceres left a comment (w3ctag/design-reviews#1244)

Thanks for the wait. We've completed our review and the TAG is satisfied with no concerns. The only minor thing that stood out was that for "Device Bound Session Credentials for Single Sign-On " the WG should probably coordinate with the [FedID WG](https://www.w3.org/groups/wg/fedid/). Further, it might be good to explicitly list FedID as group that Web App Sec coordinates with in Section 5.1. There's a lot of collaboration happening already across the two groups because of Digital Credentials, given it builds on Cred Man.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1244#issuecomment-5186381002
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1244/5186381002@github.com>
Aquileo | Re: [w3c/manifest] Add `color_scheme_dark` member and themeable members (PR #1205)Daniel Murphynotifications@github.commid:w3c/manifest/pull/1205/c5185141377@github.com2026-08-04T22:05:09+00:00
dmurph left a comment (w3c/manifest#1205)

I keep getting bothered by a github bot about needing to review this, I'm going to move this to a draft to prevent that? As this is shelved until we get more requests for better icon support? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1205#issuecomment-5185141377
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1205/c5185141377@github.com>
Aquileo | Re: [w3c/manifest] Add `color_scheme_dark` member and themeable members (PR #1205)Daniel Murphynotifications@github.commid:w3c/manifest/pull/1205/c5185141377@github.com2026-08-04T22:05:09+00:00
dmurph left a comment (w3c/manifest#1205)

I keep getting bothered by a github bot about needing to review this, I'm going to move this to a draft to prevent that? As this is shelved until we get more requests for better icon support? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/1205#issuecomment-5185141377
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/pull/1205/c5185141377@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: use a per-cache dedicated parallel queue for Cache API methods (PR #1843)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1843@github.com2026-08-04T21:16:42+00:00
Closes #1841. Follow-up to #1755, sibling to #1838.

Give each [=request response list=] (the internal representation of a {{Cache}} object) a dedicated parallel queue and route the {{Cache}} methods that read or mutate it through the queue, so reads and writes on the same {{Cache}} object are serialized.

## Changes

- Add `<dfn>request response list parallel queue</dfn>` (a [=parallel queue=]) attached to each [=request response list=], following the same pattern that #1838 introduced for the [=name to cache map=].
- Route the following {{Cache}} method algorithms through it, replacing their existing `Run … in parallel` block:
    - {{Cache/matchAll(request, options)}}
    - {{Cache/addAll(requests)}} — only the batch-commit step; the per-request fetch step is left as bare `in parallel` since it does not touch the [=request response list=].
    - {{Cache/put(request, response)}}
    - {{Cache/delete(request, options)}}
    - {{Cache/keys(request, options)}}
- The existing `Queue a task` wrappers around promise resolution / rejection (from #1837) are preserved inside the enqueued steps.

Total change: **+7 / −5** in `index.bs`, one commit.

## Out of scope (deliberately)

- {{Cache/match(request, options)}} — a pure orchestrator that delegates to `matchAll`; enqueueing it too would cause a deadlock (it waits on a promise that can only be settled by another enqueued step). Covered transitively.
- {{Cache/add(request)}} — pure orchestrator that delegates to `addAll`. Same reason.
- {{Cache/addAll}}'s per-request fetch block — only performs [=/fetching=]; does not touch the [=request response list=].

## Rationale

Yoshi flagged this concern during #1755 review:

> The situation should also be the same for the [=cache=] object. I guess each [=cache=] object will have the dedicated parallel queue, and `match()`, `matchAll()`, `add()`, `addAll()`, `put()`, `delete()`, and `keys()` might also executed within the parallel queue for the [=cache=] object.

#1837 landed the queue-a-task-for-resolve fixes for these methods. This PR delivers the sibling per-cache parallel-queue work that was explicitly deferred in the [split plan](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716).

## Coordination

The changes here do not overlap textually with the queue-a-task changes in #1837 — that PR only touches the promise resolve/reject lines, this PR only touches the outer `Run in parallel` lines. Either can merge first.

## Related

- #1755 — parent (queue-a-task refactor)
- #1837 — Cache API queue-a-task-for-resolve (open)
- #1838 — sibling PR (CacheStorage `name to cache map` parallel queue), same dfn pattern
- #1740 — original missing-tasks-in-parallel issue
- #1831 — cache/cache-storage forgot to queue a task to resolve promise
- #1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"
- #1842 — sibling PR (Clients API parallel queue), same dfn pattern


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1843.html" title="Last updated on Aug 4, 2026, 9:16 PM UTC (09f4f7a)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1843/e91ddff...monica-ch:09f4f7a.html" title="Last updated on Aug 4, 2026, 9:16 PM UTC (09f4f7a)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1843

-- Commit Summary --

  * Editorial: use a per-cache dedicated parallel queue for Cache API methods

-- File Changes --

    M index.bs (12)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1843.patch
https://github.com/w3c/ServiceWorker/pull/1843.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1843
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1843@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: use a dedicated parallel queue for the Clients API (PR #1842)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1842@github.com2026-08-04T21:15:14+00:00
Closes #1840. Follow-up to #1755.

Give each {{Clients}} object a dedicated parallel queue and route the operations on {{Clients}} through it, so operations on the same {{Clients}} object do not race with each other (e.g. `matchAll` iterating over service worker clients while `claim` is mutating their [=active service worker=]).

## Changes

- Add a `<dfn export for="Clients">Clients parallel queue</dfn>` (a [=parallel queue=]) attached to each {{Clients}} object, following the same pattern as the `name to cache map parallel queue` introduced in #1838.
- Route the following method algorithms through it, replacing their existing top-level `Run … in parallel` block:
    - {{Clients/get(id)}}
    - {{Clients/matchAll(options)}}
    - {{Clients/openWindow(url)}}
    - {{Clients/claim()}}
- Wrap the two remaining bare `Resolve |promise| with undefined.` steps (in `get()` and `claim()`) in `Queue a task` on `|promise|`'s [=responsible event loop=] using the [=DOM manipulation task source=], matching the pattern already used in `matchAll()` and consistent with the queue-a-task refactor from #1755.

Total change: **+10 / −6** in `index.bs`, one commit.

## Rationale

Yoshi flagged this concern during #1755 review:

> I just wondered what happens if one of the service worker clients has been removed or gets execution ready flag during the sub step execution, and suggest to run Clients API algorithm within the dedicated parallel queue to prevent unexpected modifications to clients.

#1836 landed the queue-a-task-for-resolve fixes for these methods. This PR delivers the sibling parallel-queue work that was explicitly deferred in the [split plan](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716).

## Out of scope

- {{Client/postMessage(message, options)}} — lives on {{Client}}, not {{Clients}}, and does a single-client lookup rather than iterating the full client list. Can be a further follow-up if needed.
- {{WindowClient/focus()}} and {{WindowClient/navigate(url)}} — already skip the `in parallel` block entirely and use `Queue a task` on the client's own event loop, so no parallel-queue treatment is meaningful for them.

## Related

- #1755 — parent (queue-a-task refactor)
- #1836 — Clients API queue-a-task-for-resolve (merged)
- #1740 — original missing-tasks-in-parallel issue
- #1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"
- #1838 — sibling PR (CacheStorage-level parallel queue), same dfn pattern
- #1841 — sibling PR (per-cache parallel queue), same dfn pattern


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1842.html" title="Last updated on Aug 4, 2026, 9:14 PM UTC (7f622b8)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1842/e91ddff...monica-ch:7f622b8.html" title="Last updated on Aug 4, 2026, 9:14 PM UTC (7f622b8)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1842

-- Commit Summary --

  * Editorial: use a dedicated parallel queue for the Clients API

-- File Changes --

    M index.bs (16)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1842.patch
https://github.com/w3c/ServiceWorker/pull/1842.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1842
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1842@github.com>
Aquileo | [w3c/ServiceWorker] Use a per-cache dedicated parallel queue for Cache API methods (Issue #1841)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1841@github.com2026-08-04T20:48:47+00:00
monica-ch created an issue (w3c/ServiceWorker#1841)

Follow-up to #1755 (see [split plan comment](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716)) and [threading-model write-up](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-2661941708) (item 4: "Use parallel queues appropriately to avoid race conditions from separate 'in parallel' situations").

#1838 does a dedicated parallel queue on the [=name to cache map=] so [CacheStorage.match](vscode-file://vscode-app/c:/Users/monicach/AppData/Local/Programs/Microsoft%20VS%20Code/974500e64f/resources/app/out/vs/code/electron-browser/workbench/workbench.html)/has/open/delete/keys no longer race on the shared map. The sibling problem on each individual [=cache=] object is not yet addressed. @yoshisatoyanagisawa flagged this during #1755 review:

The situation should also be the same for the [=cache=] object. I guess each [=cache=] object will have the dedicated parallel queue, and match(), matchAll(), add(), addAll(), put(), delete(), and keys() might also executed within the parallel queue for the [=cache=] object.

#1837 does the queue-a-task-for-resolve pattern for these methods but does not add a parallel queue.

**Proposal**
Give each [=cache=] object its own dedicated parallel queue and route the following algorithms through it, so reads and writes on the same cache are serialized:

{{Cache/match(request, options)}}
{{Cache/matchAll(request, options)}}
{{Cache/add(request)}}
{{Cache/addAll(requests)}}
{{Cache/put(request, response)}}
{{Cache/delete(request, options)}}
{{Cache/keys(request, options)}}

**Related**
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1831 — cache/cache-storage forgot to queue a task to resolve promise
#1838 — sibling PR (CacheStorage-level parallel queue)
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1841
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1841@github.com>
Aquileo | [w3c/ServiceWorker] Use a per-cache dedicated parallel queue for Cache API methods (Issue #1841)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1841@github.com2026-08-04T20:48:47+00:00
monica-ch created an issue (w3c/ServiceWorker#1841)

Follow-up to #1755 (see [split plan comment](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716)) and [threading-model write-up](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-2661941708) (item 4: "Use parallel queues appropriately to avoid race conditions from separate 'in parallel' situations").

#1838 does a dedicated parallel queue on the [=name to cache map=] so [CacheStorage.match](vscode-file://vscode-app/c:/Users/monicach/AppData/Local/Programs/Microsoft%20VS%20Code/974500e64f/resources/app/out/vs/code/electron-browser/workbench/workbench.html)/has/open/delete/keys no longer race on the shared map. The sibling problem on each individual [=cache=] object is not yet addressed. @yoshisatoyanagisawa flagged this during #1755 review:

The situation should also be the same for the [=cache=] object. I guess each [=cache=] object will have the dedicated parallel queue, and match(), matchAll(), add(), addAll(), put(), delete(), and keys() might also executed within the parallel queue for the [=cache=] object.

#1837 does the queue-a-task-for-resolve pattern for these methods but does not add a parallel queue.

**Proposal**
Give each [=cache=] object its own dedicated parallel queue and route the following algorithms through it, so reads and writes on the same cache are serialized:

{{Cache/match(request, options)}}
{{Cache/matchAll(request, options)}}
{{Cache/add(request)}}
{{Cache/addAll(requests)}}
{{Cache/put(request, response)}}
{{Cache/delete(request, options)}}
{{Cache/keys(request, options)}}

**Related**
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1831 — cache/cache-storage forgot to queue a task to resolve promise
#1838 — sibling PR (CacheStorage-level parallel queue)
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1841
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1841@github.com>
Aquileo | [w3c/ServiceWorker] Use a dedicated parallel queue for the Clients API (Issue #1840)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1840@github.com2026-08-04T20:43:01+00:00
monica-ch created an issue (w3c/ServiceWorker#1840)

Follow-up to #1755 (see [split plan comment](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716)) and **[threading-model** write-up](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-2661941708) (item 4: "Use parallel queues appropriately to avoid race conditions from separate 'in parallel' situations").

#1836 landed the queue-a-task fix for the promise-resolution side of the Clients API, but the algorithms still use generic [=in parallel=] on the browser-process side. @yoshisatoyanagisawa pointed this out during #1755 review:

For Client API, it might affect not only service worker but also clients. Do we need a parallel queue that covers both instead of the event loop for ServiceWorker itself?

I just wondered what happens if one of the service worker clients has been removed or gets execution ready flag during the sub step execution, and suggest to run Clients API algorithm within the dedicated parallel queue to prevent unexpected modifications to clients.

**Proposal**
Introduce a dedicated parallel queue for the Clients API and route the following algorithms through it, so iteration over [=service worker clients=] cannot race with client removal or [=environment/execution ready flag=] flips:

{{Clients/get(id)}}
{{Clients/matchAll(options)}}
{{Clients/openWindow(url)}}
{{Clients/claim()}}
{{Client/postMessage(message, options)}}
{{WindowClient/focus()}}
{{WindowClient/navigate(url)}}

**Related**
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1840
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1840@github.com>
Aquileo | [w3c/ServiceWorker] Use a dedicated parallel queue for the Clients API (Issue #1840)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/issues/1840@github.com2026-08-04T20:43:01+00:00
monica-ch created an issue (w3c/ServiceWorker#1840)

Follow-up to #1755 (see [split plan comment](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-4963401716)) and **[threading-model** write-up](https://github.com/w3c/ServiceWorker/pull/1755#issuecomment-2661941708) (item 4: "Use parallel queues appropriately to avoid race conditions from separate 'in parallel' situations").

#1836 landed the queue-a-task fix for the promise-resolution side of the Clients API, but the algorithms still use generic [=in parallel=] on the browser-process side. @yoshisatoyanagisawa pointed this out during #1755 review:

For Client API, it might affect not only service worker but also clients. Do we need a parallel queue that covers both instead of the event loop for ServiceWorker itself?

I just wondered what happens if one of the service worker clients has been removed or gets execution ready flag during the sub step execution, and suggest to run Clients API algorithm within the dedicated parallel queue to prevent unexpected modifications to clients.

**Proposal**
Introduce a dedicated parallel queue for the Clients API and route the following algorithms through it, so iteration over [=service worker clients=] cannot race with client removal or [=environment/execution ready flag=] flips:

{{Clients/get(id)}}
{{Clients/matchAll(options)}}
{{Clients/openWindow(url)}}
{{Clients/claim()}}
{{Client/postMessage(message, options)}}
{{WindowClient/focus()}}
{{WindowClient/navigate(url)}}

**Related**
#1755 — parent (queue-a-task refactor)
#1740 — original missing-tasks-in-parallel issue
#1172 — umbrella "Carefully audit all uses of 'in parallel' in the spec"

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1840
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1840@github.com>
Aquileo | Re: [whatwg/webidl] draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript (PR #1184)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1184/c5180624837@github.com2026-08-04T14:42:53+00:00
nicolo-ribaudo left a comment (whatwg/webidl#1184)

The proposal has been abandoned.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1184#issuecomment-5180624837
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1184/c5180624837@github.com>
Aquileo | Re: [whatwg/webidl] draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript (PR #1184)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1184/c5180624837@github.com2026-08-04T14:42:53+00:00
nicolo-ribaudo left a comment (whatwg/webidl#1184)

The proposal has been abandoned.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1184#issuecomment-5180624837
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1184/c5180624837@github.com>
Aquileo | Re: [whatwg/webidl] draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript (PR #1184)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1184/c5180624837@github.com2026-08-04T14:42:53+00:00
nicolo-ribaudo left a comment (whatwg/webidl#1184)

The proposal has been abandoned.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1184#issuecomment-5180624837
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1184/c5180624837@github.com>
Aquileo | Re: [whatwg/webidl] draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript (PR #1184)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1184/c5180624837@github.com2026-08-04T14:42:53+00:00
nicolo-ribaudo left a comment (whatwg/webidl#1184)

The proposal has been abandoned.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1184#issuecomment-5180624837
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1184/c5180624837@github.com>
Aquileo | [whatwg/webidl] Propagate a type's extended attributes to a nullable inner type (PR #1624)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1624@github.com2026-08-04T14:21:47+00:00
<!--
Thank you for contributing to the Web IDL Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->
This patch makes types such as `[Clamp] long?` legal, propagating the extended attribute to the inner type of the nullable type.

It relaxes the definitions of `[AllowResizable]`, `[AllowShared]`, `[Clamp]` and `[EnforceRange]` so that they can be used as such; while it leaves `[LegacyNullToEmptyString]` as is since it does not really make sense to apply it to a nullable string (since then the attribute would be a no-op, given that the null is already handled).

Closes #670.

---

My motivation for doing this is that I will need it in https://github.com/whatwg/webidl/pull/1568.

---

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno: …
   * Node.js: …
   * webidl2.js: …
   * widlparser: …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1624

-- Commit Summary --

  * Propagate a type's extended attributes to a nullable inner type

-- File Changes --

    M index.bs (26)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1624.patch
https://github.com/whatwg/webidl/pull/1624.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1624
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1624@github.com>
Aquileo | [whatwg/webidl] Propagate a type's extended attributes to a nullable inner type (PR #1624)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1624@github.com2026-08-04T14:21:47+00:00
<!--
Thank you for contributing to the Web IDL Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->
This patch makes types such as `[Clamp] long?` legal, propagating the extended attribute to the inner type of the nullable type.

It relaxes the definitions of `[AllowResizable]`, `[AllowShared]`, `[Clamp]` and `[EnforceRange]` so that they can be used as such; while it leaves `[LegacyNullToEmptyString]` as is since it does not really make sense to apply it to a nullable string (since then the attribute would be a no-op, given that the null is already handled).

Closes #670.

---

My motivation for doing this is that I will need it in https://github.com/whatwg/webidl/pull/1568.

---

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno: …
   * Node.js: …
   * webidl2.js: …
   * widlparser: …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1624

-- Commit Summary --

  * Propagate a type's extended attributes to a nullable inner type

-- File Changes --

    M index.bs (26)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1624.patch
https://github.com/whatwg/webidl/pull/1624.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1624
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1624@github.com>
Aquileo | [whatwg/webidl] Propagate a type's extended attributes to a nullable inner type (PR #1624)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1624@github.com2026-08-04T14:21:47+00:00
<!--
Thank you for contributing to the Web IDL Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.

When you submit this PR, and each time you edit this comment (including checking a checkbox through the UI!), PR Preview will run and update it. As such make any edits in one go and only after PR Preview has run.

If you think your PR is ready to land, please double-check that the build is passing and the checklist is complete before pinging.
-->
This patch makes types such as `[Clamp] long?` legal, propagating the extended attribute to the inner type of the nullable type.

It relaxes the definitions of `[AllowResizable]`, `[AllowShared]`, `[Clamp]` and `[EnforceRange]` so that they can be used as such; while it leaves `[LegacyNullToEmptyString]` as is since it does not really make sense to apply it to a nullable string (since then the attribute would be a no-op, given that the null is already handled).

Closes #670.

---

My motivation for doing this is that I will need it in https://github.com/whatwg/webidl/pull/1568.

---

- [ ] At least two implementers are interested (and none opposed):
   * …
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * … <!-- If these tests are tentative, link a PR to make them non-tentative. -->
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: …
   * Gecko: …
   * WebKit: …
   * Deno: …
   * Node.js: …
   * webidl2.js: …
   * widlparser: …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …
- [ ] The top of this comment includes a [clear commit message](https://github.com/whatwg/meta/blob/main/COMMITTING.md) to use. <!-- If you created this PR from a single commit, Github copied its message. Otherwise, you need to add a commit message yourself. -->

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/webidl/pull/1624

-- Commit Summary --

  * Propagate a type's extended attributes to a nullable inner type

-- File Changes --

    M index.bs (26)

-- Patch Links --

https://github.com/whatwg/webidl/pull/1624.patch
https://github.com/whatwg/webidl/pull/1624.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/1624
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1624@github.com>
Aquileo | [w3ctag/design-reviews] Other Spec Review: css-navigation-1 (Issue #1253)Noam Rosenthalnotifications@github.commid:w3ctag/design-reviews/issues/1253@github.com2026-08-04T13:37:26+00:00
noamr created an issue (w3ctag/design-reviews#1253)

### Specification

https://drafts.csswg.org/css-navigation-1

### Explainer

https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md

### Links

- Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
- An introduction to the feature, aimed at unfamiliar audiences: https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md
- A description of the problems that end-users were facing before this proposal: https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#motivation-and-use-cases
- Alternatives considered: https://github.com/WICG/declarative-partial-updates/blob/main/route-matching-explainer.md#alternatives-considered
- Examples of how to use the proposal to solve the end-users' problems: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- What do the end-users experience with this proposal: https://  <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
- User research you did to validate the problem and/or design, if any: https://

### The specification

- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [x] Includes Security and Privacy Considerations sections based on answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).

### Where and by whom is the work is being done?

- GitHub repo:https://github.com/w3c/csswg-drafts/i
- Primary contacts: Noam Rosenthal (@noamr), Bramus Van Damme (@bramus), David Baron (@dbaron) (Google)
- Organization/project driving the specification: Google
- This work is being funded by: Google
- Primary standards group developing this feature: CSSWG
- Group intended to standardize this work: <!-- if different from the current group -->
- Incubation and standards groups that have discussed the design: https://github.com/WICG/declarative-partial-updates

### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments: Implementing
  - Mozilla comments: TBD
  - WebKit comments: TBD
- Major unresolved issues with or opposition to this specification:
- Status/issue trackers for implementations: https://chromestatus.com/feature/4771962874363904


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1253


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1253
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1253@github.com>
Aquileo | Re: [whatwg/webidl] Add an extended attribute to allow propagating TC39's AsyncContext (PR #1568)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b2026-08-04T12:36:39+00:00
@nicolo-ribaudo pushed 4 commits.

695575c626f9b1c99bd00258d543f943a1596ee6  Add an extended attribute to allow propagating TC39's AsyncContext
5bddce72eaee95292226c5016caecf6643b504d0  Get spec preview to work
2956c3f5a17845469c6c7e32435f9c1e9f985c52  Test
b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a  .

-- 
View it on GitHub:
https://github.com/whatwg/webidl/pull/1568/changes/41f898a6bd883b604c3e279f03b70789fa8bb7b4..b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b>
Aquileo | Re: [whatwg/webidl] Add an extended attribute to allow propagating TC39's AsyncContext (PR #1568)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b2026-08-04T12:36:39+00:00
@nicolo-ribaudo pushed 4 commits.

695575c626f9b1c99bd00258d543f943a1596ee6  Add an extended attribute to allow propagating TC39's AsyncContext
5bddce72eaee95292226c5016caecf6643b504d0  Get spec preview to work
2956c3f5a17845469c6c7e32435f9c1e9f985c52  Test
b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a  .

-- 
View it on GitHub:
https://github.com/whatwg/webidl/pull/1568/changes/41f898a6bd883b604c3e279f03b70789fa8bb7b4..b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b>
Aquileo | Re: [whatwg/webidl] Add an extended attribute to allow propagating TC39's AsyncContext (PR #1568)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b2026-08-04T12:36:39+00:00
@nicolo-ribaudo pushed 4 commits.

695575c626f9b1c99bd00258d543f943a1596ee6  Add an extended attribute to allow propagating TC39's AsyncContext
5bddce72eaee95292226c5016caecf6643b504d0  Get spec preview to work
2956c3f5a17845469c6c7e32435f9c1e9f985c52  Test
b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a  .

-- 
View it on GitHub:
https://github.com/whatwg/webidl/pull/1568/changes/41f898a6bd883b604c3e279f03b70789fa8bb7b4..b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b>
Aquileo | Re: [whatwg/webidl] Add an extended attribute to allow propagating TC39's AsyncContext (PR #1568)Nicolò Ribaudonotifications@github.commid:whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b2026-08-04T12:36:39+00:00
@nicolo-ribaudo pushed 4 commits.

695575c626f9b1c99bd00258d543f943a1596ee6  Add an extended attribute to allow propagating TC39's AsyncContext
5bddce72eaee95292226c5016caecf6643b504d0  Get spec preview to work
2956c3f5a17845469c6c7e32435f9c1e9f985c52  Test
b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a  .

-- 
View it on GitHub:
https://github.com/whatwg/webidl/pull/1568/changes/41f898a6bd883b604c3e279f03b70789fa8bb7b4..b8bc400f0e0a1f1c5f4f168bbd3860148d488b9a
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/pull/1568/before/41f898a6bd883b604c3e279f03b70789fa8bb7b4/after/b>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839/c5173078528@github.com2026-08-04T00:11:25+00:00
monica-ch left a comment (w3c/ServiceWorker#1839)

@yoshisatoyanagisawa Can you also review this when you get a chance!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839#issuecomment-5173078528
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839/c5173078528@github.com>
Aquileo | Re: [w3ctag/design-reviews] Question: can we better define the intention of the "disable scripting" user preference (Issue #1247)Dominic Farolinonotifications@github.commid:w3ctag/design-reviews/issues/1247/5170576066@github.com2026-08-03T19:04:54+00:00
domfarolino left a comment (w3ctag/design-reviews#1247)

Thanks for filing this. +1 to this question; I can provide some more background as I raised the progenitor of this in the WHATWG Matrix chat.

We (Chromium) got a request to disable declarative [WebMCP](https://github.com/webmachinelearning/webmcp) when scripting is disabled, so that a document with scripting disabled could not register WebMCP tools and expose them to normal documents, which could "run" the tools in the script-less documents. While I'm not opposed to this request, it got us thinking: what should and should not be allowed to happen in a document where scripting is disabled. Should it not be possible to register functionality that is "runnable" from another, colluding document that *has* scripts enabled? Is it about privacy and exfiltration instead?

Having clear criteria to check new features against when determining if they should be enabled or disabled with scripting would clear a lot of this up.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1247#issuecomment-5170576066
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1247/5170576066@github.com>
Aquileo | Re: [w3ctag/design-reviews] WG New Spec: DID Resolution (Issue #1157)Heather Flanagannotifications@github.commid:w3ctag/design-reviews/issues/1157/5169246255@github.com2026-08-03T16:49:43+00:00
hlflanagan left a comment (w3ctag/design-reviews#1157)

Hi, sorry for the delay on this one. 

I don't see any blockers for this going ahead to CR. While you continue the work, however, I have two points for you to consider:

One thing I noticed outside dereferencing: the resolver architecture describes bindings as independent ways of exposing the abstract resolution function, including local libraries, command-line tools, and HTTP APIs. It also defines a network-based resolver as a resolver that additionally implements the HTTP(S) binding. But the HTTP binding then says that “all conforming DID resolvers MUST implement the GET version” of that binding. Is that intended? As written, it seems to require even local/library implementations to expose an HTTP endpoint, which doesn't seem consistent with the architecture described earlier.

In the security section, is the statement that DID resolution does not involve authentication or authorization intended to describe the abstract resolution operation rather than resolver deployments or bindings? The current wording seems broader than the HTTP binding, which explicitly contemplates authenticated requests.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1157#issuecomment-5169246255
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1157/5169246255@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: Lightweight and Conditional Tracing for long animation frame timing API (Issue #1224)Heather Flanagannotifications@github.commid:w3ctag/design-reviews/issues/1224/5169175695@github.com2026-08-03T16:42:34+00:00
hlflanagan left a comment (w3ctag/design-reviews#1224)

Hi @guohuideng2024 - did you or the group have any response to the TAG's comments?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1224#issuecomment-5169175695
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1224/5169175695@github.com>
Aquileo | Re: [w3ctag/design-reviews] Incubation: Prerendering cross-origin iframes (Issue #1207)Heather Flanagannotifications@github.commid:w3ctag/design-reviews/issues/1207/5169162219@github.com2026-08-03T16:41:10+00:00
hlflanagan left a comment (w3ctag/design-reviews#1207)

Hi @yoichio - checking in on this. Any further updates?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1207#issuecomment-5169162219
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1207/5169162219@github.com>
Aquileo | Re: [w3ctag/design-reviews] Media Capture Capability Elements (part of PEPC) (Issue #1218)Ehsan Toreininotifications@github.commid:w3ctag/design-reviews/issues/1218/5166983302@github.com2026-08-03T13:33:04+00:00
toreini left a comment (w3ctag/design-reviews#1218)

Thanks for submitting this work. We have the following concerns regarding this spec and request clarification:

1) The spec should require that the mute trigger be _origin-bound_ and _device-bound_. (This is for consistency with [Media Stream permission policy requirements](https://w3c.github.io/mediacapture-main/#permissions-integration:~:text=values%2E-,Then,true,-%2E).)

2) Whether using `getUserMedia()` or the latest version of this proposal, every app that offers to "mute" a device retains the prerogative to unmute that device at any moment. Do you see any opportunities to provide security guarantees to users, that their camera will not suddenly be re-activated without their consent? (following the [encoureged behaviour in Media Stream permission policy](https://w3c.github.io/mediacapture-main/#permissions-integration:~:text=Agent%3A-,The%20User%20Agent%20is,met))

  We feel that there should be potential for UA interaction to reassure users that once their camera/audio is muted, it will not be suddenly re-activated without their consent. Does this design leave some space to explore solutions to this problem? Do you think it would be possible to standardize such guarantees?

3) This spec will fomalise the following action-sequence: _mute &rarr; unmute &rarr; mute_. As the mute action is already fomally defined in [Media Capture and Streams](https://w3c.github.io/mediacapture-main/#track-muted). We request the spec developers consider a clear definition for the action sequence to avoid confusion.

Furthermore, we have some observations regarding the explainer:

* There are two links included: one related to PEPC (which was a separate TAG review) and another for `<usermedia>`. The explainer for the latter, which we assumed is the focus of this review, does not follow the standard format. It lacks sections such as "S\&P considerations" and "alternatives considered" - these are important in order for readers and reviewers to understand the trade-offs made during the design of the proposal. Can you please update the explainer to be consistent with the [explainer format](https://www.w3.org/TR/explainer-explainer/)?
 
 **_Note: You may find the similar discussions in [the `<geolocation>` explainer](https://github.com/WICG/PEPC/blob/main/geolocation_explainer.md) helpful._**
    

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1218#issuecomment-5166983302
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1218/5166983302@github.com>
Aquileo | Re: [WICG/webcomponents] Reference Target "phase 2": seeking feedback and use cases (Issue #1111)woody-linotifications@github.commid:WICG/webcomponents/issues/1111/5163087489@github.com2026-08-03T06:33:47+00:00
woody-li left a comment (WICG/webcomponents#1111)

I've defined a form-field element, provided field label and validation info.
DOM example:
```HTML
<x-form-field id="user-name" label="User name:">
  #shadowDom
    <label>User name</label/>
    <slot />
    <section id="message">xxx</section>

  #lightDom
    <input aria-labelledby="user-name" aria-errormessage="user-name" />
</x-form-field>
```

Expected: the `labelledby` reference to the label element, and the `errormessage` reference to the message element.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1111#issuecomment-5163087489
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1111/5163087489@github.com>
Aquileo | Re: [whatwg/fetch] Automatic decompression should sanitize `Content-Encoding` and `Content-Length` headers from the response (Issue #1729)Jimmy Wärtingnotifications@github.commid:whatwg/fetch/issues/1729/5158251191@github.com2026-08-02T13:37:43+00:00
jimmywarting left a comment (whatwg/fetch#1729)

i don't think this two should be removed if fetching raw bytes became possible one day.

they are still desirable based on: https://github.com/nodejs/undici/issues/1462 and https://github.com/whatwg/fetch/issues/1524 upvotes and use cases

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1729#issuecomment-5158251191
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1729/5158251191@github.com>
Aquileo | Re: [whatwg/fetch] Add getStructured/setStructured to Headers (PR #1943)Julian Reschkenotifications@github.commid:whatwg/fetch/pull/1943/c5157538934@github.com2026-08-02T11:31:27+00:00
reschke left a comment (whatwg/fetch#1943)

Any reason why this needs to be baked in into `headers`? Woun't something based on strings be simpler?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1943#issuecomment-5157538934
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1943/c5157538934@github.com>
Aquileo | Re: [whatwg/fetch] Add getStructured/setStructured to Headers (PR #1943)Julian Reschkenotifications@github.commid:whatwg/fetch/pull/1943/c5157538934@github.com2026-08-02T11:31:27+00:00
reschke left a comment (whatwg/fetch#1943)

Any reason why this needs to be baked in into `headers`? Woun't something based on strings be simpler?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1943#issuecomment-5157538934
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1943/c5157538934@github.com>
Aquileo | [w3c/FileAPI] Editorial updates around encoding and MIME types (PR #223)Domenic Denicolanotifications@github.commid:w3c/FileAPI/pull/223@github.com2026-08-01T06:50:51+00:00
- "encodingName" was used as an argument, but this was confusing, because it was actually referring to an encoding's label (e.g. "utf8"), instead of its canonical name ("UTF-8").
- The mimeType argument was said to be optional, but all callers always passed it, so that was dead code.


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/w3c/FileAPI/pull/223.html" title="Last updated on Aug 1, 2026, 6:50 AM UTC (0e80c93)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/FileAPI/223/cd1d1da...0e80c93.html" title="Last updated on Aug 1, 2026, 6:50 AM UTC (0e80c93)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/FileAPI/pull/223

-- Commit Summary --

  * Editorial: use encodingLabel for algorithm arguments
  * Editorial: require a MIME type when packaging data

-- File Changes --

    M index.bs (16)

-- Patch Links --

https://github.com/w3c/FileAPI/pull/223.patch
https://github.com/w3c/FileAPI/pull/223.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/223
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/pull/223@github.com>
Aquileo | [w3ctag/design-reviews] Incubation: (Issue #1252)udascojonard03-jpgnotifications@github.commid:w3ctag/design-reviews/issues/1252@github.com2026-07-31T23:49:54+00:00
udascojonard03-jpg created an issue (w3ctag/design-reviews#1252)

### Explainer

https://

### The explainer

- [x] Includes the information requested by the [Explainer Explainer](https://w3ctag.github.io/explainer-explainer/#introduction).
- [x] Follows the [Web Platform Design Principles](https://www.w3.org/TR/design-principles/).
- [ ] Includes or links to answers to the [Security/Privacy Questionnaire](https://www.w3.org/TR/security-privacy-questionnaire/).
- [ ] Describes user research you did to validate the problem and/or design.

### Where and by whom is the work is being done?

- GitHub repo:
- Primary contacts:
  - $name (@-mention), $organization/s, $role in developing feature
  - <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
- Organization/project driving the design:
- This work is being funded by:
- Incubation and standards groups that have discussed the design:
  - {{ABC CG}} <!-- Include a link to minutes or issues in this group if possible. -->
  - {{DEF WG}}
- Standards group(s) that you expect to discuss and/or adopt this work when it's
  ready: <!-- "unknown" if not known -->


### Feedback so far

- Multi-stakeholder feedback:
  - Chromium comments:
  - Mozilla comments: https://github.com/mozilla/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - WebKit comments: https://github.com/WebKit/standards-positions/issues/NNN <!-- And/or other places they've given feedback -->
  - {{...include feedback/review from developers, implementers, civil society, and others}}
- Major unresolved issues with or opposition to this design:


### You should also know that...

_No response_

<!-- Content below this is maintained by @w3c-tag-bot -->
---

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1252


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1252
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1252@github.com>
Aquileo | [w3c/ServiceWorker] Editorial: queue a task to reject promise in InstallEvent.addRoutes (PR #1839)Monica Chintalanotifications@github.commid:w3c/ServiceWorker/pull/1839@github.com2026-07-31T22:23:54+00:00
This is a small follow-up related to #1740.

The rejection path inside the `[[service worker queue]]` block of `InstallEvent.addRoutes()` was calling `Reject |promise|` directly from a parallel queue. Rejecting a JS promise from a parallel queue crosses the event-loop/parallel boundary and is the same pattern that #1740 flags across the spec.

This PR:

- Wraps the rejection in a `Queue a task` on the service worker's event loop, using the DOM manipulation task source, matching the existing resolve path a few lines below.
- Adds an `Abort these steps.` after the rejection queue so we don't fall through to `Set |serviceWorker|'s list of router rules` and the follow-up resolve on the same promise.
- Hoists `Let |serviceWorkerEventLoop| be the current global object's event loop.` above the `[=queue/Enqueue=]` block so both the reject and resolve tasks can reference it (and so the event loop is captured on the event-loop side, not inside the parallel queue).

Editorial only, no normative behavior change beyond making the failure path stop after rejecting (which it should already do — the previous text would set the rules and resolve after rejecting, which was a bug in the failure path).

Refs: #1740


<!--
    This comment and the below content is programmatically generated.
    You may add a comma-separated list of anchors you'd like a
    direct link to below (e.g. #idl-serializers, #idl-sequence):

    Don't remove this comment or modify anything below this line.
    If you don't want a preview generated for this pull request,
    just replace the whole of this comment's content by "no preview"
    and remove what's below.
-->
***
<a href="https://pr-preview.s3.amazonaws.com/monica-ch/ServiceWorker/pull/1839.html" title="Last updated on Jul 31, 2026, 10:23 PM UTC (40bc41b)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/w3c/ServiceWorker/1839/e91ddff...monica-ch:40bc41b.html" title="Last updated on Jul 31, 2026, 10:23 PM UTC (40bc41b)">Diff</a>
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/ServiceWorker/pull/1839

-- Commit Summary --

  * Editorial: queue a task to reject promise in InstallEvent.addRoutes

-- File Changes --

    M index.bs (7)

-- Patch Links --

https://github.com/w3c/ServiceWorker/pull/1839.patch
https://github.com/w3c/ServiceWorker/pull/1839.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1839
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1839@github.com>
Aquileo | Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)Andrew Sutherlandnotifications@github.commid:w3c/ServiceWorker/pull/1764/c5147634050@github.com2026-07-31T21:30:40+00:00
asutherland left a comment (w3c/ServiceWorker#1764)

This seems like a good change; we always wanted this capability.  I do like that this provides UAs the ability to potentially bias towards always going to cache based on user preference but also having the latitude to use the network for latency reasons.

One question I think this capability inherently raises is "If we are fetching something from the network and it's not in the cache, does it get put in the cache? Or can the cache entry be updated with the network result?".  The current answer is  "no" and the existing [understanding cache lifetimes](https://w3c.github.io/ServiceWorker/#cache-lifetimes) prose already incidentally answers the question, but it could be nice to add some non-normative text around [InstallEvent](https://w3c.github.io/ServiceWorker/#installevent-interface) to maybe reiterate that point.

Refreshing my memory from https://github.com/WICG/service-worker-static-routing-api/blob/main/final-form.md I do see that there is an updatedCacheName mechanism for stale-while-revalidate and it does seem desirable that any cache updating would be quite explicit in that way.  But since we also don't really have any automatic eviction mechanism, leaving it to the SW itself to perform any content updates does seem appropriate rather than risking making it easy to create an ever-growing cache.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764#issuecomment-5147634050
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/c5147634050@github.com>
Aquileo | [w3c/editing] Actually return true from indent command (PR #547)Psychpsyo (Cameron)notifications@github.commid:w3c/editing/pull/547@github.com2026-07-31T20:55:55+00:00
It can't just not return a value.
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/editing/pull/547

-- Commit Summary --

  * Actually return true from indent command

-- File Changes --

    M docs/execCommand/index.html (3)

-- Patch Links --

https://github.com/w3c/editing/pull/547.patch
https://github.com/w3c/editing/pull/547.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/pull/547
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/pull/547@github.com>
Aquileo | Re: [w3c/clipboard-apis] Remove clipboardchange event (and replace it possibly with a promise returning method) (Issue #228)Dan Clarknotifications@github.commid:w3c/clipboard-apis/issue/228/issue_event/28786729938@github.com2026-07-31T16:24:38+00:00
Closed #228 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/228#event-28786729938
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issue/228/issue_event/28786729938@github.com>
Aquileo | Re: [w3c/clipboard-apis] Remove clipboardchange event (and replace it possibly with a promise returning method) (Issue #228)Dan Clarknotifications@github.commid:w3c/clipboard-apis/issue/228/issue_event/28786729938@github.com2026-07-31T16:24:38+00:00
Closed #228 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/228#event-28786729938
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issue/228/issue_event/28786729938@github.com>
Aquileo | Re: [w3c/clipboard-apis] ClipboardChange even spec: Callout details for cross-origin iframes and fencedframes (Issue #226)Dan Clarknotifications@github.commid:w3c/clipboard-apis/issue/226/issue_event/28786557936@github.com2026-07-31T16:20:35+00:00
Closed #226 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/226#event-28786557936
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issue/226/issue_event/28786557936@github.com>
Aquileo | Re: [w3c/clipboard-apis] ClipboardChange even spec: Callout details for cross-origin iframes and fencedframes (Issue #226)Dan Clarknotifications@github.commid:w3c/clipboard-apis/issue/226/issue_event/28786557936@github.com2026-07-31T16:20:35+00:00
Closed #226 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/clipboard-apis/issues/226#event-28786557936
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/clipboard-apis/issue/226/issue_event/28786557936@github.com>