Re: referencing properties from other specs in SVG 2

+www-svg

Comments below:

Cameron McCormack:
>>> Since we will have some substantial parts of SVG split out into
>>> other specs, like Filters, and various other CSS properties in
>>> other specs will be required, I'm wondering how we should handle
>>> definitions and links to these things.  Here are my current
>>> thoughts:
>>>
>>> * We remove from SVG 2 definitions of any properties that are
>>> fully defined elsewhere.  For example, we don't need to re-define
>>> the 'direction' property in SVG.  All we need to do is to mention
>>> that it applies to certain SVG elements.
>>>
>>> * For the definition of what the set of presentation attributes
>>> is, and for the element summary boxes that mention them, we
>>> include properties in dependent specs that SVG 2 requires.  For
>>> example, the color-interpolation-filters property will be defined
>>> in the Filter Effects spec, and SVG 2 will have a normative
>>> dependency on Filter Effects, so color-interpolation-filters will
>>> be mentioned in element summary boxes and in the list of
>>> presentation attributes. If there comes to exist some specs that
>>> build upon SVG 2, which SVG 2 itself does not normatively depend
>>> on (and which therefore UAs can rightly implement or not),
>>> presentation attributes for these properties will not be
>>> mentioned in SVG 2.  SVG 2 will however have a spec hook that the
>>> other spec can reference to define a presentation attribute for
>>> itself, so that it will be allowed on stylable elements.

Tab Atkins Jr.:
>> I agree with both of these.  Reference instead of redefining, but
>> do include them in the lists of properties that apply in whatever
>> context.

Dirk Schulze:
> I agree with the general proposal. Two things.
>
> 1) We need to update the build system, so that it can automatically
> reference to CSS specs. This is an issue that we already have in
> Filter Effects and partly CSS Transforms.

My though is that rather than modifying the build system, we would write 
a definitions.xml file for them, which we can then import for use.

But even simpler: for one of the properties that has moved out of SVG 2 
so far -- color-interpolation-properties -- I just changed its entry in 
our definitions.xml to say:

<property name='color-interpolation-filters' 
href='https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#ColorInterpolationFiltersProperty'/>

and our <a>'color-interpolation-filters'</a> links will now reference 
the Filters spec.

That's not quite "automatic" (it's not searching for property 
definitions within the Filters spec source), but it's the same level of 
automation we have for things within the SVG spec currently.

> 2) We need a general comment about the syntax for presentation
> attributes. We should continue allowing 'unit less' values as well as
> scientific numbers. But we also need a comment that we use the
> general grammar and described units from the certain CSS spec where
> the property is defined (e.g CSS Values and Units, CSS Transforms).
> Then we could also remove a lot of parts from "4.2 Basic data types"
> [1]. I think that would be in common with the resolutions that we had
> during the Hamburg F2F.

Agreed, it would be good to drop those redefined data types.

For unitless lengths and scientific notation: I think it would it be 
sufficient for us to state somewhere exactly how presentation attributes 
get turned into the specificity 0 rules in the author style sheet, and 
as part of that we would say that they get parsed according to the 
grammar for the property definition except that <length>s and <number>s 
are interpreted differently.  For some presentation attributes we'll 
need to skip this, like the one for font="".

Given that the set of presentation attributes that will exist from the 
properties defined in SVG and referenced and required from other specs 
is fixed, we can just state which ones don't get the unitless length 
parsing treatment.  For other specs which build upon SVG, and define 
their own properties and corresponding presentation attributes, they can 
state whether they get the unitless length parsing behaviour or not.

> Greetings, Dirk
>
> PS: Does this discussion need to got to public-svg? Why not www-svg?

Yes, probably should have gone to www-svg.  (My thought was that spec
writing issues didn't need to go to www-svg; we'd just have discussion
of actual technical issues there.  But at least since this topic is
related to other specs, www-svg would've been better.  Moved it there now.)

> [1] http://www.w3.org/TR/SVG/types.html

Received on Saturday, 19 May 2012 02:20:28 UTC