W3C home > Mailing lists > Public > www-style@w3.org > November 2014

Re: [css-gcpm] String-set issues

From: Brad Kemper <brad.kemper@gmail.com>
Date: Mon, 24 Nov 2014 06:09:38 -0800
Cc: Liam R E Quin <liam@w3.org>, www-style list <www-style@w3.org>, Dave Cramer <Dave.Cramer@hbgusa.com>
Message-Id: <673BC9E1-718E-45F7-8215-318E23C9E302@gmail.com>
To: Jirka Kosek <jirka@kosek.cz>

> On Nov 24, 2014, at 5:41 AM, Jirka Kosek <jirka@kosek.cz> wrote:
> On 23.11.2014 10:11, Brad Kemper wrote:
>>> Rather than keywords (content, text, attribute...) maybe a function
>>> should use CSS selectors
>> I was considering something like that when I was jotting ideas down.
>> It has the advantage of not needing an intermediary name to hold the
>> value if you did something like 'content: get("h2:first-on-page",
>> contents)', but it didn't seem quite as elegant to me as basing this
>> on flow concepts. Especially in that I prefer to not keep resorting
>> to functional notation if it can be avoided. And it felt wrong to use
>> selectors in such a non-standard place instead of finding a way to
>> use them in the usual place instead. The selectors might exist in the
>> standard position somewhere in the style sheet already, and it it
>> seems clunky to have to re-type them into a property value too.
> You can't solve more complex scenarious without such feature. There are
> existing non-browser implementations that has to support this

I'm not sure I know what you are referring to when you say "such a feature" and "this". Do you mean putting the selector into the function itself is necessary, instead of using the selector to the left of the declaration list with a different syntax? Or the other way around?

I'm not suggesting the removal of any features, just an examination of the syntax, so that we can standardize on the best method, and get as many implementors as possible to converge on that. It is possible/probable that some non-browser implementations will have to also continue to prefixed versions of older, non-standardized syntax.

> (and they
> even support full XPath instead of being limited by selectors):
> http://www.xmlmind.com/xmleditor/_distrib/doc/csssupport/xpath.html
> http://www.oxygenxml.com/doc/ug-editor/index.html#concepts/dg-xpath-function.html

Let's leave XPath support to a different thread. This one is really about the syntax supporting the features that are already in the draft. The part you quoted is about where to put the selectors and other syntax for selecting the bits and pieces that need to be strung together.
Received on Monday, 24 November 2014 14:10:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:26 UTC