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

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