“If debugging is the process of removing bugs, then programming must be the process of putting them in.” – Edsger Dijkstra
This is the Bug Tracking System for the Flyspray project. This is not a demo! Before opening a new task, please read the guidelines!
Do not issue bugs reports against versions earlier than 0.9.9.5
Security problem? Check the security section.
FS#697 - "New task" and "Task details" pages have inconsistent taskfield CSS IDs
Opened by Jonathan Santaana (jsantaana) - Wednesday, 19 October 2005, 08:57 GMT+1
Last edited by Florian Schmitz (Floele) - Monday, 07 November 2005, 15:45 GMT+1
|
DetailsThe pages generated for submitting a new task and viewing the details of an existing task show the same detail fields, but identify some fields (drawn from the same database column) with different CSS IDs. This causes inconsistent results if the theme in use applies custom styling to one of the fields in question.
The “New task” page uses the following IDs: tasktype, productcategory, itemstatus, assignedto, operatingsystem, taskseverity, task_priority, productversion, closedbversion, due_date. Affected code is in details.php and newtask.php (potentially modify.php as well, but currently that seems to be consistent with details.php). No patch is currently included because I’m not sure which set of names should be considered “correct”; I’d favour the ones that remain consistent with the names used for localisation strings, but that means both are partially accurate. (On a related note, it’d be nice to have the same CSS IDs on the table rows that contain the fields and their labels. This would provide a convenient way of styling the field and label at the same time, and would be particularly useful to hide a field completely - currently you can’t hide the label just by tweaking the theme stylesheet. But that should probably be a separate bug with a separate patch.) This issue will certainly be affected by the release of 0.9.8, since the proposed templating system after that point will change the situation; in fact, it may become completely irrelevant. There’s no way to be sure until said templating system is finalised, though. |
Tuesday, 08 November 2005, 04:48 GMT+1
Reason for closing: Fixed in devel
One thing to watch out for with CSS IDs: They should be completely unique on the page you’re viewing. An element should never have the same ID as any other element. So unfortunately, putting the ID on the field and the containing element is not a possibility. But an ID could be used on the element, and a class on the field, or on the element as well.
You’re right about the templating... it may have a big effect here, depending how much change the html/css code has during the transition.