Skip to content

1.6.3

Choose a tag to compare

@github-actions github-actions released this 22 Sep 19:41
· 10 commits to master since this release
fff5746

Fixed

  • bg-transparent, text-transparent, border-transparent, ring-transparent, fill-transparent, stroke-transparent, decoration-transparent and to-transparent resolve. None of them ever had. WindThemeData._initColors built a MaterialColor for every entry in defaults/colors.dart, used MaterialColor(0, {}) as its "this value is not a colour" sentinel, and then dropped the sentinel with removeWhere((_, value) => value.toARGB32() == 0). An ARGB of 0 does not mean "not a colour": it is exactly transparent (Color(0x00000000), defaults/colors.dart:4). So the filter deleted the one token it was never aimed at, isValidColor('transparent') answered false, and every parser that resolves a named colour walked past the class to whatever came before it. The sentinel meanwhile was unreachable, because all 26 shipped entries are a Color or a Map<int, Color>, so the branch was dead in both directions and the filter only ever did harm.

    Reported from a consumer's login screen: a ghost button styled w-full bg-transparent border text-gray-500 rendered as a filled brand-coloured button with muted grey text on it, unreadable. The measurements that isolated it, all against a default palette: bg-transparent resolved to null, bg-primary bg-transparent resolved to primary while bg-primary bg-white correctly resolved to white, and neither bg-transparent/0 nor bg-[#00000000] was a way out.

    _initColors now builds the map by iteration and inserts only the entries it could narrow, so a value that is neither shape is skipped rather than materialised and filtered back out. Filtering on the sentinel's identity instead of on its value would have fixed the symptom too, and was rejected because a sentinel nothing can produce is not worth constructing. The regression gate is not "transparent survives" but "no token is lost", since a fully transparent colour is indistinguishable from absent by ARGB alone and only the key set can say it. (lib/src/theme/wind_theme_data.dart, test/theme/wind_theme_data_test.dart, test/parser/parsers/background_parser_test.dart, test/parser/parsers/text_parser_test.dart, test/parser/parsers/border_parser_test.dart, test/parser/parsers/ring_parser_test.dart, test/widgets/w_div/background_test.dart, test/widgets/w_svg_test.dart) (#216)

    Three shipped widgets change behaviour, because the token was inert inside this package too. WButton picks its spinner colour from the parsed text colour, and its own class doc recommended loading:text-transparent as the loading pattern. That class did nothing before and would now paint an invisible spinner for the whole loading state, which is exactly what the _contrastColor fallback beside it exists to prevent. The text colour is skipped when it is fully transparent: text-transparent says "do not show the label", the spinner is not the label, and loadingColor is still the channel for asking for a transparent spinner deliberately. The recommendation is off the class doc as well, because this widget REPLACES the child with the spinner rather than overlaying it, so there was never a label for that class to hide. WCheckbox's own default className carries checked:bg-primary checked:border-transparent, so a checked box kept the border-gray-300 outline it is written to shed and now sheds it; two widget tests pin the checked and unchecked cases against each other. WSelect's resting option arm was bg-transparent, which now resolves and so builds a BoxDecoration, which trips WDiv's needsContainer and wraps every unselected option in a DecoratedBox that paints nothing, once per row for the length of the list. That arm is the empty string now: it means "no background", and the empty string is the spelling that costs nothing. (lib/src/widgets/w_button.dart, lib/src/widgets/w_select.dart, test/widgets/w_button_test.dart, test/widgets/w_checkbox_test.dart)

  • ring-[#12345] and shadow-[#12345] drop instead of painting a colour nobody wrote. Both regexes read #[0-9a-fA-F]{3,8}, so a five- or seven-digit typo matched, reached int.parse('12345', radix: 16) and painted Color(0x00012345): an invisible ring and an invisible shadow, which read as "the class did nothing" while the class had in fact been claimed. skills/wind-ui/references/tokens.md already told agents these two took "3, 4, 6, or 8 hex digits", so the loose form matched neither the documentation nor the four families fixed above. Narrowed to the same {3}|{4}|{6}|{8}; every arbitrary colour in the docs, the demo gallery and the test suite is six digits, so nothing that worked stops working. (lib/src/parser/parsers/ring_parser.dart, lib/src/parser/parsers/shadow_parser.dart, test/parser/parsers/ring_parser_test.dart, test/parser/parsers/shadow_parser_test.dart) (#216)

  • bg-[#AARRGGBB], text-[#AARRGGBB], decoration-[#AARRGGBB] and from- / via- / to-[#AARRGGBB] take their alpha, along with the four-digit #ARGB shorthand. hexToColor has accepted 3, 4, 6 and 8 digits since it was written, doc/utilities/color-helpers.md documented all four, skills/wind-ui/references/tokens.md told agents bg-[#hex] took "3, 4, 6, or 8 chars", and border-[#...] and ring-[#...] genuinely did. The background, gradient-stop, text and decoration regexes were left at {3}|{6} when the border one was widened, so the four token families that needed alpha most were the four that could not express it. A non-matching class is not an error anywhere in the pipeline, so bg-[#80FF0000] did nothing at all and the class before it won.

    Widened to {3}|{4}|{6}|{8}, spelled exactly as border_parser.dart already spells it. Not {3,8}: a five- or seven-digit value is a typo rather than a colour, and taking it would answer one nobody wrote. Alpha leads in both wide forms because that is what hexToColor does and what the rest of the package documents (Flutter packs AARRGGBB where CSS writes RRGGBBAA); a consumer porting #RRGGBBAA out of a web project gets a different colour, not a dropped class. Landed here rather than on its own branch because it is the same defect surface: with the palette fixed and this left alone, bg-transparent works and every partially transparent background still has no spelling. (lib/src/parser/parsers/background_parser.dart, lib/src/parser/parsers/text_parser.dart, doc/styling/background-color.md, doc/styling/background-gradient.md, doc/typography/text-color.md, example/lib/pages/styling/background_color_basic.dart, skills/wind-ui/SKILL.md, skills/wind-ui/references/tokens.md) (#216)