Re: Styling class proposal

From: Ryan Lee <>
Date: Wed, 15 Jun 2005 22:11:33 -0400

Emmanuel Pietriga wrote:
> As Chris, I'm very happy with the whole proposal. A few comments:
> 1) I'm a little worried about fresnel:Transform's "domain". Looking at
> your example, it looks like you declare a Transform globally, and that
> you define its scope/domain only by specifying
> fresnel:transformProperty, giving the name of the property. Meaning that
> it applies to all such properties, no matter the context of their
> display (e.g., by which lens are they displayed). However, I can very
> well imagine that for the same property type, people would like
> different transforms to happen depending on the context (e.g. what lens
> is displaying this property). Using FSL selectors as the value of
> fresnel:transformProperty only solves part of the problem (it puts
> constraints on the property's context (in the RDF graph), but not on the
> presentation context (what lens/group is currently used to display this
> bit of information). Or maybe I have missed something and you can do
> something like that, maybe using groups, e.g. by associating the
> Transform toa group?

(using 'Transform' solely for the purpose of differentiating between our
old Styles and what we aim to do now)

In our previous vocabulary, Styles and Lenses were generally supposed to
be grouped together for greater effect. My implementation experience
grouped ungrouped strays together; 'global' doesn't mean quite the same
thing to me since everything ended up in a group of some sort. The
catch all group just didn't tend to look consistent. A Transform should
be intentionally grouped with related lenses.

I believe the intent behind using the :styleDomain is because we felt
that it would cut out repetitive delcarations - associating Styles
directly with the Lens would end up at least requiring a link from Lens
to Style. I think it's probably the same for :transformDomain. For
Styles, we gave ourselves an override in :PropertyDescription and :use
in Lenses, and it could be the same for Transforms.

:foafPersonDefaultLens rdf:type fresnel:Lens ;
   fresnel:domain foaf:Person ;
   fresnel:showProperties ( foaf:name
                           [ rdf:type fresnel:PropertyDetails ;
                             fresnel:property foaf:knows ;
                             fresnel:sublens :friendsLens ;
                             fresnel:use :someTransform ] ) .

> > The box model is done away with. There is no presumption that, say,an
> > XHTML tree is structured with the property element nested inside its
> > subject resource element.
> 2) Agreed.
> 3) I'm also fine with just considering symbols in core (for class/style
> hooks)
> 4) About terminology:
> - I don't really like "hook". Even if it describes the role of this
> thing well, it sounds too low-level/technical to me. However I don't
> have a strong feeling about this.

I'm not attached to hook. I could maybe be convinced that :*Style terms
are still fine here, but it's because it feels so general (general
enough to be used for styling instructions in an extension) that I'm not
sure about it. See below as well.

> - fresnel:style vs. fresnel:transform: I'm in favor of transform.
> Everything is considered as "styling" by CSS, including
> content-before/after, etc., but they are not actually using a specific
> terminology to refer to this part of the language. We are. And
> considering this I find "style" to be misleading. Looking quickly at the
> CSS 2.1 WD, other terms come to mind: "fresnel:Content",
> "fresnel:Formatting". Just suggestions, I'm not sure this actually fits
> better.

I am also concerned about using 'styling' where it doesn't quite fit.
We have tried to find a more appropriate term for the things we're doing
with a 'Transform' and haven't yet come up with anything we all like.

We could consider using some totally unrelated word...but I don't think
I'd like that much either.

Ryan Lee       
W3C Research Engineer    +1.617.253.5327
Received on Thu Jun 16 2005 - 02:09:33 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:40:51 EDT