| 00:23 | <MikeSmith> | TabAtkins: about @charset, is it valid per the relevant CSS specs? |
| 00:24 | <MikeSmith> | if not, is there normative statement somewhere about it not being valid? |
| 00:24 | <MikeSmith> | I ask because at https://drafts.csswg.org/css-syntax-3/#charset-rule I see the following notes: |
| 00:24 | <MikeSmith> | > Note: The algorithm to parse a stylesheet explicitly drops the first @charset rule from the document, before the stylesheet is grammar-checked, so valid rules that must appear first in the stylesheet, such as @import, can still be preceded by an (invalid) @charset rule without making themselves invalid. |
| 00:25 | <TabAtkins> | The answer is slightly complex: @charset, the at-rule, is invalid. But @charset, the ASCII byte sequence, is allowed at the start of the stylesheet, according to some stringent requirements. |
| 00:25 | <MikeSmith> | OK |
| 00:25 | <TabAtkins> | AKA, there's no such thing as a @charset at-rule, but CSS's inline encoding declaration happens to look similar to an at-rule. ^_^ |
| 00:25 | <MikeSmith> | hai |
| 07:43 | <annevk> | It probably shouldn't say that it drops the first @charset rule then? but that it drops a sequence resembling such a rule? |
| 19:18 | <TabAtkins> | @annevk Nah, it's accurate. This stuff happens, conceptually, before grammar-checking. Everything at-rule-shaped parses into an at-rule, and then later invalid ones get thrown out. So we first recognize the byte sequence as an encoding declaration, then parsing runs and turns it into an at-rule, then grammar-checking runs and discards it as invalid (or would, if we didn't first throw it out). |
| 20:35 | <annevk> | When do you throw it out? |
| 21:27 | <TabAtkins> | annevk: https://drafts.csswg.org/css-syntax/#parse-stylesheet |
| 21:27 | <TabAtkins> | Step 3 |