I notice that there's a lot of padding below the radio buttons in the new images compared to the old ones. It looks a little excessive to me. Is that deliberate, or a bug in whatever layout you're using to generate the screenshots?
This is somewhat confusingly worded, since the title is "Labels on the left" but the text says "it is recomended to place the lables to the right".
Same: we're overloading the word "label", which is confusing.
"whitespace" was fine, I think.
"resizeable" was fine IMHO, and "resize able" is just wrong. :)
I think "titlebar" is a technical term here, so it doesn't need the space in the middle.
"Kirigami and Plasma's"
"smallspacing and largespacing from Kirigami or Plasma"
"when ever" -> "whenever"
No need to capitalize "Multiples"
"mock ups" -> "mockups"
"multiple" -> "multiples"
"gridUnit, you wont" -> "gridUnit, and you won't"
"re sizable" -> "resizable"
"scroll able" -> "scrollable"
How about this?
"The labels that are to the left of their connected widgets should be right-aligned. This makes the whole group of form widgets appear to be center-aligned."
Let's not use the term "group box" here, as that could seem to imply that we're advocating the use of group boxes, which I believe we're trying to move away from.
To me the content on the page is too much focused on form layout anyways. These should be more general guidelines for spacings and paddings. So I would rather not change that here, but in a next step add more general examples to the page and probably create a content pattern for forms.
Text looks good to me now. However I'm noticing that in the new images, there's an unequal amount of bedding on the two sides of the radio buttons and checkboxes: the label on the left is much closer than the label on the right.
I think because we're trying to move towards separating groups of controls using whitespace and horizontal lines instead of group boxes.
I worry that such a guideline could result in undesirable visual inconsistency on single page, with some using a label on the left, and others having a label on top. We're trying in general to move away from labels that are trying to be paragraphs. :)
But that's exactly what this sentence is suggesting: "use a 16px spacer to separate group of related options".
I'm not saying we should also add a screenshot. This is the place where we add "exceptions", right? Given that sometimes you cannot reduce the length of the label (see again the screenshot above), I think it's important we clarify what we should do in such cases.
The guideline--sans group box recommendation--was moved to a different part of the document, onto line 106.
IMHO, it's almost always possible to reduce the length of the label. If it's not because the concept is rather complicated, then it would be better to express the information in another way, such as with a short label for the control itself, and an extended explanation label beneath it. Gwenview's Advanced Settings page does this, as an example.
This is looking good from my perspective, FWIW!
"check box" -> "checkbox"
"that will" -> "which will"
"Keep track on label length" -> "Minimize label length"
"checkbox> see" -> "checkbox>, see"
"units as" -> "units such as"
"largeSpacing" -> "and largeSpacing"
"that will" -> "which will"
- Fixed typos and improved wording from phab feedback
As Nate said, the guidelines is not removed, but it is moved to a more appropriate page. Since this page is only about alignment, I moved it to "Metrics, placement & keylines" which has a lot of rules about spacing and paddings.
The HIG pages for check boxes https://hig.kde.org/components/checkbox.html has a rule, that could extend to cover these cases:
I'm noticing while implementing T9036 that 12px of whitespace space between sections feels too cramped, and the sections still kind of blended into one another. I tried with 18px and IMHO it looked vastly better:
If others agree, I might say that we should consider recommending 18px instead of 12px for spacers.