Well, it seems I totally missed my point by mentioning the hypothetical
insertRule example or by focusing too much on performance I was more talking about interoperability and grouping effort (which could lead to better performance among other advantages).
To be clear @evancz, I agree with you and I am not particularly advocating its use at this point.
Let’s try again: currently elm-css and elm-ui use two different APIs and algorithms to attach styles to a node, then merge all styles (usually at a higher level in the DOM tree), currently in a
style node, and applying them (usually using a
I was wondering if it was possible to find a common API for this, with one or several implementations in libraries (that would not require any elm modification or kernel code). The advantages would be:
- it would be easy to test different implementations and compare them (speed, DOM size, ease of debugging, readibilty, etc.). For example elm-css could test the elm-ui one and vice-versa if both are implemented, before choosing a common one.
- once a common implementation is used, it might allow to use nodes or styles from one UI library into the other without conversion. It seems interesting to me as we could add some (unfortunately sometime needed) css hacks using elm-css in an elm-ui application, or include some elm-ui elements in an elm-css application without conversion.
- a new UI library using inline styles could focus on UI, widgets and layout instead or having to re-implement this. And libraries using the same inline styles merging implementation could be used together without conversion (like elm-css
- it could be more practical to benchmark at such a low level, easier for a new-comer to understand the code and propose some improvements, and if elm someday adds some new API to improve this (because it has been proved to be worthwhile), then once this/those low-level librarie(s) use it, all the UI libraries that depend on it/them would benefit from the improvement.
This is only for the last point that I mentioned
insertRule, but it was just a very hypothetical example, maybe a bad one.
At last @rtfeldman, I am aware of the work in progress in the elm-css phantom branch as I am trying to actively contribute to it (#452 and #453), but it seems to me to be partially at a higher level, maybe not incompatible with what I am talking about.
However as I said, this was just a thought and I don’t know
elm-ui well yet, so I may be completely wrong. Anyway I am sorry if I wasted your time by missing my point (it is sometimes not so easy when english is not the native language), or by wondering about some non-sense. I will try to give a more concrete example when I find the time.
Have a nice day