The reset.css file used in the Seven theme resets <ul> and <li> formatting.
A list is presented on screen as ordinary text, not as a list.

[At least on Firefox/Mac & Safari/Mac]

See admin/help/block for an example.

I'm not sure where I can look at mockups/style guide to see how a list should be presented,
but it doesn't look right at the moment.

CommentFileSizeAuthor
#84 dashboard-lists.png40.63 KBmrfelton
#84 563390-seven-style-followup_2.patch7.74 KBmrfelton
#81 dashboard-different-bullet-style.png46.15 KBaspilicious
#80 content-style-fix.png23.45 KBaspilicious
#79 563390-seven-style-followup_1.patch7.14 KBmrfelton
#79 overlay-secondary-tabs-padding.png43.55 KBmrfelton
#78 ugly_border.png32.75 KBaspilicious
#77 secondary-tabs-border.png27.61 KBmrfelton
#77 secondary-tabs-noborder.png27.62 KBmrfelton
#75 double_border.png20.35 KBaspilicious
#74 563390-seven-style-followup.patch6.93 KBmrfelton
#73 563390-seven-style-followup.patch6.57 KBmrfelton
#65 formatting-lucidia.png202.67 KBmrfelton
#62 formatting.png207.46 KBmrfelton
#60 formatting-after.png254 bytesmrfelton
#56 563390-seven-style_8.patch7.5 KBmrfelton
#56 formatting-before.png171.75 KBmrfelton
#56 formatting-after.png179.56 KBmrfelton
#54 563390-seven-style_7.patch6.68 KBmrfelton
#52 563390-seven-style_6.patch2.71 KBmrfelton
#51 563390-seven-style_5.patch2.37 KBmrfelton
#42 563390-seven-style_4.patch2.3 KBmrfelton
#41 myfirebug.png19.08 KBjhodgdon
#31 help-text-formatting.png33.78 KBmrfelton
#30 translation-dl.png14.14 KBjhodgdon
#29 563390-seven-style_3.patch2.34 KBmrfelton
#27 operations-before.png5.54 KBmrfelton
#27 operations-after.png5.43 KBmrfelton
#26 563390-seven-style_2.patch2.5 KBbleen
#22 opsnotinline.png5.6 KBjhodgdon
#22 verttabs.PNG17.31 KBjhodgdon
#19 563390-seven-style.patch2.55 KBagentrickard
#17 screenshot_008.png28.88 KBbatigolix
#16 seven-style-css-3.patch1.34 KBbatigolix
#15 seven-style-css-2.patch1.29 KBbatigolix
#14 Screen shot 2009-11-21 at 13.20.36.png18.98 KBgargoyle
#11 seven-style-css.patch1.29 KBbleen
#9 seven-style-css.patch1.3 KBbatigolix
#5 nobullets.jpg24.79 KBjhodgdon
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

seutje’s picture

subscribe

alanburke’s picture

jhodgdon’s picture

Category: task » bug

This is not a task, it is a bug.

Several of the help screens are using UL lists, and they need some kind of list formatting/bullets.

jhodgdon’s picture

Priority: Normal » Critical
FileSize
24.79 KB

Actually, I think this is priority "critical" in the sense that I don't think we should ship Drupal without fixing this, as several of the core help screens are not really readable unless this is fixed. See attached screen shot, which is a UL list from the translation module help screen, but you can't tell because there aren't any bullets.

bleen’s picture

I would handle this issue and #634224: Seven theme needs vertical space between paragraphs together ...

bleen’s picture

Title: Seven theme lacks formatting on lists » Seven theme lacks formatting on lists & paragraphs
jhodgdon’s picture

Issue tags: +D7UX

Tagging

batigolix’s picture

FileSize
1.3 KB

i looked into this and seven uses a reset css that removes formatting from common html elements such as ul, h1, del, sub, etc etc

the attached patch adds css that restores some of the lost formatting for the content area (#page #content) of the seven theme pages

the html is based on firefox default html rendering

no css is included for tables or headers

batigolix’s picture

Title: Seven theme lacks formatting on lists & paragraphs » Seven theme lacks formatting on common html elements such as lists & paragraphs
Status: Active » Needs review

changing title and setting status to "needs review"

bleen’s picture

FileSize
1.29 KB

I think this patch is going to fail...

--- 7/themes/seven/style.css	2009-11-20 05:27:40.000000000 +0100
+++ 7-boris/themes/seven/style.css	2009-11-21 12:42:29.000000000 +0100

You need to create this patch from inside your 7-boris folder

--- themes/seven/style.css	2009-11-20 05:27:40.000000000 +0100
+++ themes/seven/style.css	2009-11-21 12:42:29.000000000 +0100

... other than that, I applied it this patch looks good to me :) Pages like /admin/help/block are much easier to read now

bleen’s picture

I think Drupal's server forgot about daylight savings time, OR I'm posting this from the future. Either way...

seutje’s picture

Status: Needs review » Needs work
--- 7/themes/seven/style.css	2009-11-20 05:27:40.000000000 +0100
+++ 7-boris/themes/seven/style.css	2009-11-21 12:42:29.000000000 +0100

I think u took the diff from a level too high or however to call it

gargoyle’s picture

This now breaks the contextual menus on the dashboard (see screenshot), as the themes/seven/style.css overrides the definitions in misc/contextual_links.css.

I guess there are many ways that this can be fixed, my idea would be to copy the contextual_links.css into the seven theme and update themes/seven/seven.info to add the reference to the new stylesheet file after the style.css one.

The only down side I can see to this would be that you are loading the same set of CSS twice, but I guess that's a small price to pay for the flexibility of the Drupal theme system!

batigolix’s picture

Status: Needs work » Needs review
FileSize
1.29 KB

i changed the identifier for the li element from

#page #content li {
display: list-item;
}

to

#block-system-main li {
display: list-item;
}

by this i made it less specific thus giving preference to the css rules of contextual_links.css
(i think)

batigolix’s picture

FileSize
1.34 KB

added a rule to give increase fontsize of code element as requested in #634218: Seven theme: CODE elements are too small

batigolix’s picture

Status: Needs review » Needs work
FileSize
28.88 KB

it now breaks the vertical tabs on the node edit page

i guess we will continue seeing these issues with the different css rules clashing on different levels

gargoyle’s picture

I am quite new to contributing to drupal and have only had a very short look at some of the D7 code, but it seems that if things carry on like this, then there is just going to be a big mess of stylesheets from the word go.

Would it not be better to strip all the fancy styles and have a generic reset and base (a bit like the YUI ones) in the core? Then all themes (front-end or back-end) will have a basic starting ground?

agentrickard’s picture

Status: Needs work » Needs review
FileSize
2.55 KB

@gargoyle

This is a theme-specific stylesheet issue. It is only a problem because Seven wants to change the defaults behavior.

Attached is a patch that correctly formats .item-list and tries to solve the vertical-tabs issue, albeit by making the total width < 100%.

batigolix’s picture

similar problems with the reset.css of seven are discussed in #575294: Add reset.css through drupal_add_css() instead of through the .info file

seutje’s picture

my apologies for the cross-post earlier, and more apologies for not even noticing it until now :x

jhodgdon’s picture

Status: Needs review » Needs work
FileSize
17.31 KB
5.6 KB

It looks like the consensus on #575294: Add reset.css through drupal_add_css() instead of through the .info file is that this issue can be fixed independently. And it really does need to be fixed!

So I applied this patch... There are a few unintended consequences:
- On list pages such as admin/content, the "operations" TDs contain a [UL class="links inline"] element. These are not being displayed in-line, but should be (see screen shot).
- I dont' think vertical tabs should have bullets. It makes them look very strange (see screen shot). These are [UL class="vertical-tabs-list"], for reference.

That's all I saw...

mrfelton’s picture

Marked [670908] as a duplicate of this post.

mrfelton’s picture

Marked #670908: add top and bottom margin to paragraph tag as a duplicate of this post.

jensimmons’s picture

subscribe

bleen’s picture

Title: Seven theme lacks formatting on common html elements such as lists & paragraphs » Seven theme lacks formatting on common html elements such as lists, paragraphs & <code>
Status: Needs work » Needs review
FileSize
2.5 KB

lets give this a whirl ...

mrfelton’s picture

Status: Needs review » Needs work
FileSize
5.43 KB
5.54 KB

One problem I noticed with this path installed (#26) is the spacing of operation links (edit, delete) which now seem to be shifted about 15px to the right. See attached screenshots.

kika’s picture

+ #page #content p {

Any particular reason why so strong selectors? Why not just

p {
mrfelton’s picture

Status: Needs work » Needs review
FileSize
2.34 KB

This version uses less specific css selectors and moves a one of the changes for vertical tabs from style.css into vertical-tabs.css

jhodgdon’s picture

Status: Needs review » Needs work
FileSize
14.14 KB

I tested this latest patch.

The problems with previous patches reported in #27, #22, #17, #14 appear to be fixed. That is good...

However, the formatting on Help screens is still lacking. See attached screen shot of the Content Translation module help (admin/help/translation), which has DL lists without much differentiation between the DTs and DLs, and without much vertical space.

Hmmm... I think the UL lists are OK now, but these DL/DT/DD lists definitely need some work. Most of the help screens are now DL/DT/DD, so pretty much any one you choose will illustrate the problem.

mrfelton’s picture

FileSize
33.78 KB

@jhodgdon: What browser/os was the screenshot taken with... looks good in FF/Ubuntu:

jhodgdon’s picture

Screen shot I posted was from Firefox on Windows.

jhodgdon’s picture

But I just tested in Firefox/Ubuntu and it looks the same as my other screen shot. I have caching disabled completely on both of those browsers...

Ah, I think you are using Overlay. I am not. Maybe that is the difference? ... Nah, turning on Overlay didn't do anything for me.

So do you have Firebug? When I use Firebug to inspect those DD/DT elements, I just see a bunch of generic formatting from reset.css and nothing that would cause the DD's to get indented as yours are. Where is your styling coming from?

mrfelton’s picture

on the dd: style.css (line 47)

#block-system-main dl dd, #block-system-main dl dl {
margin-bottom:10px;
margin-left:20px;
}

on the dl: style.css (line 3)

#block-system-main dl {
margin:0 0 20px;
}

as reported by firebug.

I have caching completely disabled.

jhodgdon’s picture

I see those DL/DT styles, but this help page is not inside #block-system-main when I look at admin/help/field_ui on my system.

It's in body > div#page > div#content.

seutje’s picture

Status: Needs work » Needs review

I can confirm it looks like mrfelton's screenshot in #31 on my FF on vista

patch in #29 looks pretty solid, just one lil thing that sorta bugs me:

+ul, menu, dir, .item-list ul li {
+  list-style-type: disc;
+  margin: 0.25em 0 0.25em 1.5em;
+}

menu and dir were already deprecated in HTML4.01, weren't they? do we rly need to add these?
and it feels weird to put the same styles on ul and on .item-list ul li

also

+#block-system-main li {
+  display: list-item;
+}

isn't this a browser default? it doesn't seem to get overridden to anything else in reset.css and removing this didn't change a thing for me so can u please elaborate on the reason u added this?

but those are just nitpicks I guess, this is already a big improvement

jhodgdon’s picture

Status: Needs review » Needs work

So why am I not seeing the same thing? On my system, the help is not displaying inside a #block-system-main div. What is causing that to be different on our systems? I have all of the core modules turned on except Overlay...

seutje’s picture

Status: Needs work » Needs review

I can confirm things look as they do in mrfelton's screenshot in #31 on FF/Vista and the styles he mentioned in #34 appear before and after applying the patch

also, for the structure, it does reside inside the #block-system-main div, otherwise those styles would have no effect ofc

inside an overlay or not doesn't and shouldn't make any difference, as this is an iframe so styling doesn't conflict

@jhodgdon: I dunno what could be causing that, but it's obviously unrelated to this issue, u sure ur working on a fresh checkout?

-> http://gyazo.com/785ec1af6ea71d7476a03d69c9d4676b.png

jhodgdon’s picture

OK. So why are you two getting things insdie a #block-system-main div and I am not? I just built a completely clean Drupal install off the latest CVS head today. What are you running?

jhodgdon’s picture

I just grepped through the entire current Drupal code base, and I am not seeing "block-system-main" anywhere except in seven's CSS files. I also looked for just "system-main" and didn't see that anywhere either. What is generating that ID on that DIV?

And yes, I am working with a CVS checkout I just did this morning. Are you?

It is not unrelated. If the styles you are putting in the style.css file are not relevant to the current HTML being produced, then the styles won't work...

jhodgdon’s picture

FileSize
19.08 KB

Here is what my firebug is showing. As you can see, not the same as yours...

mrfelton’s picture

@seutje I only altered the patch to make the selectors less specific so that we could get a retest and try and move this forward. I don't know why the styles you mentioned were added and I don't know the position on support for depreciated html elements (though I don't see why we should be supporting them) but I think I agree with your points.

Here is a re-roll which makes all your suggested changes with the exception of removing the formatting on one of ul or .item-list ul li because I'm unsure weather the formatting really should be applied to both, and if not, which one it should be applied to.

mrfelton’s picture

@jhodgdon: this is strange... I'm running with a CVS checkout from today. Literally just updated it. I too do not see "block-system-main" or "system-main" anywhere except in seven's css files so I'm a bit baffled as to where that could be coming from and how it is that @seutje is seeing the same as me!

jhodgdon’s picture

Yes.

Can you put in a comment here the entire tree of divs you have, starting with the div id=content class=clearfix, which I can see in the seven theme page.tpl.php? Maybe we can figure out what is happening from that. For me, the DL/DT is going straight inside that. For you, it is apparently getting nested inside several divs...

So, I totally reinstalled this morning on a clean database (after CVS update), with the minimal install profile, and then enabled all the modules except Overlay, and then went to Appearance and turned on Seven as the admin theme.

What was your install procedure? Perhaps the Default install profile gives you a different system layout somehow?

jhodgdon’s picture

And do you have any contrib modules installed/enabled?

seutje’s picture

@jhodgdon: the main content bit was turned into a real block a while back, this is the system.module "main" block and the default block template adds an ID of "block-$module-$delta"
I made my checkout 10 mins prior to testing this from the drupalfr git mirror and looking at http://drupalcode.org/viewvc/drupal/drupal/modules/system/system.module?... line ~1843 and the recent commits make me believe this is accurate
[EDIT]I did a checkout from the CVS to make sure the git mirror wasn't out of sync, but I'm getting the exact same results[/EDIT]
again, I have no clue why you are getting a different result

@mrfelton: I wasn't addressing any1 in specific, guess I should of made it "why this was added" :P
on the ul & .item-list ul li thing: afaik list-style stuff is usually set on the ul/ol as ul and ol both can contain li's but reset.css seems to set it to non on ul.links, ul.links.inline, ul.links li, .block ul, ol, ul, .item-list ul, .item-list ul li
which in term overrides system.css' .item-list ul li { list-style-type: disc; }

so basically,
by default, a browser puts list-style-type: disc; on ul's, not li's
then seven's reset.css sets it to none on ul's
but... by default, no list-style-type is set on li's by the browser
system.css sets it to disc (on the li's not the ul's)
then seven's reset.css resets it to none (on both ul's and .item-list ul li's)
and then seven's style.css sets both ul and .item-list ul li to disc

doesn't make much sense to me, but again, this is sort of nitpicking...

jhodgdon’s picture

Status: Needs review » Needs work

OK, I have figured it out....

If you install with the Default/non-expert profile, the Seven theme is enabled, and the "Main Content" block from the System module is turned on for you.

I installed with the Minimal/expert profile, though. I then turned on Seven as my admin theme. If I also "enable" the Seven theme (it can be the admin theme without being "enabled"), and then go to the Blocks admin page, I can see the "Main Content" block in the Disabled section. If I put it into the Content section and save the blocks config page, all is well, and my screen looks like yours.

But if I then disable the Dashboard and Blocks modules (neither of which is a required core module), my screen goes back to how it looked for me before, with the bad formatting.

So... In my opinion, the CSS for the Seven theme needs to consider that the "main content" block might not be enabled, and that the Blocks module can be turned off. So the patch needs some work, because a lot of the styles in the seven.css file depend on that assumption -- the div#block-system-main div does not exist without the Blocks module turned on and the Main Content block being displayed in a region.

mrfelton’s picture

@seutje: Yes I can see that list-style should only be set on the ul then... but I was more concerned with what would happen when the margin was removed from one or the other, as currently it's on both (with the patch applied). Not sure of a page where lists are used extensively, so need to find a good page to test with.

seutje’s picture

@jhodgdon: hmm yea... good point, so I guess it is related to this issue, my sincere apologies

@mrfelton: the margin on ul gets overridden to 0 when it resides in a .block on which we obviously can't rely anymore as block.module isn't required anymore, as pointed out by @jhodgdon

so we really need to move away from assuming everything is in a block, but since we were assuming everything was in a block, it doesn't rly matter and removing all references relative to blocks should do
perhaps we might have to change the #block-system-main to #content (although that would also make them apply to other blocks being put in that region, which might or might not be desirable, can't rly see a reason why it wouldn't be, but I'm rather sleepy, so brainfarts are likely :P)

jhodgdon’s picture

Remember, we're talking about the Seven theme, which is designed as an administrative theme. So it shouldn't matter a whole lot if some formatting is applied to #content that affects other blocks that go into that region. Those blocks can always have some specific theme overrides that apply particularly to their block.

In any case, in my opinion, the default formatting for DL/DD/DT, UL, P, etc. should be to make them look like they were being used to display text, have reasonable spacing, etc.. If those HTML elements are being used for navigation etc. then the style should be overridden for that specific use.

mrfelton’s picture

Status: Needs work » Needs review
FileSize
2.37 KB

Ok, this version removes anything to do with blocks and sets the styles with the least specific selectors as possible. No references to blocks, block-system-main, content or anything else like that. To be consistent about the ul/li thing, I have applied disc and margin to the li elements (ul li, .item-list ul li) as opposed to the the ul in one case and the li in the other.

mrfelton’s picture

FileSize
2.71 KB

The last patch had a little regression with respect to the vertical tabs. Attached patch fixes.

jhodgdon’s picture

Status: Needs review » Needs work

Um. The currently-committed version of style.css already has those #block-system-main things in it, and this latest patch does nothing to remove them. When I applied the latest patch and turned off the block module, I saw the screen shot in #30 again.

Ah. Maybe you just forgot the dl/dt/dd styles?

Anyway, I don't understand why the best solution wouldn't be to just remove all of those #block-system-main style clarifiers from the existing style.css file, rather than duplicating the existing styles, once for people with block turned off, and again for people with block turned on?

mrfelton’s picture

FileSize
6.68 KB

@jhodgdon: Perhaps I don't know enough about the theme or why it was coded the way it was. However, I was under the impression that this patch was supposed to be kept quite simple and was limited to providing formatting to common html elements. I guess I thought that #575294: Add reset.css through drupal_add_css() instead of through the .info file would be fixing the bigger issues.

I did do a quick test simply removing references to #block-system-main like you suggested, and whilst it seemed to work ok when seven was used as the admin theme, it made a complete mess of things when used as the default theme. The patch is attached for reference.

jhodgdon’s picture

OK, then the quick fix is to make sure that the DL/DT/DD styles from #block-system-main are included in the default styles as well.

mrfelton’s picture

Status: Needs work » Needs review
FileSize
179.56 KB
171.75 KB
7.5 KB

This version removes references to #block-system-main. In many cases is was required to be more specific than just element name, and I used #page to narrow down the selections in these cases. I also tried to integrate the new styles (code, abbr etc) into appropriate places within the stylesheet a little more rather than just tagging them onto the end as was being done previously.

I have done light testing with /without the overlay and with/without the blocks module in FF/Ubuntu.

I highly doubt if this would be the final patch, but I think it's definitely an improvement (see attached screenshots of a basic test page).

jhodgdon’s picture

Just a quick note on your basic test page: it would be good to have the DL contain DT/DD/DD/DT/DD to get full coverage on the DL section. There is at least one help screen that has multiple DDs in a row, and definitely several with DD/DT/DD.

Glancing at the screen shot: why is there so much space at the top of the fieldset box before the text begins?

Otherwise, the "after" screen shot looks good. Haven't tested the patch, need to go do some work for a client now...

mrfelton’s picture

The fieldset... I know why the space is there, but I didn't want to touch that until I can properly cross browser test it as I know it will be a pain with IE. I should be able to do it tomorrow.

aspilicious’s picture

maybe this post is important for the fieldset issue

#676800: Fieldsets break design badly

mrfelton’s picture

FileSize
254 bytes

Since #676800: Fieldsets break design badly seems to be dealing with the fieldsets quite nicely I'm going to leave it out of this patch. Attached is a new screenshot that has the fieldset patch applied and shows a more extensive use of dl/dd/dt.

Lets get some testing done and try to get it marked as RTBC please :)

aspilicious’s picture

picture is white, can you please attach the right one ;)

mrfelton’s picture

FileSize
207.46 KB

Screenshot didn't work for some reason... here it is again. Also note that my fieldset is still showing extra space at the top. I don't really understand it because the reason is that there is a br tag at the top of the fieldset, yet my source for the page doesn't have a br tab. This seems to be being injected into the page somehow. If I use firebug to remove the extra br tag the fieldset looks perfect.

yoroy’s picture

Why are we seeing Verdana? Personal browser setting?

mrfelton’s picture

Are you seeing Verdana? I have no personal browser preferences, and Verdana is not declared in the Theme. Firefox tells me that font-family: Lucida Grande, Lucida Sans Unicode, sans-serif; is being applied.

mrfelton’s picture

FileSize
202.67 KB

ok, so you (and I) were seeing Verdana because Lucida Grande is a Mac font and I'm on Linux. So, the vast majority of Linux users will see it the way I did in #62. I have installed the mac fonts on my Ubuntu now, and it looks like the attached. Personally, I preferred it in Verdana.

yoroy’s picture

Aaah, much better :)

markboulton’s picture

Just a quick comment. The vertical rhythm looks great, but all headings were original designated Helvetica in the designs I did (with a fallback to Arial). The reason for Lucida over Verdana is that Lucida is a slightly more condensed (more modern and friendly feeling too) than Verdana. Verdana is somewhat voiceless, 'harder', and masculine/technical.

jhodgdon’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #56 is working well for me.

This patch doesn't change any font types that I can see, so regarding #67, I think that is a separate issue. Not being a style/theme expert, and not having seen the design, I'll leave that to someone else to file.

Let's get this patch in, so we can at least (finally) be able to read/scan the help pages that the doc team worked so hard on.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

YAY!!!

Thank you SO much! Gleefully committed to HEAD.

A small request to mrfelton: could you please put the template you used to test these elements in the handbook somewhere? I think that would be tremendously valuable for themers as a checklist.

webchick’s picture

Hm. I think this might've caused #679096: Dashboard headings look funny.

casey’s picture

-#block-system-main ul.menu li,
-#block-system-main ul.menu li a,
+#page ul.menu li,
+#page ul.menu li a,
 #secondary-links ul.links li,
 #secondary-links ul.links li a {
   float: left;
 }

Errr, why are we floating menu links? #679326: Dragging "User menu" block into Dashboard looks oooglay

Is there a reason for the float? If not, we should remove that float. If there is a reason, we should make that reason not to need that float any more... That float is not supposed to be there.

mrfelton’s picture

I only really focused on adjusting the existing formatting rules so that they were being applied properly... not sure of the reason why it was there. I just tested removing that entire definition locally and it didn't seem to break anything. Patch attached to other issue.

mrfelton’s picture

Status: Fixed » Needs review
FileSize
6.57 KB

I don't think this patch was tested enough before being committed, and it has caused several other issues including, but not limited to #679326: Dragging "User menu" block into Dashboard looks oooglay and #679096: Dashboard headings look funny. Rather than writing patches for each of these individual issues, I have rolled fixes for those issues, as well as for several other issues I have noticed since this patch was applied into the attached patch. Is this an acceptable way of doing it?

mrfelton’s picture

Yet more bugs and inconsistencies found and fixed. I'm a little concerned that this patch may be turning into a bit of a monster seven theme tweak patch, but whilst I'm going along fixing the issues caused by the original patch, I keep finding more and more little inconsistencies and little annoyances. This version:

  • Ensures that the lists on admin/config and admin/modules, /admin and admin/by-module are displayed consistently in normal and compact mode (before, /admin had no bullet points whilst /admin/by-module did, and all the lists were too far indented).
  • Ensures that the heading styles are applied to all elements properly (The patch from #679096: Dashboard headings look funny fixed the dashboard h2s, but broke other h2s in the process)
  • Fixes the margin and padding on the title in the #branding area (back to how it was before the earlier commit from this thread)
  • Removes the unneeded float as described in #71
  • Removes the erroneous extra bullet points from the action-links on /admin/modules (+Update existing modules, +Install new module)
  • Adds a little margin under form submit buttons (look at the 'Save Changes' button on /admin/config/system/shortcut/shortcut-set-1 for why)
aspilicious’s picture

FileSize
20.35 KB

Mrfelton, can you also delete the border from this.
Or do something else to prevent the issue seen on my attachment.
In the overlay it looks rly ugly...

ul.secondary {
  float: none;
  clear: both;
  font-size: 12px;
  text-align: right;
  padding: 5px 10px 4px;
  line-height: 20px;
  overflow: hidden;
  border-bottom: 1px solid #ccc;    <====
  background: #fff;
}
webchick’s picture

Since this creates obviously broken end-user facing bugs, added to the alpha hit list.

Thanks a lot for taking this on, mrfelton!

mrfelton’s picture

@aspilicious: That's difficult, because sometimes that border is actually needed to separate the secondary tabs from the rest of the content and without it the tabs get lost. See my screenshots. The problem is that there is no way to know if the secondary tabs have bordered content directly below them as per your screenshot, or if the tabs have other content, like some help text (as per the book outline page) that does not provide it's own border.

Compare these two pages:
/admin/content/book
/admin/content/comment

And compare my two screenshots, one with the border and one without. So, removing the border fixes the double border your seeing, but also makes the tabs less noticeable on other pages. Personally I find the secondary tabs hard enough to see as it is, and I know for a fact that many other people often miss them so loosing the border would only worsen that situation.

Perhaps a better idea would be to add some help text to to comments page? I mean, shouldn't that page have some help text anyway?

aspilicious’s picture

FileSize
32.75 KB

But in the overlay they look rly rly bad!

mrfelton’s picture

Ok, yes point taken. How about this then (see screenshot). Problem for me is that I can't access the comments page without getting an error message, which is displayed in the help text section and so I can't ever see the two items but up against other!

However, this version will definitely look better for you because the length of the line will be the same as the border below it. I also added a little margin under the line so that it doesn't butt up against the border of the table below it.

Thoughts?

aspilicious’s picture

FileSize
23.45 KB

it looks like this

aspilicious’s picture

Is it normal that the different lists have different bullet styles in the dashboard?
Look at the collor of the bullets.

mrfelton’s picture

RE the underline: What do you think? I think it's not too bad. At least it is consistent with the rest of the site (the table has a border, the links have an underline, and there is no double width border). Another option is to remove the extra margin from under the secondary links so that the two lines are butt up against each other again, and make a special case of this page by removing the top border from the 'update options' table... but I think that is a bad hack as the issue will just appear again on any page where there is a bordererd table directly below the secondary links.

About the bullet points: Good catch, IMO all the bullet points should use the solid circle as per the who's online block in your screenshot. I'll incorporate a fix for that into this patch.

aspilicious’s picture

I prefer some extra space like you did it. Yes the bullets have to be filled.

mrfelton’s picture

Updated patch attached.

Please note that I have only tested this in FF/Ubuntu so far.

EDIT: Tested in IE, and the expanded and collapsed list images (triangles) are slightly out of position, but they are no worse than for garland and stark.

aspilicious’s picture

Status: Needs review » Reviewed & tested by the community

I have the feeling this is already committed to head?? Cause I can't reproduce the uglyness...
Someone confirm this so we can close this...

bleen’s picture

Status: Reviewed & tested by the community » Needs review

@aspilicious: webchick committed many of the changes (in #69) but those changes caused new issues to bubble up. Everything since #69 refers to new CSS problems caused by the committed patch

aspilicious’s picture

Yeah im not dumb, #78, #80 and #81 are my posts.
In those posts you see an attachment with problems.
Those problems are fixed in latest head...

Thats why i was wondering if the latest patch was commited to head.

RobLoach’s picture

Status: Needs review » Needs work

Some of the changes that were in #84 have already been committed:
http://drupalcode.org/viewvc/drupal/drupal/themes/seven/style.css?r1=1.4...

Does this mean that this issue is now fixed? What else are we missing?

aspilicious’s picture

Like i said before, i don't have any layout problems anymore...
Maybe someone smarter then me see some?

mrfelton’s picture

It appears that the patch in #82 has been applied.

EDIT: Lets create new tickets for any new display issues that are noticed, rather than keeping this rather widely scoped thread alive.

webchick’s picture

Status: Needs work » Fixed

Hm. Sorry, folks. I must've accidentally committed it with another change. But, um. Yay for fixed bugs? :)

Status: Fixed » Closed (fixed)
Issue tags: -D7UX, -webchick's D7 alpha hit list

Automatically closed -- issue fixed for 2 weeks with no activity.