"timer initialization steps" perform EnsureCSPDoesNotBlockStringCompilation with undefined timer value

[fred-wang]

What is the issue with the HTML Standard?

cc @lukewarlow @koto @nicolo-ribaudo

See https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#dom-setinterval

Step 9.6.3 reads

Perform EnsureCSPDoesNotBlockStringCompilation(realm, « », handler, handler, timer, « », handler). If this throws an exception, catch it, report it for global, and abort these steps.

but timer is not defined in previous steps.

It seems https://w3c.github.io/webappsec-csp/#can-compile-strings instead expects the value "TIMER".

(Note that function is also called from https://html.spec.whatwg.org/multipage/webappapis.html#hostensurecancompilestrings(realm,-parameterstrings,-bodystring,-codestring,-compilationtype,-parameterargs,-bodyarg), which passes the enum value from https://tc39.es/proposal-dynamic-code-brand-checks/#sec-hostensurecancompilestrings)

[lukewarlow]

This was decided as the format to use when I was upstreaming changes. There's no consistency with how enum values are written at the minute.

[domenic]

I would indeed prefer to match ES's formatting and use "TIMER". I guess we should do all the enums at once though.

It'd be even better if we could link to the definitions of the enum values in the ES spec, but I don't know if they have proper <dfn>s.

[annevk]

I did look at this when reviewing, but the problem is that they use <emu-const> with text-transform: uppercase. We would have to do something evuivalent so you get the same experience/semantics.

[domenic]

I'm not sure the semantics/experience is significantly different... the end effect that, e.g., AT or users see, is just the uppercase text. And it's not clear there's any "semantics" being conveyed by the implementation choice they've made.

[annevk]

Depending on what browser you copy from, you might get lowercase or uppercase text, for instance. If they change their style sheet, this could also change.

@syg @ljharb thoughts on what we should do? Perhaps ECMAScript shouldn't use text-transform for this?

[syg]

I guess I'd be fine with actually typing uppercase. Looping in other 262 editors @bakkot and @michaelficarra.

[bakkot]

I forget why we decided to use a text transform instead of just making it actually uppercase to begin with. I'm fine with changing the source if there's not a compelling reason not to.

Re: copying, we're considering having ecmarkup add some hidden text with tildes so these values would copy as ~timer~, though that's mostly for the convenience of people copying algorithm steps into comments in tests or implementations.

[michaelficarra]

We only did it as a CSS text-transform because we were playing around with other possible presentations before we settled on that. I don't really like changing the case in the ECMA-262 document since it's entirely presentational (non-semantic) and it will make existing instances of copy/paste into comments and other places stale. For the HTML spec document, I would probably match 262, personally: all lowercase in the document and text-transform: uppercase in the CSS.