Closed blakeembrey closed 7 years ago
I don't really use change events so I'll count myself out; once my app has rendered once it doesn't define any more styles
Sounds way more performant, I'm on board.
All good. It's a backward compatible change (I'll keep changeId
), just wanted to get some eyes on it. I'll update the issue when it's implemented 😄
Note to self: Useage in typestyle : https://github.com/typestyle/typestyle/blob/d4de3659c88f348e1c2220cc405aba62c9db4b04/src/internal/typestyle.ts#L87-L99 /cc @notoriousb1t
(I'll keep changeId),
Well be fine then :rose: :heart:
Non-breaking change is great to hear.
/cc @basarat, @ajoslin, @jkroso
Free-Style 2.0 removed the change event listeners in favour of a simpler
changeId++
approach. However, this isn't great for the browser re-parsing styles. I'd like to propose adding handlers (not an event system) that will receive style changes and you can sync up with a<style />
element usinginsertRule
anddeleteRule
directly.onAdd(rule, index)
onChange(rule, newIndex, oldIndex)
onRemove(rule, index)
All you would need to do is propagate this events directly into a
<style />
element instead of resetting the entireelement.textContent
and causing the browser to re-parse and potential FOUC.