[whatwg] [editing] HTML Editing APIs specification ready for implementer feedback
ayg at aryeh.name
Fri Aug 5 13:57:13 PDT 2011
On Fri, Aug 5, 2011 at 2:24 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 8/5/11 1:59 PM, Aryeh Gregor wrote:
>> Yeah, it's a problem. The basic issue is that there are no standard
>> interfaces to query things like "what's the height of this<br>?"
> That depends on how you define "height" (esp when clearance is involved).
>> or "are these two nodes in the same line box?"
> This is, generally, a nonsensical question...
Yeah, I more or less realize that. If the questions I wanted to ask
made any sense per the CSS specs, my life would be a lot easier here.
> More precisely, the basic issue you're running into is that the CSS box
> model doesn't necessarily map onto most people's mental model of wysiwyg
> editing areas (insofar as such a thing even exists).
Nor does the DOM, but I mostly get stuff to work reasonably
regardless. Really I guess the issues are more like
1) I don't actually understand the CSS box model very well (unlike the DOM).
access to the CSS box model, so it's much easier for me to test out
information I'd want to use, I don't know if browsers actually store
it in a form that's usable internally by DOM methods. I know DOM
stuff is readily accessible to internal browser methods, because you
was told things like "you can't access computed styles of nodes in
detached trees, because we don't compute them".
> It gets worse. What about white text on a white background? What about
> rgba(0, 0, 0, 0.01) text? What about text with other stuff on top of it?
Yeah, it all looks the same to the user, so I don't see why
visibility: hidden should be any different. Just let the user select
and manipulate the hidden text like any other text.
More information about the whatwg