'Widget' 'onclick' function not working-- Not sure what principal I am missing - Wiki Project

I put together this simple ‘page flipper’ script for my Wiki App-- I ideally it is originally ‘hidden’ or ‘display:none’ and then appears after the search is conducted in place of the main logo on the page.

That part ‘works’ in a sense, but I seem to loose the ability for the ‘onclick’ event to trigger in the entire area of where the original image is-- Or one can see if you click the very ‘bottom’ of the page the papers will sort as they are supposed to-- But you click slightly higher up and nothing.

I also tried completely removing the logo and search bar from the DOM, but still nothing-- it is ‘blocking’ the ‘onclick’ event in this area.

I’m not quite sure what principal I am missing.

Wiki API app is here: https://codepen.io/abalducci/pen/OzbRME

But I also have the ‘widget’ I made separately so at least it is clear what it is ‘supposed’ to be doing: https://codepen.io/abalducci/pen/aEYPmz

Neither work for me. Why don’t you get the results to display first on the Wiki app then do the widget thing.

Oh ? Hm… What browser are you using out of curiosity ? I actually already have gotten the results to display, that part is “there” just I wanted to make it more of a ‘portfolio’ piece…

The widget pages slide left but immediately slides back right. Maybe that’s how it is meant to work?
Using Chromium.

Well the pages are supposed to ‘stack’-- Or yes, if you click on the ‘top most’ page yes it will just slide right back and maybe I should adjust for this… But if you click on one of the ‘lower’ pages below it is supposed to ‘pull it out’, put it on top and then re-order the stack.

A little bit of a bump on this as I’ve asked around a number of places and not really found an explanation.

I feel I should also ‘rephrase’ a little, as to be honest I don’t think I am looking for a specific ‘code’ solution, more so a better understanding of what could be going ‘wrong’ here as this seems a pretty basic principal.

I realize, perhaps, ‘rule number one’, if you want things to be interactive in the DOM just don’t stack the damn things on top of one another.

However it seems like there would be many use cases when you’d want to do something like that.

Or perhaps even a better way to ask would be ‘how do I debug this’ ? Obviously the click even is going ‘somewhere’ but this is also a time when console.log just won’t do.

I must admit there are some times when ‘web’ programming can be hair-pulling frustrating as you just don’t find all these weird conflicts in other languages. Sometimes it feels a bit like a bunch of guys sat down on a weekend and just shoved all this stuff together and now that is what the world uses.

Showing and hiding using display:none with other display styles is my favourite way of revealing hidden content.

Which language would this be easy in?

1 Like

All the ‘Visual’ series of languages— VB, C#, were fairly WYSIWYG in terms of interface design. Even Python with a Tkinter layer or similar, I think are much more ‘straight forward’. And even in the most basic case of something like CPP, you are writing directly to the frame buffer and of course in many cases have to physically implement all the features such as fonts, image scaling, etc.

‘Web’ does of course try to interface things at a much ‘higher’ level of design/language, but for one even in its own history-- One browser always trying to out compete another, though finally they are starting to coalesce a bit-- And yes, of course there is ‘canvas’, or in this regard I should say JS has been fairly well ‘regulated’ like other traditional languages-- Broad support, standards are met, but when you start placing things into the DOM it gets ‘messy’.

Things you think should work, just don’t.

Personally, I think most ‘real code’ happens on the ‘back-end’. It is nice to make things ‘pretty’, but does your application ‘do anything’ ? That is only a personal philosophy.

I think also that is why architectures like React have started to become so popular-- It is bringing not only the interactivity, but also a much more rigid structure to the DOM.

It is also a little hard to explain if one hasn’t totally crafted, even a simple GUI ‘by hand’ in a lower level language. Yes, it can be a lot of work, but at the same time you have ‘total control’.

You never think ‘is it CPP’ (i.e. my flavor of the browser) that is interpreting something wrong ? You think, ‘it is something in my code’.

I should also follow-up and say that I’ve determined it is CSS-Grid that seems to be blocking my methods after some trial and error. I really really like grid, and consider it much better than other alternatives, but even for Edge it is only just supported in the latest ‘creators’ update which not everyone has. I still don’t know ‘why’ it doesn’t like this layers method, but I’m going to just rewrite the thing with a different layout scheme.