This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-07
Channels
- # babashka (30)
- # beginners (49)
- # calva (22)
- # cider (9)
- # clara (2)
- # clj-commons (1)
- # cljdoc (1)
- # clojars (7)
- # clojure (153)
- # clojure-australia (2)
- # clojure-europe (45)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-nl (17)
- # clojure-portugal (3)
- # clojure-uk (6)
- # clojurescript (21)
- # conjure (4)
- # copenhagen-clojurians (5)
- # cryogen (3)
- # cursive (19)
- # datahike (14)
- # datascript (4)
- # datomic (9)
- # events (5)
- # fulcro (23)
- # graalvm (1)
- # gratitude (4)
- # helix (2)
- # holy-lambda (5)
- # improve-getting-started (2)
- # jobs (10)
- # kaocha (1)
- # leiningen (1)
- # liquid (8)
- # membrane (81)
- # off-topic (88)
- # polylith (29)
- # quil (1)
- # reitit (2)
- # remote-jobs (8)
- # reveal (8)
- # sci (1)
- # shadow-cljs (14)
- # specter (4)
- # sql (5)
- # tools-build (11)
- # tools-deps (5)
Is Zulip clojurians down?
hm. now works for me as welll
Somewhat off, somewhat on topic: is there a better way to work with CSS than "random tinkering attributes until things kinda work"? I mean, it all seems random... sometimes elements occupy 100% of the sceen when the parent asks for them to be centered, there are weird issues if you use transform
, etc...
Also, does someone tried, or even thinking, about designing an "explainer" for CSS? Something like "why does this attribute have this value" and then the tool shows you what is influencing that behavior?
Alas, I don't think it's a surmountable task. Not only CSS+HTML is immense, browsers are also finicky as hell. A few weeks ago was dealing with an issue where Safari versions X and Z were working properly but Y, where X < Y < Z, was ignoring overflow properties on children of table cells. And of course one of my clients had version Y. And just a few days ago, encountered a bizarre issue, where some very particular combination of flex containers with inline children were causing text with links to take as much vertical space as would be required for the text if it was wrapped at each word. Even though the text wasn't wrapped at all. Very hard to stumble upon randomly and impossible to find an explanation for. Somewhat related: https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html
I don't think working directly in html/css/javascript will ever get passed tinkering until it sorta works. Chrome dev tools does have a tool that shows you how a property is set:
Yeah, but nothing shows you how the combinations of those properties interact. Sometimes, you can find some explanations online, which are often along the lines of "here's this neat trick that accidentally does what you need".
For me, the devtools is only useful to get what the browser computed. Most "computed styles" are set from parents, from grids/layouts, or bizarre combinations of these (like setting align-items: center;
that sets width/height of parent elements, for example). So, I see the computed style, see that there's nothing exclusively setting that, then I start to comment attributes one by one until that "computed style" changes, so that I finally can understand why things happen the way they do...
every-layout.dev
might be a valuable resource (haven't seen it before), but those are all static "top-down" explanations. I.e. they're great when you want to achieve something and that something happens to be described.
But when you have a "down-top" situation, when you have something interacting in a strange way, it won't help much.
Oh, at this point I'm so jaded by tracing issues to browsers' bugtrackers that I'm always blaming the browsers by default.
I feel that with today's standards, we could replace CSS with the original idea of having a programming language for styles. I believe it would even simplify the implementation of layout engines, to be honest...
Like, literally in the CSS for JS devs course the author says: When you make a mistake in Typescript, you get a helpful tooltip telling you exactly what you did wrong. In CSS, by contrast, you're left in the dark
It feels like old-time school programming where you had to prepare a batch of commands, send to a computer, wait a lot and then get back "segfault" 😢
I just don't think the trifecta of html/css/javascript is a good medium for specifying user interfaces.
css isn't great and I would also say that using div
s and span
s as primitives is a bad idea
I'm not sure if that consistency is required or even beneficial for UI. I don't have that much experience, but desktop UI development has always seemed to be much simpler. Of course, web UI and desktop UI in general have different sets of requirements. But at this point it's still unclear to me that desktop UI technologies can't be more effective that web UI ones while developing the said web UI.
> this is pretty expensive and was just released but it targets the problem pretty directly. I haven’t tried it, though https://css-for-js.dev/ Havent looked at it myself either, but the same author also maintains a pretty insightful blog: https://www.joshwcomeau.com/
I think that the amount of freedom you get with html/css/js as opposed to the fixed nature of desktop widget toolkit is both a source of complexity, as well as one of the primary reasons the web became as large and diverse as it is.
I would dare to say that desktop development provides you with even more freedom. :) I mostly have experience with Qt 4 and early 5, but you can change absolutely anything there and make it work.
@UDF11HLKC there's also the EFL framework that do offer a separation between UI and logic, so you can have both. EFL also decided to not do CSS at all, and instead have a scripting language for layouts. This made skins that essentially behave extremely different from each other, but use the same "backend" (if we can call it like that). I remember being kinda revolutionary at the time it was presented
(sure, they didn't care about backwards compatibility at all, so people decided to not use, but still 😄)
Sure, but would you still classify that as easy. I think that for many people, creating custom components is easier on the web than in a widget toolkit. Although I’m much better versed in web than in widget toolkits :’)
Yes, it was easy. Qt is amazing with documentation and examples. Well, was, at least.
web UIs are a strict subset of desktop UI options.
In terms of possibilities, yes. It's just that those possibilities are exposed in an often not-so-friendly way, if at all.
Is that true? QT, cljfx, chromium embedded framework, and electron all offer webviews for using html/css/javascript
CSS is such a vast topic im dealing with for years almost every day at work and I still learn new things constantly.
What I realized a bit late was that about all properties that have to do with layouting are parameters to a layouting function set through display
. But every now and then weird things start to happen because there are all too many rules on behavior that cannot all be kept in mind the same time and in addition specificity (style overrides) make things even more complex for the mind. I would appreciate a clojuresce approach of minimizing things one have to keep in mind while doing things.
E.g. did you know that if you set width/height on a flex-child that refers to the current main axis makes that width/height behave as flex-basis? Its things like that which appear in the wild and are really hard to keep together in a small mind especially when many styley fly around.
This discussion is interesting to me because I genuinely think CSS is hard to do right, despite being a web dev since almost 10 years, so it is kind of my daily business to do this. Now many struggles described here and elsewhere often come down three issues: 1. CSS is a non-orthogonal system (like helicopter controls), with strong defaults (I don’t mean just browser defaults, but rather how declarations interact). It is very easy to get a thing right that fits right into the model, but very hard for special cases. 2. Many who struggle with CSS don’t take it seriously enough to study it. There are tons of details/interactions to know and experiment with to build up working knowledge. I recommend “CSS The Definite Guide” as a start. 3. CSS is hard to organize, especially if you don’t either use a preprocessor or a library that integrates your UI with it (css in js etc.) one reason for this is that everything is globally scoped and the cascading rules. If you are not careful and have no naming and structure conventions, then you get into a mess really really quickly.
But yeah I largely agree with how CSS works, it’s the quirks and special cases that make it hard and frustrating sometimes.
elm-ui did some cool stuff with that. If you haven't tried that design system, i'd reccomend it
with the understanding that CSS isn't going away.. if you are looking for a comprehensive book to fundamentally improve your understanding of CSS I found this one provided major insights for me and would highly recommend it: https://www.manning.com/books/css-in-depth
Step 1: Wait for elm-ui to release 2.0 with its complete animation story Step 2: Map out how to best represent that api in clojure (and react probably) Step 3: ctrl+c, ctrl+v Step 4: conference talks
But don't UI frameworks/libraries already provide such a functionality? Which is always enough only till it's not.
I rather use css frameworks. But even than I was unpleasantly surprised some menu item wasn't shown on some phones because of the resolution. You could fall back to drawing on a canvas, on a fixed size. It least less surprises..
I would propose an alternate approach. 1. Read about how designers think about layout (eg. design systems, design tools) 2. Map out how to best represent that api in clojure (probably not react) 3. Figure out how to automatically produce html/css from that representation (we already have clojure -> js!) 4. build stuff
@U7RJTCH6J got it right. For one, designers don’t think of the UI as being strictly hierarchical. For them it is more about an open set of relations, rules and principles. Also they adopt the models of their tools, which are layers and transformations. In web frontends we use a strictly hierarchical model and cram everything into it. The tools we have for this model are appropriate: css follows this tree model/traversal. An efficient translation layer between those two could possibly be a very worthwhile undertaking. And Clojure seems to be the right tool for this.
> Also they adopt the models of their tools, which are layers and transformations. I would say it's the opposite. Their tools adopt the [mental] models of their users. It's an anti-pattern to try to define everything in terms of the tools you already know (eg. React, css, divs, spans) rather than spending the time to define the right model.
That’s right. I have to say one thing about designers though. It is common for them to polish a design/prototype around a given state or input data such as screen size/ratio, text and others. I think a new paradigm should take that into account. I have the habit of opening the browser console on sites that I find interesting. A thing that stands out is that low/no-code tools never get this part right. They might provide abstractions that are closer to a designer’s model, but don’t incorporate the failure modes, the programmer thinking, the what ifs.
I think the main units of composition are a form of "masters" and instances in figma, rather than the tree
Adobe XD on the other hand can have a hierarchy but mostly works through relations of elements except you group them explicitely. I also get designs printed onto a PDF with A4 pages. No idea how those are made :thinking_face: Indesign?
eg. the dropdown item instance, will receive its properties from the main rather than from its parent
The main issue with react isn't that it has components, but how it manages state (hidden state, global state, side effects). I would also say that using divs and spans as primitives is bad idea that is common with react, but react doesn't prohibit using other primitives.
I think react + stuff is a fine option if you want to build stuff today, but I really hope that's not where we're at 2-5 years from now.
I want to explore Figma more now. The vast majority of designs and prototypes I get are made with XD and some Sketch. Designers I know are typically not very diligent about organizing into components and tokens either. Not explicitly that is.
Here's a few references: • https://www.figma.com/community/design_systems • https://www.figma.com/community/file/857042825430121164 • I would also check out their data model. It's interesting, https://www.figma.com/developers/api#node-types their blog has some interesting posts: • https://www.figma.com/blog/line-height-changes/ • https://www.figma.com/blog/behind-the-feature-shadow-spread/ Generally, I also think the design systems that different companies/organizations have published are interesting.
And again, I think the hierarchical model is a translation or mental compilation target. That shifts more modeling work towards designers so it translates well. But is it the right model?
A collaborator of mine tried it out a bit, but didn’t like it because it didn’t feel right for him. My guess at the time that it was just about the Ui or the familiarity.
Constraint layout is also an interesting layouting option in Android. Android has different layout possibilities that behave slightly different from each other much alike the different CSS layouting algorithms (Flex / Grid) but quite interesting. (Downside here: XML but thats just their approach) Edit: Forgot the link: https://developer.android.com/training/constraint-layout
Just came across one of these weird CSS features: https://developer.mozilla.org/en-US/docs/Web/CSS/will-change This feels like a compiler flag/annotation (inline this function/method etc) rather than an actual styling rule. It’s one of those examples of how CSS is a super leaky abstraction (in some cases). Now it obviously has history, people might have used Z transforms to achieve the same. The Z axis also has a history of being abused to for example trigger GPU rendering for CSS animations.
Its really rather weird as all it can do is optimize animation performance. It has some quirks too though as it can lead to one-pixel shifts due to those optimizations
> is there a better way to work with CSS than "random tinkering attributes until things kinda work"? If by "better" you mean more predictable, you could put in the time and effort to become a CSS expert, like the people in the thread above. Otherwise, the approach I prefer: don't create CSS, use a library. If, like me, you're not a CSS expert, and you don't require a highly customized UI, pick the most suitable UI library and stay within its bounds. You can lightly customize it, but any CSS not documented by the library should be considered a smell. CSS is too low level an abstraction for most projects. It's like making X-Windows calls for drawing/event handling when working on a Gtk or Qt app - you should be working at a higher abstraction level. There are some use cases where that low level hacking may be necessary or worth it, but in most cases it's just not. Even if we've gotten used to the expectation that it's "part of the job". "Random tinkering attributes until things kinda work" is indicative of the depth of knowledge and understanding that is required. Not understanding of the primitives and their specs, but of platform (browser) specific implementations of the spec. I.e. it's a problem of portability, caused by excessive complexity. (Who can tell that I spend most of my time in the back-end? 😝)
@U3Y18N0UC watch everything by Jen Simmons. 1. Start with CSS grid as your default mental model. It's more declarative then it's predecessors. 2. Use something like nubank workspaces or story book to keep components and functionality isolated.
However there will always be some amount of tinkering because the output relies on human aesthetics.
> Also, does someone tried, or even thinking, about designing an "explainer" for CSS? Something like "why does this attribute have this value" and then the tool shows you what is influencing that behavior? The browser will give you the best feedback for that information.
> The browser will give you the best feedback for that information. So that translates to "no" for me 😄. The best the browser shows is still way too little...
@U3Y18N0UC Can you give an example of what the browser can't show you? In chrome if i click inspect and look at the elements it will list everything in styles that it used to compute the styles. The styles, computed, layout tabs all show the information that is used to render the page.
@U0DJ4T5U1 for example, sometimes width is calculated not by explicitly setting the width. Maybe it was a max-width
, maybe because it's a flexbox, or a grid, etc. Sometimes it's unpredictable - I was trying to use flexbox wrapping and when things wrapped, the way the browser was calculating things changed.
Other possible example is when you use transform: scale...
. Sometimes I saw the parent resizing, others don't. What I end up doing is listing styles, the toggle everything off then little by little I toggle something on, to see what's influencing the behavior. It's quite like "commenting lines of code and running things until I found out why that variable contains -1
instead of 10
", and it seems incredibly unproductive (specially because I never know if that's how things are supposed to work, if it's an implementation detail, or a bug - and working with browsers, sometimes is a combination of all three)
@U0DJ4T5U1 Browser dev tools have gotten much better I have to agree. But they show very little interaction. I mentioned above how CSS is non-orthogonal: you have to turn multiple knobs at once to get a desired result. And that part is mostly implicit when it comes to tooling, you have to know and model those interactions in your head and translate the knob tuning back into CSS rules. A simple example that I think is not obvious and not explicitly shown in dev tooling: What does X% width/height refer to? Your intuition might fool you there. Similarly X% translation, box-sizing, how to compose multiple transition properties, flex interactions, margin overlap for block vs flex. Those are just some of the more basic things from the top of my head and there are tons of more subtle ones.
@U3Y18N0UC I agree with those kind of things you are either doing black box testing or just happen to know, have studied, a ton of non-obvious interactions between rules.
and to expand: max-width, flex grow/shrink and explicit width, those have non-obvious rules as well
Those rules might be non-obvious, but if the browser tooling itself can't surface how it's computing things i can't imagine what could.
I don’t quite get what you mean there. the browser shows you the calculated pixels and your rules
I'm not sure what you mean, what tool outside the brower (e.g chrome dev tools) have you been using to get information about your css?
the flexbox tools in Firefox are pretty good tho. Same with grid 🙂.
I think there is a misunderstanding here. I meant the tooling is not sufficient to really understand what is going on
Sure, I guess I would need to see a specific example to see if it was or wasn't. But in general yea, i run into things all the time i can't easily explain 🙂. My point was just that the browser tooling is the best place to look.
I have to say though. The MDN pages and the book CSS the definite guide are excellent resources to find even the weirdest interactions
firefox developer browser is great for css: grid, flex, etc...
I think the browser could add some "debug information" about CSS. I mean, it is already rendering what's going on, and sometimes even add source-map for SASS and LESS, for example.
Yes, but they link it on the devtools, that's what I meant
I think the issue is that lots of times "whats going on" is a royal tire fire. Which is why your best bet is to use the higher level new stuff like grid and flex. If your having issues there then your likely in the same camp as me :)