Property names

[cornae]

@jcbrand, The naming convention for Patterns properties is to replace space by dashes, instead of camel casing and to avoid boolean properties, as they are less declarative and not matching a CSS style syntax. For the boolean part a little bit more thinking from both our sides would be required, but could you change the mapping already for the current properties to dashed style?

[jcbrand]

yes, I agree we should clean up pat-upload and bring it inline with Patternslib conventions.

[fulv]

Just my 2c: It seems to me like the camel case convention has the advantage that you can use the same name everywhere, in CSS and in JavaScript. Names with dashes can not be used in JavaScript (or in Python for that matter), so you have to have different names, e.g. my-name in properties, my_name in JavaScript.

[jcbrand]

@fulv I wasn't there when the convention was chosen, however, the Patternslib convention came first. Deciding later to then choose a different convention for Mockup was therefore IMO irresponsible.

If we wanted to move to a different convention for Patternslib, we would have to change all the existing patterns.

[fulv]

Fine, I'm not trying to subvert. On the other hand, names with underscores instead of dashes work everywhere, too, and almost look the same. ;)

[cornae]

Hi Fulvio,

It's true what you say about the underscores. One of the goals of Patternslib is to make a library that is designer friendly. One way of achieving that by making the optics of the syntax similar to something designers are familiar with: CSS. In CSS only dashes are used as a space replacement. Also dashes are sometimes considered 'prettier' than underscores and pretty helps to get designers on you side :).

Op 17 dec. 2014, om 15:52 heeft Fulvio Casali notifications@github.com het volgende geschreven:

Fine, I'm not trying to subvert. On the other hand, names with underscored instead of dashes work everywhere, too, and almost look the same. ;)

—
Reply to this email directly or view it on GitHub #1 (comment).

[cornae]

That's also true :)

Op 17 dec. 2014 om 15:52 heeft Fulvio Casali notifications@github.com het volgende geschreven:

Fine, I'm not trying to subvert. On the other hand, names with underscored instead of dashes work everywhere, too, and almost look the same. ;)

—
Reply to this email directly or view it on GitHub.

[fulv]

Hi @cornae,
I've cleaned up all the CamelCase configuration value names and converted them to lowercase-dash-separated. I have not yet made the changes you requested in your "alternate" documentation table, because some of them are semantically different from the current ones. I wanted to be sure that the "cleaned up" names keep working as before, as a first step. Some of the configuration values don't even seem to be implemented, or at least I can't see that they do anything at all. But part of it might be that they get passed down to Dropzone(), which expects them to have a certain name and semantics. This would be another argument against changing the semantics.