Am Mittwoch, 14. August 2013, 09:51:00 schrieb Friedrich W. H. Kossebau:
Hi,
sorry for ignoring this email for so long, but priorities, well...
Am Donnerstag, 1. August 2013, 01:37:50 schrieb Philip Peitsch:
Hi everyone,
I have been looking at some funky "valid" ODT documents and discovering some fun behaviours around cursor positioning. I thought this was a good time to bring up some potential changes, as I noticed on IRC the other night that Friedrich had also discovered sometimes the user is unable to place the cursor inside a text:a block.
The existing rules for valid cursor positions only allow placing the cursor inside what is known as a "grouping element", which is either a span, p or h. This has already caused me some challenges, because for one of the highlight overlays I'm doing on top of webodf I need to wrap document text in a normal HTML span, which then prevents the cursor from entering.
In the situation Friedrich found, there is actually no requirement saying the text content within a text:a element must be placed in a span.
The suggestion on IRC yesterday was to just add text:a into the grouping element definitions (a reasonable one), but I got to thinking a little more about whether this is the best long-term solution. Especially as there are other elements that could possible contain character data. And for extensibility purposes, ideally we don't want to have to redo this core cursor positioning logic every time the UI requires some extra containers and wrappers to help display things :).
Re-reading the ODF specs[1], the preferred approach laid out is actually a blacklist, not a whitelist as we're currently doing. The blacklist as required for processing is already defined & used in StyleHelper.isAcceptedNode, is used for OpRemoveText and OpApplyDirectStyling.
Would anyone have any problems if I changed OdtDocument.TestPositionFilter to use the blacklist approach instead? The blacklist will need an additional entry to exclude the cursor as well, so I'll put that in also.
From my testing with this, it appears to function identically to the existing approach, with the added bonus of being able to navigate within text:a tags that don't contain a span :)
Cheers,
Philip
P.S., sorry for all the list spam lately! Apparently I have too much time for philosophy :)
(if only more spam would be philosophical ;) )
[1] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html# F oreignElementsAndAttributes
Having now read the referenced ยง3.17 Foreign Elements and Attributes I would agree that this code needs to be turned into rather blacklist-based.
I might have missed/forgotten the content of related discussions on irc/in real life, but I recall there has been some.
So Jos & Aditya, do you remember any reasons you had for staying with the white-list (besides not needing any new coding effort ;) )?
Turned into redmine issue http://webodf.org/redmine/issues/82 to track this problem. Cheers Friedrich -- Friedrich W. H. Kossebau // KO GmbH http://kogmbh.com/legal/