Problem/Motivation

Bartik only works for desktop-sized viewports because it hard codes pixel values in its layout CSS and assumes a significant amount of horizontal space in its navigational element design.

Proposed resolution

Convert Bartik’s design to be a responsive web design, including changing those width values from pixels to percentages.

Remaining tasks

  1. Convert the sidebar/main content, triptych, and footer areas to use media queries to use different numbers of columns in the layouts depending on viewport size. See comment #10
  2. Decide how to handle tabs, secondary links, and primary link navigation. See comment #10, comment #13 and comment #17

Sandbox

http://drupal.org/sandbox/mjohnq3/1681742 (The sandbox is no longer maintained. mjohnq3)

D7 Backport

D7 backport at http://drupal.org/project/responsive_bartik.

CommentFileSizeAuthor
#151 Tablet opra browser 2.png121.63 KBlewiking
#151 Tablet opera browser 1.png77.25 KBlewiking
#151 Tablet default Browser 2.png128.65 KBlewiking
#151 Tablet default Browser 1.png74.18 KBlewiking
#151 Tablet Chrome browser 2.png120 KBlewiking
#151 Tablet Chrome browser 1.png64.58 KBlewiking
#151 iphone4s safari.png124 KBlewiking
#151 iphone4s opera 1.png124 KBlewiking
#151 iphone4s chrome.png128 KBlewiking
#151 Iphone 1.jpg1.43 MBlewiking
#151 BlackBerry browser 3.jpg1.74 MBlewiking
#151 Blackberry Browser 2.jpg1.64 MBlewiking
#151 BlackBerry Browser 1.jpg1.3 MBlewiking
#151 Android Phone Maxtthon Browser 2.png77.88 KBlewiking
#151 Android Phone Maxthon Browser 1.png74.1 KBlewiking
#151 Android Phone Default Browser 3.png86.31 KBlewiking
#151 Android Phone Default Browser 2.png52.19 KBlewiking
#151 Android Phone Default Browser 1.png103.33 KBlewiking
#151 Android Phone Chrome brwser 1.png72.16 KBlewiking
#151 Android Phone Chrome browser 2.png58.03 KBlewiking
#149 GCI Screenshots.zip8.72 MBAnonymous (not verified)
#147 screenshots.zip1.92 MBenhdless
#128 chart.png1.73 KBro-no-lo
#124 bartik-RTL-support-1192044-124.patch3.02 KBtarekdj
#123 layout-rtl.css-1192044-123.patch352 bytestarekdj
#122 layout-rtl.css-1192044-122.patch405 bytestarekdj
#113 responsive.diff16.11 KBmoshe weitzman
#110 Photo 3-08-12 11 57 10 PM.png143.6 KBonco_p53
#103 responsive_bartik-1192044-103.patch16.26 KBmjohnq3
#98 responsive_bartik-1192044-98.patch11.18 KBmjohnq3
#88 responsive_bartik-1192044-81.patch15.36 KBjessebeach
#84 photo.jpg24.16 KBtkoleary
#80 drupal8.bartik-responsive.80.patch14.14 KBsun
#79 bartik-responsive-1192044-73.patch14.26 KBsun
#73 bartik-responsive-1192044-73.patch14.3 KBeffulgentsia
#68 bartik-responsive-1192044-68.patch9.08 KBeffulgentsia
#53 1192044-53-responsive-bartik.patch2.28 KBmjohnq3
#49 1192044-49-responsive-bartik.patch2.28 KBmjohnq3
#47 1192044-47-responsive-bartik.patch2.69 KBmjohnq3
#44 1192044-44-responsive-bartik.patch12.04 KBmjohnq3
#43 1192004-43-responsive-bartik.patch12.04 KBmjohnq3
#31 1192044-31-responsive-bartik.patch5.29 KBManuel Garcia
#30 1192044-26-responsive-bartik.patch4.5 KBJohnAlbin
#27 bartik-nowidths.patch2.77 KBManuel Garcia
#26 bartik-nowidths.patch1.18 KBManuel Garcia
#13 bartik-320-px.png23.1 KBtarekdj
#10 20120412-q6e9gjqkx2iqfxbs9gimfkp8qi.png185.68 KBJohnAlbin
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jeff Burnz’s picture

Title: Convert layout to a fluid grid » Convert Bartiks layout to be adaptive / responsive
Assigned: LewisNyman » Unassigned

I'd like to invite conversation on what approach we might take here, here are some ideas:

1. Fluid grids
2. Adaptive layout

Fluid grids have a lot of merit - they can display on any size screen and with media queries we can move regions around to give a better layout or small screens. The really nice thing is that they expand to fill the screen (up to a max-width), which means we can essentially future proof for all resolutions. One of the bad things about fluid grids is the fluid gutters - I would rather have consistent pixel based gutters - this is doable but requires more markup than other approaches. We also have that nagging problem with IE and Opera having inane handling of percentages - not insurmountable problems but issues non-the-less (I have build a 24 column fluid grid that works across browser so I know it can work).

Adaptive layout works a little different - instead of relying on fluid grids we use predefined widths and switch stylesheets using media queries - normally grids are px based. This is how frameworks like Less and 320andup work. At the moment many frameworks are going with something like 320, 480, 768, 992 and 1382px. Less actually defines a proper grid, 320andup is more of a boilerplate and only really defines the media queries.

I haven't made up my own mind on the best approach for Drupal core. I'm leaning towards the adaptive approach and something like Less with a mobile first approach like 320andup using media queries and polyfilling for unsupported browsers (old IE mainly). One of the main reason I like this is more control over things like gutters and layout.

Jeff Burnz’s picture

I will just add, so we can avoid any bikeshedding around this - I do not want to simply shoehorn some other framework into core - we'll need to build our own and we will not be embedding grid classes into the markup - that is old school grid ideology and we are all past that horrible, yet momentary, regression in web standards...

JohnAlbin’s picture

Issue tags: +mobile

Interestingly, Jeff, your point about "more control over gutters" being a point in favor of adaptive layouts can be overcome with box-sizing: border-box;. And take a look at all the green on When can I use CSS3 box-sizing? (I'll keep my fingers crossed that we can kill off IE7 before D8 is ready.)

I'm leaning towards Responsive since Adaptive design has to continually play catch-up with new device sizes, or live with non-optimal display for those new devices.

Jeff Burnz’s picture

I am very much leaning the same way, towards a responsive layout - to my mind they are much more sustainable and those non-optimal displays are unnecessary since we have the technology (responsiveness) to avoid them.

I suspect I wanted to throw adaptive layout in the kitty because Bartik is currently fixed width and back in June was leaning in that direction, however in the ensuing months I reworked my themes to actually use this technology and after that experience I very much prefer working with responsive design.

RobLoach’s picture

The first step would be to make it use a Grid system to manage the column widths seamlessly.

watsonerror’s picture

this is a nice grid system, perhaps it can be mimicked or used.

http://cssgrid.net/

Jeff Burnz’s picture

Not really seeing the point in the extra overhead of using a grids system, we can do responsive design just fine without littering the markup with rubbish classes.

jensimmons’s picture

I don't like the idea of implementing a grid framework. I think in too many cases a grid framework is not the right tool for the job, and it makes me anxious to see so much of the Drupal community assume that installing grid frameworks is the best Step 1 for every project. I much prefer to write custom reponsive layout-CSS for each site I work on. Using someone else's grid framework layout code severely limits what's possible in the design.

I also don't see the need for a including a grid framework. Bartik was designed to be simple and use what's built into core, and not add-on more complex GUI tools for users to change their layouts (say the way Omega or Adaptive theme do). I understand that when you endeavor to create a complex tool with lots of options to click, some kind of framework is needed. But Bartik doesn't go down that road.

I do have a lot of ideas about how Bartik could become responsive. I use an approach like 320 and Up on every site I build these days. I much prefer a responsive design to an adaptive one (where responsive means fluid, and adaptive means jumping from one fixed-width design to another).

dOwen-1’s picture

I've developed custom responsive/adaptive CSS and non-drupal sites. I've also worked with drupal and created drupal sites.

Does this qualify me to convert Bartik to be responsive/adaptive?

JohnAlbin’s picture

I made a Skitch of the issues when making Bartik responsive.

To be clear, we should start with a "mobile first" approach. Start with a single column mobile layout with no media queries and make that look awesome. Then build up more "advanced" layouts for larger screen sizes.

The biggest challenge is what to do with Bartik's header area: the navigation, header region, secondary links, logo, etc.

And for the triptych and footer sections, do we just rearrange the regions? Or re-think how the blocks get placed in those sections? i.e. change how the regions work so we can keep similar design aestethics but be more responsive.

jpamental’s picture

I'd agree with Jen. Don't think a grid is necessary (I see this as very similar to the approach I took in creating a responsive Zen them in D6)

Triptych and other blocks: I'd say 'width 100%; float: none' and let them be a linear progression down for the mobile-first view.

Similar take for the header, though I am really liking the notion of the nav region moving to the bottom and include a 'menu' anchor link fixed to the top area of the screen. I'd think that making the rest of the header content more linear seems like a reasonable default:

Utility links (my account, etc)

Logo/site name

Header content

It's not a one-size-fits answer, but will certainly get people off in the right direction pretty quickly.

(and I'm happy to help)

I'm used to using LESS.css but it's certainly possible to do the math the hard way instead :)

brewthis’s picture

Agree that a grid isn't necessary and that a linear progression down for smaller screens is the way to go for now.

For the header and navigation, options to show them as a
for smaller screens could also be an option. Though I'm not sure it's bulletproof enough.

As for using css-preprocessors, I believe it's better to leave that up to others and keep the theme standard for people to edit.

tarekdj’s picture

FileSize
23.1 KB

Hi,
@JohnAlbin: What about this concept ?
bartik 320 px

For a responsive text we can use fittext

mjohnq3’s picture

Re: #13

Seems like a good layout except for a few minor (or not so minor) items...

Changing the Menu to a drop-down list is probably a good idea on smaller screens. Not sure if it's possible to combine the Main and Secondary menus in the same list, however. I'm guessing that's a Javascript thingy - what happens with devices that don't have JS?

The main Content area ends up too far down on the screen. If Sidebar First has multiple blocks, Content is pushed even further down. Sidebar First should be moved below Content.

The Featured and Highlighted areas have much less significance in a small screen context since they end up the same size and one on top of the other. However, if a site wants to feature and/or highlight specific pieces of content then it should probably be displayed that way on smaller screens also.

Jeff Burnz’s picture

The main Content area ends up too far down on the screen. If Sidebar First has multiple blocks, Content is pushed even further down. Sidebar First should be moved below Content.

Yes, precisely, a big weakness of Bartik is that its not a content first type layout, so as far as rethinking regions this could be a high priority. That said there are reasons why its not content first - mainly ease of modification. Right now its trivial to modify the sidebar layout, with no tricky recalculations required. I would tend to be falling on the side of making it content first, being a best practice and virtual industry standard these days, and providing us better layout capability on smaller screens.

I'm not really a huge fan of the select list as navigation idea, personally I would prefer to see those menus hide behind a single "menu button", with a no-js fallback simply outputting the menus as per normal with some appropriate style.

Manuel Garcia’s picture

Glad to see some thinking going on about this issue!

The content region should go after the header, i mean, second in order for tablets, and perhaps even first for smaller devices, in my opinion.

I agree it'd be better if we take a mobile first approach to restructuring Bartik's regions. This means a lot of work, true, but the other way around is probably even more, and much less maintainable.

JohnAlbin’s picture

There's some interesting things about navigation in this recent blog post. http://palantir.net/blog/scalable-navigation-patterns-responsive-web-design

JohnAlbin’s picture

Priority: Normal » Major

This should be a priority. There's nothing blocking it. (Unlike other issues in the Mobile queue.) Let's get this done!

JohnAlbin’s picture

Title: Convert Bartiks layout to be adaptive / responsive » Convert Bartik's layout to mobile-first and responsive

Over in #1192068: Graceful degradation for browsers that don't support media queries we discussed how to support browsers that don't support media queries. Since we're going to use a mobile-first approach, the only desktop browsers that don't support media queries is IE8 and earlier. We can add a conditional stylesheet that force feeds the current desktop-sized layout to IE8 and earlier. I've closed that issue, so we can do that here while converting to a mobile-first layout.

In regards to the responsive images, we will have to tackle that in a separate issue, #1170478: Responsive Images. We'll just use the CSS-based image resizing in this issue since we'll need that same CSS once we have a proper responsive image solution in Drupal 8.

JohnAlbin’s picture

Good news! #1645494: Allow core themes to display single-column on IE8: do not compensate for lack of media query support landed so we don't have to use IE conditional comments to send a desktop-sized layout to IE8. IE8 will just receive the single column mobile layout.

JohnAlbin’s picture

Looking at http://bradfrostweb.com/blog/web/responsive-nav-patterns/, I think we should pick patterns from that page for the secondary links at the top right and for the primary links. Let's brainstorm about what combination of approaches we can use for those 2 navigation links so that we don't end up with a confusing interface.

I think we should look at the following patterns:

Let's discuss!

Manuel Garcia’s picture

Im worried about how select menu would handle secondary links, and active links... It could very much become a mess very quickly on a lot of sites.

I'm in favour (for bartik's case, which is very broad) of going either the footer anchor (easy to implement and maintain), or the toggle. The left flyout nav is probably a pain to maintain, and could cause a ton of bugs on different browsers.

The anchor menu is my favorite, because of my own experience using the mobile mainly for reading articles. I rarely use the mobile for actualy browsing around a whole site, I just want to get the article as quickly as possible and read it.

If we keep the nav out of the way in the bottom or in a flyout, we dont have to worry about how many items people will have in their navigations. By keeping it just using the anchor we can even not worry about what to do when there is section menu item that should be active (wether or not to provide triggers on that) or what have you...

Here is my ideal source code:

<body>
  <a href="#nav">Go to navigation</a>
  <article>
    <h1 id="page-title">Article title</h1>
    <p>Body field</p>
  </article>
  <nav id="nav">
    <a href="">link 1</a>
    <a href="">link 2</a>
    <a href="">etc</a>
  </nav>
  <a href="#page-title">Back to the article</a>
</body>
LewisNyman’s picture

I'm not really feeling for the foot anchor. Won't this give a confusing behaviour to site users with the blocks system?

I actually think that the select menu translates sub items pretty well, with the ability to nest select options supported by all modern mobile browsers. The active menu item can simply be the default selected item. It would be nice to have this menu select theming function in core for use for contrib.

The toggle is a nice option but feels heavier, let's not forget that the main menu nav needs support in any region it's placed in.

Manuel Garcia’s picture

Yep, the anchor option is probably the worse UX, although the fastest to render, thats for sure.

If the select menu can handle subitems, and doesnt take too long to render, it's got my vote. We could even print it below the content so that the user sees the content before the select menu has finished rendering.

JohnAlbin’s picture

Ok, I think I got the discussion off to the slightly wrong foot by posting possible solutions. Let's first identify the problems we have with the current primary links and secondary links in the header area (and their relative closeness next to each other in the header), especially for small viewports. Then, once we've identified those problems it will be easier to evaluate the pros and cons of possible solutions.

Can somebody list out all the problems of using the current navigation design at smaller screens?

Manuel Garcia’s picture

FileSize
1.18 KB

Here is a patch removing all widths and min-widths form layout.css so we can all test a bit faster.

Here is what I see right away:

  1. The Main menu buttons are too large for small devices (way too much padding).
  2. Once they reach the max width of the device, they jump to the next row, which is ok, but they dont have margin on top, so they touch the row above (ew).
  3. The rounded top-right and top-left are ok if only one line of links is displayed, but not so much when we have more and there are more of one row of menu items.

I suppose we could use this markup as is and just make the buttons smaller, inline and centered in the container... perhaps that would work, something like http://spainjs.org/ does for small devices.

Manuel Garcia’s picture

FileSize
2.77 KB

OOps... forget the last patch, the attached one should apply properly. Note that this is just for testing porpuses

webchick’s picture

Status: Active » Needs work

YAY! Awesome to see a patch here! Marking "needs review."

webchick’s picture

Status: Needs work » Needs review

Ahem. Actually doing what I said. :P

JohnAlbin’s picture

I've written a patch that adds the minimal media queries necessary to get a mobile layout. You can use that to examine how Bartik's current navigation styling works (or doesn't work) on a mobile device.

I've also pushed this patch to http://dev.d8mobile-1192044.gotpantheon.com/ so you can review and report on the navigation problems without building a sandbox yourself.

[edit: looks like manuee and I had the same idea at the same time. :-D I think my patch gets us a little closer to the goalpost, so let's review this one instead of the "remove widths" patch.]

Manuel Garcia’s picture

OK, here is a go at the navigation.

I've also changed the breakpoint so that the search bar doesnt breakup as much in layout.css.

The breakpoint for the nav i've included in style.css because otherwise it would not be picked up since sytle.css is loaded after layout.css.

Once we settle down on concepts and the way to go we shouuld probably move responsive stuf to responsive.css perhaps?

tstoeckler’s picture

I don't know what the scope of this issue is, since it's currently CSS only. But in general, I would expect the sidebar to fall below the content area, where currently it sits above. Also could you enable some more blocks on that site for the right sidebar and the various tryptich and footer regions? Again, might be off-topic here.

Bojhan’s picture

@tsoeckler I would agree, however it is also where navigation could live. This is a bit of an annoying Drupal Bartik thing, but it is a real problem.

mototribe’s picture

Are you all testing on an iphone or use a simulator?
I've recently came across http://iphone4simulator.com and you can include the domain at the und for quick access, for example: http://iphone4simulator.com/dev.d8mobile-1192044.gotpantheon.com/

mjohnq3’s picture

For a less Apple-centric view of the device world use The Responsinator (www.responsinator.com) to see how this will look on a variety of devices. http://www.responsinator.com/?url=http://dev.d8mobile-1192044.gotpantheo.... Appending &scroll=ext to the URL places the scroll bars outside of the device frame. http://www.responsinator.com/?url=http://dev.d8mobile-1192044.gotpantheo...

Manuel Garcia’s picture

Two things:

1. My patch on #31 is a proposal on handling the navigation (on top of @JohnAlbin's patch), it could handle any number of menu items on there. Comments?

2. I think we should decide on source order first. I'm willing to put in the time to prepare the patches, but unsure what the process is to decide what regions should go first etc.

mjohnq3’s picture

I spent some time working on this today. I made the following changes:

1) Converted the layout to content first source order - the Sidebars follow the Main Content.
2) Added a another media breakpoint to cover devices in the approx. 600px to 800px range. The Sidebars will be placed adjacent to each other below the Main Content in this range instead of stacked.

You can view the demo site here: http://mjq977.dev4.webenabled.net.

tstoeckler’s picture

Nice!!! Looks good.

tim.plunkett’s picture

Status: Needs review » Needs work

Can we see a patch for that? The site looks good.

webchick’s picture

Wow, GREAT job mjohnq3!

Manuel Garcia’s picture

@mjohnq3 I totaly agree on the source order and the new breakpoint for the sidebars.

Bojhan’s picture

Issue tags: +Usability
mjohnq3’s picture

Patch for changes noted in #37 -

mjohnq3’s picture

Oops! Sorry, wrong file name.

This should be correct.

Manuel Garcia’s picture

Status: Needs work » Needs review
mjohnq3’s picture

TODO:

1) Determine the width at which the Triptych blocks become too narrow and need to stack.
2) Determine the width at which the four Footer blocks can stack two over two and then singly.
3) Determine any changes required to the Featured region by device widths.
4) The dreaded Menus!

Demo site now includes No's. 1 and 2: http://mjq977.dev4.webenabled.net

mjohnq3’s picture

Patch for responsive ccs for Triptych and Footer regions.

Status: Needs review » Needs work

The last submitted patch, 1192044-47-responsive-bartik.patch, failed testing.

mjohnq3’s picture

Trying again.

webchick’s picture

Status: Needs work » Needs review

Bumping to needs review.

Status: Needs review » Needs work

The last submitted patch, 1192044-49-responsive-bartik.patch, failed testing.

Jeff Burnz’s picture

The patch in #44 appears to include HTML5, ARIA roles etc, lets not do that here - just the responsive design please.

mjohnq3’s picture

Re-rolled the patch from #49.

mjohnq3’s picture

Status: Needs work » Needs review

Needs review.

Status: Needs review » Needs work

The last submitted patch, 1192044-53-responsive-bartik.patch, failed testing.

mjohnq3’s picture

Demo site now updated with preliminary changes for all the items mentioned in #46.

http://mjq977.dev4.webenabled.net/

moshe weitzman’s picture

Status: Needs work » Needs review

Looks great on http://iphonetester.com/. I love how the tabs stack.

Manuel Garcia’s picture

@mjohnq3 Totaly love the responsive navigation

Jeff Burnz’s picture

The test site is looking good, the nav I like also, great idea.

The patches look like they are being "cut off" and we really need it for review.

Does this account for header region content, such as menus?

mjohnq3’s picture

I'm still experimenting with the Header region and the Secondary Menu links.

As far as the patching is concerned, I'm not sure what's wrong but, then again, this is the first time I've attempted to create a patch against Drupal core, so I'm obviously not doing it correctly. I'm reading deeper into the Git documentation to figure it out.

webchick’s picture

mjohnq3 feel free to hop into #drupal-contribute on IRC as well if you need more 'real-time' help. And thank you SO much for working on this!!!

attiks’s picture

@mjohnq3 do you have a sandbox somewhere or can you post an updated patch? I'm now using your patch from #44 for #1679728: Drupal 8 version of responsive images (resp_img), but would like to use the latest code.

attiks’s picture

Your patches in #47, #49 and #53 look incomplete (only 2kb), #44 is 12kb in size. I assume you're missing some files

mjohnq3’s picture

I created a sandbox that contains all the changes to date: http://drupal.org/sandbox/mjohnq3/1681742

attiks’s picture

@mjohnq3: thanks

@all: I created a demo site using this theme to showcase the responsive images (doesn't work in IE for now): http://atix.be/ZkA

Jeff Burnz’s picture

Status: Needs review » Needs work

The tricky 32% width main menu items break with long link text.

mjohnq3’s picture

Yes. long links do break at small screen sizes. I'll have to look at changing the Nav pattern for screen widths around 400px to 500px and below.

effulgentsia’s picture

For those who like patches, here's a patch I generated by diffing the Bartik Responds sandbox with the Bartik code in HEAD, and ignoring the name change. There's nothing here that needs a testbot run, so leaving at "needs work" per #66.

mjohnq3’s picture

Demo site updated with restructured Primary and Secondary navigation regions.

http://mjq977.dev4.webenabled.net

I'll update the sandbox tomorrow.

Jeff Burnz’s picture

While I like the nav idea I'm not convinced this can work for core in its current state - locking the height of menu items does not allow for expansion in the case of very long menu items that need to wrap - indeed merely switching language could break the display. Perhaps a less evil breakage is to allow the height to expand, while this won't look fantastic it does at least leave the menu items readable.

The logo position changes between about 600 and 800 or so px, it moves up, then back down again.

I'm getting some overflow in Chrome associated with sidebar second, I can see what looks like margin but could not find the actual CSS that is causing this. Overflow hidden on any region/wrapper is not very flexible - in terms of modules that may well wish to overflow, aka dynamic menus.

The featured region blocks have no left/right padding, so the block text runs up hard against the edge.

There are max-widths set in the theme - I think this needs some review and thought.

I haven't done a complete review, will wait for an updated patch, but it looks like we have at least some unnecessary duplicated CSS declarations.

All in all very minor issues and looking great, can't wait for the updated patch.

mjohnq3’s picture

1) Primary links are no longer fixed-height. They will expand to accommodate long-length link text. The results can be seen on the demo site.

2) Secondary links are at the top and will wrap at smaller screen lengths. The Logo and Site name will drop below the links depending on screen width. This still needs to be cleaned up a bit along with the rest of the Header region.

3) Fixed the overflow problem found in Chrome.

4) Featured region now has left/right padding.

5) Max-widths can be changed or deleted. I left them in for now.

6) Cleaned up duplicate CSS.

Demo site and sandbox have been updated. Working on a patch now.

mjohnq3’s picture

#2 above should say: Secondary links are at the top and will wrap at smaller screen widths.

effulgentsia’s picture

Status: Needs work » Needs review
FileSize
14.3 KB

I'm not sure if #70 was asking for a literal patch, or just commits to the sandbox, but in case the former, here it is.

mjohnq3’s picture

@effulgentsia

Thanks very much. It will come in handy for anyone who wants to review the changes.

mjohnq3’s picture

Issue summary: View changes

Update to proper issue summary

attiks’s picture

Small thing I noticed, if you have the toolbar enabled it will start wrapping on multiple lines and hiding the 'my account' link as well as part of the logo

mjohnq3’s picture

@attiks

Yes, that's something that will eventually have to be addressed but I'm thinking that it's, perhaps, outside the scope of this issue. I haven't seen that addressed in other responsive themes that I've looked at, either.

jessebeach’s picture

attiks’s picture

@jessebeach thanks for the link.

sun’s picture

Removed all trailing white-space from this patch.

sun’s picture

bleh. Now for real.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

To me, this is done. The demo is at http://mjq977.dev4.webenabled.net/ if anyone wants to review it.

mjohnq3’s picture

I do have a few changes to the menu links and the header area which I expect to finish up early tomorrow. I'll update the sandbox, the demo site, and try to post a complete patch.

Bojhan’s picture

Status: Reviewed & tested by the community » Needs work
tkoleary’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
24.16 KB

Tried to view the demo on iPhone and got this (attached). Artifact of the demo?

tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs work

Cross post.

echoz’s picture

On webkit a horizontal scrollbar appears when the window is narrowed to where the sidebars drop under the content. I haven’t been able to determine any element pushing out to cause this, only that it is resolved with body or html given overflow-x: hidden;

jessebeach’s picture

The scrollbar is being triggered by the .element-invisible styling on the Read more link of each node.

https://skitch.com/jesse.beach/ejaxt/screen-shot-2012-07-30-at-6.58.49-pm

If we add left: 0 to .element-invisible, it'll fix it.

Rerolling the patch.

jessebeach’s picture

The patch promised in #1192044-87: Convert Bartik's layout to mobile-first and responsive.

Added left: 0 to .element-invisible in system.base.css.

jessebeach’s picture

Status: Needs work » Needs review

Setting to Needs Review.

mjohnq3’s picture

@tkoleary, re: #84

During some changes I made to the demo site the mobile-friendly meta tags (detailed in this issue - http://drupal.org/node/1468582) that need to be added to html.tpl.php were inadvertently removed. I've added them in again. Please see if this solves the problem.

mjohnq3’s picture

Applied the fix for the overflow problem in #88 to the demo site.

tkoleary’s picture

Problem solved. Displays properly in mobile safari (3Gs).

effulgentsia’s picture

Status: Needs review » Needs work

Still needs work per #82, but otherwise I think this is nearly RTBC.

effulgentsia’s picture

Status: Needs work » Reviewed & tested by the community

DrupalCon Munich is in less than 3 weeks. Having our main theme responsive by then would be most satisfying. Committing this by the end of the week would give 2 weeks for people who aren't following this issue to see it, find problems, and help fix them. And of course, we can still polish after then too. Therefore, RTBC'ing. #82 is still most welcome either before commit or in a follow-up. Thank you, @mjohnq3, and everyone else who worked on this!

sun’s picture

Slightly abusing this tag to leverage the @drupalchanges mechanism.

mjohnq3’s picture

Completed changes to Header, Menus, and Pager mentioned in #82.

Demo site updated - http://mjq977.dev4.webenabled.net/

Sandbox updated - http://drupal.org/sandbox/mjohnq3/1681742

Patch to follow.

Bojhan’s picture

I agree, unless an updated patch is posted lets get this in. This looks really exciting.

mjohnq3’s picture

Patch for all the latest changes.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, responsive_bartik-1192044-98.patch, failed testing.

mjohnq3’s picture

Ok, someday I'll figure it out. <:-|

aspilicious’s picture

You'll have to update your drupal 8 version before creating the patch.
So you have to merge in a new drupal8 version into your sandbox.

And couple of problems found regarding to trailing whitespaces:

$ git apply responsive_bartik-1192044-98.patch
responsive_bartik-1192044-98.patch:98: trailing whitespace.
  }
responsive_bartik-1192044-98.patch:326: trailing whitespace.

responsive_bartik-1192044-98.patch:361: trailing whitespace.
    display: block;
responsive_bartik-1192044-98.patch:371: trailing whitespace.

responsive_bartik-1192044-98.patch:458: trailing whitespace.

error: patch failed: core/themes/bartik/css/layout.css:8
error: core/themes/bartik/css/layout.css: patch does not apply
error: patch failed: core/themes/bartik/css/style.css:1602
error: core/themes/bartik/css/style.css: patch does not apply
aspilicious’s picture

ow wait... your sandbox isn't based on drupal8 but is a custom theme based on bartik...
No idea how to fix that

mjohnq3’s picture

Another try at a patch.

tim.plunkett’s picture

Status: Needs work » Needs review
cweagans’s picture

Status: Needs review » Needs work
+++ b/core/modules/system/system.base.cssundefined
@@ -235,6 +235,7 @@ tr .ajax-progress-throbber .throbber {
+  left: 0;

Why do we need this?

+++ b/core/themes/bartik/css/layout.cssundefined
@@ -75,26 +41,156 @@ body,
-.breadcrumb {
+#breadcrumb {
   margin: 0 15px;

This is not okay. I have seen instances where a site has multiple breadcrumbs on the page (for instance, one at the top and one at the bottom). We should use a class for this, not an ID.

+++ b/core/themes/bartik/css/layout.cssundefined
@@ -75,26 +41,156 @@ body,
+  .region-footer-fourthcolumn {
+    display: inline;
+    float: left; /* LTR */
+    position: relative;

Trailing whitespace.

+++ b/core/themes/bartik/css/layout.cssundefined
@@ -75,26 +41,156 @@ body,
+  .region-triptych-last { ¶
+    width: 33%;

Trailing whitespace here too.

+++ b/core/themes/bartik/css/maintenance-page.cssundefined
@@ -61,7 +54,21 @@ body.maintenance-page {
+@media all and (min-width: 600px) { /* @TODO find the proper breakpoint */
+  .maintenance-page #page {
+    margin: 20px 40px 40px;

Can we take care of this TODO before the patch goes in? Seems like it should be reasonably easy.

+++ b/core/themes/bartik/css/style.cssundefined
@@ -1602,3 +1630,106 @@ div.admin-panel .description {
+ /* ------------ Header and Menus -------------------------- */

Trailing whitespace.

+++ b/core/themes/bartik/templates/page.tpl.phpundefined
@@ -90,7 +90,24 @@
   <div id="header" class="<?php print $secondary_menu ? 'with-secondary-menu': 'without-secondary-menu'; ?>"><div class="section clearfix">
-
+    <?php if ($secondary_menu): ?>
+      <div id="secondary-menu" class="navigation">
+        <?php print theme('links__system_secondary_menu', array(
+          'links' => $secondary_menu,
+          'attributes' => array(
+            'id' => 'secondary-menu-links',
+            'class' => array('links', 'inline', 'clearfix'),
+          ),
+          'heading' => array(
+            'text' => t('Secondary menu'),
+            'level' => 'h2',
+            'class' => array('element-invisible'),
+          ),
+        )); ?>
+      </div> <!-- /#secondary-menu -->
+    <?php endif; ?>
+    ¶
+    ¶
     <?php if ($logo): ?>
       <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home" id="logo">
         <img src="<?php print $logo; ?>" alt="<?php print t('Home'); ?>" />
@@ -142,22 +159,7 @@

@@ -142,22 +159,7 @@
       </div> <!-- /#main-menu -->
     <?php endif; ?>
 
-    <?php if ($secondary_menu): ?>
-      <div id="secondary-menu" class="navigation">
-        <?php print theme('links__system_secondary_menu', array(
-          'links' => $secondary_menu,
-          'attributes' => array(
-            'id' => 'secondary-menu-links',
-            'class' => array('links', 'inline', 'clearfix'),
-          ),
-          'heading' => array(
-            'text' => t('Secondary menu'),
-            'level' => 'h2',
-            'class' => array('element-invisible'),
-          ),
-        )); ?>
-      </div> <!-- /#secondary-menu -->
-    <?php endif; ?>

There's some trailing whitespace here. Also, why are you re-ordering this? IMO, menus should come after the logo/site name in the markup.

+++ b/core/themes/bartik/templates/page.tpl.phpundefined
@@ -177,12 +179,6 @@
-    <?php if ($page['sidebar_first']): ?>
-      <div id="sidebar-first" class="column sidebar"><div class="section">
-        <?php print render($page['sidebar_first']); ?>
-      </div></div> <!-- /.section, /#sidebar-first -->
-    <?php endif; ?>
-
     <div id="content" class="column"><div class="section">
       <?php if ($page['highlighted']): ?><div id="highlighted"><?php print render($page['highlighted']); ?></div><?php endif; ?>
       <a id="main-content"></a>
@@ -209,6 +205,12 @@

@@ -209,6 +205,12 @@
 
     </div></div> <!-- /.section, /#content -->
 
+    <?php if ($page['sidebar_first']): ?>
+      <div id="sidebar-first" class="column sidebar"><div class="section">
+        <?php print render($page['sidebar_first']); ?>
+      </div></div> <!-- /.section, /#sidebar-first -->
+    <?php endif; ?>

This is introducing some trailing whitespace as well, and same thing about the DOM ordering here. Why stick the first sidebar after #content?

Finally, I'm not sure that making the theme completely fluid is in scope for this issue. It seems like Bartik should be 960px wide on screens that are wide enough, and go down from there.

effulgentsia’s picture

Why stick the first sidebar after #content?

So that on narrow devices, the content is above the sidebar. On wide enough devices, #content is then floated right to allow the sidebar to come up to the left.

cweagans’s picture

Ah, that makes sense.

kattekrab’s picture

Wow! Great work - just had a look at the demo

http://mjq977.dev4.webenabled.net/

Serious kudos.

aspilicious’s picture

Don't feel people akward that they see a different interface wen they turn their ipad?

onco_p53’s picture

FileSize
143.6 KB

No I don't feel awkward when the layout changes when I rotate the iPad.

However thanks for raising this point, because I noticed a possible bug. When you rotate the screen from landscape to portrait back to landscape the page overflows the screen.

This is only a problem in Safari (not Chrome) on the iPad.
iPad responsive

mjohnq3’s picture

@onco_p53

That appears to be the well-known Safari viewport scaling bug: http://filamentgroup.com/examples/iosScaleBug/

One somewhat undesirable fix would be to disable user scaling. There is also a javascript fix, which I'm not really keen on adding.

LewisNyman’s picture

That is an effect from #1468582: Add mobile friendly meta tags to the html.tpl.php.

It is the lesser of several evils and a bug that is due to be fixed in iOS 6.

moshe weitzman’s picture

Status: Needs work » Needs review
FileSize
16.11 KB

In response to cweagans in #105,

  1. see #88 for why we added left: 0
  2. reverted to .breadcrumb
  3. hopefully my editor fixed all that trailing whitespace
  4. i don't agree that agreeing on a breakpoint width is a prerequisite for committing this.
Dries’s picture

Status: Needs review » Fixed

Committed to 8.x! Yay, so great to see our base theme being responsive. Another step towards a mobile friendly Drupal core.

Thanks mjohnq3, Manuel Garcia, effulgentsia, sun, JohnAlbin, jessebeach and moshe.

effulgentsia’s picture

Those names are just the list of people who submitted patches, but there's many others here who helped way more than me by testing and reviewing. Thank you all! If there's any tweaks still needed, please post follow ups.

webchick’s picture

YAY! :D

Any chance of a D7 backport as a contrib project? :)

cweagans’s picture

I was thinking about that: is there any major reason that we couldn't just apply this patch as-is to D7 Bartik? A contrib project would be really easy, but making D7 Bartik responsive would be a big win, IMO.

tim.plunkett’s picture

No way this is backportable. Changing that much CSS is out of the question, and the markup changes are 100% not backportable.

JohnAlbin’s picture

I want to second what Effulgentsia said. Thank you all for reviewing and testing the patches. Especially for mobile issues, the reviewing is harder then writing the patches!

Thank you! Thank you! Thank you!

Manuel Garcia’s picture

wow this went much faster than I expected, a w e s o m e ! !

Congrats all on a great job, specially @mjohnq3 && testers

webchick’s picture

There's now at least a semi-working D7 backport at http://drupal.org/project/bartik_respondz. WARNING: It was done by me so it probably will light your computer on fire upon clone.

tarekdj’s picture

Status: Fixed » Needs review
FileSize
405 bytes

This is a great job thanks everyone. I've found some troubles on RTL display. Patch attached fixes the problem.

tarekdj’s picture

Here is an optimised one. Patch size from 405 Bytes to 352 Bytes

tarekdj’s picture

Patches #122 and #123 work only on desktop screen. I've worked on other screen sizes.
It was successfully tested on FF and chrome (with Mobile Resizer extension), not tested on real mobile devices.

hgurol’s picture

We believe the work over here brings in new problems and effects the work to fix the issue #1057912: Border with Google Chrome and Safari in .element-invisible.
I highly suggest you take a look at the screen shots and comments on that issue from post #73 through #75.

echoz’s picture

In #87 we patched core’s .element-invisible by adding left: 0;

If we instead use Snook’s version, http://snook.ca/archives/html_and_css/hiding-content-for-accessibility, which fixes #86 too, and we’re already using with zen, it may not cause the issue of #125 from #1057912: Border with Google Chrome and Safari in .element-invisible

This would be rather than left: 0; using:

height: 1px;
width: 1px;
overflow: hidden;

Sorry I’m not set up to patch D8, I figured posting this was quicker.

hgurol’s picture

bowersox, who is one of the people that actively works on the other issue #1057912: Border with Google Chrome and Safari in .element-invisible thinks that this problem should also be fixed in that issue, rather than here.

What I think is; the people who actively works on this issue and on the other issue needs to talk about how and where to fix it. Im just a messenger myself.

ro-no-lo’s picture

FileSize
1.73 KB

QR Code of http://mjq977.dev4.webenabled.net/ for easier testing on mobile devices.
QR Code

Fannon’s picture

Works great on my Sony Xperia S!

One Suggestion: The Search Input Field could use the full width if the site has just one column left. (Or generally the full width of the block its residing in). The Search Button/Icon looks a little bit less tall than the search field itself.

And this is a matter of personal taste: But I think the buttons could look better if they have the same border-radius as the menu buttons from above.

Greets,
Simon

mgifford’s picture

Nice work @ronan.orb

I tested it briefly with my iPhone using the QR Code provided (cool).

Only problem I noticed was that in tilting the screen between landscape & portrait (and back again) on my iPhone that the zoom was wrong on the menu.

I think my iPhone was displaying it in tablet mode or something as the buttons (the second time it was in Landscape) was zoomed in so I could only see 2/3 of the menu items. I had to scroll over to the second set of buttons.

Would be useful to know if others can replicate this.

mjohnq3’s picture

@mgifford

Please see items #110, #111, and #112 above for an explanation of the scaling/zoom problem.

mgifford’s picture

@mjohnq3 - Thanks! Sorry I missed that when I went to do my quick review.

Anonymous’s picture

Title: Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support) » Convert Bartik's layout to mobile-first and responsive

Please disregard this message.

catch’s picture

Title: Convert Bartik's layout to mobile-first and responsive » Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support)
Anonymous’s picture

Title: Convert Bartik's layout to mobile-first and responsive » Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support)
Status: Fixed » Needs review

Some experiences with the D7 development version of the Bartik Responsive theme.

There may be some overlap, such as the video resizing, as the two mirror each other:
http://drupal.org/node/1801752

Really impressed by the Bartik theme. It is beautiful and really wel thought out. Things such as the typography, spacing, and colors are absolutely stunning.

mjohnq3’s picture

Title: Convert Bartik's layout to mobile-first and responsive » Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support)

@design_dolphin

All of the credit for the visual design of Bartik belongs to jensimmons. This issue primarily addressed converting the layout to responsive, mobile-first.

I'll review the issues you found in Responsive Bartik D7 in that issue queue.

tim.plunkett’s picture

Title: Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support) » Convert Bartik's layout to mobile-first and responsive
Status: Needs review » Fixed

This 100+ comment issue was already committed and closed, a follow-up for RTL should be just that, a follow-up in another issue.

effulgentsia’s picture

Someone: please open that follow up for RTL, add whatever relevant information from above related comments to it, and then add a comment here linking to that new issue. Thanks!

mjohnq3’s picture

Title: Convert Bartik's layout to mobile-first and responsive (follow-up for RTL support) » Convert Bartik's layout to mobile-first and responsive
Status: Needs review » Fixed

@ effulgentsia

The patch for RTL is here: #1804446: Add Right-To-Left (RTL) CSS to Bartik

Status: Fixed » Closed (fixed)

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

fubhy’s picture

The patch that got committed here (comment #113) added an grey border around header region. Was there a reason for that? Menu blocks now look pretty ugly because they add a border themselves too.

xjm’s picture

Title: Convert Bartik's layout to mobile-first and responsive » [Change notice] Convert Bartik's layout to mobile-first and responsive
Priority: Major » Critical
Status: Closed (fixed) » Active
Issue tags: -Needs architectural review, -Needs design +Needs change record
xjm’s picture

Issue summary: View changes

Added link to sandbox, since its buried in a post and hard to locate when other posters refer to it.

Gábor Hojtsy’s picture

Title: [Change notice] Convert Bartik's layout to mobile-first and responsive » Convert Bartik's layout to mobile-first and responsive
Priority: Critical » Major
Status: Active » Fixed
Issue tags: -Needs change record

Added change notice at https://drupal.org/node/2011426

Gábor Hojtsy’s picture

Issue summary: View changes

Added link to D7 Backport

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

Anonymous’s picture

Issue summary: View changes

Edited: Correct name and link to D7 backport. Sandbox no longer maintained.

enhdless’s picture

My job for this Google Code-In task was to take screenshots of Bartik on different devices and provide feed back, here is what I got:
The theme looks consistent across the mobile browsers I tested. The exception is Opera, which doesn't display rounded corners. You can take notice of that in the screenshots. Also, on devices with a higher resolution, like the iPad Air, the drupal logo was blurry. On the Galaxy S3, on Firefox, font was displayed slightly smaller than on other browsers. The space inbetween the page header and post title was a bit big. Lastly, for the main title in the header, it would look better if it were vertically centered.

enhdless’s picture

My job for this Google Code-In task was to take screenshots of Bartik on different devices and provide feed back, here is what I got:
The theme looks consistent across the mobile browsers I tested, which is great. The exception is Opera, which doesn't display rounded corners. You can take notice of that in the screenshots. Also, on devices with a higher resolution, like the iPad Air, the Drupal logo was blurry. On the Galaxy S3, on Firefox, the font was displayed slightly smaller than on other browsers. The space inbetween the page header and post title was a bit big. Lastly, for the main title in the header, it would look better if it were vertically centered.

enhdless’s picture

Issue summary: View changes
FileSize
1.92 MB
Shyamala’s picture

@enhdless, Thanks for the great review & screen shots. Do you think you can create issues for the specific issues & link it from here. For how to create an issue refer: https://drupal.org/issue-summaries

Anonymous’s picture

Anonymous’s picture

I am doing a Google code-in (Gci) task.My task is to get screenshots of Drupal 8 site with the bartik theme on different devices .
Throughout all of the devices the theme have been constant Except for the Iphone and blackberry the Header is slightly paler . Another thing is that the extra search block which i have placed in the header only show in the Maxthon browser on the android phone. Otherwise from those problem which i see everything is ok.
Screenshots : https://www.google-melange.com/gci/work/download/google/gci2014/52910435...

lewiking’s picture

I am doing a Google code-in task .My task is to get screenshots of the Bartik theme for Drupal 8 on different devices.
While i was testing and taking screenshots everything looks ok but the blackberry and the iphone header section was lighter than the others(Blackberry,iphone simulated in browser) .Another thing which i realize is that only the maxthon Browser(Maxthon picture,compare) show and extra search block which i placed in the header.
Otherwise fom those simple problem i did'nt find anymore so its ok.
Screenshots;Zip file
screenshots Separate
==================================================
Android phone chrome 1
Android phone Chrome 2
Android phone Default 1
Android phone default 2
Android phone Default 3
Android phone Maxthon 1
Android phone Maxthon 2
Blackberry Browser 1
Blackberry Browser 2
Blackberry Browser 3
iphome browser simulation
iphone4s chrome
iphone4s opera
iphone4s safari
Tablet Chrome 1
Tablet chrome 2
Tablet Default 1
Tablet Default 2
Tablet opera 1
Tablet opera 2