Post not yet marked as solved
Looks like Safari doesn’t like counter/counters any more. Guess what will happen if you insert "li::after { content: "tERROR"; } just after the opening brache of name-group!
BTW: both browsers don’t count any more since they got the last two (Safari + Firefox = 4) updates.
Post not yet marked as solved
Nice “Update” (of Safari). Now counters don’t work any more. And: not only counters!
Just have a look. Same code. Inspector in Safari:
Inspector in Firefox:
Post not yet marked as solved
Just a shorter version of my(?) main-problem: https://jsfiddle.net/Rolf_b/axjvuo5y/
I don’t think so. Because it happens after weeks where I’ve not been here. And it happened at the first try to write here. Then, after some time, it works. I can do one post. But then I can’t edit it: same symptoms: after nor replay no edit. But here, this thread, I can.
Additional: now, after a few seconds, I try to edit here … If you see this paragraph: working.
I don’t know what’s wrong. Now I could append one reply: https://developer.apple.com/forums/thread/729793
But: I wanted to edit it (make it looking a bit better): same thing: I can do the edit, but it doesn’t get updated here. Hitting the button gives one or zwo seconds of pause, then there is the “edit or update me” display again there.
Post not yet marked as solved
Safari still does another kind of math! It’s the only thing, computer or calculator, making ceil(a) to return (ceil(a)==a) ? a+1 : ceil(a);
[https://w3c.github.io/csswg-drafts/css-values/#funcdef-round](“If A is exactly equal to an integer multiple of B, round() resolves to A exactly”)
They do come back: “Submit” is now the same as „select all“. If I can submit sth. here? Who knows!
Tested: here submit does submit. D…!
Post not yet marked as solved
Wrong question!
Why? Because even
:root {
container-type: size;
contain: strict;
max-width: 100vi; /* you can try 100vw and … */
max-height: 100vb; /* 100vh too */
width: 100%;
height: 100%;
}
doesn’t stop safari from painting elements at “120vi“ or such things. Somewhere outsides from the legal region! Firefox does a bit(!) better, but is unable to calculate even simple things (more worse than Safari). And: moving this restricting part of CSS to some child (body?) is breaking him down too.
Forget the thought, you have a piece of control! Go back to table-layout!
Post not yet marked as solved
Another joke, but not with Safari or another WWW-browser as origin: did you know, you can’t calculate? Ok, not calculate, you can not CSS-calculate!
Try it, use the results for your tests. Find out, if the results are number or pixels (CSS or real ones), if they are percents or what else:
calc(100vw ⁄ 100vh), calc(100cqw ⁄ 100cqh), calc(1em + 1vh) or calc(1em * 1vh), calc(10% * 1em) or calc(10% + 1em), …
Did you graduate some school? What did your teachers telly you about your math? Or: about this … mhaff?
Post not yet marked as solved
“breaking news” — LOL
calc(sqrt(12.249 999 999 999 999 111 821 580 299 874 767 661 094 665 527 343 75)) results 4, calc(sort(12.249 999 999 999 999 111 821 580 299 874 767 661 094 665 527 343 749 999 999 999 999 999 99…)) results 3.
round(to-zero, x, y) results 0
How I found this number and round?
Took calc(saqrt()) tu build a grid mostly square. Input: the total number of grid-items. Then I tried to figure out a solution, a combination of bugs, solving the problem (Safari ≠ WWW) && (Firefox ≠ WWW).
Happy new math! Computers do this very … fine?
BTW: the spaces in my examples are because of the forum software. Without them the numbers are “illegal”.
Post not yet marked as solved
Wow, did find some new kind of math!
If you do sth. like calc(2em ⁄ 1em) you get 2em as result! No chance to do things like aspect-ratio-calculations.
Try to use another “result”: calc(300% ⁄ 100%)!Aren’t 3% enough?
Update:
Hey, what’s this? The “Live Preview" shows / instead of the division slash? Fine, I try to find some replacement … and you have no luck with C&P!
Now I can do replies. Don’t know, why, but … solved!
Post not yet marked as solved
Sorry for that. The real bug is done by the creators of “CSS pixels”. And some guy, who said, it is not possible, to figure out the real pixel size.
Another one did say sth. like “you can asume 95dpi – or the real sizes” So: why not the return of the pixel-layout? Ok, now you have to use an unknown factor (the users display dimensions), so no one knows, what dimensions should be shown. Not the CSS-pixler, either the user.
STOP: a printing device must know it! It has some magical inside, knowing how to beam CSS-pixels to paper. Printing devices must reproduce physical dimensions …
Ooops, I know another magical! With OS X 10.3 (AFAIR) and, again, with iOS Ventura 13.3 (or 13.2?) preview is able to show PDFs in a nearby perfect size! Damn… preview must use CSS-pixels too!!!
Post not yet marked as solved
Another issue:
If --count is set to 1 as result of round: --count: calc(round(down, calc(sqrt(var(--images))), 1) + 1);
grid-template-columns: repeat(var(--count), 1fr);
grid-template-columns: 1fr;
isn’t the same (in Safari)! The first line results in 2 columns, not in one!
Looks like the same reason. Because
grid-template-columns: repeat(calc(var(--count) -0.01), 1fr);
gives one column.
That’s not the problem. I didn’t want to modify the old text. I wanted to “answer” myself. Because I got some information, belonging to the old contents. And that doesn’t work.
────
Result of an “experiment”: here I can modify my post at least!
