| 00:00 | <jamesr> | yes, you can't depend on DOMContentLoaded necessarily blocking paint |
| 00:02 | <jamesr> | d'oh |
| 02:18 | <MikeSmith> | Domenic: dunno how you came across https://stackoverflow.com/questions/32656594/domcontentloaded-blocks-page-loading (I had earlier today as well, just from browsing through new questions) but I read through some of his other answers and some others of them are also pretty clever |
| 03:35 | <JonathanNeal> | TabAtkins: thinking alot about your comments regarding write-svg and your suggestion to create elements with further at-rules, like @rect. That seems like too many custom at-rules and <font-face> / @font-face seems particularly troubling. In the odd event you’re around, I was kicking around some other solutions. |
| 03:37 | <JonathanNeal> | One would be to treat inner @svg at-rules as selectors for the element, like @svg id_of_svg { @svg rect#thing {} } // generates something like <svg><rect id=“thing”/></svg> |
| 04:08 | <TabAtkins> | JonathanNeal: "Number of at-rules" isn't significant. |
| 04:09 | <TabAtkins> | <font-face> can be safely ignored; we're dropping it from SVG in the first place. |
| 04:18 | <JonathanNeal> | So it's okay to have a few dozen at rules? |
| 04:19 | <TabAtkins> | They're all scoped to only be valid within @svg. |
| 04:19 | <TabAtkins> | So sure. |
| 07:05 | <JonathanNeal> | Should it allow any node or limit itself to a list of valid SVG nodes? @svg <name> { @element-Name { ... } } |