- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Sun, 09 Jun 2019 19:44:27 +0000
- To: public-houdini-archive@w3.org
> That would have different semantics than what I described. Ah, you didn't describe in enough detail for me to tell which you meant. ^_^ If you just want it to invalidate the property it's found in, throw in the worklet (or I guess return a non-Typed OM value, but throwing will definitely work). > You're asking why booleans are useful when writing code for separation of different concerns? Yes, CSS doesn't have tests like that, so I was curious. Remember, I have very little experience with Sass actually; also, I responded to this part before I read down to your `if()` example. ^_^ Makes sense tho. > 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. It means you just get handed the arguments as a string, and have to parse them on your own. Yes, it is annoying. But see the following point... > I don't understand why this spec wouldn't drive this change instead of being beholden to it... I'm editor on both specs, so neither's beholden to the other. But I'm also trying to make sure the feature is reasonably implementable quickly, so I'm keeping it hovering around an MVP. There are *several* additional features I want to add to custom functions that'll also wait for v2 most likely! But further, optional arguments in CSS functions don't currently have a widespread pattern to follow. The contents of a function are, philosophically, no different from the value of a property, and so generally follow property conventions for optionality on a per-component basis. Coming up with a new, and intended-to-be-consistent, way to handle variable-arity functions isn't something I want to commit to hanging on this proposal's v1. There's a lot of variation between languages on how optional args are handled, after all, and I'm not 100% sure what way would be best for CSS immediately. (Like: named args are probably good, for both readability and writeability?) > 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. Hm, this is why I was asking for specific use-cases. Can you give me a concrete example of this? I'm pretty sure this case you're describing happens as a side-effect of Sass doing its programming within CSS, and it either doesn't occur in custom functions, or can happen within the JS which already has all the semantics you're talking about. (I think you're talking about something like `--if(--isAngle(var(--val)), sin(var(--val)), var(--defaultSine))`, so you only try to invoke `sin()` when the value is a legit type for it, as otherwise evaluating `sin(var(--val))` will error when --var is subbed in and automatically make the declaration invalid-at-computed-value-time. If so, then yeah, this doesn't apply, you'd just do that error-checking in JS if you needed to.) > It would be really great if using functions didn't cause a declaration to stop conforming to normal css declaration resolution Yeah, that would be great, but it's a much longer-term goal, because it's *enormously* more complicated than just relying on the var()-resolution timing and logic. Happy to chat more on the details of why full "make invalidly-used custom functions invalidate the property they're used in like builtins do" is much harder, but for now suffice to say: omg it's so much harder. ----- Oh, and responding to an older comment that @isiahmeadows's comment reminded me I'd accidentally skipped over: > using true and false idents but only be able to declare an input as accepting `<ident>` which is a much bigger input space. You can declare your grammar to be particular idents, so `true | false | FILE_NOT_FOUND` works just fine and properly constrains you without you having to do error-checking in the impl of your function. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/857#issuecomment-500239621 using your GitHub account
Received on Sunday, 9 June 2019 19:44:29 UTC