- From: andruud via GitHub <sysbot+gh@w3.org>
- Date: Mon, 29 Apr 2019 21:42:17 +0000
- To: public-houdini-archive@w3.org
I had my doubts about this at first too (hence #778), but if we change `div.style.setProperty("--foo", "bar")` to never validate, it will be inconsistent with how `setProperty` works for regular properties. We create an inconsistency somewhere either way. For Typed OM, the spec for `.parse()` and `.set()` currently automatically works for registered custom properties, because they behave consistently with standard properties. If we do something like (3), we would need to handle registered custom props as a special case (e.g. if `.parse()` doesn't throw for invalid grammar, it needs to return _something_. A ` CSSUnparsedValue`, probably, which seems kind of lame if the property in question is registered as e.g. a `<length>`). (CSS _Untyped_ OM Level 1)? :P I do like that the current approach (4, I suppose) does seem to work quite consistently with CSS Typed OM by default. I also think it's appropriate to give consistency with TypedOM extra weight in this matter, since gaining a type (with all that it entails) is the main point of css-properties-values-api. (Though I'm not sure if (4) really is the least inconsistent approach, or if I just got used to how it works, accepted it, and moved on). -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/880#issuecomment-487754615 using your GitHub account
Received on Monday, 29 April 2019 21:42:18 UTC