Skip to content

Styling Rework #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sleepy-monax opened this issue Apr 9, 2025 · 5 comments
Open

Styling Rework #51

sleepy-monax opened this issue Apr 9, 2025 · 5 comments
Assignees

Comments

@sleepy-monax
Copy link
Member

No description provided.

@pauloamed
Copy link
Contributor

Splitting computed style into compute style and computed value

  • relative sizes (eg. em) can live in compute style but not value
  • relative font weight (bolder, ligther) can live in compute style but not value
  • calc values can live in compute style but not value
  • currentColor can live in compute style but not value
  • computed value for size could be a union of auto, perc, au
    • able to identify if a Width is a percentage as a computed value

Another points:

  • Should border collapse be solved as a computed value? If yes, grid building should also, since it depends on that.

Structure for computed style/props

  • A prop can be thought of as tuple key, css value (as in lady bird), which wouldn't enforce types when creating the prop, only when applying. This could affect our performance. Prolly it's better to stick to a specific value type for each prop? However, on the other hand, having a bit Union for all the props hurts compile time.
  • In the current design, there is duplication of code and recomputing regarding default values of Props and their initial() methods.

@pauloamed
Copy link
Contributor

pauloamed commented Apr 11, 2025

Ongoing discussion/refinement with @LuneMercier :

  • investigate if transforming Any non-void case from recursive to loop would enhance performance
  • suggestion about shifting requires { T::load(parent); } into specific type LoadableStyle, over the cost of adding burden into developer needing to know if the prop they create should be LoadableStyle or not
  • benefit from the fact that name() is a one2one relation with a property and use this to optimize the matching T::name() != propName

@pauloamed
Copy link
Contributor

pauloamed commented Apr 14, 2025

Specs related to this task: https://www.w3.org/TR/css-cascade/#value-stages

Compute:

  • values with relative units (em, ex, vh, vw) must be made absolute by multiplying with the appropriate reference size
  • certain keywords (e.g., smaller, bolder) must be replaced according to their definitions
  • percentages on some properties must be multiplied by a reference value (defined by the property)
  • valid relative URLs must be resolved to become absolute.
  • The declared value of transparent is "transparent" while the computed and used value is transparent black.

Not compute:

@pauloamed
Copy link
Contributor

Another task from this milestone is "Separation build phase and compute phase", to be tackled by @sleepy-monax when adding Stylesheet information in DOM nodes (thus needing to have specified values on stylesheets).

@sleepy-monax
Copy link
Member Author

We should probably closly follow the model described in:

@sleepy-monax sleepy-monax self-assigned this Apr 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants