Re: Thoughts on GTK+ and CSS

[Keith Rarick <kr xph us>]

On Sun, Jul 26, 2009 at 11:41 PM, Robert
Staudinger<robert staudinger gmail com> wrote:
> The limitation regarding pseudo elements is not that we aren't aware
> of their existence, but that libcroco doesn't support them at this
> point.

Gotcha. I wonder if libcroco would accept a patch implementing that.
I'll ask on libcroco-list.

>> This also plays nicely with pseudo-class selectors:
>>
>> GtkNotebook::tab:foreground {
>>  font-weight: bold;
>> }
>
> What is ":foreground" supposed to mean?

Maybe I should have spelled it ":selected". In this case I intended it
to mean the tab that is in the foreground and whose contents are
visible. Is it "the selected tab"? I don't know the proper
terminology.

I just wanted a suggestive example; I didn't mean to presume any
existing functionality.

>> ## Mapping Properties into CSS
>>
>> To some extent, GTK _properties_ could be mapped into CSS just at XML
>> _attributes_ are.
>
> This is already implemented.

Wonderful! It seems I am very under-informed. I will look through the
source code.

> Rather
> than aiming to invent vocabulary for vague descriptions we should aim
> to
>  (1) Consistently apply system-wide base styling, e.g. GtkButton.
>  (2) Specifically refine the styling where needed, e.g. pick
>      prev/next/pause buttons by their stock ID.

What you describe addresses the separation of semantic structure from
presentation, but that approach is far more powerful if the semantic
information is sufficiently rich and sufficiently general. Currently,
writing a gtk theme feels like styling an html document made of
nothing but div and span and some id attributes. I want it to feel
like styling p, h1, nav, section, article, dl, blockquote, etc, with
lots of useful classes too. Picking a next button by stock ID is too
specific.

For example, what if an app has a new group of related buttons, say
"local view" and "remote view", not accounted for by existing themes
that only pick buttons by their stock ID? There is no way to get the
proper look for that group of buttons.

Furthermore, how would a theme distinguish a solitary next button from
one that is part of a prev/pause/next group? A theme might
legitimately want those two next buttons to look different, but I
don't see how it can be achieved reliably.

Perhaps a "hints" property is flawed in detail, but I think the idea
is sound. I advocate denoting *well-defined* but *generic* semantic
structure.

Here is roughly the reasoning I used for the "related" hint:

 * A theme might want to display prev/pause/next buttons in a visually
distinct group.
 * A theme might also do that with icon/list/compact view buttons or
back/forward buttons or some other as-yet-unknown set of buttons.
 * What semantic properties do all of those examples share?
 * They are all groups of buttons somehow related to one another in a
meaningful way.
 * This is a useful piece of information for themes.
 * Unfortunately, there is currently no way to express this information.
 * We should invent a way to denote this.

I had similar lines of reasoning for the other example hints I listed.
But maybe they should be handled on a case-by-case basis. Say, make up
a new property for each one. I didn't suggest that because I thought
it would have too much inertia. I want it to be easy for people to add
new semantic structural information to apps -- the more the better!

> The "margin" property in gtk is not implemented like you assume above.
> Also does GtkContainer not expose information about child widget
> positions like you suggest using ":first-child" and friends. Work on
> those limitations would break the way for more a more comprehensive
> mapping of css onto gtk.

Okay. I only meant that example to suggest what a theme could do in
principle, even if it uses features that don't exist yet.

Would you accept a patch with work toward those things, such as margin
or first-child?

kr