This is a meta-issue for gathering all the requirements for Bartik, Busy and Corolla themes to get into Drupal 7 core.

This is just my personal proposal, feel free to discuss and extend it further :

  • - print support
  • - RTL support
  • - all pages render properly under IE6/IE7/IE8 and standards-compliant browsers
  • - valid XHTML 1.0 and CSS3 (with browser extensions allowed)
  • - all files are structured consistently with other core themes
  • - code follows Drupal coding standards
  • - primary and secondary links are hard-coded in page.tpl.php (pointed by Joachim)
  • - no custom theme settings (pointed by webchick)
  • - consistent stylings for hover, focus and active states
  • - region names consistent with other themes

I'm not sure whether following features should be required (more opinions needed):

  • old color module support (if patch from this issue will not get into core) - being limited just to 5 colors means providing color schemes that will be plain ugly. Old color module can shift similar colors, but this feature produces disastrous results (probably because colors are shifted in RGB space)
  • admin/overlay stylings - doing this properly is a bit tricky, even Seven theme which is an admin theme by design has a lot of issues. Currently Drupal assumes that all themes are supporting admin stylings - it would make more sense to provide a way for specifying whether theme should show up in list of admin themes and focus all the work on Seven theme.
  • full WCAG AA compilance - just like with old color module, some portions of WCAG AA would require me to make the theme ugly, I mean especially color contrast requirements.
  • handheld stylesheet - both Garland and Seven don't support it, mobiles these days are ignoring it anyway.
CommentFileSizeAuthor
#102 t4settings.png10.11 KBJeff Burnz
#76 footer-sample.png59.11 KBeigentor
#75 footer.png158.82 KBJarek Foksa
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim’s picture

- primary and secondary links are placed together in such a way that if they are combined from the same menu, they make visual sense as two levels of the same thing. (See garland for example.)
- two sidebars

joachim’s picture

> - all pages render properly under IE6/IE7/IE8 and standards-compliant browsers

I think we can allow graceful degradation for IE6, as discussed for Bartik's rounded corners. So perhaps say 'render meaningfully for older browsers such as IE6'?

mcrittenden’s picture

Sub.

geerlingguy’s picture

Subscribe. And, concerning IE6, I think this depends on whether we're talking about Drupal 7 or Drupal 8. For Drupal 7, we should at least have graceful degredation for IE6. For Drupal 8, we're not going to have to worry about this.

Cliff’s picture

Full WCAG AA compliance is definitely a "must" in my book. Attractive color combinations can be obtained while maintaining accessibility — it just takes a little more work to get there.

aspilicious’s picture

We have to support IE6 in core themes for D7!
It sucks but it's a must.

Everett Zufelt’s picture

Agreeing with Cliff, WCAG 2.0 level AA is a must. Well argued exceptions to degrade particular criteria to level A should be considered by the accessibility community.

Also agreeing with Cliff, I don't believe that it is necessary that a theme be ugly to meet contrast requirements at the AA level. This requires a contrast ratio of 4.5 as best I recall.

Cliff’s picture

Correct, Everett. At level AA, the color used for small text, which usually means the body of the page, needs a contrast ratio to background of 4.5 or higher.

For large text, which usually means headings, the number for compliance at level AA is 3.0 or higher.

At least some core themes should comply at level AAA or better. That means 7.0 for small text and 4.5 for small text.

But if a theme cannot support level AA compliance, even if it only fails contrast, it should not be in core.

Jarek Foksa’s picture

I have noticed that Garland does not show contextual links under IE6. Is it still a "graceful degradation" (like not showing rounded corners)?

IE6 does not support hover states on anything other than anchors, so implementing this would require adding some classes via jQuery.

mgifford’s picture

This is ultimately about setting standards for Drupal and working to meet them.

These standards are going to change with time. Three months ago I would have said we have to support IE6 too, but with all of the recent security problems that have arisen, with companies like Google officially dropping support, with countries warning their citizens about security problems with IE & that it is important to upgrade...... well, let's just say even if Drupal 7 supports IE6 just fine, I'd rather not publicize it.

Just like when the community decided to leave PHP4 in the dust in an effort to give more life to PHP5, we need to do what we can to leave IE6 in the dust so we can help move the web along.

I wasn't keen on CSS3, but seems like W3C is validating it now so +1 - http://jigsaw.w3.org/css-validator/#validate_by_uri+with_options

If we're adding new color module sample options for themes, then they should all be validated to ensure that they have proper color contrast. There is currently a problem with Garland in this bug:
#660576: Ensuring Proper Color Contrast for Garland

Drupal 7 should not be shipping with sample color combinations which are difficult for people with low vision to read. This doesn't mean that they need to be ugly. However, they need to be readable and there are means to evaluate this. There is some code here that may help come up with readable color combinations, but won't get into the color module till D8:
#134359: Warn users about contrast problems when using the color module

WCAG 2.0 doesn't mean ugly, just like standards based xHTML doesn't mean ugly.

As a community, we do need to be setting accessibility goals for D7 & soon for D8. I'd really like to see a commitment for D7 to be WCAG 2.0 AA, although frankly there are still areas of D7 core which haven't been evaluated for accessibility so I don't think we can claim any fixed standard of accessibility yet for Drupal 7. I would hope that there is at least a commitment to WCAG 2.0 A in D7. I would expect that we would have higher expectations for D8.

Drupal 7 is presently committed to being is xHTML compliant, but someone made that decision. At some stage we'll need to embrace HTML5. The standards are changing and we need to be continuing to discuss how we are going to adopt them and continue to update the best practices for our community.

It is still draft but for Drupal 8 we will need to seriously consider adopting WAI-ARIA. It would also be useful to have a review of ATAG 2.0 compliance as well.

Everett Zufelt’s picture

Regarding accessibility, one argument may be that the current core themes may not be WCAG 2.0 AA compliant, and therefore it is unfair to require new themes to be compliant. I understand that point of view. However, IMHO, this is not acceptable.

1. Theme developers have a myriad of resources available to them to ensure that their themes are accessible. Community members with specialties in accessibility should review work, not start from scratch explaining how things should have been done in the beginning. I am in no way saying that this is what has happened with the three candidate themes, I am making a general statement about any theme that may ever be considered for core.

2. Yes, we have themes in core now that may not conform completely to WCAG 2.0 AA. They are like holes in the ship, that over time the mighty, but small, accessibility group will attempt to fix. We don't need to build new decks that have their own holes. At least not without discussing the holes with the people that will likely end up being responsible for fixing them in the future.

Apologies for the directness.

Jacine’s picture

Most of this sounds fine to me.

- all files are structured consistently with other core themes

I disagree with this. Just because core dumps it all in one directory doesn't mean it's right.

- primary and secondary links are placed together in such a way that if they are combined from the same menu, they make visual sense as two levels of the same thing. (See garland for example.)

Stark (core) puts the primary menu in the header and the secondary in the footer. This variable is either the user menu or the secondary menu depending on the users settings. This is not like Garland. IMO a requirement like this would box a designer into a corner uncessarily. One theme cannot be everything to everyone.

Now, accessibility...

I think all the efforts to make Drupal accessible are great. I totally understand about the colors. That's all fine.

Regarding accessibility, one argument may be that the current core themes may not be WCAG 2.0 AA compliant, and therefore it is unfair to require new themes to be compliant. I understand that point of view. However, IMHO, this is not acceptable...

We don't need to build new decks that have their own holes. At least not without discussing the holes with the people that will likely end up being responsible for fixing them in the future.

This all depends on what you are talking about here. This is far too vague. We are looking to outline specific requirements for themes. These requirements need to be agreed upon and implemented by us, in order for these new themes that everyone wants to get in.

Colors and things like menu/block titles are totally understandable. However, if you are referring to structural Drupal issues, i.e. fixing things, like #520704: How should theme_image() deal with screen readers not reading the image title attribute?, I'm totally against that. I agree that these issues should all be filed against Drupal and I personally will do what I can to help fix them, but if for whatever reason that doesn't happen the burden of meeting additional requirements cannot be pushed onto the themers. That would be wrong.

As far as a myriad of resources available to us, I disagree. I would like to see a quick, all-in-one place document that includes instructions for themers to test accessibility as it relates to Drupal. I see a lot of requirements being thrown around (usually with links to other issues that are unrelated to the task I'm trying to achieve, or a huge spec) without suggestions or tips on how to fix them. I'm sure this exists somewhere, but I haven't seen it. We have limited time and resources too, so please help make it easy for us. Point us to some condensed documentation, give us some tools. We'll do what we can :)

Given the time constraints, I think the most reasonable approach here is that each new theme should get an accessibility review once all other issues are resolved, and whatever issues come up should be resolved to a point where both sides are happy.

webchick’s picture

I think of all our themes, Seven has had the most accessibility love given to it (please correct me if I'm wrong). So one idea for the accessibility bar may be "Is that accessibility issue present in Seven?" If so, then it's a "Drupal" issue that needs to get resolved across all themes, and shouldn't hold up any one in particular. If not, then it's the theme authors' responsibility to fix it.

But some concise documentation from the accessibility team that outlines the things to check for, the tools to do the checking, etc. as Jacine mentions in #12 I think would be pure gold, and really help increase the overall "Accessibility IQ" of our community, and would also spread the load around so the handful of you don't have to be policing this all the time.

webchick’s picture

And incidentally, I've brought this up on other issues before, but it relates to requirements, I'll reiterate it here:

I am perfectly fine with graceful degradation in IE (esp. IE6), like core already does with rounded corners in Seven. The theme needs to function in all browsers supported by jQuery, which includes IE6, but it doesn't need to look pixel-perfect IMO, as long as there are no glaring visual bugs.

joachim’s picture

> Stark (core) puts the primary menu in the header and the secondary in the footer. This variable is either the user menu or the secondary menu depending on the users settings. This is not like Garland. IMO a requirement like this would box a designer into a corner uncessarily. One theme cannot be everything to everyone.

Coupling the primary and secondary links together from the same menu is a core feature of Drupal's menu system: core themes should support this.

Either Stark is wrong, or as a starter/bare theme it's outside such considerations.

Jacine’s picture

@joachim It should not be the themes responsibility, especially for a core theme, to hack fixes in for this as a requirement. I also don't think Drupal/Stark should be considered a "base theme" in the typical sense since we are touting that CSS-only themes are a viable option in Drupal 7 (and they really are, I am going this route myself). Whomever it's wrong, it should be worked out elsewhere. I suspect is hasn't been because of the way it can be either a user menu or the actually secondary menu, which is another separate issue.

Everett Zufelt’s picture

@jacine

This all depends on what you are talking about here. This is far too vague. We are looking to outline specific requirements for themes. These requirements
need to be agreed upon and implemented by us, in order for these new themes that everyone wants to get in.

As far as a myriad of resources available to us, I disagree. I would like to see a quick, all-in-one place document that includes instructions for themers
to test accessibility as it relates to Drupal. I see a lot of requirements being thrown around (usually with links to other issues that are unrelated to
the task I'm trying to achieve, or a huge spec) without suggestions or tips on how to fix them. I'm sure this exists somewhere, but I haven't seen it.

I don't think that the accessibility requirements of WCAG 2.0 level AA are vague. But, I do agree with you that The documentation for Drupal accessibility requires a whole lot of love. My recommendation is that themers familiarize themselves with WCAG 2.0 and do their best to meet eachthe success criteria, each of which comes with best practices. For issues where Drupal core itself is causing the problem then the accessibility team can provide a simple work around, where available, or providing that the problem area has been filed against core give that particular issue a pass for the theme. I agree, it isn't the responsibility of themers to fix underlying accessibility problems with Core.

Not all success criteria can be assessed with an automated tool. However, for the SCs that can be tested with a tool I find http://wave.webaim.org to be a very easy to use tool.

@Webchick

So one idea for the accessibility bar
may be "Is that accessibility issue present in Seven?" If so, then it's a "Drupal" issue that needs to get resolved across all themes, and shouldn't hold
up any one in particular. If not, then it's the theme authors' responsibility to fix it.

I think that this is a good rule of thumb. It would be helpful to see these issues documented so that the accessibility folk can take a look to see if it is a problem in Seven that isn't caused by core, or if it is a problem in core itself. And, of course, every accessibility issue in Seven and core should be filed by someone so that they can be addressed for D8.

joachim’s picture

@Jacine: I don't know what you mean by 'hack fixes'. This isn't a hack. This is supporting a feature of core Drupal. If you enable this feature with a Bartik as it currently stands, you get something that makes no sense.

Jacine’s picture

@Everett, I wasn't implying that the WCAG 2.0 level AA spec is vague at all. I personally would love to familiarize myself more with the requirements as they relate to theming, but I will not be reading that entire spec over the next few weeks/months; I just don't have the time. I'm really just asking that you guys help us help you. A cliff-notes version or maybe just some DO's and DON'T's?

Jacine’s picture

@joachim I'm not disagreeing with you. My point is that it should be fixed in core (in a separate issue). It should not be pushed to the themer to fix. I'm not even talking about Bartik here. CSS-only themes need to "make sense."

Everett Zufelt’s picture

@Jacine

I'm not sure how the WCAG 2.0 guideline can be condensed without losing any information. And, I wouldn't frame this as themers helping accessibility specialists, accessibility specialists are helping themers. If a theme is core-worthy than the team developing it should have at least one member who is familiar enough with accessibility to have a rough working understanding of WCAG 2.0.

joachim’s picture

@Jacine: Ah, I get you now. I hadn't thought of CSS-only themes extending Stark... DUH! :/

Filed an issue on Stark: #739250: Primary and Secondary links are too far apart.

Jeff Burnz’s picture

We have substantial documentation on accessibility in the theme guide, under Best Practices:

Accessibility Guide
Accessibility 11 Point Checklist

The 11 point checklist is a fair place to start, not everything is relevant but most things are in one way or another.

We should not put off accessibility issues, they need to be dealt with early and as they arise, that's the best practice, otherwise we'll be duplicating work or finding out all too late that things are fundamentally flawed.

If you want a quick list of must haves for accessibility they are, at least in my book:

1) Skip navigation
2) Relative font sizing
3) Contrast and color pass WCAG 2
4) Leave form labels as they are, don't remove them, hide them (think search label) with .element-invisible class.
5) Proper headings, good heading structure, use H2 for node teaser and block titles, h3 for comments and not h5 or whatever (yes, I see this in contrib all the time). Again, don't remove headings, hide them.
6) Focus/outline styles.

I'm a bit pushed for time right now, but that, off the top of my head is what I would say is mandatory.

Jarek Foksa’s picture

Here are menu descriptions from admin panel:

Main menu
The Main menu is used on many sites to show the major sections of the site, often in a top navigation bar.

Secondary menu
The Secondary menu is used on many sites for legal notices and contact pages.

Legal notices and contact information usually appears at the bottom of the page, not just beneath header navigation.

catch’s picture

@joachim: there are lots of features in Drupal core that if you enable them make no sense - forums in Garland look nothing like a forum for example. Just because a feature exists, doesn't mean a core theme should assume it will be used, especially when it's an option that's by no means used by every site.

joachim’s picture

> Secondary menu. The Secondary menu is used on many sites for legal notices and contact pages.

To my mind, if you're doing that, the intention is that you'd put the Secondary menu in the footer region with the menu block rather than the theme links.

@catch: I really think if themes don't support this then it's a WTF for the user setting up their menu system.

catch’s picture

@joachim - should themes look good when disabling menu module too? What about disabling block module? How about setting simpletest as the default front page? Drupal core lets you get your site into a right mess very easily, I don't think where links appear in a theme is our worst problem. That menu feature is incredibly confusing even with Garland, it's poorly explained (and very hard to explain) in the UI, you need menus correctly set up in the first place. I really don't think core themes need to bow to this particular feature any more than the other wtf features I mentioned which are just as easy to do.

eaton’s picture

Coupling the primary and secondary links together from the same menu is a core feature of Drupal's menu system: core themes should support this.

I'm with Catch. Coupling the Primary and Secondary menus is a feature that Drupal supports. You're saying that every core theme has to use a particular design just because a capability exists in core. One of the traditional problems with Drupal's core themes is that they scream 'Drupal conventions' rather than 'Drupal flexibility.' I think it might be better for us to separate the 'Must have to commit' features from the 'Consider implementing' features.

@catch: I really think if themes don't support this then it's a WTF for the user setting up their menu system.

I feel the opposite. Putting a set of primary links in a prominent location with the main site sections, and a set of secondary links tucked away with terms of service, contact, etc. links, is an extremely common approach, and it maps cleanly to many, many visual designs. In core, unfortunately, we do not support 'multi-level primary links' so we hack it together by allowing the primary and secondary links to be coupled with each other. The fact that we use that mechanism for multi-level primary nav menus is the WTF: I think it's a useful feature, but we should not lock every core theme to one design approach just because we want to make sure people know about that one particular kludgy workaround.

Jacine’s picture

@Everett

I'm not sure how the WCAG 2.0 guideline can be condensed without losing any information. And, I wouldn't frame this as themers helping accessibility specialists, accessibility specialists are helping themers. If a theme is core-worthy than the team developing it should have at least one member who is familiar enough with accessibility to have a rough working understanding of WCAG 2.0.

I'd like to think the accessibility specialists, themers, developers, and designers, etc. all help each other get things done in the Drupal community. I was merely asking for some quickstart documentation, so I can get up to speed quickly and help others to do the same. Telling me to go read the RTFM is not helpful.

@Jeff Burnz - Awesome stuff. Thank you very much! I agree with all of it. There's nothing really new there as far as I'm concerned, other than the color stuff (that's probably because I rarely ever make color schemes :D). Just looks like good old semantic markup. ;)

Regarding the accessibility reviews, I agree it should be done as early as possible. Bartik and Corolla have already gotten preliminary reviews from Everett, so I was thinking another final go around would be the way to go them. Although, I just realized that Busy hasn't had a review yet.

I think this is a pretty good list so far. What else?

mgifford’s picture

This has been a very interesting thread! Very neat to see the community come together and talk about establishing new best practices for Drupal 7. It will trickle down to the rest of the themes I am sure.

As far as guidelines, folks can always ask the people in the Accessibility Group for a review or opinions about things. There are lots of experienced people involved in this community & who are passionate about both Drupal & accessibility issues. The lists & tools that have been mentioned above are great of course, and there is a lot that can be learned in this area.

WebAIM produced a checklist for WCAG 2.0 which is quite useful. I've tried to extend it a bit and address only items that are relevant to Drupal in this wiki page (this is a wiki page intended to be edited & reviewed by the community). It's difficult to summarize the full meaning & range as Everett's said, but I don't know anyone who can read W3C data without falling asleep.

This is an impressive list! It would be neat to see this express itself in terms of a Drupal Accessibility Statement, but that's a bit of a tangent.

Everett Zufelt’s picture

@Jacine

I agree with you that all members of the Community need to work together, regardless of their interests and specialties. I didn't intend my comment to be interpreted as RTFM.

I do believe that the most meaningful understanding of the WCAG guidelines comes from reading the success criteria and supporting documentation. But, I agree with both @mgifford and @Jeff's recommended reading on implementing accessibility for Drupal.

emmajane’s picture

@jacine I completely agree that themers don't need to be accessibility experts as well as being themers...however, (and as you've already noticed) good themers tend to be accessible because they follow standards. :) When you get a chance to skim through WCAG guidelines I think you'll find that it's almost all common sense.

For those themers who are new to accessibility scan-friendly and human-language resources also include:

- mgifford's wiki page is a good starting point: http://groups.drupal.org/node/18595
- dive into accessibility sorted by design principle http://diveintoaccessibility.org/by_design_principle.html (note: it's an *old* resource)

Jarek Foksa’s picture

May I use ::selection pseudo-element? It was removed from CSS3 specs some time ago and it will not validate, but it seems to be supported by almost all browsers.

Jacine’s picture

Ok, here's an updated list... I added some more things and attempted to categorize it a little:

Browser Support

  • Themes must be cross-browser tested and look as similar as possible in standards compliant browsers.
  • Non-standards compliant browsers down to IE6 are still supported (for now) and therefore must "function." This means that layouts must not break, and obvious differences/bugs should be worked out. It also means, for example, that using border-radius to create rounded corners is perfectly acceptable and browsers that don't support this (lte IE8) are fine without them.

Drupal Coding Standards

  • Coding Standards must be adhered to.
  • CSS Coding standards, while still a draft, should be adhered to as much as possible.
  • Template files should not exist in the theme unless they have been changed.
  • Template files should not remove critical RDF/Accessibility functionality.
  • Default regions should be used where possible (as opposed to creating new similar ones with different names)

Theme Features

  • A print stylesheet must be included
  • RTL styles must be added
  • Color module must be supported
  • Custom theme settings are not allowed (per webchick in D7)
  • Overlay must be supported
  • Primary and secondary links need to be supported
  • At least one additional region for navigation and content-related blocks

Web Standards, Validation & Accessibility

  • Markup must be standards compliant
  • Must pass XHTML 1.0 Strict validation
  • CSS must validate under profile level 3 (CSS3), with the exception of browser extensions
  • Compliance with WCAG 2.0 level AA should be the target, including:
    Note: This does not apply to issues caused by Drupal core.
    • :focus/outline styles are required
    • Skip navigation needs to stay in place
    • Font sizes need to be relative, i.e. ems, %
    • Contrast and color need to pass WCAG 2
    • Form labels must remain as they are (don't remove them, hide them (think search label) with .element-invisible class)
    • Proper headings, good heading structure, use H2 for node teaser and block titles, h3 for comments and not h5 or whatever.

Let me know if I missed anything or if there are any issues...

I also think that going forward, for Drupal 8, that in addition to having these requirements available up front, all candidate themes should reside in contrib first if possible. At some point (early on) during core development, themers/designers looking to offer up a theme/design as a core candidate should be required to come forward stating their abilities & intentions and be given the opportunity to solicit a team to help to whatever needs to be done to get a theme core-ready. After that, a plan of action should be drawn up. Deadlines also need to be worked into the core development cycle. This likely wont be easy, but it's critical that we at least try harder for next time.

This will help ensure:

  • Development occurs under traditional Drupal channels. Therefore the updated code is available to all via CVS (or Git -- not GitHub -- if that is that case).
  • The theme's popularity, flexibility, and general support can be assessed upfront, and one person will not stuck with the burden of doing everything his/herself.
  • The issue queue can serve as the themes track record and provide a means of measuring the community support and dedication to its success.
joachim’s picture

Sidebars?

> I also think that going forward, for Drupal 8, that in addition to having these requirements available up front, all candidate themes should reside in contrib first if possible. [etc]

This sounds good to me.

Jacine’s picture

Hmm, sidebars... I don't know. Do you mean one-sidebar, two, both?

Maybe we should mention at least one sidebar, but then again Seven doesn't have any.

I'm curious to hear what others think about this. I'm tempted to say just leave it out and deal with theme candidates on a case-by-case basis, but if all combos are going to end be a requirement (and I really hope not), then we should add it so people know upfront.

joachim’s picture

I reckon core themes should have two sidebars, and if not in the classic left/right setup, use CSS layout that makes them easy to reorder (which Corolla does).

Seven is somewhat an exception as it's only meant for the overlay (at least that's what I assume is the reason for what would otherwise be a shocking omission).

By all combos, do you mean allowing only left, only right, both, and none? That's really not a big deal to implement; my patch to get Bartik to do this was just a few lines. The core theme engine provides you with body classes like 'one-sidebar', 'sidebar-left' depending on what's there, and you just change your content div widths based on those.

Jacine’s picture

Seven is somewhat an exception as it's only meant for the overlay (at least that's what I assume is the reason for what would otherwise be a shocking omission).

Well, it's not ONLY meant for the overlay, but it's an admin theme, so that could be an easy exception in whatever rule we come up with.

By all combos, do you mean allowing only left, only right, both, and none? That's really not a big deal to implement; my patch to get Bartik to do this was just a few lines. The core theme engine provides you with body classes like 'one-sidebar', 'sidebar-left' depending on what's there, and you just change your content div widths based on those.

It's not a huge deal with you are dealing with the fixed width layout, and although it gets a little trickier for fluid widths, the CSS implementation isn't really my concern. I'm really referring more to the design aspects. For example: Having to support 2 sidebars really reduces the amount of space you are left to work with for content. As a result post images end up needing to be smaller, or workarounds need to be put into place, and sometimes the intended design kinda ends up having to be scrapped because it can't do everything well.

I'm fine with whatever we end up agreeing upon. I would just rather be more lenient with design requirements.

eaton’s picture

I'm fine with whatever we end up agreeing upon. I would just rather be more lenient with design requirements.

I agree. I'd actually prefer a rule like "At least one additional region for navigation and content-related blocks" over "two sidebars." In addition, I've made my thoughts clear on the issue of primary and secondary links. I think supporting them both is a must, but requiring that they be linked together (as they are in most core themes currently) is an unnecessary restriction.

Jarek Foksa’s picture

I suspect that 12px text will not be readable in languages such as Chinese or Arabic, may I provide theme setting for specifying custom base font size?

This could be also solved by using :lang pseudoclass, but afaik IE7 does not support it.

Jeff Burnz’s picture

No extra theme settings.

You do not need to use the pseudo class, you can set a body class for language however that may not be very sustainable in a core theme.

There is no requirement for the base font size be 12px, only that font size values must be relative.

mgifford’s picture

Just reposting this. I'd originally posted it #686410: New core theme for Drupal 7: Corolla by mistake.

I'd agree with the integration of the color module for all themes, including Seven. At the moment Seven isn't supporting it but I think it would be a lot better if it did. The constant gray is going to get a bit boring after a short while. Would be good to have an easy way to mix it up a bit.

Especially if we're pushing for more use of the color modules it's important to be aware of color contrast issues for accessibility:
#660576: Ensuring Proper Color Contrast for Garland
#740756: Ensuring Proper Color Contrast for Seven
#134359: Warn users about contrast problems when using the color module

There are some great tools to evaluate color choices.

@jarek posted some good critiques of the color module here:
http://drupal.org/node/686410#comment-2775766

Jacine’s picture

@eaton I like this:

At least one additional region for navigation and content-related blocks

I added it to the list in 34.

I also agree about the primary and secondary links. The way it's written now should cover that: "Primary and secondary links need to be supported." If you the wording needs improvement just let me know.

Are we good on this?

Jeff Burnz’s picture

Can we be more precise wrt to Browser compatibility.

Typically I follow Yahoos graded browser support recommendations : http://developer.yahoo.com/yui/articles/gbs/

How well a browser is supported I think is already defined - meaning its looks like we're all in agreement that progressive enhancement is employable and the right way to go.

This is the current list of Yahoos graded browsers, note there are no Linux browsers, although I think we should perhaps identify the major Linux browsers and add them.

Win XP Win 7 Mac 10.5 Mac 10.6
Firefox 3.0 A-grade
Firefox 3.6 A-grade A-grade A-grade
Chrome 4.0 A-grade
IE 8.0 A-grade A-grade
IE 7.0 A-grade
IE 6.0 A-grade
Safari 4.0 A-grade A-grade
Jarek Foksa’s picture

I would vote for dropping support for IE6. It's market share is already far below 10% in US and Europe, and by the time Drupal is released and widely adopted it should fall even further.

eaton’s picture

I also agree about the primary and secondary links. The way it's written now should cover that: "Primary and secondary links need to be supported." If you the wording needs improvement just let me know.

Are we good on this?

Yeah, I think the list has evolved into a really, really solid set of guidelines.

Jeff Burnz’s picture

IE6 is a tough one, I agree, because we're right on the cusp of it falling off the scale - clearly usage is dropping fast now, down 50% in the last year from around 20 to 10%. If that continues it'll be 5% in a year which is still a lot of internet users and more than Safari at the moment.

I don't think the theme has to look as good in IE6, but at least the site should still be usable. 10% is still a lot of internet users so I tend to think we need to provide at least rudimentary support.

aspilicious’s picture

We can't drop IE6 for drupal 7. This is discussed plenty times before....

webchick’s picture

No. Can't drop support for IE6 in D7, but also don't need to make it pixel-perfect. Just acceptable. "Acceptable" is obviously subjective, but generally means "Won't result in numerous duplicate issues from people who say the theme is broken in IE6."

Everett Zufelt’s picture

I quite like the list put together by @jacine in #34. I would only recommend one change.

Compliance with WCAG 2.0 level AA should be the target. Note: This does not apply to issues caused by Drupal core.

If we could add Including before the specific list, so that the list of accessibility issues after the above point isn't seen as exclusive I would be on board.

Jacine’s picture

@Everett I'm not exactly sure what you are asking. Can you please clarify? Thanks :)

Everett Zufelt’s picture

@Jacine

It appears in the list you provide in #34 that WCAG compliance is listed, after which are listed several specific accessibility issues. I just wouldn't want anyone to be confused and to think that the specific list is all that is required for WCAG compliance.

Jacine’s picture

Oh, I see... No problem! Updated #34.

It looks like we are all good with this, so where will this go and how do we get it there?

Jeff Burnz’s picture

@jacine: Probably under http://drupal.org/contributors-guide, perhaps under "Standards, security and best practices"?

Jacine’s picture

Status: Active » Fixed

Thanks Jeff! I posted the page where you suggested:

Core Theme Candidate Requirements

It's now out in the wild :P

webchick’s picture

Great work, all! This is a wonderful set of requirements, and sets great goals for contrib to aspire to a well!

As far as a deadline goes, I've been away for awhile so haven't had a chance to sync up with Dries on this yet. But obviously, the sooner the better, since the original deadline was Jan 31. :P~

When we reach a final deadline I'll update all the various theme issues.

webchick’s picture

Ok, discussed this with Dries and the Bartik maintainers at Drupalcon.

We would like to see the first beta release of Drupal 7 on or around May 21, 2010. If we're going to add core themes, they need to be RTBC before the first beta release. That means working in all major browsers, no obvious visual bugs, and all the other stuff on this list needs to be done (or at the very least a very solid plan for completing them).

Therefore, this means the deadline for new core themes is May 17, 2010 to allow for a few days to squash any additional bugs before the beta.

Start yer engines!

eigentor’s picture

This is one not disguised at all subscribe post.

BenK’s picture

Keeping track of this thread....

Jarek Foksa’s picture

Do I have to use the default logo image? Drupalicon is really ugly.

eigentor’s picture

I guess for the favicon, yes. But not for the big logo, at least IMHO.

Jeff Burnz’s picture

Any consensus or thoughts on Jareks Logo question in #60? I would assume we have to use the Drupalicon but this is not explicit in the requirements.

My preference would be to use Drupalicon; since we're brand "Drupal" and not some other brand, we should use it.

eigentor’s picture

Nah please not the druplicon. It's all over the place in Drupal and having it in the favicon should be enough. I find this seriously limiting design.

We sure have enough druplicon, while we are even more sure short on design. John Albin, to the rescue ;)

Jeff Burnz’s picture

For you its all over the place, for someone new its not, might be only the second or third time they have ever seen it. Most users will change it immediatly or switch it off. Not really seeing the argument for it *not* being the Drupalicon. How exactly does this logo lend itself to branding Drupal and making a better design? IMO the current corolla logo is rather bland and doesn't really say anything about Drupal (a logo by definition should really stand for something, corolla's is a few swishes of color).

Jarek Foksa’s picture

I think that the best solution would be to create a stylized image of water drop, somthing like this but without headphones.

Drupalicon is tied very heavily with Drupal brand, we probably don't want it to be used by unrelated websites. Besides, it's ugly and does not fit in with most color schemes.

eigentor’s picture

Good move Jarek: making a Druplicon-like logo that looks better. Something up your sleeve?
I did something similar for the website of our local usergroup: http://dug-hannover.org/

Jarek Foksa’s picture

@eigentor I will be working on alternative logo later, for now we can use anything that meets core requirements.

eaton’s picture

I'd actually vote against requiring the Logo feature. There are a lot of core-worthy cases where a giant Druplicon would be intrusive. A mobile theme that's content-centric, for example. I don't think that anyone's going to have a problem figuring out that they're using Drupal if they just installed and are customizing Drupal. And if our goal is to ensure that visitors know a site's running Drupal, we should rely on the 'powered by...' block instead.

eigentor’s picture

+1 eaton! let's fight over-Drupliconization.

joachim’s picture

When would you ever leave the built-in logo anyway?

I think themes in their default state should show the Druplicon, as long as it's always easy to change the logo or simply remove it. Which is is :)

eigentor’s picture

The logo is part of the design. As it is very prominent, it makes a big difference to have one that suits the design of the Theme. Druplicon has its place (which is nearly everywhere), so it feels like a breeze of fresh air to _not_ have it in some places.

Jacine’s picture

I think logos are one of those things that is probably better dealt with on a case-by-case basis. I think core themes have more than enough requirements as it is.

eaton’s picture

I think logos are one of those things that is probably better dealt with on a case-by-case basis.

Seconding, perhaps thirding. Yes.

Thirding.

Jarek Foksa’s picture

Default regions should be used where possible (as opposed to creating new similar ones with different names)

Is it required to have a footer region? Corolla is going to look awkward with footer blocks - they just don't fit in with the design.

Seven has no footer regions, Garland has one and Bartik has five.

Jarek Foksa’s picture

FileSize
158.82 KB
eigentor’s picture

FileSize
59.11 KB

The thing is that the footer is there. Someone with an eye for how his website looks will not just drop in a block, but rather write his copyright notice and place a short horizontal menu.

People who do not care at all about the looks of their website probably will not even put in a footer. It is pretty hard to keep people from spoiling the look of their site.

But the footer is something very basic and a core theme definitely must have a usable region to put blocks there.

Jeff Burnz’s picture

I think being a core region and something that most sites have - a footer - it really needs to be included in a core theme, especially since we don't have the footer message in D7. Seven is a special case and I don't think we can really compare our front end themes to the core admin theme.

Jarek Foksa’s picture

Do I have to show header, sidebars and footer when Corolla is used as an admin theme? Pages such as admin/modules are going to break if two sidebars are displayed.

Jeff Burnz’s picture

Users can easily disable blocks/regions using block visibility, so attempting to make this decision for end users seems like too much hand holding for a core theme, and at the same time takes away the end users ability to show a block if they want to (say something like a DHTML menu in one sidebar). Less is more in core themes I think, not trying to predict the use case, but allow for maximum flexibility.

Only Seven does not have sidebars, Garland, Stark and Bartik do, so this would be out of line with other core front end themes, which seems a bit strange why one would do this, but not the others ("hey, where'd my sidebar go?")

My2cents.

Jarek Foksa’s picture

Ok, I will specify bigger width and min-width values for page wrapper, but only on admin pages.

Jeff Burnz’s picture

!important - right now there is an understanding that there should be no use of !important in core, will this apply to core themes or just modules? Under what circumstances might this be acceptable in a core theme - for example to support the IE6 workaround for min-height?

Jacine’s picture

@Jeff That is a core module rule. It doesn't apply to themes.

Jeff Burnz’s picture

Good stuff, thanks for the quick reply Jacine.

Jarek Foksa’s picture

It's impossible to implement 3-column admin layout that would fit on 1024x768 screen and wouldn't break. I don't see any other way around than hiding the sidebars.

More on this issue: http://drupal.org/node/814730

dcrocks’s picture

Why is color module support mandatory for core themes?

It doesn't seem to be maintained.
The documentation is out of date.
Is it possible to consider it a 'release' grade, polished module?
Only the garland theme does not make an effort to restrict its 'colorization' of a theme to strictly controlled areas.
It may not have any 'critical' issues but I think some of the problems would appear critical to any users of a 'released' D7.

It is a clever module but I think it has inherent issues that will result in frustrating WCAG problems.

janusman’s picture

Speaking of color.module, this patch might make UX better across core themes: #828578: Make clicks on theme settings preview select palette fields to edit

Whilst a *horribly late* attempt at a new feature, unobstrusive and simple to implement IMO.

Status: Fixed » Closed (fixed)

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

yoroy’s picture

Version: 7.x-dev » 8.x-dev
Category: support » task
Status: Closed (fixed) » Needs work

Subscribe & bumping to 8 to keep this open. Needs handbook page.

Jacine’s picture

Hey @yoroy! There's a handbook page here: http://drupal.org/node/769692

yoroy’s picture

Hey jacine! Good to know :) I added a link to this discussion to it. circle of life.

emmajane’s picture

On the final list we have, "Primary and secondary links need to be supported" but we don't explain enough to know whether they are "two separate sets of navigation" (as is available in Bartik) or "the sub-navigation for primary menu items" as joachim mentioned in comment #1.

I disagree with catch (comment #25) and eaton (comment #28) that the coupling of primary/secondary links is not required. In the current version of Drupal core 7 there are instructions on how to enable sub-navigation by setting the Secondary links to be the same menu as the Primary links. Core themes must do what the Core UI says is possible. (Contrib themes are welcome to be unruly.)

I have no problems with there being two sets of "links" or menus that are unrelated. (I sometimes call this Footer Navigation or Utility Links depending on where the alt set of nav exists.) But I do think there needs to be support for the coupling of links to provide sub-navigation for nested menu items in core themes. To not support this makes the UI text in core something between misleading and "broken."

Edit: See also #503810: Convert primary and secondary menus to blocks

Cliff’s picture

@emmajane, I agree wholeheartedly. In my experience, separate but only tangentially related navigation blocks confuse users. There ought to be consistent integration of primary and secondary navigation as a best practice. In complex sites, having navigation approaching a site map in the footer is often helpful. But users still need the consistent use of nested navigation as the main path to content.

Jeff Burnz’s picture

Yes, after much thought and assessment of this I have to agree with everything in #91. I would probably go one step further and say its more than the docs that are misleading, but the actual UI is broken when the Main Menu is set as source to the Secondary Links - no one will expect the child menu items to appear in the footer - that is weird (the automagic coupling feature is not going to be removed from D7, that would be a travesty to not have at least some sort of drill down capability in core).

Jeff Burnz’s picture

I have posted a new issue to discuss the process of core theme selection: #912458: Design Initiative: Core theme selection and development process

Jeff Burnz’s picture

I would like to reopen the discussion regarding two crucial points:

- Color module must be supported
- Custom theme settings are not allowed (per webchick in D7)

I would propose that themes can get away with partial color module support (to extend the scope for designers) and that custom theme settings should be allowed.

Forcing full color module support imposes limitations on designers - for example color module can only support very basic gradients (when images are used). I would propose its perfectly OK to not have full color module support and allow partial support - such as changing the color of text, headings and other page elements.

Not allowing extra theme settings was IMO a draconian move - theme settings are something supported by core and we should be allowed to use them - for example allowing users to change the font, the page width or layout method (fixed or fluid aka Garland) is very simple to do. I would like to convert to Bartik to be a more responsive design in Drupal 8 and have the option to choose between fixed and fluid layout - I am not really seeing an earth shattering reason why we cannot do this.

joachim’s picture

> have the option to choose between fixed and fluid layout

I'd like to see that in all core themes.

And regarding theme settings -- my gut feeling is that if one core theme has setting X, they all should. But then I guess that means having to fit in support for a new feature into older themes which may be more effort than it's worth... :/

eaton’s picture

And regarding theme settings -- my gut feeling is that if one core theme has setting X, they all should. But then I guess that means having to fit in support for a new feature into older themes which may be more effort than it's worth... :/

I'm actually on the opposite side of the fence. Suggesting that every core theme must implement the same theme API features is like saying that every core module should use the same hooks. Different designs have different needs and strengths. A perfect example would be an uploadable 'header image.' Some designs don't have visual space for a header image, and the setting would make no sense. But holding all core themes to the same settings would cripple a design that does have a header.

joachim’s picture

Could we perhaps split the difference and have a way having both:

- theme features provided by core, so all themes can benefit
- a way for themes to state whether they want to use a feature or not

Jeff Burnz’s picture

Well thats how it does work already - such as site name, slogan, logo visibility etc and use the info file to disable certain features, for example very few of my contrib theme enable Main/Secondary menu, I disable those and use a region/block combo.

With catch on this one, clearly each theme is going to be very different and have different requirements. On the point of fluid/fixed widths maybe also a min/max for 100% fluid width is something that is almost trivial to set up in theme settings, if we did this for Bartik + the new theme its not a huge amount of duplicated code, and not something we really want in core since only some themes would ever use this, many would not imo.

eaton’s picture

- theme features provided by core, so all themes can benefit
- a way for themes to state whether they want to use a feature or not

That could lead to awkward bloat on core's part, and would also eliminate our ability to judge, in a core theme, whether changes we've implemented in core make it easier or harder to build advanced themes.

eigentor’s picture

I guess the point with these theme settings is: even if they are not in core, they should be unified for all core themes. So say core theme team 1 drives noggin till it is so awesome it drives us blind.
Core Theme team 2 should be allowed to chip in and say: we got slightly different needs, (or don't need it at all).
So noggin would only live in theme 1, but maybe a potential theme 3 would use it. Building the stuff api-like might allow to re-use it from one to another theme.

But when you get to the point that two themes are using it, having it inside both themes instead of core sounds duplication.

Whatever solution will be chosen: core theme functionality should somehow bee seen and worked on as a whole, not completely seperate.

Jeff Burnz’s picture

FileSize
10.11 KB

OK, lets put some scope around what I mean by allowing theme settings, what I'm talking about is a toggle setting for fluid and fixed width - not a whole lot of theme settings for header images or what not, I don't think we really want our core themes to have a lot of theme settings (or do we...):

Lets look at how much code this is for a fluid/fixed toggle:

function garland_form_system_theme_settings_alter(&$form, &$form_state) {
  $form['garland_width'] = array(
    '#type' => 'radios',
    '#title' => t('Content width'),
    '#options' => array(
      'fluid' => t('Fluid width'),
      'fixed' => t('Fixed width'),
    ),
    '#default_value' => theme_get_setting('garland_width'),
    '#description' => t('Specify whether the content will wrap to a fixed width or will fluidly expand to the width of the browser window.'),
    // Place this above the color scheme options.
    '#weight' => -2,
  );
}

This is not huge duplication of code if two themes have this, nor should it be in core IMO, not many themes can actually support this type of layout switch and if they do the themer has likely built their own settings and logic to do this - if this was in core its unlikely that toggle would integrate well with the themers own form, for example look at this form I just did in a new base theme I am building for a client:

t4settings.png

As you can see a toggle in core for fluid/fixed width is not going to work in this flow, I would end up unsetting cores setting and simply using my own. The logic is going to be a total mismatch, I use this setting inside a custom layout-engine-come-grid-builder, so almost impossible to decided on a generic way to use this type of setting - perhaps other than either doing nothing (simply save the setting) or maybe add a class to body classes, thats about it.

EvanDonovan’s picture

In re: #95 (which reopened this issue):

Seems to me like scope creep to have custom theme settings that are supported by core as an API. I think that would not inherently be a bad idea, but I think that should be a separate issue (feature request), so this one could be closed again.

As to Jeff's other point, about color.module support, I think partial support, as he defines it, would be fine. We don't want to constrain designers of potential core themes because they have to make their regions completely recolorable.

We should define more specifically which regions of the theme should be mandated to be recolorable so that we can revise http://drupal.org/node/769692, so that bullet point requirement is more defined.

Then, this can be marked fixed again.

kirk59’s picture

Category: task » feature

Hi Drupal Developers,
I am new to drupal so the learning curve to use drupal is fresh.
One module which is of great value to making a site work as you want is the views module.
I have found this challenging even with the great tutorials from onenode.se.
My thoughts are that you could have a check box next to each field of the content type you wish to add to a view to avoid having to search through different areas to add the fields or content.
Once the items to be part of the view were selected and put into a view area giving an outline of what your new view would contain with the options of dragging and dropping to reorder. (I appreciate that reordering is already in the D7 views module)
The next stage would be to select options for sort /visibility/filter etc and when selected and new sudo view layout would be created to show the new view. (similar to the preview in the views module)

Alternatively would be a drag and drop system of items to put into views to create groups of related content type.

I appreciate that the views module is powerful but at the same time it is difficult (for someone new to drupal) to get even a simple result executed well without a lot of effort.

I would also love the context admin module to be core so that you could create a simple content input and edit system for those even less technical than my self. (This is again tricky to use but has lots of potential to make drupal more user friendly.

The layout system in drupal is difficult even with blocks. There is a wordpress theme called glide at themeforest.net which allows you to build up individual areas of varying sizes for different pages where you then open a context menu and just choose the content you wish in each area. (i.e. title/ image/text area/ gallery etc)

I appreciate there is panels in drupal but again these could be made more user friendly by using this method of creating pages.

P.S. I love Drupal but would love it more if it was easier to use.

Keep up the brilliant work.

Cheers,

Kirk

mgifford’s picture

Version: 8.x-dev » 9.x-dev

Looking forward to this discussion in D9.

catch’s picture

Version: 9.x-dev » 8.1.x-dev

New theme could be added to a minor version.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Needs work » Closed (outdated)

This was marked fixed 13 years ago, it was reopened 12 years ago for discussion on Drupal 8. The following discussion did not result in changes to the handbook page.

There has been no discussion here for 8 years and we now have two new themes in core. It seems that having a list of features for a core theme is outdated. Therefor, I am closing it as outdated.