Home › Forums › XMetaL Tips and Tricks › CSS: Hiding Specific PIs and Styling Selected PIs Differently › Reply To: CSS: Hiding Specific PIs and Styling Selected PIs Differently
Reply to: CSS: Hiding Specific PIs and Styling Selected PIs Differently
August 11, 2015 at 7:03 pmI won't say it's impossible but it depends whether you expect it to be exactly the same. If similar functionality had been recreated using script and I had access to that code I'd give it to you. However, I'd say it would probably not be much work to make it look the same but it would likely be quite a bit of work to get it to function exactly the same as far as interaction goes.
For change tracking XMetaL inserts PIs for change tracking, but these are not “normal” PIs. They aren't really in the XML source when you are viewing the document in Tags On or Normal view, they are a special type of node that gets rendered separately from the rest of the document (using different logic, and not directly connected to the CSS engine). When you save or switch to Plain Text view or use an API that specifically deals with them (like Selection.TextWithRM) the PIs are inserted into the XML source. The interaction with these PIs is also different from regular PIs when it comes to adding and deleting content and moving them around.
You could create scripts that insert and remove “real” PIs into the document to either wrap or replace content. And you can style those PIs using CSS (using text-decoration: line-through for deletions for example). Your PIs could be similar to XMetaL's change tracking PIs, but they would need to be slightly different so they were not be interpreted by XMetaL as its own. However, interaction with these PIs will not be the same as with XMetaL's native change tracking PIs, they will function like all other “normal” PIs when you type. You might try to get around that by making these nodes read-only, which would take additional script to do. If you copy content from XMetaL that contains an insertion or deletion and paste that into another application the insertion will be there and the deletion will not be. There are a great many subtle behaviors like this and without playing around with the feature for an hour or so I don't think I could list or describe them all. For any of those features that you wanted to duplicate you would need to try to create a script that somehow does that, so interaction that is identical would either be very tricky to implement or not entirely possible.
What it sounds like you need is for us to implement a new feature that would give you identical change tracking functionality but with PIs that have a different target. I can make that request but at this time I don't think many clients would need the feature (which is the main driving force behind all new features).
What problem will this solve for you? What is the goal behind implementing a separate set of change tracking PIs?