Edgewall Software
Modify

Opened 9 years ago

Closed 6 years ago

Last modified 4 years ago

#8866 closed defect (fixed)

Admin pages messed up with browsers other than IE

Reported by: jouvin@… Owned by: Remy Blank
Priority: high Milestone: 1.0
Component: admin/web Version: none
Severity: normal Keywords: layout css
Cc: itamarost@…
Release Notes:

Improved the layout of admin pages.

API Changes:

Description

Hi,

I upgraded to recent trunk revision (8858, then 8872). In these versions, admin page layout is completely messed up when using a browser other than IE. This is the case for example for Ticket→milestones, and General→permissions: the area to enter new information overlap the list of existing entries.

Attachments (9)

milestone-admin-r8881.png (17.7 KB ) - added by Christian Boos 9 years ago.
defaults and tickets column are missing; browser is IE8
Admin-Permission-Opera.PNG (42.3 KB ) - added by jouvin@… 9 years ago.
Screen capture of messed up display with Opera 10
firefox-permissions.png (136.2 KB ) - added by Remy Blank 9 years ago.
Permissions panel with Firefox
test.html (609 bytes ) - added by Carsten Klein <carsten.klein@…> 9 years ago.
sample html and css for the new layout
perm-admin-firefox-3.6.10-1366x768.png (34.4 KB ) - added by Itamar Ostricher 8 years ago.
Permission admin overlap with Firefox 3.6.10 on 1366x768 screen
milestones-truncated.png (32.9 KB ) - added by Christian Boos 6 years ago.
milestones admin panel at r11154, screen width of 1237px
plugins-truncated.png (56.2 KB ) - added by Christian Boos 6 years ago.
plugins admin panel at r11154, screen width of 1603px
8866-addnew-top-r11161.patch (1.0 KB ) - added by Remy Blank 6 years ago.
Quick and dirty prototype implementing comment:40.
8866-addnew-top-r11163.patch (14.2 KB ) - added by Remy Blank 6 years ago.
Proper implementation of .addnew panels at the top

Download all attachments as: .zip

Change History (64)

Changed 9 years ago by Christian Boos

Attachment: milestone-admin-r8881.png added

defaults and tickets column are missing; browser is IE8

comment:1 Changed 9 years ago by Christian Boos

Confirmed, this is not really optimal for narrow screens.

comment:2 Changed 9 years ago by jouvin@…

I should have said I did all my test on a screen 1280x800. I tested IE8, Firefox, Opera and Chrome. It works properly only in IE8.

Michel

comment:3 Changed 9 years ago by Remy Blank

You should have a scrollbar at the bottom of the table that allows seeing the hidden portions of the table. While not ideal, it's better than what we had before, namely that the "new item" boxes were overlapping the table transparently, with no way to access the overlapping part. The new behavior was introduced in [8246] on 0.11-stable.

The screenshot shows a very narrow view, about 500px. This is not a narrow screen, it's a very narrow screen ;-)

Anyway, better ideas welcome.

Changed 9 years ago by jouvin@…

Attachment: Admin-Permission-Opera.PNG added

Screen capture of messed up display with Opera 10

comment:4 in reply to:  3 Changed 9 years ago by anonymous

Replying to rblank:

You should have a scrollbar at the bottom of the table that allows seeing the hidden portions of the table. While not ideal, it's better than what we had before, namely that the "new item" boxes were overlapping the table transparently, with no way to access the overlapping part. The new behavior was introduced in [8246] on 0.11-stable.

It seems I'm still getting what you call "old behaviour" (it was working fine in fact with r7799, the last revision I used before upgrading to r8858), as you can see in the screen shot. It was made with Opera but I get exactly the same result with Firefox and Chrome. Only IE8 works for me.

Changed 9 years ago by Remy Blank

Attachment: firefox-permissions.png added

Permissions panel with Firefox

comment:5 Changed 9 years ago by Remy Blank

That's weird, I have the correct behavior here with Firefox 3.0.14 and r8872 (see attachment:firefox-permissions.png) and Opera 10.10.

The changes were done to the stylesheets. Could it be that your browsers still cache the old stylesheet? Try a Shift+reload or emptying the cache to make sure. Also, do you have any custom stylesheets in your environment?

comment:6 Changed 9 years ago by Christian Boos

Also, if you have done a trac-admin ... deploy ... and used htdocs_location, you need to re-deploy again (we should make TracUpgrade more explicit about the need to do that after every upgrade).

comment:7 Changed 9 years ago by jouvin@…

I never used trac-admin deploy and htdocs_location is blank in my trac.ini. So I don't think this is the pb here. Nevertheless I tried a deploy and defining htdocs_location to the resulting directory and I lost my css… I never had such a pb so far so I am not sure this is the reason.

Clearing the browser cache doesn't help too…

comment:8 Changed 9 years ago by jouvin@…

More on the original issue…

I identified that this is a conflict with the project-specific CSS I use to define formatting of headings… The pb happens with all projects with such a CSS defined. It doesn't happen for one project where the CSS (for some unknown reason…) is ignored since the project was created (a while ago).

Still diging…

comment:9 Changed 9 years ago by anonymous

I identified the culprit in my poject-specific css (that I use for many years…):

h1 {

margin-top: 1em;

}

Removing margin-top attribute restores the normal behaviour… I still have to find the reason and why it is working properly with IE8 (it seems that for some attributes IE is not implementing inheritance where other browsers do, I don't know if this may be the cause…).

comment:10 Changed 9 years ago by jouvin@…

Here is the end of the story… It really seems that browsers (except IE) have a problem to correctly size the "revokeform" from (in the middle) if the top marging of the h1 and h2 (both displayed at the top of the page) are not identical. The workaround I implemented is to add to my project-specific CSS:

.admin h1 { margin-top: 0; }

Probably, the easiest would be to put it in the standard admin.css to ensure that whatever is defined by default for h1 margin-top, this doesn't affect how the admin pages are displayed.

comment:11 Changed 9 years ago by Michel Jouvin <jouvin@…>

Priority: normalhigh
Severity: majortrivial

Is it possible to get the proposed patch merged into the trunk or explicitly rejected?

--- lib/python2.4/site-packages/Trac-0.12dev_r8912-py2.4.egg/trac/htdocs/css/admin.css.r8912    2009-12-16 08:45:00.000000000 +0100
+++ lib/python2.4/site-packages/Trac-0.12dev_r8912-py2.4.egg/trac/htdocs/css/admin.css  2009-12-16 08:42:54.000000000 +0100
@@ -1,3 +1,9 @@
+/*
+ Patch proposed by Michel Jouvin <jouvin@lal.in2p3.fr> to fix a potential
+ problem with all browsers. See ticket #8866.
+*/
+.admin h1 { margin-top: 0; }
+
 #content.admin h1 { float: left; }
 
 #tabs { background: #f7f7f0; border: 1px solid black;

comment:12 Changed 9 years ago by Christian Boos

Keywords: layout css added
Severity: trivialnormal

I think the change proposed in the patch doesn't harm but I haven't tested it yet. We keep an eye on it and I (or Remy) will later integrate it or not, depending on our testing.

The more general issue about this ticket is that we need to find a general way to make the admin panels work well on narrow windows. I'd like to see something like this:

+---+ +----------------+ +-----+
|idx| | table          | |add  |
|   | |                | |panel|
|   | |                | +-----+
|   | |                |
+---+ |                |
      |                |
      +----------------+

on wide windows (as it is now), and:

+---+            +-----+
|idx|            |add  |
|   |            |panel|
|   |            +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

for narrow windows, but the CSS for this is not trivial (or I wasn't able to find the correct pick yet).

comment:13 Changed 9 years ago by Michel Jouvin <jouvin@…>

I understand your point for the final goal but I think it should not prevent to integration of the proposed change at least as a temporary step as the current CSS just doesn't work if you have defined a margin-top in your project-specific CSS. IMO there is nothing wrong in doing that and you should expect not to break anything. Trac core CSS should protect themselves against side effect of site modifications.

Because the current CSS is in fact unusable, I raised the priority to high… and I think it is really! Fixing this particular issue should not prevent further refactoring along the lines you said (but I am not completely sure it's doable on the basis of my CSS expertise, limited I must admit). Even if you succeed implementing what you propose, you'll have to get working properly in the context that was the source of this ticket!

comment:14 Changed 9 years ago by Michel Jouvin <jouvin@…>

A comment on my proposed patch. I think that to fully address the problem with all browsers (except IE8) when h1 and h2 margin-top are inconsistent, the patch should define both to a consistent default value (0) that can be modified anyway by the site later on. Thus my proposed patch is:

+/*
+ Patch proposed by Michel Jouvin <jouvin@lal.in2p3.fr> to fix a potential
+ problem with all browsers. See ticket #8866.
+*/
+.admin h1 { margin-top: 0; }
+.admin h2 { margin-top: 0; }
+
 #content.admin h1 { float: left; }
 
 #tabs { background: #f7f7f0; border: 1px solid black;
@@ -20,7 +27,7 @@
 }
 
 #tabcontent { padding: 0.4em 0 0.4em 2em; margin-left: 12em; min-height: 300px; }
-#tabcontent h2 { color: #333; margin-top: 0; }
+#tabcontent h2 { color: #333; }
 #tabcontent form { overflow: auto; padding: 0 1px; }
 p.help { color: #666; font-size: 90%; margin: 1em .5em .5em; }
 

Not that the current definition for h2 in fact works because the first h2 used in the context of #tabcontent but IMO may be a source of future problem in case some h2 appears before #tabcontent.

comment:15 in reply to:  12 ; Changed 9 years ago by Michel Jouvin <jouvin@…>

Replying to cboos:

The more general issue about this ticket is that we need to find a general way to make the admin panels work well on narrow windows. I'd like to see something like this (on narrow windows):

+---+            +-----+
|idx|            |add  |
|   |            |panel|
|   |            +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

In fact, about the proposal for narrow windows, I'd suggest this small variation when there are several add panels (like for permissions) if it fits:

+---+    +-----+ +-----+
|idx|    |add  | |add  |
|   |    |panel| |panel|
|   |    +-----+ +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

comment:16 in reply to:  15 Changed 9 years ago by Remy Blank

Replying to Michel Jouvin <jouvin@…>:

In fact, about the proposal for narrow windows, I'd suggest this small variation when there are several add panels (like for permissions) if it fits:

I'd be very interested in seeing how this can be achieved using HTML and CSS alone (i.e. having panels on the side if the table fits, on the top if it doesn't).

comment:17 Changed 9 years ago by Remy Blank

Owner: set to Remy Blank

I'll try to reproduce and fix the initial issue, but this shouldn't block 0.12.

comment:18 Changed 9 years ago by Remy Blank

Milestone: 0.120.12.1

(Forgot to change the milestone)

Changed 9 years ago by Carsten Klein <carsten.klein@…>

Attachment: test.html added

sample html and css for the new layout

comment:19 Changed 9 years ago by Carsten Klein <carsten.klein@…>

see the attached sample html + css for a semi-working layout

please note that the order of .admin-panel and .panel and .tab-content is important, otherwise .panel will float below .tab-content

comment:20 Changed 9 years ago by Carsten Klein <carsten.klein@…>

the problem is though, that it will not render the two .panels below each other when there is enough space for all three (.admin-panel, .tabcontent and .panel) to be rendered side by side. perhaps you will find a solution to this.

comment:21 Changed 9 years ago by Carsten Klein <carsten.klein@…>

i think we should stick with float:left for all inside #content so that even on small displays the content does not overlap and layouts adaptively.

however, as of now, at least 800x600 should be possible on so-called netbooks.

resolutions below that should cope with what is available, IMO.

but remove the fixed size on #content unless reestablished by a user provided site.html and associated css.

comment:22 Changed 9 years ago by Christian Boos

See also #9225 screenshots for a reminder of the old buggy behavior in 0.11.

comment:23 Changed 8 years ago by Mikael Relbe

I've seen the symptom demonstrated in attachment:snapshot_git_trac_problem.jpg:ticket:9225

In my case, I resolved the problem by shrinking the size of the font of the "Administration" header so that its width didn't exceed the width of the left panel beneath it — that trick made the whole page render fine. (As I remember this, this was browser-indendepent, i.e. same result in any browser before and after the "fix".)

Perhaps a clue to the root cause?

comment:24 in reply to:  23 Changed 8 years ago by Carsten Klein <carsten.klein@…>

Replying to mrelbe:

Perhaps a clue to the root cause?

fixed size on #content and inner elements exceeding that size causing it to overflow?

comment:25 Changed 8 years ago by Remy Blank

Milestone: 0.12.1next-major-0.1X

Postponing until a patch implementing better behavior for the side panels is proposed.

Changed 8 years ago by Itamar Ostricher

Permission admin overlap with Firefox 3.6.10 on 1366x768 screen

comment:26 Changed 8 years ago by Itamar Ostricher

Cc: itamarost@… added

Just wanted to note that I get the overlapping behavior with Firefox 3.6.10 on a 1366x768 screen (see screenshot (using the t.e.o site.html and css).

Maybe I can get someone who knows his ways with CSS to take a look at it…

comment:27 Changed 8 years ago by Itamar Ostricher

Also interesting to note that when I view the attachment I've added, the adsense-bar on the right floats above (and hides) the part of the image that extends beyond the content-boundary.

comment:28 in reply to:  26 Changed 8 years ago by Michel Jouvin <jouvin@…>

Replying to itamaro:

Just wanted to note that I get the overlapping behavior with Firefox 3.6.10 on a 1366x768 screen (see screenshot (using the t.e.o site.html and css).

Maybe I can get someone who knows his ways with CSS to take a look at it…

This is clearly the problem caused by the margin inconsistencies described in my previous comment. Have you tried the workaround proposed in #comment14 ?

comment:29 Changed 8 years ago by Michel Jouvin <jouvin@…>

I tried to answer #comment25 but my answer is considered as SPAM… I'll try to put it in an attachment…

comment:30 in reply to:  29 Changed 8 years ago by Michel Jouvin <jouvin@…>

Replying to Michel Jouvin <jouvin@…>:

I tried to answer #comment25 but my answer is considered as SPAM… I'll try to put it in an attachment…

I really don't understand why the workaround I proposed has not been integrated into 0.12 until a definitive fix is available solving all known issues… As shown by previous replies, the current problem caused by different margin-top for h1 and h2 makes some admin panels unusable and this has nothing to do with the window/screen size. I think the proposed workaround should have a side effect close to 0 and a site really wanting a non zero margin-top will still be able to implement it in a site CSS. At least, the 0 margin should not prevent admin panels to be usable…

comment:31 Changed 8 years ago by Christian Boos

Milestone: next-major-0.1X0.12.2

Sure, we can reconsider this.

comment:32 Changed 8 years ago by Remy Blank

Resolution: fixed
Status: newclosed

Patch from comment:25 verified and applied in [10369]. I'm closing this ticket, as the initial issue is fixed. For layout improvements, please open a new ticket.

comment:33 Changed 8 years ago by Remy Blank

Owner: changed from Remy Blank to Michel Jouvin <jouvin@…>

comment:34 in reply to:  15 ; Changed 6 years ago by Christian Boos

Milestone: 0.12.2next-stable-1.0.x
Resolution: fixed
Status: closedreopened

I'd like to revisit this issue (which is still not satisfyingly solved), by adopting the following layout:

Replying to Michel Jouvin <jouvin@…>:

Replying to cboos:

The more general issue about this ticket is that we need to find a general way to make the admin panels work well on narrow windows. I'd like to see something like this (on narrow windows):

+---+            +-----+
|idx|            |add  |
|   |            |panel|
|   |            +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

In fact, about the proposal for narrow windows, I'd suggest this small variation when there are several add panels (like for permissions) if it fits:

+---+    +-----+ +-----+
|idx|    |add  | |add  |
|   |    |panel| |panel|
|   |    +-----+ +-----+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

See repos:cboos.git:ticket8866/take2 (visible in action in demo-0.13 for those having admin rights there).

It's not 100% finalized, as there's still some overlap between the two .addnew panels in the permission panel, but I'll eventually get there.

comment:35 in reply to:  34 ; Changed 6 years ago by Christian Boos

Replying to cboos:

… there's still some overlap between the two .addnew panels in the permission panel

I found a way to fix the overlap problem, see rebased and completed branch repos:cboos.git:ticket8866/take2-r11150.

I'd like to get this in 1.0, so feedback welcome.

comment:36 in reply to:  35 ; Changed 6 years ago by Christian Boos

Milestone: next-stable-1.0.x1.0

Replying to cboos:

I found a way to fix the overlap problem, see rebased and completed branch repos:cboos.git:ticket8866/take2-r11150.

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

comment:37 in reply to:  36 ; Changed 6 years ago by Remy Blank

Replying to cboos:

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

That is… not me :( Ok, fixed now.

I'm afraid I don't like the new layout. Most of the admin pages have only a single "Add…" panel, and therefore have a large block of white space above the table, and the interesting data is pushed down unnecessarily. Moreover, on "normal" screens, the table becomes overly wide, which is not useful for most admin pages (i.e. all ticket admin pages).

It would be fine if the new layout appeared for narrow screens only, and the old layout remained when the table fits next to the panels, but AFAIK this kind of re-flow isn't possible with CSS alone. So we're basically optimizing for the rare case (narrow screen) while making the common case less functional and not so good-looking (IMO, of course).

I would prefer keeping the current layout.

(OT, while I see it: are you very attached to the text shadows on buttons? I find they make the text fuzzy and less readable. But if you prefer keeping them, I'll remove them locally here.)

comment:38 in reply to:  37 Changed 6 years ago by Christian Boos

Replying to rblank:

Replying to cboos:

Now visible on demo-0.13 (for people who have TRAC_ADMIN there, of course).

That is… not me :( Ok, fixed now.

I'm afraid I don't like the new layout. Most of the admin pages have only a single "Add…" panel, and therefore have a large block of white space above the table, and the interesting data is pushed down unnecessarily.

It's not unnecessarily, the very purpose to push the data down is to fix the issue raised in this ticket, i.e. the truncation of the content of the table due to the presence of (even one) .addnew float on the right. This is still a serious problem I think:

Not exactly narrow, even if you take out the grey borders specific to t.e.o.

Now I agree that for the other panels like the ticket enums, the whitespace at the top is probably too big.

An alternative would be to place the .addnew below the table, it would also fix the issue and avoid pushing the table down.

Moreover, on "normal" screens, the table becomes overly wide, which is not useful for most admin pages (i.e. all ticket admin pages).

I suppose this can be fixed… and maybe the .addnew panel would just move up when there's some space left. I'll try harder.

It would be fine if the new layout appeared for narrow screens only, and the old layout remained when the table fits next to the panels, but AFAIK this kind of re-flow isn't possible with CSS alone. So we're basically optimizing for the rare case (narrow screen) while making the common case less functional and not so good-looking (IMO, of course).

(OT, while I see it: are you very attached to the text shadows on buttons? I find they make the text fuzzy and less readable. But if you prefer keeping them, I'll remove them locally here.)

Well, yes I like them. For me, the text is not fuzzy but looking between normal and bold (if you have a screenshot I'm interested; maybe it only looks good for me on Windows ;-) ).

Changed 6 years ago by Christian Boos

Attachment: milestones-truncated.png added

milestones admin panel at r11154, screen width of 1237px

Changed 6 years ago by Christian Boos

Attachment: plugins-truncated.png added

plugins admin panel at r11154, screen width of 1603px

comment:39 Changed 6 years ago by Remy Blank

Never mind, then. But please, whatever solution you end up keeping, please allow reverting it with CSS only. It should not be necessary to write a Genshi template (and therefore lose in performance) if I choose readability over fanciness.

comment:40 Changed 6 years ago by Remy Blank

Wait, here's a different idea. How about making the "add panels" more rectangular than square? This would allow a layout like the following:

+---+ +----------------+
|idx| +add panel       |
|   | +----------------+
|   | +----------------+
|   | +add panel       |
|   | +----------------+
|   | +----------------+
+---+ | table          |
      |                |
      |                |
      |                |
      |                |
      |                |
      +----------------+

It would require putting edit files and possibly labels on the same line, for example:

+- Add component ----------------------------------------+
+ Name: |_____________|  Owner: |_____________|  | Add | |
+--------------------------------------------------------+

This would make better user of the available space, and scale better when the number of panels increases (not that we expect much more than 2-3, but still). And yeah, no big white empty space :)

comment:41 Changed 6 years ago by Christian Boos

I experimented a bit further and managed to get the "usual" layout when the window is wide enough, and the "stacked" layout otherwise. In the latter situation, we don't have that much whitespace left, as it happens only for narrow window widths.

There are still a few issues left, described in the commit log:

I'm not sure yet why there's such a difference between Chrome/Safari and the other browsers and if I'll be able to "fix" it for them.

Changed 6 years ago by Remy Blank

Quick and dirty prototype implementing comment:40.

comment:42 Changed 6 years ago by Remy Blank

8866-addnew-top-r11161.patch demonstrates what I meant in comment:40. It's implemented as a quick hack, for testing the ticket admin pages, but the same effect can be applied in the other panels. What I especially like is the straightforward layout, the available space is used well, and there's no "magic" jumping around on resize

I just wanted to get some feedback before implementing (or not) the whole thing cleanly. In particular, I'll need to reorganize some elements in the plugins and permissions panels, and I will create a class separate from .addnew for the new layout to avoid breaking plugins that use the old layout (e.g. AccountManagerPlugin).

Thoughts?

comment:43 in reply to:  42 ; Changed 6 years ago by Christian Boos

Replying to rblank:

8866-addnew-top-r11161.patch demonstrates what I meant in comment:40. It's implemented as a quick hack, for testing the ticket admin pages, but the same effect can be applied in the other panels. What I especially like is the straightforward layout, the available space is used well, and there's no "magic" jumping around on resize

Yes, this looks indeed better than I thought. I think we should dig further in this direction, as I didn't get any insight about why the behavior of my approach is so broken with non-WebKit browsers. Even there we have the "jump" effect, which is probably not optimal.

I just wanted to get some feedback before implementing (or not) the whole thing cleanly.

We'll need to structure the fieldsets a bit more, because a mere display: inline is not really good: depending on the width, you can end up with, e.g.

Name: __________________ Due:
_____________________  Format: MMM d, yyyy h:mm:ss a 
[Add]

We need to make sure the label and its input field always stay on the same line.

In particular, I'll need to reorganize some elements in the plugins and permissions panels, and I will create a class separate from .addnew for the new layout to avoid breaking plugins that use the old layout (e.g. AccountManagerPlugin).

It depends… if the new style could just fit on the existing .addnew panels provided by plugins, that would be better. So maybe do that rename step last, so that we can play around with the plugins first.

comment:44 in reply to:  43 Changed 6 years ago by Remy Blank

Replying to cboos:

We'll need to structure the fieldsets a bit more, because a mere display: inline is not really good

Sure, as I said it was only a quick hack to show what I meant.

We need to make sure the label and its input field always stay on the same line.

Yes, that's fairly easy to achieve, especially when the <input> is nested in the <label>.

It depends… if the new style could just fit on the existing .addnew panels provided by plugins, that would be better. So maybe do that rename step last, so that we can play around with the plugins first.

I'll try. I thought that AccountManagerPlugin used tables in the "Add …" panels, but that's actually wrong, so it may just work. The plugins and permissions pages will require structural changes, but there it doesn't matter because they use different classes and it's unlikely that a plugin used them.

Changed 6 years ago by Remy Blank

Proper implementation of .addnew panels at the top

comment:45 Changed 6 years ago by Remy Blank

This turned out pretty well, I think. 8866-addnew-top-r11163.patch implements the ".addnew panels at the top" variant properly. Field labels and hints are kept with the field when wrapping, and all admin panels look good in all browsers (even IE7, I stole your trick for display: inline-block). Even AccountManagerPlugin looks good, although it could look even slightly better if it moved the help text after the button, as I did for our panels. I left a rule to set <br/> to display: none even though I removed the tags, in the hope that it will make plugins using the .addnew class look better.

Thoughts?

comment:46 Changed 6 years ago by Christian Boos

Great! I like it.

I'd perhaps just add:

  • trac/htdocs/css/admin.css

    diff --git a/trac/htdocs/css/admin.css b/trac/htdocs/css/admin.css
    index 3da6757..fa7be83 100644
    a b form.addnew div.buttons {  
    6060 padding: 0.2em 0.5em 0.2em 0;
    6161 white-space: nowrap;
    6262}
     63form.addnew div.buttons { float:right; }
    6364form.addnew div.buttons input { margin: 0 0.5em 0 0; }
    6465form.addnew p.hint,
    6566form.addnew span.hint {

comment:47 in reply to:  46 Changed 6 years ago by Remy Blank

Release Notes: modified (diff)
Resolution: fixed
Status: reopenedclosed

Replying to cboos:

I'd perhaps just add:

Mmh… That makes the forms with few controls (e.g. "Priorities") look weird on a wide screen, with the input at the far left and the button at the far right. Also, we tend to have buttons left-aligned (this page, the wiki, milestones, etc.). So I'd rather do without.

Patch committed in [11164].

That was the last open ticket for 1.0 (except for the translation stuff). How about releasing 1.0beta1 this week-end?

comment:48 Changed 6 years ago by Remy Blank

Owner: changed from Michel Jouvin <jouvin@…> to Remy Blank

comment:49 Changed 6 years ago by Jun Omae

When the button in .addnew panels is pushed, the layout is disarranged by the margins for the button. The style is from .buttons input[type=submit]:active.

[1786a767/jomae.git] for the issue.

comment:50 Changed 6 years ago by Christian Boos

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

comment:51 Changed 6 years ago by Remy Blank

Heh, funny effect :)

comment:52 in reply to:  50 ; Changed 6 years ago by Jun Omae

Replying to cboos:

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

[14f0d06a/jomae.git] uses position: relative. I confirmed with IE 7-8, Firefox 14, Chrome 21 beta and Opera 12.

I think it would be simple and a small impact on other forms (e.g. is provided by plugins) than adjusting the button margins.

comment:53 in reply to:  52 Changed 6 years ago by Christian Boos

Replying to jomae:

Replying to cboos:

Good catch! However I also had the idea to revisit how this particular effect was achieved, using position: relative perhaps (nothing concrete yet).

[14f0d06a/jomae.git] uses position: relative. I confirmed with IE 7-8, Firefox 14, Chrome 21 beta and Opera 12.

I think it would be simple and a small impact on other forms (e.g. is provided by plugins) than adjusting the button margins.

Yes, perfect! Please commit.

comment:54 Changed 6 years ago by Jun Omae

Applied in [11195]. Thanks.

comment:55 Changed 4 years ago by Ryan J Ollos

In [12952], removed CSS rule that is unused after [11164]. Merged in [12953].

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Remy Blank.
The resolution will be deleted.
to The owner will be changed from Remy Blank to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.