- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Oct 2018 00:59:47 +0000
- To: public-css-archive@w3.org
> UA can certainly tell which text node given all major UAs support text selection via mouse drag. By "we", Hayato was referring to the user of the API; they wouldn't be able to tell which text was at the provided point (given the suggested behavior), since they'd just get the container element. > Instead of look for the first element in CSS box tree, find the node and the return its parent in the composed tree if the node is not an element (obviously after considering which node should be visible to which tree). That doesn't seem to address my points: * How is that consistent with `elementsFromPoint()`? (Should a `display:contents` ancestor be in the list or not? Why or why not?) * How is it consistent with `getBoundingClientRect()` (which returns a 0x0 rect at 0,0 for `display:contents` elements)? * What makes `display:contents` special here, given that a similar problem exists without shadow DOM at all - any markup with intermixed raw text and sibling elements doesn't tell people *which* text node is at the specified point, since it'll just report the parent element. Defining the algorithm as suggested, where it finds the first element generating a box generating a fragment containing the specified point, gives us good, consistent answers to the first two bullet points. Adding a `nodeFromPoint()`, as Hayato suggested, solves the third bullet point in all of its variations - you can always tell which text node is at the specified point, regardless of how its surrounding/ancestor elements are styled. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/556#issuecomment-431211232 using your GitHub account
Received on Friday, 19 October 2018 00:59:58 UTC