Remove 'data-' prefix requirement for setAttribute() and make more consistent.

[Leftium]

Briefly summarized in code:

Item.setAttribute('data-name', 'value') // Normal case: sets @name to value
Item.setAttribute('name', 'value')      // Silently ignored

Item.setAttribute('id', 'value')        // Throws exception
Item.setAttribute('data-id', 'value')   // Silently ignored

Item.setAttribute('data-type', 'note')  // Changes type of item to note
Item.setAttribute('data-type', 'data')  // Changes type of item to note but new tag @type(data) expected.

Item.setAttribute(name, value) would be more intuitive if name did not have to be prefixed with "data-". It's confusing that name is "data-tag" but the actual tag being set is just the unprefixed "@tag".

Furthermore, it seems the prefix is no longer required because the built-in attributes ("id", "indent") now exist in their own properties outside of the attributeNames property.

"data-type" is also a built-in attribute, but I recommend moving it outside, as well. It prevents TaskPaper from properly handling an Item with an actual tag named "@type". Or it should at least follow the convention and not be prefixed with "data-"

And "indent" is both an Item property and found in attributeNames. The attribute should be removed.

Finally, the documentation needs to be updated: The "data-" prefix sounds like an optional convention in the documentation, but any calls where "data-" is not prefixed are actually silently ignored.

I am guessing this issue will have ripple effects with related methods like getAttribute and even processing search queries...

[jessegrosjean]

I agree there's some oddness in attribute names, let me see if I can explain.

First there's three places to think about attribute names: Item.setAttribute names, @tag names encoded in item.bodyString, and @attribute names in item path queries.

item.setAttribute

At the item.setAttribute level the only restriction is that you can't set an attribute using the attribute name id. This restriction is in place to avoid confusion since each item already has a immutable id property.

In your above examples where you are setting an attribute that looks like it's "silently ignored" it's not really ignored. It's being stored, it's undoable, you can get read the value back using getAttribute. You can even target it in your stylesheet.

It's just not encoded as a tag an inserted into the item body text.

body text @tag names

TaskPaper's @tag syntax complicates things. They are used to represent attributes that are set/get on items using setAttribute and getAttribute. But I don't want all attributes represented as tags. For example there's an indent attribute used internally to track "tab" indentation, but I don't want a @indent(1) tag associated with each item.

I also want there to be a general way in the API to set attributes on items that don't automatically get exposed as @tags in the items body text.

This is what the data- marker is for. All user entered attributes (i.e. attributes that they enter by typing @tag syntax are namespaced using data-. This convention is good because it make it so that users typing @tags can't overwrite internal attributes. It's also good because at the API level when someone calls item.setAttribute() it's easy to look at the attribute name and know if it needs to also be encoded as a tag in the body text or not.

Unfortunately there's one big inconsistency ... I should have named data-type just type. But changing this now is difficult because there are already scripts and styles that depend on the current behavior.

Also I've filtered out a few tagnames to avoid confusion. For example @id, @type, and @text are all ignored, since they are used for internal purposes and shouldn't be set by the user just typing in a tag name. But this ignoring is somewhat arbitrary.

Item Path attribute names

In the item path query language I want to query both user entered @tag attributes and built in attributes such as @id. But I don't want users to have to type data- before each @tag attribute.

So when lookup up values when doing a item path query I currently look for a few hard coded cases (such as @id and @text) and then I prepend data- to the attribute name and see if there's an attribute under that name.

I'm now changing that code a bit so what it will do is:

1. Look for direct matching attribute (ie without prepending data-). If found return that.
2. Otherwise prepend data- to the item path specified attribute and see if such an attribute exists.

Once this is in place that would mean that when creating item path queries the attribute myattribute would take precedence over the attribute data-myattribute. Odd ... but for 99% of cases shouldn't make any difference non data- namespaced attributes aren't used much right now.