Re: [css-gcpm] String-set issues

> On Nov 25, 2014, at 11:43 PM, Liam R E Quin <liam@w3.org> wrote:
> 
> On Tue, 25 Nov 2014 22:01:55 -0800
> Brad Kemper <brad.kemper@gmail.com> wrote:
> [...]
> 
>> Another thing is I think there is too much of a tendency to go to functional notation in CSS, which is not as easy to read as simple name:value declarations. I really don't want to see functions inside of other functions, and it sounds like functions might really be needed for date and number formatting. So, I'd prefer we avoided functions here for content pulls.
> 
> I think we already have that attr(), and we'll see more with combinations of format-number and calc.

Exactly. That's why I don't want to make it worse, if we can avoid it. 

> The problems are more complex and harder to describe, so that a more complex notation isn't a surprise. Most people won't need to do arithmetic on page numbers, but when people do, it should be obvious how to do it.

I agree with that. 

>> If we did go with functional notation, I think I'd almost prefer to get rid of the indirection altogether, and have a real selector as an argument of the function, like Liam and I touched on. That would make your example look like this:
>> 
>> @page:left {
>> @top-left {
>>   content: copy-from("h1:first-of-page");
>>   }
>> }
> 
> 
> I think that sort of idea is becoming very common these days with the success of jQuery.

Although I am not usually a fan of having multiple syntaxes to do the exact same thing, I wouldn't mind if we had the flow -> name method AND this, for convenience. I'n not an implementor, but I t doesn't seem like much to add the ability to flow a copy instead of the original, nor to allow more keywords besides 'content' for determining what part of the original to flow. 

Once you have the content, whether from flowing it into a name or selecting it inside the function, adding it into the content shouldn't be that hard (easy for me to say).

I suspect implementors might have some issues with issues with doing selecting inside the property value, since that would take place after the normal cascade.  

You could probably avoid recursion issues by saying that content flowed from an element does not include content that was added to that element through CSS. That would keep it sane, but it also means you can't grab content from ::before or ::after (no great loss there). So this:

a { content: copy-from("span1:first-of-page");") }
span { content: copy-from("a1:first-of-page");") }
 
...would not cause recursion issues. 

>> But that could get cumbersome too:
> 
> [...]
> 
>> content: "Chapter " copy-from("h1:first-of-page", counter(chapter) ": " contents ", " formatDate(attr(date), "MM/DD/YYYY"));
> 
> Yes - although you have your nested function calls :-).

Yeah, I did that on purpose, to show what an unreadable mess it can become, trying to track parentheses. 

> This is similar to one of the ways to do this in XSLT + XSL-FO; the other is closer to your flow example. Sometimes one is better and sometimes the other.

Yeah, I vote for both! :)

> I don't like having to invent names for things that don't have problem-domain-level significance if it can be avoided.
> 
> -- 
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/

Received on Wednesday, 26 November 2014 14:26:48 UTC