Skip to content

fix: grid tool raises an uncaught ValueError on unsupported track syntax (%, repeat(), auto, minmax) #282

Description

@ShotaroKataoka

Summary

The grid tool's track-list implementation only supports a subset — fr, px,
and bare integers — but the documentation describes it as a "track-list" and as
"equivalent to CSS grid-template-areas". When the model writes common CSS
syntax (%, repeat(), auto, minmax()), the tool raises an uncaught
ValueError instead of returning an error message
.

The coordinate math itself is correct; this issue is about the accepted input
syntax and error handling.

Reproduction

from sdpm.engine.layout.grid import compute_grid
compute_grid({"area": {"x": 0, "y": 0, "w": 1000, "h": 100},
              "columns": "50% 50%", "rows": "1fr", "gap": 0})

Result:

'50% 50%'                → ValueError: could not convert string to float: '50%'
'repeat(3, 1fr)'         → ValueError: could not convert string to float: 'repeat(3,'
'auto 1fr'               → ValueError: could not convert string to float: 'auto'
'minmax(200px,1fr) 1fr'  → ValueError: could not convert string to float: 'minmax(200px,1fr)'
'1fr 1fr'                → OK [500, 500]

Cause

_resolve_tracks in sdpm/sdpm/engine/layout/grid.py interprets each token as:

  • ends with px → fixed size
  • ends with fr → fr value
  • otherwise → float(t) (a bare number is treated as fr)

so % and function notation fall through to float(t) and raise ValueError.

On top of that, the grid tool in sdpm/sdpm/tools/__init__.py only catches
JSON parse errors
; exceptions raised during computation are not caught:

try:
    grid_spec = json.loads(spec)
except (json.JSONDecodeError, TypeError) as e:
    return {"error": f"Invalid grid spec JSON: {e}"}
return compute_grid(grid_spec)   # ← exceptions here propagate

Why the model may write CSS syntax

  • grid tool docstring: columns: track-list string
  • sdpm/references/guides/grid.md: "areas: Equivalent to CSS
    grid-template-areas"
  • Same guide: "The combinations of columns/rows/gap/areas are open-ended — invent
    freely to match the content."

The description reads as "CSS Grid equivalent" and the supported subset is not
stated anywhere. All examples in the guide use fr / px, so the frequency is
probably low, but there is room for the model to invent syntax.

Expected behaviour

  1. Unsupported syntax should return an error message the model can act on,
    not raise an exception
    (e.g. {"error": "unsupported track syntax: '50%'. Use fr, px, or an integer."})
  2. The supported syntax should be documented

Proposal

Minimal

  • Detect unknown tokens in _resolve_tracks and catch them in the grid tool to
    return {"error": ...}
  • State "only fr, px, and integers are supported" in the grid docstring and
    in grid.md

Optional

  • Support % (a simple conversion to a fraction of available)
  • Support repeat(n, X) (a simple expansion)
  • Leave auto / minmax() unsupported since they require content measurement,
    and say so explicitly in the docs

For reference: the computation itself is correct

Verified, no problems found:

Case Result
"1fr 1fr 1fr" + gap 40 (area width 1720) 547 + 547 + 546 + gap 80 = 1720 (exact; the remainder is absorbed by the last fr track)
Right edge Matches area.x + area.w
"300px 1fr 200px" + gap 20 (width 1000) 300 + 460 + 200 + gap 40 = 1000
Slide aspect ratio Independent — it is a pure calculator over the given area

Related files

  • sdpm/sdpm/engine/layout/grid.py_resolve_tracks
  • sdpm/sdpm/tools/__init__.py — the grid tool (exception handling + docstring)
  • sdpm/references/guides/grid.md — description of supported syntax

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions