Skip to content
This repository has been archived by the owner on Jan 30, 2024. It is now read-only.

Declarative & programmatic layout/style #14

Open
bergos opened this issue Jun 29, 2023 · 9 comments
Open

Declarative & programmatic layout/style #14

bergos opened this issue Jun 29, 2023 · 9 comments

Comments

@bergos
Copy link
Member

bergos commented Jun 29, 2023

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
Copy link
Contributor

HolgerKnublauch commented Jun 29, 2023

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
Copy link
Member Author

bergos commented Jun 30, 2023

@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
Copy link
Contributor

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
Copy link
Contributor

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;'."
  1. It is the responsibility of the application to honor or not these annotations, the application could very well ignore them

@tpluscode
Copy link

tpluscode commented Aug 25, 2023

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
Copy link
Contributor

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
Copy link

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

@HolgerKnublauch
Copy link
Contributor

HolgerKnublauch commented Aug 25, 2023

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
Copy link

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants