Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added function for hiding elements #6

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from

Conversation

lennardnl
Copy link

I added functionality for hiding elements. I didn't use display:none or something like that because then the element would disappear and other items on the page would move; now it becomes transparent so other elements on the page don't move.

You use it by hovering on an element and pressing the delete key.

Plus I added some semicolons for consistency.

@mcstepp
Copy link

mcstepp commented Mar 9, 2016

My two cents throwing in (been watching this repo for a while now)...

instead of opacity, use visibility: hidden. Opacity still responds to pointer events - i.e. if you have a parent element with child links, the cursor would still respond to the child elements, so you'd have turn off pointer-events for all children with a opacity: 0 parent.

visibility: hidden works like display:none, except it preserves the space for the element, which is what you want.

@tomhodgins
Copy link
Owner

@lennardnl That's pretty cool! The original demo that inspired dragon.js took whatever element was under the mouse when you clicked on the page, cloned it, and turned the original element transparent (to leave an element-sized hole of space in the layout. If you were to make it position: absolute it would pop out of the flow and the layout would collapse the space it left behind. Cool Addition!

Did you know that in a desktop web browser, using Inspect Element, if you select a node from the document view and press 'Delete' it will delete the node from the rendered page entirely? You can also drag & drop the location of nodes in Inspect Element too. It's a very versatile tool :)

@mcstepp That's pretty cool too. I knew about visibility: hidden, but you make it sound like if visibility: hidden is set on a parent element it won't be inherited by that element's children! Suppose I have a modal on a page and by default it's hidden from view with: opacity: 0; pointer-events: none; but fail to also toggle visibility: hidden would its children still be clickable? This hasn't seemed to be my experience, but maybe I should go back and strengthen up my styles :O

@mcstepp
Copy link

mcstepp commented Mar 10, 2016

I meant hidden via opacity: 0 not visibility:none - I clarified above. Sorry for the confusion!

But in terms of usability, consider using visibility:none on this addition. Added benefit for screenreaders as screenreaders will still read an element at 0% opacity, but smart enough to know to skip over visibility:hidden (and display: none for that matter) elements. In the very off chance someone with a screenreader uses your tool and deletes an element, a screen reader will know that it's not meant to be included. Some low-hanging fruit.

but now I'm curious if form controls and links can still have focus with or without cursor-events or is basically treated like it's tabindex:-1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants