Semantic markup in the detail panel

[jri]

The fields rendered in the detail panel should be annotated with the respective type URIs:

<div class="dm4.datetime.date">
    <div class="dm4.datetime.month">...</div>
    <div class="dm4.datetime.day">...</div>
    <div class="dm4.datetime.year">...</div>
</div>

This would allow for individual styling. Even HTML could be generated purely by CSS (using pseudo elements). In some cases this would allow plugins to render parts of the detail panel individually without writing any code (that is custom renderer implementations), but purely declarative (that is CSS).

[Malte]

For this case, please consider to employ standard HTML 5 markup for application specific "metadata" about elements by using the prefix "data-". In this case, introducing e.g. an attribute named "data-type-uri" attribute to such DIVs would allow for CSS styling too.

I would be in favor of going this way as this seems to be exactly the case for HTML 5 Custom Data Attributes (see ​http://html5doctor.com/html5-custom-data-attributes/ and HTML 5 Spec ​https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#embedding-custom-non-visible-data-with-the-data-attributes).

Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.

A style definition in CSS would then look like, for example:

[data-type-uri="dm4.datetime.month"] {
    color: #f00;
}

Also i went for this approach in the stableviews ui, so ideally, webclient style definitions would be meaningful for this alternate topicmaps renderer, too.

[jri]

Replying to Malte:

A style definition in CSS would then look like, for example:

[data-type-uri="dm4.datetime.month"] {
    color: #f00;
}

What would be the advantage over this:

.dm4.datetime.month {
    color: #f00;
}

The data attribute is meant for enriching the DOM with arbitrary application data like DB IDs. Here I'm talking about semantic markup. In this context a DM type URI matches the meaning of a CSS class perfectly. Think of my example as:

<date>
    <month>...</month>
    <day>...</day>
    <year>...</year>
</date>

[Malte]

I did not state that there was any advantage in my approach but why i came up with using "data-" is:

• I consider the "type_uri" of any dm4-type metadata about the data represent within the element
• It is totally legit to consider the dm4 core or the dm4-webclient (and thus such URIs coming with them) as application data (thus not specifically arbitrary)

Also, your approach just would not work. Despite that a CSS class matches the meaning of semantic (as in meaningful) markup it does not match CSS class names syntactically because the period character has a special when writing CSS selectors. Your examplary rule ".dm4.datetime.month" would actually not match the element you mentioned above but instead just elements which have all three classes set.

<div class="dm4 datetime month">...</div>

[jri]

Replying to Malte:

[...] your approach just would not work [...] because the period character has a special when writing CSS selectors.

You're right! My example would not work.
I forgot to escape the dots.

Correct example:

.dm4\.datetime\.month {
    color: #f00;
}

See ​http://www.w3.org/TR/CSS21/syndata.html#characters

Thanks!

[Jörg Richter <jri@…>]

In 8974548789a6e0f2cc3a4a473e6a17c605710808/deepamehta:

Webclient: revise PageModel? API (#929).

BREAKING CHANGES

2 dm4c.render.page_model methods are changed:

dm4c.render.page_model.render_page_model(page_model, render_mode, level, ref_element, incremental)
                                    ->  (page_model, parent_element, render_mode, level)

The incremental parameter is dropped.
The rendering is always appended to parent_element.

dm4c.render.page_model.render_box(page_model, ref_element, render_mode, level, incremental, is_removable)
                             ->  (page_model, parent_element, render_mode, level, is_removable)

The incremental parameter is dropped.
The rendering is always appended to parent_element.

See #929.

[Jörg Richter <jri@…>]

In f9689efb551f4f16cccc7d50160a6a3444a4b67c/deepamehta:

Webclient: refactor PageModel? types (#929).

A 4th page model type is introduced:

dm4c.render.page_model.type.RELATED_TOPIC

Formerly this was handled as a special form of a COMPOSITE page model.

A RELATED_TOPIC page model combines a topic page model and a Relating Association page model.

See #929.

[Jörg Richter <jri@…>]

In 8a474e862232055c3fbc9d377760ec8e18ad9355/deepamehta:

Webclient: semantic markup in detail panel (#929).

Divs that represent a simple or composite topic are attributed (via class) with the type URI.

So, to style e.g. the Month field (defined in Datetime module):

.dm4\.datetime\.month {
    float: left;
}

Note that dots within type URI must be escaped with backslash.
Thanks to Malte for pointing out!

See #929.

[Jörg Richter <jri@…>]

In 5e08c3abcac89f51b8b5717a43c014f4d024d563/deepamehta:

Date/Time? detail panel layout (#901).

In the detail panel the Month/Day/Year? fields as well as the Hour/Minute? fields are respectively layouted in a row (instead of on top of each other). Applies to both, info mode and form mode.

This gives a much more pleasant user experience, in particular e.g. for Event topics (part of the Events module) which employ a lot of date/time information.

The layout is defined solely via CSS (see #929).

Example for the Month/Day/Year? fields:

/* === Date === */

.dm4\.datetime\.month,
.dm4\.datetime\.day,
.dm4\.datetime\.year {
    display: inline-block;
}

.dm4\.datetime\.day,
.dm4\.datetime\.year {
    margin-top: 0 !important;
    margin-left: 1em;
}

/* Form */

.dm4\.datetime\.month input,
.dm4\.datetime\.day   input {
    width: 2em !important;
}

.dm4\.datetime\.year input {
    width: 3em !important;
}

See #901.

[jri]

Replying to Jörg Richter <jri@…>:

Divs that represent a simple or composite topic are attributed (via class) with the type URI.

If a div represents a child topic and if the underlying definition involves a Custom Association Type then the div should be attributed additionally with the Assoc Def URI. Thus child topics of the same type could be distinguished and styled individually, e.g. the Event's From and To Datetime fields.

[Jörg Richter <jri@…>]

In edc4ff36b84eff21d1bdb1bffe1f2dc595dc955c/deepamehta:

Add AssocDefUris? to detail panel markup (#929).

If a div represents a child topic and if the underlying assoc def involves a Custom Association Type then the div is attributed additionally with the Assoc Def URI.

Example (generated markup for an Event, extract):

...

...

Note that both divs are still attributed with the generic dm4.datetime class.

Thus your styles can provide both:

• a generic Datetime style (e.g. attach a Calendar icon by using CSS ::before).
• individual styles for the From/To? fields, e.g. attaching "From"/"To" labels respectively.

The CSS rules for the latter would look like this:

div.dm4\.events\.event > div.dm4\.datetime\#dm4\.events\.from::before {
    content: "From";
    ...
}

div.dm4\.events\.event > div.dm4\.datetime\#dm4\.events\.to::before {
    content: "To";
    ...
}

See #929.

[jri]

The generated markup looks like this:

<div class="box level1 topic dm4.datetime dm4.datetime#dm4.events.from">
    ...
</div>
<div class="box level1 topic dm4.datetime dm4.datetime#dm4.events.to">
    ...
</div>