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

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