Can't believe I had it working within 2 minutes when I had spent the best part of 9 hours trying to get it to work - just shows how the SDL Communities page is the answer to your problems!

I did do a little bit of investigation as to using the "string" type that you both tried to use.

This is really Tony's area of expertise, and maybe he will chime in later when (and if) he sees this thread (as he is in Wales).

From what I found, it appears to me that for now you'll have to stick with the "integer" type if you are going to use attr() with the text-align property.

However, just so you know where I got to and what I found ...

The first thing I found was that the following was not processing the "string" argument (it just kept processing the number argument):

$X->xppattr('fred', ' ', 9, 'center');         [ ' ' is meant to represent just having two single quotes ]

When I changed it to the following, then I could see composition processing the "string" argument with the xppattr() code:

$X->xppattr('fred', 'string', 9, 'center');

But then in the CSS having either of the following still did not work (where leaving out the type-or-unit argument is documented to default to "string"):

text-align: attr(xpp\:fred string);
text-align: attr(xpp\:fred);

And what I found was that this line in the CSS was considered syntactically incorrect and silently ignored (as Bart noted).

When I changed "string" back to "integer" as a test, then I did see composition processing the text-align property but of course I didn't get a match on the string value (e.g. "center") as a number.

Then I went and looked at the documentation in the XPP CSS manual, and for the text-align property for attr() this is what it says for acceptable syntax (page 3-36 of 9.4 version):

So, it appears to be documented that for the text-align property only the "integer" type is allowed (at least that's how I interpret it).

And I did some further poking around in the XPP CSS documentation for the specified syntax of attr() on other properties, and found attr(name string[,fallback]) was only listed for the font-family property and there were some properties where attr(name integer|unit[,fallback]) was listed for syntax (i.e. two possible type-or-unit values allowed). That seems to reinforce the same conclusion.

Not sure I understand why the "string" type for attr() would not always just be considered to be syntactically correct and allowed to "pass through" to the property value processing, but I'm sure there's a reason.

I imagine Tony would know "right away".

At this point, you've gotten it working so all is good.

Depending on what Tony says, having it work with the "string" type might be something for an "XPP Idea" (aka RFE) - or maybe it might even considered to be a "Bug" (if it's an oversight).

Jonathan,

Interesting and thanks for looking into this.
Let's wait and see what Tony has to say about it.

I'm very interested to know what is the underlying reason for not accepting the string version in the text-align (or possibly other) property.

Personally I do not think it is a big problem it is only working with a numeric argument. If you are deep enough into the inner workings of CSS/XPP to set up something that is using the xppattr(), I guess that the fact it does not accept a string argument poses a big problem for the user that got this far. PLUS: it is documented.

Still it would be convenient though if both the numeric and string argument would work, so maybe at the same time you can ask Tony how much work it would cost to get the string argument to work as well...

Chris,

All you had to do was ask...

First, it was never intended that the CSS 3 attr() function be used to set any and all CSS values using e.g. <foo font="Helvetica" text-align="-xpp-ragged-right" font-variant="small-caps" ...>.

When a "string" value is used as the value-type of an argument to the CSS 3 attr() function, it is (or was) specified that the string value not be re-parsed by the CSS processor, it ends up being both ugly, error prone and inefficient.

That said, it is perfectly reasonable that Chris wants to set text align to left or right depending on the value of an x-register.

So why not this:

sub check{

. . .

if ($notest == 1){

$X->xppattr('align', 'string', '', 'center');

} else {

$X->xppattr('align', 'string', '', 'left');

}

and in the CSS

para[xpp\:align='center'] { text-align: center; }

para[xpp\:align='left'] { text-align: left; }

In my opinion, this is a bit more readable than setting Fred to '9' or '10'.

The real reason(s) for implementing the CSS 3 attr() function in XPP are:

1) To address the "tabular problem in CSS", i.e. that fact that not all composition values are restored properly if you have e.g. a CALS table with an <entry> element with embedded tags which change e.g. text alignment, font weight, font size, and your t5 spec is setup to restore body/header c/p values on each <entry>. See cals_t5.css spec. By using the xppattr xymacro, it is possible to "save" composition values as attributes on the MLH (markup language header), and then you can set font-size, font-width, text-align using the CSS 3 attr() function.

2) To facilitate QA testing, where you may want to specify c/p values using attributes for data-driven XML testing.

3) For cases like Chris mentioned, as shown above.

That's my 2p's worth, for today anyway.

Tony

Thanks Tony for the detailed reply. This looks more elegant that using numbers so I will try this!

Tony, brilliant..simple, elegant and a lot more readable .

However this is only usable when the number of choices is limited.
If you want to use an attribute in which the user can put whatever value he wants (or you calculate by some logic a value), you will be forced to use the attr() function.

So if you ask me there is certainly a case for adding a 4th point to your list:

4) whenever you have a variable (non preset) value either in the input or calculated by some logic, that you need to pass into a CSS property.

A simple example:
I do like in certain cases to add in the CSS some ' limited' control on how things should look like by adding some attributes to the input

<p Xsize="20pt">para in 20 pt</p>

And the CSS then looks like:

p {
    display: block;
    font-size: attr(Xsize length, 12pt);
}

You could say, well why don't you use the inline styles. Sure but that could open up a box of Pandora. Using a limited set of attributes on certain elements gives you a lot more control.

So I like the attr() function.

And it would be wonderful if the attr() function could be used to influence ALL the CSS properties, even if that means supporting the ' string' value for the attr() function for properties that only accept a string. This is not different from macro/xyperl combo in which we were able to pass on calculated or arbitrary input values into macros in order to influence any desired aspect of the final layout.
 

So, Bart, not to negate that there might be some use-cases for needing support for the 'string' type for attr() - but I don't think that the example you gave is one of them.

The CSS documentation for the font-size property says this for the syntax for attr() (page 3-25):

At first glance I thought that meant that your example wouldn't work w/o 'string' type support, because you are using a 'length' value and the documentation says 'integer'.

But I believe in this case that this documentation for font-size is actually wrong and should instead be as follows (with needed correction shown in bold):

The reason I say that is that when I look at the Syntax line near the top of the doc for font-size, length and attr() are listed as valid types (as well as some others), but not integer.

More evidence of that is that the font-size CSS/XML example on page 3-12 is showing exactly what you're cited example is doing, i.e. using 'length' with attr() for the font-size property.

So, I'm thinking that your cited example should actually work fine (and unless I'm mistaken we need to make this correction to the CSS manual).

So, where do we go from here?

Just like is often the case with XPP, there are "twenty" ways to do something and if one way doesn't work there is often another way to accomplish what you need to do (as in this case).

That being said, it's not always convenient to have to do it another way.

I think it's safe to say from Tony's response that doing more "wholesale" support of the 'string' type with attr() with all CSS properties is "bigger than a breadbox".

I believe that the CSS parsing engine being used by XPP is some open-source package, and apparently it's not already doing what you want here.

We now need to move this into the purview of XPP Ideas, as it's now apparent that this is a RFE (request for enhancement).

I would ask that one of you (i.e. Chris or Bart) open an XPP Idea on this subject and please include a use-case.

That will allow for others to vote on the request and for us to make the necessary costs versus needs analysis.

I have another question (which I have been playing with unsuccessfully). So I can pass a string (ie center) or a value (ie 12) to the xppattr - what I need to to is pass the value of a variable (which is an integer) but it does not appear to be possible - am I missing something?