LivelyKernel / LivelyKernel/lively.next

Allow sharing of CSS between HTML morphs

Open
#803 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

✨ enhancement 👶 good first issue
Dominant language
JavaScript
Stars
90
Forks
20
PR merge metrics
No merged PRs in 30d

Description

**Describe the Feature**
We currently mount and unmount the CSS declarations for an `HTMLMorph` together with the node for the morph itself. The generated CSS declarations are always scoped to only affect the specific `HTMLMorph` for which they were written. As can be seen from the screenshots below, this leads to a lot of duplication, e.g., in the case of `Spinner`. It would be nice to allow for the sharing of CSS Declarations between `HTMLMorph`s. The downside to this is of course, that the interactions of different CSS rulesets are not always obvious and sharing the declarations might result in unexpected behavior. Thus, the sharing should be entirely optional. This way, we could e.g., activate the sharing for the `Spinner` and thus get rid of three of the four nodes in the screenshot below.

**Graphics**
![Screenshot from 2023-04-12 12-33-53](https://user-images.githubusercontent.com/14252419/231485148-d72c9cc7-89c8-488f-af97-fb6d53470b90.png)

![Screenshot from 2023-04-12 12-35-24](https://user-images.githubusercontent.com/14252419/231485162-82abb62b-60d3-40a5-a266-d34fd8db095c.png)

**Implementation Details**
I imagine this to be a flag of the `HTMLMorph`. I think for all sharing Morphs there should be a single `style` node, which gets updated when a morph enters/leaves the sharing or the CSS declarations of a sharing morph get changed. It is probably the easiest way to manage a collection of all sharing `HTMLMorph`s somewhere, so that we can regenerate the complete set of rules whenever necessary, since otherwise, upon e.g., deletion of a sharing morph, we would need to find out which part of the shared styled originated from this specific deleted one.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Begin by locating HTMLMorph's CSS declaration mount/unmount logic and the Spinner usage shown in the issue. Trace how morph entry, exit, and declaration changes are handled; done means optional sharing can be evaluated for Spinner while the default behavior remains unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, javascript
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.