- From: Chris Eppstein via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jun 2019 23:10:55 +0000
- To: public-houdini-archive@w3.org
> A custom function could return an empty CSSUnparsedValue to indicate that it finished correctly, but just didn't output anything. That would have different semantics than what I described. The function would output nothing and the resulting output might still be a legal value for the declaration, whereas a value that contains null would have the entire declaration quietly declared invalid. Both are important use cases. > Can you give some example use-cases? You're asking why booleans are useful when writing code for separation of different concerns? Like I could write a function that determines if two colors meet some accessibility guidelines for contrast. it would return true or false. Another function (like the `--if` function above) can then take that boolean and perform different outputs. The logic for how to handle the color contrast issue might not be the same everywhere so delegating that to the stylesheet author is better than coupling it to the contrast determination function. > Can trailing arguments be made optional? > > Currently no, you have to predeclare your arity. I don't know fully understand what "opts out of parsing entirely so you can do something more complicated on your own." means but it sounds pretty annoying just to be able to omit what should be an optional parameter. > > This is something we'll fix over time, definitely, and apply it to all the Houdini function things. I don't understand why this spec wouldn't drive this change instead of being beholden to it... I suspect it has to do with stuff that seems really clear if you understand how the w3c standards process works but I don't 🤷♂ > You need lazy eval in JS (and I assume Sass) because running code can have side effects. No, this is useful purely from the perspective of functions having constraints on what is a legal input argument. The conditional can verify the value is legal to pass to the function and then only invoke the function if it is. Overall what I'm trying to understand is what is the mechanism for developers who create custom functions to delegate things like error recovery to the stylesheet author. I've assumed there's no built-in `try`-`catch` mechanism so that means there needs to be some basic conditionals and branching logic. If CSS isn't going to provide those as a standard library, it will be up to the community to construct a library that can be re-used. > Is there thus still a need for generics? It would be really great if using functions didn't cause a declaration to stop conforming to normal css declaration resolution thus allowing the cascade for that property to be relied upon instead of falling back to `initial`. My understanding was that a return type would help enable that. If so, I think generics are going to be very helpful. If sass is a guide, custom functions will get a lot of use, but I don't see an error recovery story here and I think the cascade should be part of that story without good error recovery, I suspect custom functions will be built with a footgun for authors. -- GitHub Notification of comment by chriseppstein Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/857#issuecomment-500066630 using your GitHub account
Received on Friday, 7 June 2019 23:10:57 UTC