Clojurians Log v2

hey guys

I’m doing a little web app to calculate scores for the board game Lost Cities (hopefully) more swiftly than using pen/paper/calculator 🙂

I’ve developed with Chrome and I’m very satisfied with the result in Chrome and Safari. However, things are not so nice in Firefox.

Are there some resources to help figure out differences in browser CSS implementations?

I looked at caniuse for for example svg, since my svgs render very differently in Chrome and Firefox. There were notes on differences, but nothing about the behaviour I saw. Same for vw.

@reefersleep Did you start with something like normalize.css (http://necolas.github.io/normalize.css/) as a base?

I can take a look at what you have if it’s open source somewhere. Typically margin and padding differences are the primary source of layout differences.

@niamu I did not!

I have some negative margins going on, but they’re top margins, and well… You better check for yourself. 😄

just a sec

so this is the app: https://eloquent-curie-577f9e.netlify.com/

and this is the source: https://github.com/Reefersleep/fast-cities

The app works like this: use Q to add handshake cards, A to remove, S D F G H K L Æ to toggle the number cards.

(probably that won’t work for you entirely, unfortunately I’ve hardcoded the keycodes for now)

Enter or space to cycle to the next color, backspace to cycle back

that’s all

@niamu in Firefox, once you’ve added cards to all piles, they start moving towards and apart each other horizontally

also, the SVG is rendered, but weirdly.

The circles are not centered, it seems, and the SVG is not square, regardless of its square height/width.

Possibly more is wrong 😄

ok, so the main issue is that SVG elements don’t support the “vw” measurement. My advice would be to use a a pixel measurement in your SVGs and then use CSS to scale them.

Lemme try that. So I can use vw for height/width, but not for stuff inside the SVG?

you can’t use it in the SVG markup itself. But you can use it in CSS to scale the SVGs beyond their width/height attributes.

leans in closer, intrigued

Imagine it like this; “vw” is viewport width. But a viewport only means something in the context of a browser and SVGs are not solely for the browser so they don’t support that level of measurement.

So you can scale the SVG elements with CSS because they are vector graphics after all.

Ah, I get it. Thanks for the context, I don’t often get that from gleaning random tips via google. So how do I scale the SVG element in CSS, like you say? Use transform or something?

I dig the scalability of vector graphics 🙂

You could give all of your SVGs a class or an id to select them with CSS.

hmmmm I calculate the vw height/width in my CLJS code, though

not that I like doing that, btw, but the whole point of me using vw for measurement is to be able to retain the height/width aspect ratio for the cards

I guess I could hardcode the vw values, once I feel good about them.

I see. I’d recommend just swapping “vw” for “px” though and see how close that gets you to cross-browser compatibility.

Once you get that far, you can apply some width/height rules in CSS for all your SVGs like so: svg { width: 300%, height: 300% } or something like that.

😕 I feel bad about using px in general, because of screen size differences. But then, none of the relative-size CSS options I’ve tried have been very nice or reliable, either.

Yeah, %’s were my saviour re: the above stuff, I thought. Been trying to do %-based design for a long time.

It’s a bit of a mental leap, but really all you’re doing is drawing the SVG in absolute units so you can scale them later.

It’s not that big a leap to me, except that I’m not very knowledgable about the precedence order of things in CSS.

(when I say CSS, I count all kinds of stylings - inline, in the header, in sheets and possibly other 😄 )

but that’s not so bad, now that you’ve told me how to do 🙂

I can figure out the order.

yeah, I have an intuition for these things, but it’s hard to explain how I’d solve the problem most of the time or why I’d solve something a particular way.

hehehe

Too much implicit knowledge

yeah, CSS is really bad for that. Best advice to most people trying to learn it is spend years doing it. Which isn’t really advice at all.

oh btw, I wrote it wrong; I thought %-based design was my saviour for resizable design, but it was not. It’s really hard to get working for all elements.

hahaha

it’s a trite trope, but CSS really is just terrible, yet I can’t help trying to get it to work. I want to put stuff on the web!

You’re absolutely on the right track using viewport width/height measurements. Just need to get those values in your CSS rather than directly in your SVG markup.

It annoys me that I can’t interact with the stylesheet from within CLJS/JS

I need programming language capabilities

hm

https://github.com/noprompt/garden helps

maybe there’s one of the CLJS CSS libs that can save me

oh yeah, like that

😄

With garden you can define all your CSS in Clojure and then it’s up to you how that final CSS string gets injected into your app. So you could have it inject a new <link rel="stylesheet" ...> in your figwheel reload function for when you alter your CSS.

Oh, I was just wondering about how to make it dynamic.

But still

that’ll have static values, and be static during post-compilation runtime, right?

that is

If I reactively resize a specific width for a class selector and compile that with garden, and put it in a <link rel ...

then the changes won’t propagate for the end user

I need to interact runtime, as well as development-time.

googles for libs

I’m not sure I follow. Are you altering style attributes dynamically at runtime currently?

yes

I don’t see anything that would cause a problem with having a single static CSS file for your application currently, but I’ve only glanced at your code.

In the resizable-card component, I’m doing a bunch of arithmetic

nothing complex. just aspect ratios 🙂

Actually, I’m not dynamically altering those values currently. They follow the viewport.

I use one vw value and derive all the other values from that one by multiplying or dividing.

But in a devcard project for my development of these components, I was able to easily scale the card elements - while keeping aspect ratios - by multiplying by a runtime-defined number, controlled via a slider.

That was rather nice 🙂

And something I was considering using for animations in the final app. (I guess I could use transforms, too)

I see what you mean. You could have the slider affect a wrapping div element around the SVG where the SVG is set to be 100% width filling the div completely as it scales.

That would accomplish the same effect and not have to re-draw your SVGs each time the size changes.

The resizable-card component is just divs (not true, there’s actually an SVG in there sometimes, but that isn’t a problem)

I just want the arithmetic derived from a dynamic number. That trivial in any programming language, and just not possible in CSS, from what I can tell.

I need the arithmetic to keep aspect ratios regardless of viewport size. The “top” number being dynamic is just a nicety, but one that is so easily accessible from within CLJS.

(And with lovely applications)

I realize that if I gave up top number dynamism, I could just have hard-coded values for everything.

Apart from that being less nice, I just really dislike it… 😄 If I need to change 1 thing somewhere, I need to change a bunch of stuff again, by hand.

I see what you mean. As long as you’re using percentage values in the children elements, you can have the parents have their width/height attributes be dynamically set on the element themselves and therefore that keeps all of the dynamic sizing features you want while keeping all of the calculations as static percentages in your CSS rather than calculating on each render as you are currently.

Whereas dynamically deriving it is well, what computers are made for 🙂

But what I’m describing isn’t really necessary. You can still do what you’re doing with no issues as long as you get the “vw” measurements out of your SVGs.

I have realized a couple of times that I’m essentially calculating percentages 😉

ok, let me frame this differently

if I want the height to be width * 1.354, can I do that in CSS?

No, you’re right that having the aspect ratio fixed but the sizing dynamic would involve having the width/height attributes embedded on the element itself and not in an external stylesheet.

Alrighty.

Thanks for all of your advice 🙂

Glad I could help.

Looks like a neat project. I haven’t played Lost Cities yet, but I’ve thought about picking it up a few times before.

I think I have my answer(s); how to render SVGs properly (px, then rescale with CSS, or use percentages, then rescale with css), how to size children dynamically (percentages, of course : ) and finally, aspect ratios; decide on hardcoded values.

Thanks! @niamu thanks a lot for your time 😄

Lost Cities is great btw!

You’re welcome. 🙂

🙂

It’s cheap, fast to play, very portable. Two drawbacks; the big cards are a bit hard to shuffle, and the calculation in the end can be a bit tedious 😉

BTW @niamu : did you witness the stacks sliding back and forth horizontally when cards have been added to all stacks, and you're adding and removing cards from a pile? Or maybe you addressed that when you talked about the SVG stuff?

I honestly didn’t understand the interface enough to reproduce that. If the SVG adjustments don’t fix that problem, let me know and I can look at it again.

Type a s d f g h j, then enter, repeat until you've added cards to all five stacks. Now use some of the same keys to toggle and untoggle cards for one stack. Stacks will slide around like Bambi on ice.

It's a more serious problem than the SVG thing. I can do without the fanci SVG drawing, the card stacks are essential.

I can try ripping out the SVG elements entirely and see if the sliding behavior persists.

Tomorrow 😊 it's nighttime here. Have a nice evening!

Couldn’t help giving it a little go before bedtime; without the SVG elements above the stacks, they behave nicely. You hit the nail on the head!

That’s great, I bet I could have scratched my head for long about that!