devinivy / cuttyssark Goto Github PK

The triggers in stylesheets is confusing for most. A better option would be to provide a JS API and support a configurable manifest describing these triggers.

I'm reading the description of your tool on your site and I'm finding it confusing.

Often events are registered using JavaScript for the sole purpose of updating styles.

The term "registering events" is ambiguous. I think you're referring to the process of binding event handlers.

The goal of CuttySSark is to allow the front-end developer to write compliant CSS that interacts seamlessly with the JS event model.

This is not a very informative statement. This could be said about most JS libraries that interact with CSS.

Registers events to apply a style block.

I have no idea what this means.

Allows remote triggering by one DOM element on another.

I have little to no idea what this means.

This selector registers a click event on #big

No. CSS selectors don't "register events". This is confusing.

From what I see, your tool is a JavaScript library which adds an on HTML attribute to certain elements based on which events fire at those elements. This is not explicitly stated on your site, but it should be.

Also, there is one unexplained aspect of your tool: How does your tool know which on values to write? Does it parse the CSS to see which event types are used in the CSS and on which elements?

This should be explained on the site.

Disclaimer: I know this may sound like a rant, but I'm just giving you an honest description of my experience with your site.

Use event delegation and some management to allow newly-added elements to take advantage of Cutty's eventing.

Perhaps css-on, on-[event], etc. See #1. Open for discussion.

From what I understand, custom HTML attributes defined by our web apps should be prefixed with data- to guard against potential name collisions.

I might be wrong.