HTML-style attributes about hamlpy HOT 11 CLOSED

Correct link: http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#htmlstyle_attributes_

You may want to take note of what's happening in #52 as it may pose some problems

from hamlpy.

Hi Kyle
While looking into fixing html style attributes, would you by any chance be looking to solve the issue with non-value based attributes like the itemscope attribute in HTML5 (More info is on the Schema.org site)?
In HAML, you would do: %div{:itemscope=>true} but in HamlPy, that actually results in itemscope being assigned the value of true, which is not what is desirable for this element.
Cheers,
Mehershad

from hamlpy.

Ok, So I did some looking around.
I am not saying this is the solution, but its what I thought would be the solution and looking at the source in the original HAML github branch, I think it confirmed what I thought.

So here it is, to enable the itemscope style emtpy attributes in an tag, HAML does this in this file in the build_attributes function:

if value == true
    next " #{attr}" if is_html
    next " #{attr}=#{attr_wrapper}#{attr}#{attr_wrapper}"
elsif value == false
    next
end

In HamlPy, in this file, I assume that condition would have to be added to the _parse_attribute_dictionary function where it says:

if isinstance(v, int) or isinstance(v, float):
    self.attributes += "%s='%s' " % (k, v)
else

add something like this:

if v.lower() in ("yes", "true", "t", "1"):
    self.attributes += "%s " % (k,)
if isinstance(v, int) or isinstance(v, float):
    self.attributes += "%s='%s' " % (k, v)
else

The problem is that the eval statement causes the attributes to get ordered in lexicographic order from what I can understand and even using an OrderedDict does not solve the ordering for now resulting in:

<div itemprop='foo' itemscope>

I honestly don't have an explanation for why does eval swap the ordering of the keys in the dictionary. Here is a series of statements I ran in the Python Interpreter:

>>> eval("{'items':'true', 'itemp':'what'}")
{'items': 'true', 'itemp': 'what'}
>>> eval("{'itemsc':'true', 'itempr':'what'}")
{'itemsc': 'true', 'itempr': 'what'}
>>> eval("{'itemsco':'true', 'itempro':'what'}")
{'itemsco': 'true', 'itempro': 'what'}
>>> eval("{'itemscop':'true', 'itemprop':'what'}")
{'itemprop': 'what', 'itemscop': 'true'}

Notice they swap ordering when they reach itemscop and itemprop

Thoughts?

• Mehershad

ps> Should I make this a separate issue and propose the solution or are we answering on the same page re: the issue?

from hamlpy.

I have emailed the mailing list of schema.org asking if the order even matters or if we are fine with where it stands.
Let's see if they answer.

from hamlpy.

Ok, the response was that the order does not matter. So the above fix I have posted does the job for me.
What is the process to commit the changes to the branch?

from hamlpy.

What I did was fork the project, make my changes on my fork, and then submit a pull request (http://help.github.com/pull-requests/). It's then up to the project owner to accept the pull request and merge the code with the main branch

from hamlpy.

Hi md3sum, the yes/true/t/1 is interfering with attributes that are supposed to have that value. How would you feel about something like this instead?

itemscope: None

from hamlpy.

@bcoughlan Sorry about the delay. I was out of the country. I am OK with the change. Sorry for having the code interfere with some other working solution.
Just for knowledge - what solutions does it interfere with?
Cheers

from hamlpy.

@md3sum Just things like %input{type:"submit", value:"true" or %option{value:'1'}

from hamlpy.

@bcoughlan Ah, Gotcha. Sorry for the trouble and thanks for the fix. :)

from hamlpy.

No apologies needed, these things happen!

from hamlpy.