|
While working on a SPA I had some CSS that I was applying on the click of a button.
When the button was clicked, it would make one or the other DIVs go fullscreen (except for a small portion at the top where the nav bar was).
Imagine you have these two divs -- one yellow and one cyan;
#first{
background: yellow;
}
#second{
background: cyan;
} Then when you click a button in the navbar it would make one or the other go fullscreen by applying a fullscreen CSS class.
It worked great & I was very happy with the simplicity of it all.
If you really want to see it work (toggle), take a look at this simple jsfiddle[^].
.fullScreen{
width: 100%;
height: 90%;
z-index: 20;
position: absolute;
top: 12%;
padding: 10pt;
} Here's the button click code.
document.querySelector("#first").classList.add("fullScreen");
document.querySelector("#second").classList.remove("fullScreen");
It Worked, Then Didn't!
It was all working. I copied the code to another project and had it all set up.
But suddenly clicking the button wouldn't do the fullscreen. I tried all manner of things.
Was the button click working? I added an alert() and saw the button was working.
I was going out of my bleedin' mind.
Then I looked real hard at the styles that I had copied to the new project.
Can You See It?
Do you see the problem?
#first{
background: yellow;
}
#second{
background: cyan;
};
.fullScreen{
width: 100%;
height: 90%;
z-index: 20;
position: absolute;
top: 12%;
padding: 10pt;
}
Oy!! I have only myself to blame.
As Sophocles said: The keenest sorrow is to recognize ourselves as the sole cause of all our adversities.
Sophocles was obviously a software developer.
|
|
|
|
|
raddevus wrote: Do you see the problem? Don't see the reason for it off the top of my head. Absolute should work with a static parent. Usually when stuff is not shown and it's not a display issue (or no content) then it's related to height. As body height needs to be set as well, etc. So that would be my guess.
Couple points about your code though...
I urge you to consider never, ever doing that again though. You don't need to hard code offsets, as that'll just make things harder to maintain. And, this day and age we should be using flexbox for layout. And yes that includes fullscreen dialogs. It'll keep things organized sooo much better and if you ever need to stack a dialog on top of your main content or stack multiple dialogs, then it'll make your life easier.
Also, never, ever use height 100% in that manner. There are better ways now. That was the trick 20 years ago. These days it's much, much better to use viewport units for layout. Height 100% means 100% of the parent. That trick only only worked when you set both the html and body tag to height 100%. I still set both html and body out of habit for viewport, but there's no need for that now. Just use viewport units with the added benefit of being semantic.
Also, consider using the semantic dialog tag. It'll fall back to a regular div on non-supported browsers. But if the intent is to have a fullscreen dialog show, then it'll help screen readers know what's up.
Tossed together a fiddle for poops and giggles. Clickety
Jeremy Falcon
modified 22-Jul-24 20:31pm.
|
|
|
|
|
Wow, thanks for the tips. I really appreciate it.
I was just going for the absolute quickest way I could get a div to go fullscreen.
I will examine the JSFiddle more closely and make some changes.
Thanks again.
|
|
|
|
|
Any time, buddy.
Jeremy Falcon
|
|
|
|
|
Just checked the fiddle again and there was a tiny bug in it with the hidden style. If the dialog tag is supported then most browsers apply an automatic user agent style to it. So, forgot to add padding and margin resets in the class.
This fixes it: Clickety. So should work if you apply the hidden class to either the popup or the main tag.
It's worth noting this isn't an modal or modeless overlay dialog anymore, but quite literately replaces the main content while still allowing for having a nav bar up top. If it were an overlay that just covered the whole thing (drop shadow etc.) then absolute positioning is the way to go. But, IMO overlays don't look nearly as modern as this does.
Jeremy Falcon
modified 23-Jul-24 15:27pm.
|
|
|
|
|
|
|
Not a Javascript programmer, but I guess the extra semicolon?
|
|
|
|
|
You got it!
It was the semicolon located after the second style.
That just blew my mind! I will make no more mistakes with semicolons (he said doubting himself).
#first{
background: yellow;
}
#second{
background: cyan;
};
.fullScreen{
width: 100%;
height: 90%;
z-index: 20;
position: absolute;
top: 12%;
padding: 10pt;
}
|
|
|
|
|
Ha ha ha ha ha. I totally missed that. Awesome catch.
Jeremy Falcon
|
|
|
|
|
Be thankful it's CSS not Python.
Then your bug would be invisible.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I have similar code I used to swap between dark and light theme css file, selected via a checkbox:
function switchCssMode() {
var chkMode = gebi("chkSwitchTheme");
if (chkMode.checked) {
document.querySelector("link[href='css/lite.css']").href = "css/dark.css";
}
else {
document.querySelector("link[href='css/dark.css']").href = "css/lite.css";
}
}
function gebi(el) {
return document.getElementById(el);
}
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
For modern browsers, you could do that without any JavaScript. Set up the colours to use as CSS variables / properties[^] in the :root context; use those variables throughout the stylesheet; and use the :has selector[^] to switch between dark and light themes.
:root {
--background-color: white;
--text-color: black;
}
body:has(input[id='chkSwitchTheme']:checked) {
--background-color: black;
--text-color: white;
} Demo[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Interesting, and good to know. I'm way behind on modern CSS.
There are no solutions, only trade-offs. - Thomas Sowell
A day can really slip by when you're deliberately avoiding what you're supposed to do. - Calvin (Bill Watterson, Calvin & Hobbes)
|
|
|
|
|
I'm going through a book right now which is fantastic!
It's the best intro to OSes (how they are designed/programmed) I believe you'll ever read.
First of all, you can read it for FREE online (PDFs).
Operating Systems: Three Easy Pieces[^]
Have you read the book? It's fantastic because it starts out with simple code examples (in C) that teach one specific point at a time. Amazing!
If you've never read it, please skip all the (intro nonsense) & go right for the meat (to get an idea of how great the book is). Read this chapter[^] (be aware this will open the PDF in your browser) & I believe you'll be convinced how great the book is too.
And Now For the Weird & Wonderful
While examining the common_threads.h file for the 3rd example I stumbled upon these lines:
#ifdef __linux__
#include <semaphore.h>
#endif
I always wonder about strange things like that and in this case I thought, "Where is the __linux__ defined?"
I looked it up and discovered Gnu docs for the C PreCompiler (cpp exe)[^].
I tried the command they suggested:
$ cpp -dM
But when I did I could see that cpp was running but just had an empty string.
You actually have to point it at an exe and it'll pull out all the preprocessor commands. What!?!
$ cpp -dM ./threadx
When I ran that I saw a huge list of PreProcess commands. Huge!
I then ran it thru grep like this:
$ cpp -dM ./iox | grep -i linux
I saw the following!!
#define __linux 1
#define __gnu_linux__ 1
#define linux 1
#define __linux__ 1
So, I can see that over the years the convention to determine which OS the compiler is running on has changed.
Wow, things get messy as time goes on, don't they.
BONUS
Here's my favorite pre-processor define I found in the list.
#define __FLT128_DENORM_MIN__ 6.47517511943802511092443895822764655e-4966F128
|
|
|
|
|
raddevus wrote: First of all, you can read it for FREE online (PDFs).
Operating Systems: Three Easy Pieces[^] When I open the link, it tells me that the PDF version is USD 10. I am not that curious about the book.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
It opened for me, no messages. What browser are you using??
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
I re-tried both links (the one to the book's main web site) and the one directly to the PDF & both worked for me.
Honestly the book is free so I hope you get a chance to take a look.
Someone else has confirmed that they links worked too.
Try the link to the main site and then try clicking the chapters in the grid. Maybe you'll be able to get it there.
|
|
|
|
|
I've got the dead tree version on my shelf. It is a very good book.
|
|
|
|
|
Dave Kreskowiak wrote: I've got the dead tree version on my shelf.
Very cool that you've read it.
I am really enjoying the code samples, because they :
1. touch on very basic but very clear topics
2. are self contained & don't require a lot to get them compiled.
3. Touch on important topics like file i/o, simple threading ideas, etc.
Really amazing book so far.
|
|
|
|
|
You can get a list of the compiler Manifest Defines via
echo | cc -dM -E -
In my case, I get 442 #defines for c++, and 380 for cc. Interestingly, the C compiler and the pre-processor produce exactly the same manifest defines.
Messing around with different C/C++ standards gets different values for different standard versions e.g -std=c89 or -std=gnu17 or -std=gnu++11 , so might be worth inspecting, to see how you can tell whether you're compiling for C89, C99, or if you're using clang (#define __clang__ ), etc
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Very cool. Thanks for sharing
|
|
|
|
|
In LVGL you can set an image source to either be a file path or a structure.
lv_obj_t* ui_img = lv_img_create(ui_screen);
lv_img_dsc_t img_dsc;
img_dsc.header.always_zero = 0;
img_dsc.header.cf = LV_IMG_CF_RAW;
img_dsc.header.w = 800;
img_dsc.header.h = 480;
img_dsc.data_size = 800*480*LV_COLOR_DEPTH/8;
uint8_t *img_mem = (uint8_t*)ps_malloc(img_dsc.data_size);
img_dsc.data = img_mem;
memset(img_mem,0,img_dsc.data_size);
lv_img_set_src(ui_img,&img_dsc);
That's one option.
Here's another
lv_obj_t* ui_img = lv_img_create(ui_screen);
lv_img_set_src(ui_img,"A:/minou_480.jpg");
The lv_img_set_src() function takes a void* for the second argument and either accepts an instance of a lv_img_dsc_t structure or a string!
Worse, there's no lv_img_dsc_init() function to set the struct to a known state (with for example, a magic cookie in it that can be used to flag it as the structure rather than a string)
Ultimately here's how it checks:
if(u8_p[0] >= 0x20 && u8_p[0] <= 0x7F) where u8_p[0] is the first byte of the source argument.
This is in battle tested production code used in many many devices in the real world.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
img_dsc.header.always_zero = 0; I have no idea of the layout of the struct, but for example if this is at the start, it would discriminate it from a valid string, would it not? Then the range check would separate empty strings from real ones.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
It is at the beginning of the struct and it is used as a discriminator.
And yet it seems extremely accident prone, and I should add the docs do not clarify this.
At worst there should be, IMO, a function to initialize the structure.
At best, there should actually be two lv_img_set_src() functions - one for paths, and one for lv_img_dsc_t structs.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|