figure vs. canvas

[msrosenberg]

I thought I was told that we were abandoning "canvas" for "figure," but I note that the default.nexss and testtree.nexss files still use "canvas". We need to finalize a decision for consistency moving forward.

[jimallman]

My bad. I'll update this to use figure...

[jimallman]

On second thought, I'm not sure the nexss selector needs to address figure instead of canvas.

To me, the conventions in nexss reflect "tree thinking", describing a canvas containing one (or more?) trees, each of which holds a hierarchy of nodes, etc., similar to the hierarchical DOM in CSS. For example, to highlight all edges in the ingroup clade we might say:

node[ingroupClade=true] node {
    edge-color: red;
    edge-thickness: 4;
}

But note that this might not correspond to the structure and elements in the tree's source document! While there are tree and node elements in NeXML and NexSON, the tree structure (hierarchy) is constructed on-the-fly for display, from a flat collection of nodes and edges.

Similarly, our current treatment of properties is radically simplified versus the actual source document. In the example above, traditional CSS would match only an element that looks like this:

<node ingroupClade="true" ... >
   <node id="MATCHES" ... />
</node>

In NeXML or NexSON, it's more likely that we'll find the ingroupClade property in a nearby metadata (meta) element -- possibly a child of the <node>, or somewhere else but pointing to this node as in NexSON annotations. I'm proposing that we use the simple notation above as a shorthand, and rely on the nexss interpreter to try all of the above (speed permitting) and match regardless of how the property is actually stored.

This is admittedly weird, but it also seems expressive, powerful and adaptable to different kinds of tree data. Thoughts?

(Oh, and where does this leave figure? These elements would be abstract bundles of values that define a figure: its tree(s), its styles, its intended media or use, perhaps physical dimensions. Those ingredients would in turn be used to build the visible figure, including its canvas or display context.)

[daisieh]

I was assuming that the <figure> element has references to trees and, as a default selector, refers to styling that applies to the implied figure, even if it's not explicitly specified. In that way, I think it is equivalent to the intent of the original canvas selector, in that the canvas selector was never meant to have a corresponding <canvas> element.

[jimallman]

OK, I'll buy that. Changing this now..