> On Jul 19, 7:34 pm, Mike Orr <[email protected]> wrote: >> On Tue, Jul 19, 2011 at 3:20 PM, Ross Vandegrift <[email protected]> wrote: >> > Hi all, >> >> > Any reason why select() doesn't support taking disabled as a keyword >> > args like the other input tags? Is something like the below desirable? >> >> The helpers were written a few years ago before 'disabled' and other >> attributes became popular. There are some other related tickets in the >> bugtracker. >> >> Boolean attributes and other HTML 5 >> enhancementshttps://bitbucket.org/bbangert/webhelpers/issue/46/html-5-enhancements >> >> "data-" >> attributeshttps://bitbucket.org/bbangert/webhelpers/issue/55/cant-pass-html5-da... >> >> We need somebody who uses these features to propose a general way to >> handle them, and to implement it. Would you like to work on this?
On Tue, Jul 19, 2011 at 9:36 PM, Eric Ongerth <[email protected]> wrote: > Any reason why just passing **kwargs through wouldn't fit the need? > That's exactly what I did in my own home-cooked helpers. That's the generic fallback but it's not very helper-ish. We can't add a helper syntax for every obscure case, but these are common enough that we should consider expanding the API for them, if we can come up with an elegant enough way that has the support of HTML 5 users. * Mako chokes on placeholders that contain embedded {} literals: ${h.tag("a", href="...", **{"data-foo": "bar"}} * Some template engines don't allow Python escapes. I.e., they can't do Mako's: <% attrs = {"data-foo": "bar"} %> * HTML 5 has a lame-brained definition of boolean attributes. If the attribute has any value including '', it's true. To make the attribute false you have to remove it completely. That's impossible to express in a 'kw = value' expression, so you'd have to have something higher-level than that. WebHelpers does have a function 'convert_boolean_attrs' that converts Python true/false keys to HTML booleans, but it's mainly for internal use and would require a Python escape (separate Python statement) in a template. So it may be the beginning of such a helper but not the helper itself. * We can also expand the internal list of boolean attributes which are automatically recognized and converted to HTML booleans. For this I'd need a list of attributes, and some reassurance that it's OK to always convert these attributes wherever they appear. I'm also not sure if HTML 5 allows ad hoc boolean attrs; that is, outside the list of predefined names. If so, how should we accommodate that. Forcing the user to manually convert 'selected=True' to 'selected="selected"' and 'selected=False' to deleting the attribute, is not desirable. I just had an idea for the 'data-*' attributes. What if the helpers accepted a 'data' argument as such: data={"foo": "bar", ...} => convert items to data- attributes: data-foo="bar" data="bla" => if the value is not a dict instance, treat it as a normal keyword arg (i.e., format it as an unknown HTML attribute) -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
