TreeSS is not (quite) CSS - TreeViz/metastyle GitHub Wiki

NexSS TreeCSS is similar in spirit and intent to CSS, but not quite the same. Here are the major differences:

TreeSS encourages and leverages tree thinking. It uses the concepts and idioms of CSS but applies them to a hierarchical tree (and a surrounding figure) as its "document".

It's important to note that this hierarchy may not exist in the source document. In NeXML and most other file formats that include rich tree data, the recognizable tree is constructed on-the-fly from collections of nodes and edges, related OTUs and various bits of metadata. While CSS can be used to style XML documents, working directly with such a tree is far beyond its capabilities.

TreeSS overcomes this through wishful thinking, by simply assuming that the tree we expect is present and (probably) rooted. So we can describe nodes and their properties (including metadata), cladistic relationships as hierarchy, and tree-based visual styles. This puts the onus on the TreeSS interpreter to make sense of all this in a given tree-visualization app.

Attribute selectors in TreeSS resemble those in CSS, but with a wider range of operators (support for these may vary across implementations).

• = equals
• != does not equal
• ^= starts with (strings only)
• $= ends with (strings only)
• *= contains (strings only)
• > greater than
• >= greater than or equal to
• < less than
• <= less than or equal to

Unless specified, all these should have the expected results with string or numeric values. (The TreeSS interpreter should coerce values to the expected type where possible, with string as the default type if coercion fails.)

These operators make it easy to set threshold values for (e.g.) support values:

node[treess:support>0.5] {
    border: 8px;  /* sets adjacent edge thickness */
}

node[treess:habitatCount>=2] {
    color:green;  /* colors node shape and label */
}

TreeSS simplifies the use of metadata by making logical assumptions about where a node's "property" might actually be found. For a simple test like this:

node[treess:iucnStatus=endangered] { ... }

... the TreeSS interpreter should search all the following locations, returning the first match:

• the attributes of the original NeXML node element

  <node treess:iucnStatus="endangered" ... />

• any meta tags (children of the node) with a matching property

  <node ... >
      <meta xsi:type="nex:LiteralMeta" 
            property="treess:iucnStatus" datatype="xsd:string" content="endangered" 
      />
  </node>

Possible future plans include these additional places to check:

• other more distant meta elements that are somehow keyed to this node
• all of the above, for an otu associated with this node

Current TreeSS interpreters don't support some advanced CSS features, like these:

• selector tricks like A > B and A + B
• pseudo-elements like :before and :after
• multiple selectors for a ruleset like A, B
• @import statements
• !important to override normal inheritance

Fully implementing the inheritance and cascade behaviors of CSS is a tall order. Current implementations (as of Sept 2014) fall short in their treatment of specifity of rules, relying instead on the original order of TreeSS rulesets in the specified stylesheet(s). When in doubt, re-order and try again!