Bonsai: style elements with no material, and a question on hatch class names - #9361

Two related problems with material hatching in drawings, found while documenting the stylesheet system. This PR fixes the safe one and asks about the other rather than changing it unilaterally.

Fixed here: elements with no material are unstyled

drawing/operator.py:1460 emits material-null when an element has no material:

else:
    classes.append("material-null")

default.css has no rule for that class. It does have .material-blank { fill: white; }, which nothing ever emits. So the two halves have drifted apart and elements without a material get no fill styling at all.

This makes the existing rule match both, keeping .material-blank so any stylesheet already targeting it continues to work:

.material-blank, .material-null { fill: white; }

One line, no behaviour change for anything that works today.

Not fixed here, because it needs a decision: the built-in hatches rarely match

canonicalise_class_name (tool/drawing.py:170) is:

return re.sub("[^0-9a-zA-Z]+", "", name)

It strips non-alphanumerics but does not change case. So a material named "Concrete" produces the class material-Concrete, while the shipped rule is .material-concrete. CSS class matching is case sensitive, so it does not apply.

The practical effect is that the fifteen material hatches in default.css, concrete, brick, glass, earth, wood and so on, only work if materials are named in all lowercase. In real projects they are usually "Concrete" or "C30/37" or "Beton", so the shipped hatches mostly never fire and it looks as though hatching is simply not implemented.

I have not changed this, because every option has a cost and the choice belongs to whoever maintains this:

Lowercase in canonicalise_class_name. Cleanest, and makes the hatches work as intended. But it changes the class names in every drawing, so anyone whose custom stylesheet targets material-Concrete today would break.

Emit both variants, for example material-Concrete material-concrete. Backwards compatible and the hatches start working, at the cost of a slightly longer class list per element.

Leave the code and document it, telling people to name materials in lowercase or to write selectors matching their own names. Zero risk, but the shipped hatches stay mostly decorative.

I would lean towards emitting both, since it fixes the visible problem without breaking anyone. Happy to implement whichever you prefer, or none.

Two smaller findings, reported not fixed

Five dead selectors. .PredefinedType-STUD, WOOD, STEEL, CONCRETE and PLASTERBOARD are not emitted anywhere in the Python or the C++.

sample.css looks orphaned. Referenced nowhere, and its vocabulary (.hidden, .solid, .leader, .stair, .break) does not match any current selector.

Related

The stylesheet system is documented for the first time in #9358, including the material naming trap above in its troubleshooting section, so users have an answer regardless of what is decided here.

Produced with AI assistance.