Fork me on GitHub
#hoplon
<
2017-01-29
>
thedavidmeister04:01:42

@mynomoto dunno, i've got plenty of potential snippets 🤷

jumblerg07:01:29

@chromalchemy, @grant: you might find the last commit helpful. elements can be overlaid now via the :distribute attribute. :d :pile. i did the most lightweight implementation possible to get through a project, so if you want to use this feature, you'll need to (a) make sure the elem is explicitly sized and (b) does not require the :pad and :align attributes, which will not have the intended effect. in practice, i haven't found them necessary. here's what it looks like in practice:

(elem :s 400 :d :pile :b 2
  (elem :s (r 1 1) :a :mid :c (hsl 0 (r 1 1) (r 1 2) (r 1 2))
    "bottom")
  (elem :s (r 1 1) :a :mid :c (hsl 240 (r 1 1) (r 1 2) (r 1 2))
    "top"))

dm309:01:57

maybe call it :stack? Sounds nicer to me

jumblerg10:01:18

@dm3: i've been on the fence between :stack and :pile. my thinking was that :flow and :pile paired better since neither is a data structure. i could be convinced to change it though.

jumblerg10:01:04

maybe pile is a bit sloppy.

jumblerg10:01:16

i was also considering a more elaborate :ltr, :rtl, :ftb, :btf implementation, but wasn't sure there was value in it. i haven't had any concrete cases where i needed right to left layout (other than for internationalization , but that applies only to text).

dm310:01:36

it invokes negative associations not related to computing, as in "pile of ..."

dm310:01:47

not sure about ltr/rtl

dm310:01:14

you should be able to reverse the elements programmatically

dm310:01:58

I guess a pile is unorderly

dm310:01:02

while a stack is neat

jumblerg10:01:15

it does seem that stack would come more naturally to programmers too; i'll make the change on the next commit.

thedavidmeister10:01:26

@jumblerg i've had to swap the layout rtl and it wasn't just text

thedavidmeister10:01:47

apparently it made sense to move the sidebar too

jumblerg11:01:42

@thedavidmeister: hm, switching a sidebar from the left to right side is an interesting case. i guess normally this would be done by reversing the order of the sidebar & body elements in the dom; is there any advantage in allowing those elements to remain in the same place while reversing the order in which they render?

thedavidmeister11:01:32

this would have been in like 2010

jumblerg11:01:35

also, if i were to to support right to left layout for things other than text, i'd probably need to implement both back-to-front and front-to-back layout.

thedavidmeister11:01:39

so things were different then

thedavidmeister11:01:18

i suppose the obvious thing is screen readers going from top to bottom

thedavidmeister11:01:26

but if you have aria stuff on your sidebar should be ok

jumblerg11:01:26

i haven't even begun thinking about the accessibility stuff.

thedavidmeister11:01:44

from memory there was something in css

thedavidmeister11:01:08

also affects direction of flow of table cells

thedavidmeister11:01:49

flexbox would also let you swap ordering

jumblerg11:01:08

i was using that css attribute when i first added the ui distribution attribute, then took it out in the interest of simplification when i couldn't think of a concrete case for rtl layout.

mynomoto11:01:04

@thedavidmeister may I put the snippet on the wiki for now?

thedavidmeister11:01:50

@jumblerg this was a while ago, but i think i was supporting pashto language

thedavidmeister11:01:17

it's basically that when you swap the text order, you might also want to swap the layout

thedavidmeister11:01:32

as in, sidebar goes "where you start reading from" not "on the left"

jumblerg11:01:50

hm, so it lets you do it in a more general, uniform way in this case.

jumblerg11:01:08

makes sense

jumblerg11:01:08

seems like a sensible guiding principle. although incidentally, i remember placing the sidebar on the right for certain web apps because i'm right handed and it felt more natural to have it on the same side as my hand/mouse.

mynomoto11:01:11

@thedavidmeister cool! I have something like that on github client and will put in a library hopefully soon.

thedavidmeister11:01:48

@mynomoto maybe you might be interested in this too?

thedavidmeister11:01:53

(ns el.resize-observer.dom
 (:require [hoplon.core :as h]
           [javelin.core :as j]
           polyfill.ResizeObserver))

(h/defelem div
 [{:keys [width height]} children]
 (let [el (h/div
           :class "clearfix"
           children)
       ; 
       el-attached? #(-> % .-ownerDocument .-body (.contains %))
       cb (fn [es] (let [rect (-> es first .-contentRect)]
                    ; Don't trigger a resize when the el is detached from the
                    ; DOM as it will always be 0 and lead to a FOUC.
                    ; There is another resize when the el is re-attached anyway.
                    (when (el-attached? el)
                     (j/dosync
                      (when width (reset! width (.-width rect)))
                      (when height (reset! height (.-height rect)))))))]
  (.observe (js/ResizeObserver. cb) el)
  el))

thedavidmeister11:01:13

it's an element that knows how big it is

thedavidmeister11:01:49

not sure what counts as "snippet worthy" 😛

mynomoto11:01:04

Let them bloom! We are missing resources atm

thedavidmeister11:01:37

that one needs this to work:

thedavidmeister11:01:41

; ResizeObserver polyfill.
                                            {:file ""
                                             :provides ["polyfill.ResizeObserver"]}

thedavidmeister11:01:51

because of browser support

mynomoto11:01:09

Done. Keep them comming 🙂

thedavidmeister11:01:46

ah, just working on something atm

thedavidmeister11:01:54

i'll ping you with other stuff later 🙂