What is the issue with the HTML Standard?

1. Should platform modifier key conventions influence dropEffect when effectAllowed = "all"?

Question:

When effectAllowed = "all", should User Agents map the current modifier‑key state to dropEffect using the native OS/file‑manager convention (e.g., Ctrl→Copy on Windows, Option→Copy on macOS) for the initial value of dropEffect during dragenter/dragover (before handlers run)?

Proposed Answer: Yes

When no constraints are imposed by effectAllowed, the browser should honor the native OS modifier key semantics for drag-and-drop.

2. Does the order of effects in effectAllowed (e.g., "copyMove") define priority?

Question:

For multi-effect values such as "copyMove" or "moveLink", does the left-to-right order define which effect has priority when no modifier key is pressed?

Proposed Answer: Yes

The ordering defines priority:
• The first effect is the primary/default (P0)
• The second is the fallback (P1)
Rules:
• If no modifier key is pressed → use P0
• If modifier requests P1 and it’s allowed → use P1
• If modifier requests an operation not allowed → stay with P0

3. What if the user requests an operation not permitted by effectAllowed?

Question:

When the user’s modifier key indicates a specific operation (copy / move / link), but that operation is not allowed by effectAllowed, how should the browser compute dropEffect?

Proposed Answer:

Use the following rule:
(A) If only one operation is allowed
→ Always use that operation, ignoring modifier keys.
(B) If multiple operations are allowed

1. Check if the modifier-requested operation is allowed.
   o If yes → use it.
   o If no → ignore it.
2. Fall back to the primary allowed operation (P0) based on the ordering rule (see section 2 above).

Example
• effectAllowed = "linkMove"
• User presses Ctrl (Windows → COPY request)
• COPY is not allowed
→ Browser should use LINK (P0), based on "linkMove" ordering.

A flow diagram image has been attached for reference.