This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # announcements (1)
- # babashka (16)
- # beginners (222)
- # bristol-clojurians (6)
- # calva (13)
- # cestmeetup (5)
- # cider (19)
- # cljs-dev (2)
- # cljsrn (4)
- # clojure (64)
- # clojure-europe (31)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojure-uk (33)
- # clojurescript (64)
- # community-development (5)
- # core-async (18)
- # cursive (13)
- # datomic (6)
- # devcards (1)
- # emacs (18)
- # figwheel-main (102)
- # fulcro (51)
- # graalvm (2)
- # helix (8)
- # instaparse (33)
- # jobs (8)
- # jobs-discuss (3)
- # leiningen (42)
- # off-topic (88)
- # pedestal (15)
- # re-frame (18)
- # reagent (26)
- # reitit (15)
- # rum (3)
- # shadow-cljs (119)
- # spacemacs (9)
- # sql (2)
- # tools-deps (7)
@jarvinenemil I build a 'micro-cms' was quite fun and pretty easy. Idea was via a websocket read/write files on the server, and create a static site from the files. Using spec both to validate, and generate the ui. But then the site wasn't need anymore, and is was clear spec was being redesigned. So it's left more as an experiment then anything usefull, https://github.com/gklijs/mv.
Thanks maybe once spec2 is not alpha anymore I'll pick it up again, but for my 'own' page then..
I used to work with an 'enterprise' cms, but in practice I think you don't need much more, als long as you can edit, see you changes, and have a secure way of putting them live, without others being able to make changes. But some go wild with authentication structures and workflows. But I guess even those things would be much easier to implement with Clojure. I'm not sure though if I would start on something like that right now, if I would use websockets and a custom logic, or GraphQL. Using GraphQL would make it a lot more easy to add other content.
@gklijs i've seen some cms systems on the jvm (written in Java) that uses portlets heavily 😄
Seems like they all become headless and exposing GraphQL, and you can use whatever you like for UI?? My company is still kind of waiting for the next big open source Java CMS 😂.
Can someone more proficient with Flexbox please explain why on Earth the yellow box is not as wide as the green box here? https://jsfiddle.net/r531Lbpz/1/
I'm trying to understand why the yellow box is not as wide. The parent ignores the width of the child with no content, thus creating the overflow. I don't understand why.
Because it's only going to go as far as necessary, dictated by the content. If you put width: 100% for that div with the yellow background, it will stretch all the way across.
> dictated by the content But the content is already wider than it is. Isn't the green div considered a content?
I'm not trying to make the yellow parent as wide as possible. I'm trying to make it as wide as the children. No matter what the actual content of the children is.
I dont think you need the width 100% since by default the content is stretched to fit the container
For example, take a look at this modification. Now the yellow part doesn't make sense in the slightest. https://jsfiddle.net/r531Lbpz/2/
An alternative goal - I want to come up with a way to make a parent div (the yellow one) to always respect the sizes of the children. No matter if there's text or not, if there are inputs or not.
@U013CA8A28J The yellow part is now neither the width of the text, nor the width of the input field. Where does its width come from?
I think the yellow container does not have a flex- property which is why it evenly divided into the parent div
flex: 1 0 auto and it will grow. Replace the 1 with 0 and it goes back to what you had
To get it working I would just leave the yellow container as a normal div. And explicitly set the other divs as flex containers.
And if I do that, the
flex: 0 0 400px; is ignored and the divs become as narrow as the text.
flex:0 0 400px is kinda weird, since its parent isn’t
display:flex. If you change this to
width:400px it works as expected.
Here's a version that illustrates my frustration with it a bit better: https://jsfiddle.net/r531Lbpz/3/ Notice how the 400px-wide divs are overlaid on top of each other. That's undesirable.
@U0DTSCAUU The parent is
display: flex - look at the CSS panel. All divs there are flex.
Well, I said to make the yellow div a normal div, not a flexed div. And explicitly set the flex divs
@U013CA8A28J Visually - something like that. But
flex-base. If I understand correctly, the behavior is different if I decide to use
Ah, I see. So the
<div> around “Hello there” is also
display:flex , it itself is indeed 400px wide. It creates a virtual element around the “Hello there”, and that virtual element is too small.
Ah yes, the default for
flex-grow is zero, so the virtual element around “Hello there” definitely won’t grow.
@UB0S1GF47 Yep. And if there are some laws of Web 2.0 that make it impossible, I would love to know about them. I once tried reading the spec, but I must admit I dropped it as soon as I found something that was working differently in different browsers.
It’s hard with the global rule setting all div’s to display:flex. You’re really overriding the default layout engine of the browser.
I couldn't imagine that it would be a problem given the wide-spread support of flexbox.
Even if I am doing something obscene from the POV of the browser - can you explain why the
input example works so much differently from the
It’s not a matter of support, it’s that your intuition about browser layout is based on divs being display:block, and globally setting display:flex throws that out the window.
Nah, I don't have any intuition here. :) Or rather, I have somewhat of an intuition for flexbox that works 99% of the time. This particular example is from that 1%.
The other strange thing is the
flex:0 0 400px rule. That
400px part is shorthand for
flex-basis:400px, which tweaks how flex allocates extra space to that element. I’m surprised it does anything when it has no siblings. If you’re looking for an explicit width you should really set
width on the appropriate element.
> I’m surprised it does anything when it has no siblings True. But if you add a sibling, the behavior doesn't become more predictable. At least, not for me.
Yea honestly I would just keep the yellow div as a normal div. And set its children to an explicit width of 400px;
> If you’re looking for an explicit width
I would prefer to leave
flex-basis just because it (again, AFAIK) will work with
flex-shrink whereas the plain
width will not. I.e.
width: 400px with
flex-shrink will never actually shrink. Or grow. Unless something else breaks.
I really want to avoid CSS media queries and still have everything work nicely on all screen sizes. Maybe I want too much...
I ran into this issue as well and I was able to get this working only to find out that the solution didn't work in IE. So keep that in mind if you need to support IE
> How about `max-width:400px`? Huh. Now I feel both stupid and that this solution is itself "stupid" enough to just work with no hassle.
Now only the initial question is left - why on Earth does it work that way, especially why the difference between
My guess is that the browser treats
flex:0 0 400px as just
width:400px, since grow and shrink are both zero.
I also guess that since inputs default to
display:inline, you’re seeing the same problem as with the raw “Hello, there” string.
The issue you had with input is the fact that the yellow div is not flexible. If you set it to be, then it works fine. https://jsfiddle.net/hanrdxc5/12/
Flexbox is really easy. You are just describing the relationships the boxes have to each other. If you want to hard code something, like preventing the scaling from going to ludicrous lengths on large screens, you use max width. You really should use media queries though. It keeps things simple.
@U0DTSCAUU > My guess is that the browser treats flex:0 0 400px as just width:400px, This guess is wrong - you can easily check it by replacing the former with the latter.
@U013CA8A28J No such thing is "flexible". There's
display: flex and there's
flex-grow. If you set
flex-grow to 1, then you get a behavior that I explicitly said before I don't want.
Well they’re the same from the perspective of setting the width of that element. Somewhat surprised that it has that downstream effect of growing the yellow box. But then again, when all divs are display:flex there’s bound to be surprising things all over the place.
> when all divs are display:flex there’s bound to be surprising things all over the place. And that's a pity. I remember reading about drag-n-drop in HTML5 and how it's messed up at a fundamental level. After a couple of years some of the members of W3C acknowledged that they could've done a better job. Then I started tinkering with web audio API. Turns out, it's also messed up at a fundamental level, and at some point some W3C members also acknowledged that. And now I wonder if that's the case with Flexbox. Or the whole CSS3 or whatever the number now is.
Don’t get me wrong, I find flexbox essential for any non-trivial web design. I love hot sauce too, but it’s a mistake to put it on everything. 🙂
@U2FRKM4TW I think I may be able to answer your question about the yellow div's width. There is a default width on input elements and thats what the div's width it set to originally. Then the children div the one with the
flex: 0 0 400px causes the input and div elements to stretch to 400px; So when you give any of those children an explicit width the yellow div knows how wide it needs to be. Hopefully that made sense.
@U2FRKM4TW the root cause is
flex-flow: column, which causes
flex-basis to control the height instead of the width. However, this is hidden from you since the body and the outer divs are too small
Example showcasing how the green box has height 400px after explicitly expanding the height of the parent: https://jsfiddle.net/a6n302yf/
^ see a flex box question. Oh i might be able to help. "reads 64 replies". I'll see myself out.
p-himik's hypothesis: "Each question about flexbox with N divs will result in a discussion with at least 2^(N+1) replies."
Whats your best option for having fastest text search in a note taking app. Full text search sqlite db? Just regular read and match with regex? Moby Dick is ~600pg and 1.2mb, so loading most of the things in memory shouldnt be a problem i guess