Extended HSL/HSLA/HSB Handling with Float Support

[danielebarbaro]

This PR introduces extended support for handling HSL, HSLA, and HSB color formats with floating-point values.

The changes address and resolve Issue #89.

Changes:

1. Centralized Regex Patterns:

   • Introduced HsPatterns class to centralize and manage regex patterns for validation and extraction.
   • This ensures consistency and maintainability of regex patterns across the library.

2. Enhanced Parsing Logic:

   • Updated Hsb, Hsl, and Hsla classes to use the new HsPatterns class for parsing.
   • Modified the fromString methods to correctly parse and handle floating-point values in color strings.

3. Validation Improvements:

   • "Refactored" Validate methods (hsbColorString, hslColorString, and hslaColorString) to utilize the new centralized regex patterns in HsPatterns.

4. Tests and Dataset Enhancements:

   • Added test cases in Colors to cover scenarios involving floating-point values in HSL/HSLA/HSB strings.
   • Examples include edge cases such as hsla(357, 12.12%, 44.5%, 0.1) and hsl(221, 11.52%, 32.35%) (taken from the issue).
   • All updated test cases pass successfully, and new datasets were added to ensure comprehensive coverage for float handling.

Resolves:
Issue #89

[freekmurze]

Let's make these protected

[freekmurze]

These also can be regular class properties, not constants.

[danielebarbaro]

I decided to change from private to protected.

My initial idea was to create a ColorPattern class instead of HsPattern, but that would have required a complete refactor of the package—and doing that the day before Christmas would have been a bit naughty.

Using constants feels cleaner to me, as it allows me to avoid touching VALIDATION_PATTERNS and EXTRACTION_PATTERNS.

[freekmurze]

Let's make these regular properties, they can be static

[danielebarbaro]

Hi Freek,and thanks for the suggestion! I'm a bit confused, I understand the reasoning, but I think constants are a better fit in this specific case:

• Immutability: These patterns (HUE, COMPONENT, ALPHA) are not meant to change at runtime, so using constants makes the intent clearer and avoids unnecessary complexity. 🤓
• Performance: Constants are resolved at compile time, while static properties involve runtime allocation.
• PHP Compatibility: Since the composer.json specifies PHP 7.3 as the minimum version, using typed static properties (introduced in PHP 7.4) would break compatibility.

If I misunderstood your comment, I’m here to help and follow your directions. Please feel free to double-check how I’ve declared the constants in the file to ensure they align with your expectations!

[freekmurze]

Ok, those are good arguments, thanks for explaining. 👍

[freekmurze]

Thank you!