Declarative & programmatic layout/style

[bergos]

This issue is a follow-up to the discussion started in the Forms vs Views issue.

The discussion started based on an example of aligning two fields horizontally instead of vertically. That leads to the general topic of declarative vs. programmatic layout and style.

Declarative

Use case: Explorative, using ontology information and show/edit data aligned to the rest of an application.

Pro:

• Declarative layout/style information could be included in the ontology
• Easier for applications to combine their layout/style with the one defined in the shapes
• Easy to use outside HTML rendering engines
• Already partially defined in SHACL (sh:order, sh:group)

Con:

• Not an option for pixel-perfect results
• Requires to draw a clear line on what will be included/excluded so we don't reimplement HTML

Programmatic

Use case: Application development, mainly based on custom-tailored shapes for a specific application/context.

Pro:

• Full control for pixel-perfect results
• Definitions in the shapes are closer to the rest of the application (JS variable/function names, CSS selectors, ...)

Con:

• Difficult to use definitions and components outside the application for which the shapes have been designed for
• Hard to extract layout/style information in other environments

Based on the background of the participants, I expect the task force is interested in both options.

[HolgerKnublauch]

Extending the first Pro argument: some of the relevant layout information IS already stored declaratively, namely sh:order and sh:group. So if we now come up with a competing approach that for example is based on a new top-down approach to defining a whole form at once, then what would happen with those existing annotations? An incremental design may be something like ex:firstName ... sh:relative .. ex:lastName ... right.

[bergos]

@HolgerKnublauch Good point. I added the argument to the list.

It should not be one or the other. We should figure out an elegant solution to combine both approaches. I expect one would use the declarative option exclusive or combined, declarative and programmatic. For example, the programmatic part could be assigning a group to a slot defined in HTML/JS. Inside the group, the declarative logic is used.

A more tricky example: I want to change the font weight and background color for a single property. It could be done in three different ways, from plain programmatic (1) to declarative (3).

1. Create a custom Web Component that contains all the CSS information and assign the component only to that property.
2. Define a shui:style property that contains the full CSS as a literal and merge that into the CSS of the Web Component.
3. Define shui:cssProperty properties for both CSS key/value pairs with shu:cssKey and shu:cssValue properties, convert that RDF data into CSS, and merge it into the CSS of the Web Component.

[HolgerKnublauch]

In today's meeting we discussed the use case of displaying text as monospaced vs normal font. This would apply to things like source code or markup. It would be best to express such info in the most generic and model-driven way as possible.

One idea would be to have some kind of mimetype property that links to a MimeType instance, which then carries additional triples to inform whether something should be rendered in monospace, and also could be used as a validation constraint.

If we don't want to introduce mimetypes, then user-defined datatypes would be an option. rdf:JSON is a good example here, which would both be used for validation and to determine how to best render and edit such values.

[tfrancart]

Not sure I fully understand all the implication of the initial issue description, but here my thoughts:

1. I would find it useful to declare generic CSS-related property(-ies) to attach CSS-related information to any entity, be it a class, a shape, a property, an instance, etc...
2. On my side I have defined and published VOLIPI (VOcabulary for LInked data Presentation) which declares:

• volipi:class "A CSS class associated with the resource, typically to indicate the CSS class to use when displaying the resource. Must be a valid CSS class name string such as one would put in an HTML 'class' attribute"
• volipi:style "A valid CSS style string such as one could put in an HTML 'style' attribute, e.g. 'color: red;'."

3. It is the responsibility of the application to honor or not these annotations, the application could very well ignore them

[tpluscode]

In today's meeting we discussed the use case of displaying text as monospaced vs normal font.

As I missed that call, could you recap a takeaway from that discussion.

Specifically, I find this specific decisions (font face) a purely styling matter. I would expect a property to be styleable either via custom properties or Shadow Parts

I am not convinced, however, whether that should be the responsibility of the shape to declare or rather the component library itself

[HolgerKnublauch]

The example that I have is that some strings are reStructuredText (some markdown). People would want to see them rendered in monospace (e.g. because indentation matters) but not the other string literals.

[tpluscode]

If it's a separate property than maybe that would be a dedicated viewer?

[HolgerKnublauch]

I am worried that would cause an explosion of viewers and editors, just for something that really ought to be a configurable attribute of these viewers. For example consider that you would need to have all these variations both for TextAreas and TextFields.

Something like this may work

dash:editor [
    a dash:TextAreaEditor ;
    xy:fontFamily "monospace" ; # CSS equivalent
] .

[tpluscode]

Gotcha. And I like the blank node as the means to extend/configure a component