nx_paint_box_borders.nx

nx_paint_box_borders.nx -- paint a box's 4 borders (top / right / bottom / left) into a Framebuffer. Phase 4 third primitive of NISHI_BROWSER_ROADMAP. Composes nx_css_apply (cascade) + nx_css_dimension_to_px (border-width) + nx_css_color_decode (border-color) + nx_paint_solid_rect (actual pixel fill). Per W3C CSS Backgrounds and Borders Module Level 3, each border has independent width + color + style. This primitive supports solid borders only (style: solid). Other border-styles (dashed, dotted, double) are Phase 4b queued. Geometry: borders are painted OUTSIDE the box's content/padding rect in the CSS box model, but since nx_layout_block currently uses content-box width (b.w = content_w) and mixed-axis height (b.h = padding_top + content_h + padding_bottom), border placement here treats b as the BORDER box (top edge at b.y - border_top_w, etc.). Until nx_layout_block grows border-box semantics in Phase 3b, the simpler convention is borders drawn INSIDE b's rectangle along each edge. What it does NOT handle yet (Phase 4b queued, explicit in header): - border-style values other than solid (dashed, dotted, double, groove, ridge, inset, outset) - border-radius (rounded corners) - border-image - corner blending where two adjacent borders meet (currently the right/bottom borders paint OVER the top/left at corners -- last-wins, source-order; W3C spec wants mitred joins) - independent border-width directional shorthand parsing (border-width: 2px 1px 3px 1px) -- only longhands today Per cardinal feedback-honest-perf-verdict-no-aspirational-claims: gap list is EXACT. genealogy_id: w3c_css_backgrounds_borders_module_level_3 + substrate_browser_phase_4_box_borders lineage_id: nishi_browser_paint_box_borders_v1