547389 - Ensure all <th> cells used as form control labels are tagged with the 'form-label' class

Status: RESOLVED WONTFIX

(Bugzilla :: User Interface, enhancement)

Description

[Gordon P. Hemsley [:GPHemsley]]

Bug 547171 and bug 547311 will be creating the 'form-label' class, to be used with <th>s inside <form>s to be used as labels for the following <td>s

This bug is to ensure that all <th>s that fall under that category (particularly those not otherwise differentiated) are tagged with the 'form-label' class. This will help create a more harmonious Bugzilla. :)

Comment 1

[Max Kanat-Alexander]

We already have a class called field_label for bug fields.

Comment 2

[Frédéric Buclin]

If *all* <th> inside <form> are concerned, why not have something like

form > th {...permanent rules...}

in global.css? This would be better than adding the class to all <th>. You would only add a class to those <th> which should not inherit this "permanent rules".

Comment 3

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #1)
> We already have a class called field_label for bug fields.

Indeed you do, and it does appear to have some things in common with this 'form-label' class, as well as some existing CSS. But it only shows up on the bug edit page, and it is only used on <td>s, not <th>s. So you have to determine how you want to go about this.

(In reply to comment #2)
> If *all* <th> inside <form> are concerned, why not have something like
> 
> form > th {...permanent rules...}
> 
> in global.css? This would be better than adding the class to all <th>. You
> would only add a class to those <th> which should not inherit this "permanent
> rules".

I don't want to make that assumption, since there's a chance there are some <th>-only rows or whatever else may pop up. And are you sure that that is supported by the legacy browsers you want to support?

Comment 4

[Max Kanat-Alexander]

(In reply to comment #3)
> Indeed you do, and it does appear to have some things in common with this
> 'form-label' class, as well as some existing CSS. But it only shows up on the
> bug edit page, and it is only used on <td>s, not <th>s. So you have to
> determine how you want to go about this.

  It's used on <td>s because that's what was there historically, but logically they're really <th>s. 

  field_label is logically the label for a bug field.

  If you want to use "form-label" as a class, I'd call it "form_label".

> (In reply to comment #2)
> > form > th {...permanent rules...}

  That rule wouldn't work anyway--a th is never a direct descendent of a form. :-)

> I don't want to make that assumption, since there's a chance there are some
> <th>-only rows or whatever else may pop up. And are you sure that that is
> supported by the legacy browsers you want to support?

  Here's a reasonable assumption:

  form th { text-align: right }
  form thead th { text-align: center }

  And then look through Bugzilla and see what that messes up.

Comment 5

[Guy Pyrzak]

side note i was hoping to remove many of the tables from our UI in favor of YUI's Grid css. The purpose of this was that it would allow skin developers to have more freedom about how the UI would look in other skins.

Comment 6

[Gordon P. Hemsley [:GPHemsley]]

(In reply to comment #5)
> side note i was hoping to remove many of the tables from our UI in favor of
> YUI's Grid css. The purpose of this was that it would allow skin developers to
> have more freedom about how the UI would look in other skins.

I'd recommend filing a new bug for that. Depending on how quickly you could get it done (and I've realized over the last few days how tedious a job it is to do a major overhaul of the Bugzilla templates), that might be worth waiting for.

Comment 7

[Guy Pyrzak]

Oh, yeah. There might even be one already I've just not hurried to write it since there are so many other usability issues.

Comment 8

[Guy Pyrzak]

To be clear my focus was going to be on the search, edit and create UI. Also it appears that there are 116 templates that have tables in them. So the task outlined in this bug seems somewhat overwhelming either way. So feel free to move forward without my patch.

Comment 9

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.

Comment 10

[Frédéric Buclin]

Bugzilla moved to HMTL5, and this bug is not needed.