This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-25
Channels
- # beginners (21)
- # boot (37)
- # cljsjs (1)
- # cljsrn (1)
- # clojure (48)
- # clojure-greece (3)
- # clojure-poland (1)
- # clojure-quebec (4)
- # clojure-spec (40)
- # clojure-uk (1)
- # clojurescript (113)
- # cursive (13)
- # events (3)
- # hoplon (183)
- # jobs (5)
- # off-topic (2)
- # onyx (49)
- # planck (35)
- # re-frame (8)
- # reagent (2)
- # sim-testing (1)
- # specter (4)
- # spirituality-ethics (2)
- # untangled (1)
- # vim (2)
- # yada (1)
@jumblerg: Hi! I've got Hoplon/UI up and running and have been poking around. I'm enjoying applying style attributes more directly in clojure data, rather than bounce back and forth between the ':class' and ':css' attributes, funging around with the values wrapped in strings.
This is helping with my general Hoplon aha moments. The value of having the dynamic environment is so mindboggling compared to the static page context. I can continue to appreciate it more with the advanced visual design code patterns being more apparent and accessible.
More invititing for Javelin functional play! :
at least to weave it into declarative styling.
@chromalchemy: glad to hear it! we’ve still got a lot of work to do, but i think this approach holds a lot of promise.
@jumblerg: I've been playing with hoplon/ui a little; my background in hoplon is generally pretty limited so apologies this will probably be pretty obvious. How should I go about putting in place HTML elements that can't be wrapped in a box? For instance I'm trying to get <ul><li></li></ul>. I can't wrap h/li in box as they cannot be wrapped in a div. If I just pass in h/li directly as a child element of (elem) I get an error on initialisation in swap-elems!:
Uncaught Error: Invalid child of type function HTMLUListElement() { [native code] } with values (#<Cell: :middle>).
(def vul (-> h/ul hui/parse-args))
(def vli (-> h/li hui/parse-args))
...
(elem :fc c/white :h (r 1 1) :av :middle :ah :right :ph 15
(vul
(vli "List Element 1")))
^ or should I not try to add <ul><li> and entirely fake it using elems appropriately laid out?
my suggestion would be to only use elems, at least, until it becomes clear that we need to introduce another component.
you shouldn’t ever have to drop down into hoplon html primitives, unless, that is, there’s a deficiency in hoplon/ui
and we need to introduce another ui primitive, so to speak.
based on the code you’ve shown me, it appears you’re mucking around with the ui internals, which isn’t something you should have to do normally.
(they’re also going to be refactored in a big way, and if you depend on them instead of the external api, your code is going to break. i haven’t added any private metadata yet because it gets in the way of my own refactoring, but most of these fns you’re calling should be made private.
are there any additional semantics you need (exposed, perhaps, as kwargs to the elem), that the approach below does not provide?
(elem :w (r 1 1) :pl 15
(elem “List Element 1”)
(elem “List Element 2”))
my goal is to have an api with a very small service area, to expose the fewest types of things possible. if all the tetris blocks were squares, everything would compose quite nicely and the game would be much easier.
Nope, thanks. Your logic makes sense and the only reason I exposed the internals was because I wasn't sure if they just weren't 'work in Progress' The only benefit of lists is bullet points and alignment of text new lines in bullets, probably doable with elems but harder.
ok, so the case is a bulleted list with the associated indentation. let me think about the best way to do this (there are css properties, for example, that could be exposed as ui attributes) and i’ll circle back with you later on.
makes me think of like the anti-tetris game, where it's really easy to make a horizontal line, but you lose points when you do it
so the goal of the game is to cover the biggest percentage of screen space in figures without making lines? 🙂
questions like @adamw’s have gotten me thinking about when it is appropriate to introduce a new element name, and specifically, semantic html.
i think it lends clarity to consider who the various actors are when thinking about how and whether we tag our elements.
so there’s (1) the platform. the name of the tag we pass createElement
carries behavioral meaning to the browser, but so do the various css styles. in most cases we can achieve the same behavior as another element my simply applying the right css attributes to a div. the browser doesn't seem to care in most cases.
(2) the developer. symbols in our code are designed for this purpose, although it could be useful, at at development time, to generate custom tags that correspond to the names of our abstractions to make it easier to debug layouts.
(3) the human user: the ornaments we hang on our data structures to make the interface more pleasant should be chosen for this purpose.
and (4) the machine user. apis are made for this purpose, our application is not. however, we may need to pragmatically support (a) web crawlers for seo (b) maybe other scrapers, but we probably don’t want these most of the time. (c) accessibility agents (4) other third party tools. but the lowest common denominator is large enough with ie 8 in play, to what extent do we care about other tools like brower plugin that implement only part of the browser's standard.
yeah, i’ve been looking around wrt <li>
vs <div>
and can’t find any advantage to incorporating the tag names specifically.
wrt #3, @chromalchemy has been giving me some awesome feedback.
i think, wrt #3, that having outer tag names that correspond to our defelems will be helpful.
otherwise, they will inevitably collide with primitive names and certain ones will be magically bestowed with new behaviors.
i never found that to be necessary though, since dev tools highlight the thing when you mouseover it
yeah, they have the data-* things, but i think given the audience, in this case the developer, i think it would be easiest to parse something like <hoplon.ui/table>
i think it is still helpful, even with dev tools, when you’re trying to match a certain thing to code in your editor. there are no sourcemaps for html i’m aware of.
and plan to implement it, but later on, i think that is an optimization we introduce for newer browsers, essentially.
iedge is thinking about it https://blogs.windows.com/msedgedev/2016/02/03/2016-platform-priorities/
maybe once ie 8 is out of the picture, stuff will get updated faster since everyone is “evergreening" it now.
i almost told adam that he doesnt need to define ul/li but then it occurred to me that those list-style-*
attributes are not exposed yet in any way in hoplon ui.
but then im not sure how useful are they really, since most of the time i just see them being turned off anyway by css reset "frameworks", like http://meyerweb.com/eric/tools/css/reset/
@micha et. al: api design question. what do you think about defining “truthy” default values for certain elem attributes in ui? consider my favorite attribute, :fu
, as an example. font underline is implemented through the css text-decoration property. the options are [:overline, :line-through, :underline nil false]
. but 90% of the time, it is easier for the user to (elem :f 21 :fu true) rather than lookup the attribute. more importantly
(elem :fu query/selected “some menu item”)` is more concise than (elem :fu (cell= (when query/selected :underline “some menu item”))
.
one downside is that validation cannot be quite as strict for such truthy attributes, but this is consistent with clojure’s philosophy i think.
eg, if i pass :fu
with a truthy default of :underline
some garbage value, it will underline the text instead of throwing an exception.
i also validate the keywords to throw an exception if not one of the expected values
(defn foop [arg]
(let [valid-things #{:foo :bar nil true}]
(doit (valid-things arg :foo))))
i’m proposing that nil
, false
, the falsey values, equate to false, true, :somegarbage default to :underline
.
gotcha, implemenation aside, sounds like that api choice seems sensible to you then?
in the context of an attribute that has a set of possible values that translate to css properties
(s/def ::colors #{:transparent :antiquewhite :aqua :aquamarine :azure :beige
:bisque :black :blanchedalmond :blue :blueviolet :brown
:burlywood :cadetblue :chartreuse :chocolate :coral
:cornflowerblue :cornsilk :crimson :darkblue :darkcyan
:darkgoldenrod :darkgray :darkgreen :darkgrey :darkkhaki
:darkmagenta :darkolivegreen :darkorange :darkorchid :darkred
:darksalmon :darkseagreen :darkslateblue :darkslategray
:darkslategrey :darkturquoise :darkviolet :deeppink
:deepskyblue :dimgray :dimgrey :dodgerblue :firebrick
:floralwhite :forestgreen :fuchsia :gainsboro :ghostwhite
:gold :goldenrod :gray :green :greenyellow :grey :honeydew
:hotpink :indianred :indigo :ivory :khaki :lavender
:lavenderblush :lawngreen :lemonchiffon :lightblue :lightcoral
:lightcyan :lightgoldenrodyellow :lightgray :lightgreen
:lightgrey :lightpink :lightsalmon :lightseagreen
:lightskyblue :lightslategray :lightslategrey :lightsteelblue
:lightyellow :lime :limegreen :linen :maroon :mediumaquamarine
:mediumblue :mediumorchid :mediumpurple :mediumseagreen
:mediumslateblue :mediumspringgreen :mediumturquoise
:mediumvioletred :midnightblue :mintcream :mistyrose :moccasin
:navajowhite :navy :oldlace :olive :olivedrab :orange :orangered
:orchid :palegoldenrod :palegreen :paleturquoise
:palevioletred :papayawhip :peachpuff :peru :pink :plum
:powderblue :purple :rebeccapurple :red :rosybrown :royalblue
:saddlebrown :salmon :sandybrown :seagreen :seashell :sienna
:silver :skyblue :slateblue :slategray :slategrey :snow
:springgreen :steelblue :tan :teal :thistle :tomato :turquoise
:violet :wheat :white :whitesmoke :yellow :yellowgreen})
disarming the nil shotgun via (def safename [x] (when x (name x))
seems like the way to go for this reason.