A global <style> before a <style scoped> silently drops the scoped CSS

[tylerturdenpants]

Summary

When a template contains a plain <style> element before a <style scoped> one, the scoped block's CSS is silently discarded: no stylesheet is emitted for it, no classes are collected from it, and no error or warning is produced.

Cause

src/build/template-plugin.js:119 selects the style element to extract by tag alone, ignoring attributes:

let styleTag = node.body.find(
  (n) => n.type === 'ElementNode' && n.tag === 'style',
);

if (hasScopedAttribute(styleTag)) {

With a global <style> first, find returns that one, hasScopedAttribute is false, and the whole extraction branch is skipped -- so addInfo and request.inline.create never run for the scoped block. The ElementNode visitor then still matches the scoped element later in the traversal and returns null for it, removing it from the compiled template.

Net effect: the scoped CSS is deleted from the output and never emitted anywhere.

Reproduction

<template>
  <style>
    .global { color: red; }
  </style>

  <style scoped>
    .scoped { color: blue; }
  </style>
</template>

.scoped is dropped. Reversing the order of the two blocks makes it work.

The same applies to a second <style scoped> in one template: only the first style element is ever considered.

Suggested fix

Find the first scoped style element rather than the first style element:

let styleTag = node.body.find(
  (n) => n.type === 'ElementNode' && n.tag === 'style' && hasScopedAttribute(n),
);

That leaves the existing "only at the root" and nested-block errors intact. If supporting more than one <style scoped> per template is out of scope, an explicit error for the second one would at least be louder than dropping it.

How this surfaced

Found while reviewing #422, which adds a stylelint customSyntax for inline blocks. That syntax lints every root-level <style scoped>, so it reports problems in CSS the build silently discards. Rather than teach the linter to replicate this behaviour, #422 documents the divergence and points here.

[tylerturdenpants]

Re-checked this against #422 as it stands now. Still reproduces, and #422 landing makes it worse rather than fixing it.

Still reproduces

Using the existing template-plugin.test.ts harness:

Template	.ember-scoped.css import emitted	scoped CSS survives
global <style> first	false	false
<style scoped> first	true	true
two <style scoped> blocks	.first true, .second false

No error or warning in either failing case.

Two stale references in the description above

5ed79dc in #422 moved hasScopedAttribute, getLangAttribute and hasInlineAttributeWithoutLang out of template-plugin.js into a new src/build/style-tag.js. So:

• the find is now at template-plugin.js:137, not :119
• hasScopedAttribute is imported rather than local

The logic is byte-identical and the suggested fix still applies verbatim, since the name is in scope at that call site either way.

The cause is a bit sharper than I wrote it

The build already disagrees with itself. Two visitors read "is this a scoped style block?" and get different answers:

• Template visitor (emits the stylesheet): node.body.find((n) => n.type === 'ElementNode' && n.tag === 'style') — only ever considers the first style element, and bails if that one is not scoped.
• ElementNode visitor (removes the tag from output): hasScopedAttribute(node) — matches every scoped element and returns null to delete it.

So every <style scoped> gets deleted from the compiled template, but at most one gets its CSS emitted. The find isn't really the bug on its own; it's the side that loses an argument the build is having with itself.

What #422 changes

#422's customSyntax walks all of ast.body and lints every root-level <style scoped>, so it takes the ElementNode visitor's side. That makes it a third reader of the same question, and the stylesheet emission the only one out of step.

Practical effect: this stops being silent. Today the CSS just vanishes. After #422 the same CSS is linted — warnings, and --fix edits, on a block that never ships. "I fixed six warnings in CSS that has no effect" is a worse first impression than the silence, and it is the one consequence the original report didn't anticipate. #422 documents it as a known limitation and links here, but that's a signpost, not a fix.

Suggested fix, revised

The one-line find fix in the description still works and is still an improvement. But #422 adds a better option: style-tag.js is now the single place both packages read scoped and lang from, and block selection is the obvious next thing to move in — something like:

export function findScopedStyleBlocks(templateBody) {
  return templateBody.filter(
    (n) => n.type === 'ElementNode' && n.tag === 'style' && hasScopedAttribute(n),
  );
}

Then both build visitors and the linter select blocks the same way by construction, instead of three independent implementations agreeing by luck. That also decides the multiple-blocks question explicitly rather than by omission: either emit all of them, or throw on the second, but not silently drop it.

That option only exists once #422 lands, so this is probably worth doing after it rather than before.