Re: [parameters] Outline for recasting SVG Parameters on top of CSS Variables

On Sat, Nov 1, 2014 at 6:35 PM, Amelia Bellamy-Royds
<amelia.bellamy.royds@gmail.com> wrote:
>> <html>
>>   <img src="foo.svg?--text=red">
>> </html>
>
> Using a URL query string will disable file caching (for the same SVG file
> accessed multiple times with different parameters) since the browser would
> not be able to distinguish this from a request for a different file from the
> server.  It could also potentially cause problems interacting with
> server-side query parameters.
>
> For <object> embeds there is the <param> element, but that doesn't help with
> images accessed as <img> or within CSS.
>
> Target fragment strings (such as are used for views) are closer to what is
> needed, in that they define a desired client-side processing of a file.
> However, there would need to be some clarification on how they interact with
> internal links.  It's normal to have a view switch when you click on an
> internal link, but you wouldn't want customized styles to disappear.
>
> A parameter fragment would need to be clearly distinguished from a regular
> target fragment, and user agents that supported parameters would need to
> preserve the parameters when the target was changed.  E.g., a single #
> followed by a token could be a target fragment, but a double ## (or a #! or
> similar) would introduce client-side parameters.

You're right that caching becomes harder, but as you note, using the
hash section means you'll lose styles if you click on a link, unless
browsers are willing to change their handling of hashes to distinguish
"target" from "var" pieces.  It also means you can't target an
element, unless you expand the syntax even further to allow "var"
hashes and "target" hashes to coexist, basically expanding the hash
section to have the same syntax and meaning as the query section.

Not saying that's not a good idea, but it's probably a harder sell.

> I don't think I like the idea of using an XML element to define a default
> for a CSS variable.  It really messes up the separation of responsibilities
> if you're using external stylesheets!
>
> I'm not sure it's necessary to pre-declare anything.  Any variables
> specified would just become part of the initial CSS properties for the root
> element.

I outlined why this is potentially bad - it echoes PHP's
register_globals "feature", allowing users of the image to potentially
override custom properties that weren't intended to be overridden.
Since custom properties can be used for more than just variables (as
we expand the functionality around them, they'll be useful for actual
*custom properties*, implemented in script), this has some harmful
potential.

>  Fallback values can already be declared at the time the variable
> is used.  If you wanted to set global fallbacks, you could use CSS syntax
> like
>
> :root {
>   --my-var-internal: var(--my-var, fallbackValue);
> }
>
> and then use `--my-var-internal` within the actual code.  Not ideal, but
> workable.

Ah, indeed, forgot about that.  I was thinking of "--my-var:
var(--my-var, fallback);", which is cyclic, but your way works fine
for actually picking up defaults.  That at least means that we can
remove the need to specify default values in the declaration of which
vars to use.

> A nicer solution would be to change the CSS variables spec itself to state
> that when you use a CSS variable inside the property declaration for that
> variable, it equates to the inherited value for that variable (similar to
> how em units work in a font-size declaration); the current spec says to
> treat that as an invalid circular dependency [2].  Not sure if that's too
> big a change to make at Last Call stage (Perhaps the CSS Variables spec
> editor can weigh in on that one!).  It wouldn't break any stylesheets that
> weren't already broken, but it might be a hassle for implementations!

I am that spec's editor. ^_^  Level 2 will contain a parent-var()
function with that functionality.

>> Currently this is only usable in CSS properties.  If SVG wants them to
>> be usable in attributes, it can define that all attributes accept
>> var() as well.  (Note that var() is allowed *anywhere* in a CSS
>> property value; it can be preceded or followed by arbitrary other
>> values, including more var() functions.  You also can't tell whether
>> the resulting value is valid until after substitution. CSS has some
>> special rules to handle this, since it can no longer reject invalid
>> properties at parse time, if they include a var().  SVG will have to
>> adopt similar rules.)
>
> There wouldn't need to be for any special rules for run-time rejection for
> XML-only SVG attributes, since these don't cascade.  (The special rules for
> invalid CSS properties using var() are needed so that you don't have to
> maintain the entire cascade for each element, just the calculated value with
> var(), and if that doesn't work use the initial or inherited value as if the
> property wasn't set on that particular element). Without a cascade to worry
> about, the result of an invalid declaration with var() would be the same as
> if the invalid value was directly set on the attribute, i.e. normal error
> rules would apply or a default value would be used.
>
> For presentation attributes, the cascade/validation rules  would be the same
> as for CSS.
>
> For actually using CSS variables in XML attributes, the obvious/easiest
> syntax is to use the CSS var() function, but then the questions would be:
>
> - Would var() only be allowed as an alternative to the complete attribute
> value, or could it be used for a single token within a string, as in CSS?
> - How would you distinguish an embedded CSS function within a free-text
> string attribute?
> - What attributes could variables substitute into?

Yup, these are all issues.

> - Would var() only work for custom CSS properties, or could you use it to
> grab the inherited value of regular CSS properties like background-color or
> line-height?  (Another thing that might be nice to have in the general CSS
> variables specification.)

Only custom properties.  The circular dependency issues are too great otherwise.

> I would argue that discussion of the appropriate places to use var() in
> attribute values should be coordinated with discussion about implementing
> the calc() and possibly the attr() functions in SVG.

Reasonable.

> It might also be worth discussing whether there should be a way to declare
> CSS variables as presentation attributes, or if inline style declarations
> are sufficient.  This is always something that could be added in later.

Sounds interesting!

> Finally, would there be a way to set text content from variables?  This
> would be great for many types of customization, but particularly
> internationalization.
>
> One option would be to simply allow the CSS `content` property (normally
> only used for before and after pseudoelements) to override the child content
> of any SVG element.  In contrast, the 2009 SVG parameters proposal suggested
> adding a XML attribute to text elements that could contain a parameter
> access function, with the parameter value replacing child content.[3] (A
> comment in the draft asks whether it should also be supported in <title>, to
> which I would say most definitely!  Localized tooltips are just as important
> as localized visible text.)

Yeah, 'content' should work - it's supposed to work for any element in
CSS, too, but the draft for that is unmaintained at the moment.
Having an explicit attribute for it, to communicate semantics better,
would also be acceptable, though.

~TJ

Received on Sunday, 2 November 2014 18:02:55 UTC