Matt Ström-Awn

I haven't written a translator, so admittedly I'm not the best judge of computational complexity. That said ... So far as I can tell in the current spec, for single-value...

> What about : > 123e3px I think this could be avoided by disallowing scientific notation — I can't think of any cases where values would be so large or...

> That would mean that this specification needs to define its own number type completely. I don't see why that's the case, since we're discussing this in the context of...

Before going deeper down the rabbit hole, I want to enthusiastically agree that splitting numbers and units would make the spec simpler and make it easier for parsers to rely...

Great points on the parsing algorithm. I think any recommendation by the spec here would be non-normative, but it's good to see how different strategies to parsing apply. Our microformat...

Wanted to see if I could come up with a formal proposal to incorporate some of the feedback here! I really want to get multiple shadows into the spec, since...

+1 to letting this be solved by tools in `$extensions` or git or underlying database - no need for an additional status or state.

I was initially very pro-hex, but seeing the comments I have been convinced that in order to define a color accurately, an author should use the proposed colorspace + channels/components...

Oh I just read all of the discussion on #137, and it seems like there's a lot of convergence. Generally speaking, I sense a general consensus around: 1. Allowing authors...

> What is the practical benefit of allowing colorSpace to be anything? It gives authors and parsers the maximum latitude, and makes it much easier for this format to be...