Support for attributes with boolean values
#3
Closed
opened 8 years ago by otherjoel
·
5 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Currently only strings are valid attribute values for a tagged x-expression. Would it make sense to support non-serialized boolean values in attributes, given that boolean attributes are a thing in XML/HTML5?
I understand how to work around it for now. But serializing
#t
and#f
into strings on my own, and remembering to omit "false" attributes from x-expressions destined for HTML output, feels like I'm doing something that belongs in the library.The
txexpr
library relies on Racket’s existing X-expression grammar, which predates HTML5 and thus neither 1) prohibits"true"
and"false"
as attribute values, nor 2) permits attributes without values like<button checked>
.That grammar is a fixed target, so changing the current
txexpr
functions would make it incompatible with other Racket X-expression functions (and possibly existing code).The right way to do what you suggest would be to introduce a
txexpr/html5
submodule that refines the grammar to be consistent with thehtml5
spec. I’m not opposed to that in principle. But supporting a particular spec means implementing all of it, which is a bigger project (e.g., I would also have to do enumerated attributes and who knows what else).Maybe I’m exaggerating the labor because I just assume anything with the W3C name on it will be a pain in the ass. I invite you to convince me otherwise 😧
Good points. I definitely am not thinking we need the whole spec done, and I share your opinion of the W3C.
I was mainly looking to understand why something like
'(tag [[highlighted #t]] "Hello")
is not considered a valid txexpr. That seems useful outside of any XML/HTML5 considerations, which perhaps I shouldn't have even brought up. For example, a Pollen tag function defined with(define-tag-function (tag attrs elems) (...))
could test boolean attribute values directly rather than usingstring=?
orstring-length
and vary output accordingly—the attribute itself might not even be intended for inclusion in any HTML output.Regarding the x-expression grammar being a fixed target, I don't know if this is relevant but with
(require xml txexpr)
:Does this have any relevance for
txexpr
? I know(permissive-xexprs #t)
allows you to put anything in an x-expression attribute, which could be bad.Yes,
permissive-xexprs
essentially suspends the X-expression grammar. I’ve wondered whethertxexpr
should respond to that parameter, but decided against it (since keeping things consistent with the grammar is intrinsic totxexpr
, and it would make the module more complex for no apparent benefit).“No apparent benefit” because you never need to use
txexpr
to manipulate X-expressions. In general, Pollen doesn’t care what you put in your X-expressions, so you can use & test boolean attribute values like so:Or did you have something else in mind?
Ok I see better now. I am writing some macros around
define-tag-function
and usingattr-set
as part of a method (in a helper function, not in the macro) to specify default attribute values. It wasattr-set
that was throwing the error on booleans (“can’t convert to string”), and I had assumed that to be a good indication that passing around txexprs with boolean attribute values was just going to be Not Acceptable. So it seems as though if I just avoid using functions fromtxexpr
anywhere I know those will be used, it will be possible to do what I want.Right. IOW,
txexpr
provides the benefit of a higher-level interface, but at the cost of being more strict about input & output. But it is always optional: X-expressions are nice because they’re simple list-based structures, so they can be manipulated with any of the list functions in Racket.