Pages: 1
Print
Author Topic: CSS: Hiding Specific PIs and Styling Selected PIs Differently  (Read 9322 times)
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« on: October 31, 2008, 03:51:57 PM »

Product(s):
XMetaL Author and XMAX versions 4.0+

Description:
It has been possible to style processing instructions as of XMetaL 2.1 using the XMetaL CSS selector extension $procins.

XMetaL Author and XMAX extended this capability starting with version 4.0. Different processing instructions can be styled based on their target and data values.

CSS Selector Syntax     Examples of Matching PIs
$procins[xm-pi-target="foo"]     <?foo?> or <?foo anything?>
$procins[xm-pi-data="bar bar"]     <?anything bar bar?>
$procins[xm-pi-target="foo"][xm-pi-data="bar bar"]     <?foo bar bar?>
   
The target value includes the first character after the PI opening question mark [?] up to but not including the first whitespace character. The target value cannot contain any spaces.

The data value includes the first character after the initial whitespace character up to but not including the PI closing question mark [?]. The data value may contain any number of spaces.

Normal CSS cascading rules apply as they do for other selectors used in XMetaL Author and XMAX.

Notes:
  • The $procins selector is proprietary and not part of the CSS recommendations.
  • You cannot override the built-in functionality of the XMetaL Author and XMAX change Tracking PIs using CSS.

Specific CSS Examples:
These PI examples are fictional. They are for demonstrating syntax and do not perform any special function in XMetaL Author or XMAX.

Hide all occurrences of any PI with a target called print, including: <?print index-start?>, <?print index-end?> and <?print page-break?>
Code:
$procins[xm-pi-target="print"] {
  display:none;
}

Hide all occurrences of <?print page-break?> but not <?print index-start?>
Code:
$procins[xm-pi-target="print"][xm-pi-data="page-break"] {
  display:none;
}

Color all PIs with a data value of index-start using blue text, including <?online index-start?> and <?print index-start?>
Code:
$procins[xm-pi-data="index-start"] {
  color:#0000ff;
}

External References:
Extensible Markup Language (XML) 1.0 "2.6 Processing Instructions" http://www.w3.org/TR/REC-xml/#sec-pi
« Last Edit: November 06, 2008, 07:03:08 PM by derekread » Logged
paorear
Member

Posts: 29


« Reply #1 on: March 07, 2014, 02:11:55 PM »

Thank you for this tip. Is it possible with the $PROCINS[xm-pi-data=...] 'template' to specify a wildcard?

What would be ideal for me would be to specify a background color for the target of a given PI and having a different background color for the content/data of the PI - where the data of the PI would vary.

Paul
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« Reply #2 on: March 07, 2014, 04:21:25 PM »

You cannot specify a "wildcard" but what you are asking is possible to do by combining the first and second example and including both in the same CSS file, making sure the cascading order is correct.

The first example listed here will apply to all PIs with that target, and the second will override the styling for the first for any more specific PIs containing the data you specify. For each subsequent PI you want to change the styling for you would need to specify an additional selector with a different value for the xm-pi-data part.

Depending on what you really need one of these two should do:
Code:
$procins[xm-pi-target="A"] {
background-color: blue;
}

$procins[xm-pi-target="A"][xm-pi-data="1"] {
background-color: red;
}

$procins[xm-pi-target="A"][xm-pi-data="2"] {
background-color: yellow;
}

Code:
$procins[xm-pi-target="A"] {
background-color: blue;
}

$procins[xm-pi-data="1"] {
background-color: red;
}

$procins[xm-pi-data="2"] {
background-color: yellow;
}
« Last Edit: March 07, 2014, 04:29:48 PM by Derek Read » Logged
paorear
Member

Posts: 29


« Reply #3 on: March 07, 2014, 04:34:10 PM »

Thank you for that tip. My problem however is that the values of the xm-pi-data would truly be unknowable, so couldn't be captured by sequential options in the CSS. We're using PI's as a sort of Reviewer markup mechanism, and so the xm-pi-data values will really just be arbitrary text.

2 examples:
1) a simple inserted comment
<?Comment [paorear]: Comment 1 [3/7/2014 10:26:38 PM]?>

2) a range comment
<?Comment [paorear]: Comment 2 [3/7/2014 10:28:42 PM Id='a8c3ff1c4b5e65a1']?>Add steps<?CommentEnd [Id='a8c3ff1c4b5e65a1']?>


Overall it works pretty effectively, it's just the display I'd like to control a bit better. :)

The more I look at it though, even if I were able to display the xm-pi-data differently, it would still be somewhat hard to read.

Paul
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« Reply #4 on: March 07, 2014, 06:39:05 PM »

I think granular control like this would require scripting.

Your script could search the entire document for PIs that match your requirements and then set the CSS using Range.ContainerStyle for those you wish to style. The DOM APIs have nodeName and nodeValue properties that return target and data values (when the node is a PI). You could parse those values as strings and ignore any portions that are not relevant. Various different APIs will allow you to find PIs and move a Range object to them (which is required if you want to use ContainerStyle).

You would probably really want to check with your users to see if they require this feature before going through all the trouble it would require to design and code it.
« Last Edit: March 07, 2014, 06:43:29 PM by Derek Read » Logged
edporterIII
Member

Posts: 16


« Reply #5 on: August 05, 2015, 07:17:21 AM »

I'm having trouble with the the CSS required to make the following PI not display:

Code:
<?revision-add-start id="m1670rev4" sws="123_345" symbols="all"?>

The PI is generated by an XFT form, and when inserted, it displays, even though I have this in my CSS:

Code:
$procins[xm-pi-target="revision-add-start"]{
display: none;
}

Any ideas?
Logged
mag3737
XMetaL Evangelist
Administrator
Member

Posts: 114

I even use XMetaL to write my business letters.


« Reply #6 on: August 05, 2015, 03:35:25 PM »

The $procins CSS as you have it here works for me. Could it be that you have some other selectors relating to PIs that are conflicting (overriding) in this case?
Logged

Tom Magliery
JustSystems Canada, Inc.
edporterIII
Member

Posts: 16


« Reply #7 on: August 10, 2015, 07:24:48 AM »

I discovered that I could force it to recognize my PI as having been inserted by refreshing the CSS. Now, I have another question regarding PI CSS.

I gather that your change tracking PIs function by tracking added or deleted text and inserting that into the "data" pseudo-attribute, and then displaying that data with the selected CSS styling.

Would it be possible to mimic that with my own PI? So, a user selects some text, right-clicks to bring up a context window, selects "Mark Added text". The macro would then capture the selected text, replace it with a PI containing the text in a data pseudo-attribute. The resulting PI would only display the selected text as inline underlined text.

My experiments with PIs haven't worked like I'd like in that respect. I tried the following CSS to test some functionality like this, but simply nothing displayed. I assume the more general display: none is overriding my :before content.

Code:
$procins[xm-pi-target="revision-add-start"]{
display: none;
}

$procins[xm-pi-target="revision-add-start"]:after{
content: 'ADD: ';
display: inline;
font-weight: bold;
color: red;
}
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« Reply #8 on: August 10, 2015, 05:05:52 PM »

You cannot use :before or :after on a node (element, PI or comment) that is not being displayed.

Or rather, you can use it, but when that node is hidden any associated content will also be hidden. The :before and :after content appear before or after the content of the node, but they are contained within the bounding box of that node (along with an child nodes: text nodes or child elements, etc). When the node is hidden everything inside its bounding box is also hidden.
Logged
edporterIII
Member

Posts: 16


« Reply #9 on: August 11, 2015, 12:38:52 PM »

So, to confirm, it's impossible to mimic the functionality of XMetaL's change tracking with our own PI?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« Reply #10 on: August 11, 2015, 01:03:37 PM »

I 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?
« Last Edit: August 11, 2015, 01:08:04 PM by Derek Read » Logged
edporterIII
Member

Posts: 16


« Reply #11 on: August 18, 2015, 12:01:53 PM »

Thanks for the follow up.

Our current XML has revision markup denoting revised, deleted, or added text. These <revision> actually publish in our final products with revision markup. We are exploring the possibility of using PI for this purpose, to add a bit more flexibility, since they're not treated as actual xml elements.

You mention that you can make a node read-only via a macro. Is there documentation or a script example for that?

Sorry to derail this thread a bit!
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2469



WWW
« Reply #12 on: August 18, 2015, 02:45:56 PM »

The XMetaL Developer Programmers Guide includes all the APIs, and (often very basic) examples for each.

The API that makes an element read-only is Selection.ReadOnly (or rng.ReadOnly assuming rng is a Range created previously).
Logged
Pages: 1
Print
Jump to:  

email us