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).

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...