Example: only file inputs should statically allow the accept attribute, i.e. this should be a compile error:
input().type_("checkbox").accept("*").build()
I think this can be done by making Input<Ty: InputType> and some zero-sized types which implement InputType. Then you'd limit the impls to only the input types that are valid:
To do this, we need the type_() function on all elements to "fill in" the generic parameter. The question I have right now is how to get the right type info at compile time while preserving the same mox syntax as we currently have:
One possible approach would be to use a const generic string once thats available:
input()
.type_::<"file">()
.accept("*")
.build()
Another would be to make the function generic over a ZST argument, but lose the "stringness" of the type attribute:
input()
.type_(File)
.accept("*")
.build()
Both of these APIs could be supported with the same surface syntax in mox but adding a bunch of web-specific constants isn't great when the macro should work across platforms.
If we don't special-case the macro and we require a different syntax for invoking the type, then we lose a bit of HTML/XML familiarity which is some of the point of the macro in the first place.
Example: only file inputs should statically allow the
accept
attribute, i.e. this should be a compile error:I think this can be done by making
Input<Ty: InputType>
and some zero-sized types which implementInputType
. Then you'd limit the impls to only the input types that are valid:To do this, we need the
type_()
function on all elements to "fill in" the generic parameter. The question I have right now is how to get the right type info at compile time while preserving the same mox syntax as we currently have:One possible approach would be to use a const generic string once thats available:
Another would be to make the function generic over a ZST argument, but lose the "stringness" of the type attribute:
Both of these APIs could be supported with the same surface syntax in
mox
but adding a bunch of web-specific constants isn't great when the macro should work across platforms.If we don't special-case the macro and we require a different syntax for invoking the type, then we lose a bit of HTML/XML familiarity which is some of the point of the macro in the first place.