WICG / observable

Observable API proposal
https://wicg.github.io/observable/
Other
543 stars 12 forks source link

Spec's internal CSS sets colors without regard to dark mode #104

Closed tabatkins closed 5 months ago

tabatkins commented 5 months ago

In particular, there's a dt rule that sets color: black for some reason, which renders a bunch of text invisible in dark mode.

I'm also not sure why the spec is using the .xxx class manually, when that's just a WHATWG-ism for the .issue class that gets auto-generated when you write Issue: text here. If you use Issue: ... it'll get colored correctly.

domfarolino commented 5 months ago

In particular, there's a dt rule that sets color: black for some reason, which renders a bunch of text invisible in dark mode.

Thanks for bringing this to my attention. This must've been in the old WHATWG spec.css that I've been copying from spec to spec for a while. I'll remove this line specifically to fix the dark mode issue, but at some point it would probably be best to actually see what all from the WHATWG-included styles are necessary / not relevant anymore.

I'm also not sure why the spec is using the .xxx class manually, when that's just a WHATWG-ism for the .issue class that gets auto-generated when you write Issue: text here. If you use Issue: ... it'll get colored correctly.

Hmm, Issue: always seemed to me like something that you'd formally reference a GitHub issue in, for follow-up, while XXX box feels to me like an inline TODO that might not need a formal GitHub issue (and doesn't need to get accumulated at the bottom of the spec, or have a separate uniquely-linkable paragraph ID).

For example, for all of the operators that have not been spec'd yet, I don't think we'd need a GitHub issue for "Spec map()", "Spec forEach()" etc, and uniquely-linkable paragraphs for each, since they appear right in the method definition. Maybe my heuristic for choosing which to use (Issue: vs XXX) is a little wonky though.

tabatkins commented 5 months ago

Hmm, Issue: always seemed to me like something that you'd formally reference a GitHub issue in, for follow-up, while XXX box feels to me like an inline TODO that might not need a formal GitHub issue (and doesn't need to get accumulated at the bottom of the spec, or have a separate uniquely-linkable paragraph ID).

I mean, you're free to do that if you want. ^_^ But the WHATWG specs just use .xxx for issues, for historical reasons, and have an option set that causes Bikeshed to use that class for Issue: ... blocks (instead of .issue, the default).

And the division you're referencing isn't observed by any other specs I know of. You can reference a GH issue in an Issue: block (using Issue(#1234): ... syntax), but it's also used for inline issues, of exactly the sort of thing you're giving examples of. Such things don't need to be collected in the issues index or given an ID, sure, but they're not harmed by it either. ^_^