From e044661e39f91ff90c4ada160b1e0a8e0b93a68b Mon Sep 17 00:00:00 2001 From: Alfiya <33545574+alfiya-udc@users.noreply.github.com> Date: Fri, 31 May 2019 12:37:45 +0300 Subject: [PATCH] in-is, abstractrly --- 2-ui/3-event-details/4-mouse-drag-and-drop/article.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2-ui/3-event-details/4-mouse-drag-and-drop/article.md b/2-ui/3-event-details/4-mouse-drag-and-drop/article.md index 19ae03ee..54080d5d 100644 --- a/2-ui/3-event-details/4-mouse-drag-and-drop/article.md +++ b/2-ui/3-event-details/4-mouse-drag-and-drop/article.md @@ -184,7 +184,7 @@ The difference is especially noticeable if we drag the ball by its right-bottom In previous examples the ball could be dropped just "anywhere" to stay. In real-life we usually take one element and drop it onto another. For instance, a file into a folder, or a user into a trash can or whatever. -Abstractly, we take a "draggable" element and drop it onto "droppable" element. +In other words, we take a "draggable" element and drop it onto "droppable" element. We need to know the target droppable at the end of Drag'n'Drop -- to do the corresponding action, and, preferably, during the dragging process, to highlight it. @@ -211,7 +211,7 @@ For instance, below are two `
` elements, red on top of blue. There's no way
``` -The same with a draggable element. The ball in always on top over other elements, so events happen on it. Whatever handlers we set on lower elements, they won't work. +The same with a draggable element. The ball is always on top over other elements, so events happen on it. Whatever handlers we set on lower elements, they won't work. That's why the initial idea to put handlers on potential droppables doesn't work in practice. They won't run.