Fork me on GitHub

@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,


cool project 👍


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.

👍 4

@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?

Vishal Gautam17:05:10

what are you even trying to do?


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.


Another option is to use flex: 1, which will tell it to fill the size of the space.


> 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.


The content is the text


not the div

Mario C.17:05:59

I dont think you need the width 100% since by default the content is stretched to fit the container


@U013CA8A28J Would you say that <input> is considered content in that case?


What are you trying to do exactly?


I'm trying to understand what's going on.


For example, take a look at this modification. Now the yellow part doesn't make sense in the slightest.


What doesn't make sense?


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?


the 400px you inserted in there


It's not 400px.


The container is


So what? I was asking about the yellow part all along.

Mario C.18:05:27

I think the yellow container does not have a flex- property which is why it evenly divided into the parent div

Mario C.18:05:16

add flex: 1 0 auto and it will grow. Replace the 1 with 0 and it goes back to what you had


On my end, it grows larger than the children. That's not what I want.

Mario C.18:05:18

To get it working I would just leave the yellow container as a normal div. And explicitly set the other divs as flex containers.

Mario C.18:05:20

I think the yellow div being just a flex container is causing the confusion.


And if I do that, the flex: 0 0 400px; is ignored and the divs become as narrow as the text.


The 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: 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.

Mario C.18:05:06

Its ignored since the parent div is not a flex container anymore


What? Why is it not a flex container?


Are you trying to accomplish this?

Mario C.18:05:45

Well, I said to make the yellow div a normal div, not a flexed div. And explicitly set the flex divs


@UB0S1GF47 Ah, and I replied to that with an explanation of why that wouldn't work.


@U013CA8A28J Visually - something like that. But width != flex-base. If I understand correctly, the behavior is different if I decide to use flex-shrink.

Mario C.18:05:22

Does the yellow div have to be flexed?


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.


(gosh, Qt was so much simpler...)


@U0DTSCAUU Do you have a variant of that fiddle that works?


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 div example?


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.


Haha, well it certainly broke my intuition 🙂


> 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.

Mario C.18:05:41

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...


How about max-width:400px?

👍 4
Mario C.18:05:55

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 div and input.

Mario C.18:05:18

Not exactly the same but similar


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.


i.e. it’s being wrapped with virtual block element.


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.


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.


You’re a very literal person hehe. When I said flexible, I meant “display: flex”.


And they do have display: flex. Every single div there has display: flex.


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.


(surprising to me, anyway)


> 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. 🙂


Maybe. BTW, the max-width solution did not work.


What's it supposed to look like? It's a bit unclear to me still.

Mario C.22:05:54

@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.

Daniel Tan02:05:28

@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

👏 4
Daniel Tan02:05:54

Example showcasing how the green box has height 400px after explicitly expanding the height of the parent:

Drew Verlee19:05:29

^ 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."

💯 12

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