Prepare graphics, motion, and assets for a product
Choose raster, SVG, or Canvas from visual and interaction requirements, then design teaching-card assets with pixel budgets, provenance, reduced motion, and failure alternatives.
Define a card asset and interaction plan and verify image failures, reduced motion, and hit-test boundaries.
A document-card graphic may be a photograph, vector icon, or script-drawn interactive diagram. Choose its representation from its purpose. A simple arrow need not become a large bitmap, and changing a photograph's filename to SVG does not make it vector artwork.
The case combines a diagram, interaction feedback, and a selectable area. It includes asset failures and reduced-motion behavior. The offline code tests geometry without generating images or running Canvas.
Choose the graphic representation
Raster images store pixels. Dimensions, encoding, and compression affect clarity and transfer size. SVG describes shapes and paths and suits scalable icons or diagrams, but complex paths, embedded bitmaps, and filters can still be expensive. A format name does not guarantee a small asset.
Canvas uses scripted drawing. Its painted pixels do not automatically become interactive DOM controls. Updates require redraws, interaction requires hit testing, and semantics and keyboard operations need separate support. A few clickable document cards are often easier to maintain as HTML.
Choose according to visual change and user tasks. Keep text selection, links, and meaningful document structure where needed. If extensive custom drawing warrants Canvas, design equivalent accessible operations. A visual screenshot does not fulfill those responsibilities.
Separate display size, pixels, and transfer cost
CSS dimensions define layout space; actual raster or Canvas pixel dimensions determine detail and part of the memory cost. A high device pixel ratio may require a larger drawing buffer without increasing CSS size. Pixel count grows with width times height, so compressed file size is not the only budget.
Prepare thumbnails for their display purpose and use responsive image candidates where suitable. Supply intrinsic dimensions or an aspect ratio to reserve space. Do not automatically lazy-load an important first-screen image. Lower-priority images can follow an appropriate deferred-loading policy.
Check transparent margins, cropping, and subject placement. An asset can have correct dimensions but an unreadably small subject. Inspect light and dark backgrounds, reduced sizes, and informative alternative text. Decorative assets should not interrupt reading.
Give motion an interaction purpose
Hover can reveal an action area, and a brief save response can confirm a change. Choose duration, distance, and triggers for the task rather than animate every static card continuously. Touch devices lack identical hover behavior; provide feedback available through touch and keyboard too.
Transforms and opacity often avoid some layout work, but painting and compositing still depend on content. Do not promise fluid performance from the property alone. Avoid repeated layout measurement and mutation per frame, then observe actual devices. Animation does not make a network request faster.
Respect reduced-motion preferences with static or limited-motion alternatives. Persistent distracting motion needs pause or an equivalent path. Preserve meaningful state feedback through text, suitable indicators, and immediate changes when motion is reduced.
Keep asset provenance and review
For generated teaching illustrations, define purpose, composition, dimensions, and legibility requirements. Retain prompts, versions, and review decisions. Generated text or symbols may be wrong and require human inspection; the image is not factual evidence by itself.
Check licenses, permitted use, and provenance for existing assets too. Do not present another person's screenshots, branded portraits, or stories as original work. A public asset record can describe safe provenance without private user images, prompts, or account data.
Associate asset IDs with versions so old caches do not indefinitely display mismatched illustrations. Verify format, actual dimensions, and size before approval. Public permission to use one illustration does not authorize public access to its entire storage directory.
Test a geometric action area
The rectangle uses left, top, right, and bottom coordinates with inclusive left/top and exclusive right/bottom boundaries. Adjacent rectangles can share an edge without assigning its point to both. The model omits rotation, scaling, layers, and browser coordinate conversion.
boxes = {"card": (10, 20, 110, 80)}
def hit(x, y):
return [name for name, (left, top, right, bottom) in boxes.items()
if left <= x < right and top <= y < bottom]
assert hit(10, 20) == ["card"]
assert hit(110, 20) == []
assert hit(5, 5) == []
print(hit(30, 40))
The output is ['card']. The top-left corner hits, x=110 is excluded, an outside point misses, and 30,40 lies inside. This establishes the synthetic geometry only, without a real pointer action or accessibility evidence.
Actual Canvas interaction must map pointer coordinates into drawing coordinates while considering CSS size, device pixel ratio, and transforms. Overlap also needs precedence rules. An HTML button can supply native interaction when custom hit testing is unnecessary.
Preserve tasks after asset failure
Keep titles, descriptions, and primary actions visible when an image fails. Reserve stable placeholder space and avoid endlessly retrying an invalid resource. Distinguish temporary network failures from missing assets, and do not present a placeholder as the completed illustration.
When a task depends on the graphic, provide an equivalent text list or standard controls for failure and reduced motion. An empty, inoperable canvas makes the feature disappear with its asset. Design resources and application states together.
Verify the actual format too; a filename extension may not match the content.
Exercise: deliver an auditable asset plan
Choose raster, SVG, or HTML graphics for three teaching cards and explain each choice. Record display dimensions, pixel dimensions, provenance, permission, and failure alternative. Define motion and reduced-motion behavior for one action, plus geometric boundary rules.
Images must not block reading after failure. Narrow screens and high pixel ratios must remain legible, keyboard users must complete the same action, and reduced motion must preserve feedback. The offline test must cover interior, exterior, and shared boundaries. Any performance claim requires device and measurement records; geometry assertions cannot establish an unmeasured frame rate.
Sources & further reading
Sources checked on 2026-11-10. Original engineering explanation; examples are teaching data, not production measurements.