- From: Praveen Puglia <praveenpuglia@gmail.com>
- Date: Thu, 25 Feb 2016 21:29:21 +0530
- To: darkdragon <darkdragon-001@web.de>
- Cc: www-style list <www-style@w3.org>
Received on Thursday, 25 February 2016 16:00:11 UTC
> > Further the choice for "--" which is the same for browser-specific > properties like "--webkit-border-radius" etc. is also confusing. I don't think vendor prefixes ever start with a double dash. They are always in the form of *-[vendor]-property-name. *So no point of confusing there. I think the way of defining fallbacks in css is first putting the fallback > and then providing an alternative if supported. That's not always true. For example - *font-family*. It contains fallbacks as a set of comma separated values. The problem with that would be to modify width/height or any property to have the capability to accept multiple values and understand what a fallback is. Which doesn't look like a good solution. In any of the cases, the properties now have to have this capability of "try this...if failed, try that" instead of just overriding stuff. From that perspective, it sounds safer to let the *var() *take care of defaults/fallbacks instead of modifying existing properties?
Received on Thursday, 25 February 2016 16:00:11 UTC