Re: Style

On Fri, Sep 7, 2012 at 12:12 PM, Bernhard Haslhofer
<bernhard.haslhofer@cornell.edu> wrote:
> You asked for a solution for Shannon's use case, and for those SVG should work.

Yes, using SVG with embedded styles would solve that particular case.


> But let me briefly respond to the other reasons you are mentioning:
>> I don't think this is a real solution for several reasons, primarily:
>>
>> * Doesn't work for non fixed pixel data (eg white border around text
>> on white reflowable page)
> I am not sure, if I correctly understand that use case

The issue is that you cannot put SVG into a text selector, but may
want to style text selections for the same reasons as for wanting to
style segments of images.


>> * Would mean that everyone had to support SVG, making media fragments pointless
> Our custom CSS-in-RDF solution means that everyone has to support CSS parsing from
> an RDF graph.

It can be just a resource, not necessarily embedded in the graph.

> I don't see why SVGFragments make media fragments pointless. You can
> still use MF for use cases in which you don't need styling info.

Right, but this is about interoperability.  So any application that
wishes to support style, creating it or consuming it or both, would
have to support SVG.


>> * Is worse for separation of concerns (semantic/presentation) than the
>> current proposal
>
> At the moment we define presentation-oriented information in a data/semantics-oriented data
> model, which means that concerns are not separated.

I disagree.  We outsource to the appropriate standard, CSS. We
reference a resource that follows, exactly, that standard.

> If we "outsource" styling of fragments
> to standards that support this, such as SVG, then we don't need to introduce presentation-oriented
> properties / classes (oax:hasStyle, oa:style). So the definition of presentation-oriented information
> lives orthogonal to the definition of data/semantic-oriented information. I would say that the latter
> is a better separation of concerns.

It still does live orthogonally, in its own CSS file.
In the SVG with embedded CSS, it is tied directly into a particular
Selector class.  Selectors should select. Style should style. That is
a separation of concerns.


>> * It's harder to ignore, as it's embedded within the SVG selector XML
>> rather than linked from the Annotation
> I don't see why it is hard to ignore information.

Because you'd need to strip it out of the SVG before rendering, rather
than just not even following the oa:styledBy relationship from the
Annotation.  And it could be scattered all throughout the SVG.

Rob

Received on Friday, 7 September 2012 18:26:11 UTC