This is currently not an error:
technically css doesn't care about newlines (as far as I know) so without permitted-values-for-properties parsing we either keep this in, or we add a soft-rule that newlines break up values. Which would have the most educational value?
I think that adding the soft rule provides the least educational value for a few reasons:
If you put a valid value for font-size in your example, like 30px, it doesn't actually get applied, because the browser's own CSS parser gets confused when it doesn't see the semicolon after the previous CSS value. So that's a very clear case of the user intending something, the browser silently failing, and the user having no feedback to tell them about what needs fixing. It'd be okay for our own soft rules to mimick those of a real browser--for instance, the way we silently ignore invalid character entity references--but in this case our soft rule wouldn't mirror the soft rules of "the real world", thus providing no value.
Because Slowparse sees font-size as a CSS value rather than a CSS property, it becomes hard for the editor to provide context-sensitive help on it.
Oh, wait, maybe I misinterpreted your suggestion. Are you suggesting that we throw an error if we see a newline in a CSS property value? I'd actually be okay with that; I don't think I've ever seen newlines in CSS property values "in the wild", so it seems okay to assume that the user has forgotten a semicolon rather than assuming that they are putting a newline in their CSS property value for code formatting purposes. Once we add the ability for slowparse to issue non-fatal warnings rather than errors, we can turn this into a warning.
How does that sound?
for the moment we can leave it as "works as intended" but it might be nice, in the future, to improve on this. closing it for now, though.