Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#84 | dashboard-lists.png | 40.63 KB | mrfelton |
#84 | 563390-seven-style-followup_2.patch | 7.74 KB | mrfelton |
#81 | dashboard-different-bullet-style.png | 46.15 KB | aspilicious |
#80 | content-style-fix.png | 23.45 KB | aspilicious |
#79 | 563390-seven-style-followup_1.patch | 7.14 KB | mrfelton |
Comments
Comment #1
quicksketchMarked #569078: List Items (li) is unformatted by default as duplicate.
Comment #2
seutje CreditAttribution: seutje commentedsubscribe
Comment #3
alanburke CreditAttribution: alanburke commentedMarked #632490: CSS in seven theme makes reading UL lists difficult as duplicate of this.
Comment #4
jhodgdonThis 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.
Comment #5
jhodgdonActually, 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.
Comment #6
bleen CreditAttribution: bleen commentedI would handle this issue and #634224: Seven theme needs vertical space between paragraphs together ...
Comment #7
bleen CreditAttribution: bleen commentedComment #8
jhodgdonTagging
Comment #9
batigolixi 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
Comment #10
batigolixchanging title and setting status to "needs review"
Comment #11
bleen CreditAttribution: bleen commentedI think this patch is going to fail...
You need to create this patch from inside your 7-boris folder
... other than that, I applied it this patch looks good to me :) Pages like /admin/help/block are much easier to read now
Comment #12
bleen CreditAttribution: bleen commentedI think Drupal's server forgot about daylight savings time, OR I'm posting this from the future. Either way...
Comment #13
seutje CreditAttribution: seutje commentedI think u took the diff from a level too high or however to call it
Comment #14
gargoyle CreditAttribution: gargoyle commentedThis 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!
Comment #15
batigolixi 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)
Comment #16
batigolixadded a rule to give increase fontsize of code element as requested in #634218: Seven theme: CODE elements are too small
Comment #17
batigolixit 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
Comment #18
gargoyle CreditAttribution: gargoyle commentedI 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?
Comment #19
agentrickard@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%.
Comment #20
batigolixsimilar problems with the reset.css of seven are discussed in #575294: Add reset.css through drupal_add_css() instead of through the .info file
Comment #21
seutje CreditAttribution: seutje commentedmy apologies for the cross-post earlier, and more apologies for not even noticing it until now :x
Comment #22
jhodgdonIt 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...
Comment #23
mrfelton CreditAttribution: mrfelton commentedMarked [670908] as a duplicate of this post.
Comment #24
mrfelton CreditAttribution: mrfelton commentedMarked #670908: add top and bottom margin to paragraph tag as a duplicate of this post.
Comment #25
jensimmons CreditAttribution: jensimmons commentedsubscribe
Comment #26
bleen CreditAttribution: bleen commentedlets give this a whirl ...
Comment #27
mrfelton CreditAttribution: mrfelton commentedOne 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.
Comment #28
kika CreditAttribution: kika commentedAny particular reason why so strong selectors? Why not just
Comment #29
mrfelton CreditAttribution: mrfelton commentedThis version uses less specific css selectors and moves a one of the changes for vertical tabs from style.css into vertical-tabs.css
Comment #30
jhodgdonI 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.
Comment #31
mrfelton CreditAttribution: mrfelton commented@jhodgdon: What browser/os was the screenshot taken with... looks good in FF/Ubuntu:
Comment #32
jhodgdonScreen shot I posted was from Firefox on Windows.
Comment #33
jhodgdonBut 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?
Comment #34
mrfelton CreditAttribution: mrfelton commentedon the dd: style.css (line 47)
on the dl: style.css (line 3)
as reported by firebug.
I have caching completely disabled.
Comment #35
jhodgdonI 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.
Comment #36
seutje CreditAttribution: seutje commentedI 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:
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
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
Comment #37
jhodgdonSo 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...
Comment #38
seutje CreditAttribution: seutje commentedI 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
Comment #39
jhodgdonOK. 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?
Comment #40
jhodgdonI 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...
Comment #41
jhodgdonHere is what my firebug is showing. As you can see, not the same as yours...
Comment #42
mrfelton CreditAttribution: mrfelton commented@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.Comment #43
mrfelton CreditAttribution: mrfelton commented@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!
Comment #44
jhodgdonYes.
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?
Comment #45
jhodgdonAnd do you have any contrib modules installed/enabled?
Comment #46
seutje CreditAttribution: seutje commented@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...
Comment #47
jhodgdonOK, 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.
Comment #48
mrfelton CreditAttribution: mrfelton commented@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.
Comment #49
seutje CreditAttribution: seutje commented@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)
Comment #50
jhodgdonRemember, 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.
Comment #51
mrfelton CreditAttribution: mrfelton commentedOk, 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.
Comment #52
mrfelton CreditAttribution: mrfelton commentedThe last patch had a little regression with respect to the vertical tabs. Attached patch fixes.
Comment #53
jhodgdonUm. 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?
Comment #54
mrfelton CreditAttribution: mrfelton commented@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.
Comment #55
jhodgdonOK, 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.
Comment #56
mrfelton CreditAttribution: mrfelton commentedThis 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).
Comment #57
jhodgdonJust 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...
Comment #58
mrfelton CreditAttribution: mrfelton commentedThe 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.
Comment #59
aspilicious CreditAttribution: aspilicious commentedmaybe this post is important for the fieldset issue
#676800: Fieldsets break design badly
Comment #60
mrfelton CreditAttribution: mrfelton commentedSince #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 :)
Comment #61
aspilicious CreditAttribution: aspilicious commentedpicture is white, can you please attach the right one ;)
Comment #62
mrfelton CreditAttribution: mrfelton commentedScreenshot 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.
Comment #63
yoroy CreditAttribution: yoroy commentedWhy are we seeing Verdana? Personal browser setting?
Comment #64
mrfelton CreditAttribution: mrfelton commentedAre 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.Comment #65
mrfelton CreditAttribution: mrfelton commentedok, 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.
Comment #66
yoroy CreditAttribution: yoroy commentedAaah, much better :)
Comment #67
markboulton CreditAttribution: markboulton commentedJust 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.
Comment #68
jhodgdonThe 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.
Comment #69
webchickYAY!!!
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.
Comment #70
webchickHm. I think this might've caused #679096: Dashboard headings look funny.
Comment #71
casey CreditAttribution: casey commentedErrr, 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.
Comment #72
mrfelton CreditAttribution: mrfelton commentedI 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.
Comment #73
mrfelton CreditAttribution: mrfelton commentedI 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?
Comment #74
mrfelton CreditAttribution: mrfelton commentedYet 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:
Comment #75
aspilicious CreditAttribution: aspilicious commentedMrfelton, 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...
Comment #76
webchickSince this creates obviously broken end-user facing bugs, added to the alpha hit list.
Thanks a lot for taking this on, mrfelton!
Comment #77
mrfelton CreditAttribution: mrfelton commented@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?
Comment #78
aspilicious CreditAttribution: aspilicious commentedBut in the overlay they look rly rly bad!
Comment #79
mrfelton CreditAttribution: mrfelton commentedOk, 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?
Comment #80
aspilicious CreditAttribution: aspilicious commentedit looks like this
Comment #81
aspilicious CreditAttribution: aspilicious commentedIs it normal that the different lists have different bullet styles in the dashboard?
Look at the collor of the bullets.
Comment #82
mrfelton CreditAttribution: mrfelton commentedRE 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.
Comment #83
aspilicious CreditAttribution: aspilicious commentedI prefer some extra space like you did it. Yes the bullets have to be filled.
Comment #84
mrfelton CreditAttribution: mrfelton commentedUpdated 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.
Comment #85
aspilicious CreditAttribution: aspilicious commentedI have the feeling this is already committed to head?? Cause I can't reproduce the uglyness...
Someone confirm this so we can close this...
Comment #86
bleen CreditAttribution: bleen commented@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
Comment #87
aspilicious CreditAttribution: aspilicious commentedYeah 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.
Comment #88
RobLoachSome 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?
Comment #89
aspilicious CreditAttribution: aspilicious commentedLike i said before, i don't have any layout problems anymore...
Maybe someone smarter then me see some?
Comment #90
mrfelton CreditAttribution: mrfelton commentedIt 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.
Comment #91
webchickHm. Sorry, folks. I must've accidentally committed it with another change. But, um. Yay for fixed bugs? :)