Annotate Live Data entries with a class corresponding to the entry id

Development
#1

Hello all,

Currently, it is not easy to identify displayed values in Live Data.
For instance, it is not safe to base the selector:

  • on the nth-element as they can be reordered
  • on the element type (e.g., td) as we support several layouts (table and cards for now)

I propose to annotate each displayer with the identifier of the property it is displaying.

Option 1: class

This is the option proposed in the currently opened PR XWIKI-21935: Annotate Live Data entries with a class corresponding to the entry id by manuelleduc · Pull Request #2930 · xwiki/xwiki-platform · GitHub

Each displayer has a new class with the same value as the property id in addition to the existing livedata-displayer

<td data-title="File size" class="cell">
  <div class="livedata-displayer filesize"><!-- The filesize class correspond to the property id of the cell-->
    <div data-tippy-component-trigger="" tabindex="0">
      <div class="view">
        <div>
          <div class="html-wrapper"> <span class="size" data-size="44816">43.8 KB</span></div>
        </div>
      </div>
    </div>
  </div>
</td>

Option 2: data

The same logic, but instead of a class, we add a new data-livedata-property-id='propertyId' on the displayer root

<td data-title="File size" class="cell">
  <div class="livedata-displayer" data-livedata-property-id='filesize'><!-- The filesize class correspond to the property id of the cell-->
    <div data-tippy-component-trigger="" tabindex="0">
      <div class="view">
        <div>
          <div class="html-wrapper"> <span class="size" data-size="44816">43.8 KB</span></div>
        </div>
      </div>
    </div>
  </div>
</td>

Conclusion

Both options are equally usable from CSS/Javascript.
Here is my +1 for option 1 as it’s more concise, but I’m also +0 for option 2.
WDYT?

#2

Hi, I feel like option 2 is semantically more accurate, and it might avoid weird side effect: e.g. if by any chance I have a CSS defined with the same name as the property ID I want to use. So +1 for option 2 and +0 for option 1.

#3

:+1: If we want to use class, in my opinion we should make sure that the ID doesn’t collide with any generic class we use in the UI. It could create a lot of unique breakages that would take time to track and fix. I’m not sure how those IDs are generated, but if they have generic values such as filesize this could quickly become a problem. An option we’d have to go around that issue and still use classes would be to prefix the class with livedata-id- => livedata-id-filesize. This way we avoid most collisions. But we do lose the advantage of conciseness…

I’d prefer to use generic HTML/CSS instead of introducing our own HTML attribute. +1 for option 1 given we make sure there’s no collision problems. +0 for option 2, it can be almost as easy to use for admins/devs if properly documented.

#4

+1 for option 2 because it’s more generic: it provides semantic information that can be used by JavaScript not only CSS. Besides that, AFAIK there’s no constraint on the property id value from the LiveData spec point of view. Sure, for a live data source based on xobjects we know that the property id can’t contain any chars, but the live data front end is generic and thus shouldn’t assume that property ids don’t have CSS special characters.

If you go with option 1 then for sure you need a prefix as @CharpentierLucas pointed out.

Thanks,
Marius

#5

+1 for option 2, imho it doesn’t make sense to have an id as a class. I’m also wondering why the attribute is on the div and not on the td element or even the parent tr as the whole tr is for the same id.

#6

I see a strong trend toward option 2, thanks a lot for all the feedback.

The attribute is currently attached to the displayer. Displayers can be used in various layout where the parent element is specific (e.g., td for table layout, but a div for cards).
Asking each layout to define the property id on the right element is not impossible but:

  1. impacts all existing layouts
  2. forces new layouts to also add this attribute at the right place

I’m not against going that way as it probably allows for more, if we agree that the small extra work is ok.

#7

I think I found an additional argument for placing the attribute on the displayer themselves.

  1. In Javascript, it’s easy to navigate to the parent
  2. In CSS, the has pseudo-class can now be used in selectors, to apply a style on the parents (see example below)
:has(> .livedata-displayer.filesize) {
  border: 1px solid #f00;
}

Applies the style on the direct parent of the displayer (of course, it is just an example. It can be easily ported to a data attribute version).

Table result:
image

Cards result:
image

Therefore, I suggest going for Option 2.

Edit: XWIKI-21935: Annotate Live Data entries with a data property corresponding to the entry id by manuelleduc · Pull Request #2930 · xwiki/xwiki-platform · GitHub updated accordingly.

#8

PR merged