Yeah, that does sound like a tricky problem if you can't get the
offsetHeight from the DOM. Even though you know the line-height, I don't
know how you could tell how many lines the input takes up.
On Thu, Dec 22, 2016 at 9:14 AM, Fabrice Marchal
wrote:
> Another example where I don't see how to
Another example where I don't see how to avoid reading the DOM: to edit an
SVG text, we put on top a non-resizeable textarea that grows in height as
the user types. I do that by reading the offsetHeight of the textarea on
each key 'input' and adjust the svg. One could compute the text size from
Thanks! It could be helpful.
On Thursday, December 22, 2016 at 2:53:13 PM UTC+1, Rex van der Spuy wrote:
>
>
>
>
>> 1. Is someone working on an higher-level SVG library than elm-lang/svg ?
>> Im thinking about support for path intersection, bounding box operations,
>> etc.
>>
>> I don't know if
Yes, I agree with Rex. The DOM is write-only by design. Going forward, I
don't expect there ever to be a generic way to read the DOM... if specific
problems come up that absolutely require it, they will be solved by
specific APIs, such as in elm-lang/window and elm-lang/dom.
On Thu, Dec 22, 2016 a
> Currently the solution seems to be 1) compute the bounding box manually
> inside the update function whenever the selection is modified, 2) keep
> the bounding box data in the model and 3) use the bounding box from the
> model when the update function performs other operations on the model
> 1. Is someone working on an higher-level SVG library than elm-lang/svg ?
> Im thinking about support for path intersection, bounding box operations,
> etc.
>
> I don't know if this is what you're looking for, but it's excellent:
http://package.elm-lang.org/packages/MacCASOutreach/graphicsvg
