I made some changes.

The Syntax section was wrapped in a <pre>, don't know why, because it's actually a <ul> and that doesn't look good in <pre>. So I removed the <pre> and wrapped each list item text with <code> tags (new Template:WrapWithCodeTags) to keep the mono-spaced font.

Each Value is now a <dl> with <dt> and <dd>. The name was a <p> previously. The font-size of the name is now a bit bigger, though. Might be too big.

I guess we could try some other things or tweak the stylesheet.

Much better, thanx.

On a related note, the Syntax items are sorting differently than the Values items. The latter reflect the order in which they were authored.  I'd assume they'd alphabetize by default, but can think of many cases where custom sort order would be useful to explain the properties together.  I don't see any way in the UI to modify the sort order except for hacking on the full wiki source.

You are right that the Values items are ordered by creation. That order can be changed manually by dragging the arrow thingy right next to the remove button, in the edit form under Values.

Sorting the Syntax items in the same way (as authored) is a bit tricky. It should work as long as the list contains less than 10 items. The problem is, the Semantic Internal Objects get created with an internal name like this:
  css/properties/break-after#1  (auto)
  css/properties/break-after#2  (always)
  [...]
  css/properties/break-after#9  (avoid-column)
  css/properties/break-after#10 (region)
  css/properties/break-after#11 (avoid-region)

Unfortunately the Syntax items are retrieved using #ask, using the internal name for sorting (it gets passed as the mainlabel and is automatically a property of type Page). The names don't get sorted in natural order, but are compared as normal strings, thus it becomes #1 #10 #11 #2 etc.

My current thinking is to add some kind of index to the #set_internal call in  Template:CSS_Property_Value, which would become the 4th property of the internal object, that could be used for sorting in #ask (would be of type number ofc, so SMW uses numerical sort). I'm thinking a combination of #expr and Extension:Variables or some alternative.

I also had the Syntax list ordered alphabetically, but that seemed confusing, 2 lists with different order. Also, if the editor wants to sort the values alphabetically, he has to sort them manually (using the arrow thingy), there might be a way to include a "sort alphabetically" button in the edit form through some JS hackery, but I'm not really sure if that's feasable.

CC'ing Alex for this one (ideas? is there an easier way? should we go for the index?)

Jeez, I really don't know. I think the approach you outline in comment 3 would be how I would try to get it to work.

I just checked with Yaron Koren, creator of Semantic Forms.

Here's what he had to say:

-----

I assume you're talking about the issue where internal objects get sorted as strings, instead of numbers (there are a few different topics on that page). That's true, and someone else once complained about it before - and offered a solution; padding the number, so that it's "001", "002", etc. That way, the sorting problem doesn't come up until you have 1,000 items on the page. :) I didn't pay that much attention to the issue before, but it's true that it's annoying. So I'll make this change to the SIO code, and it'll go out in the next release. You can do this in your version of the code, too - in the file SemanticInternalObjects_body.php, just change line 42 from:

                return $this->mMainTitle->getDBkey() . '#' .  $this->mIndex;

to:

                return $this->mMainTitle->getDBkey() . '#' .  sprintf( '%03d', $this->mIndex );

Then, as soon as any page with that problem is re-saved, the problem should go away.

Awesome, thanks! Waiting for the update. :)