Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
- 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
- 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.
Comment | File | Size | Author |
---|---|---|---|
#151 | Tablet opra browser 2.png | 121.63 KB | lewiking |
#151 | Tablet opera browser 1.png | 77.25 KB | lewiking |
#151 | Tablet default Browser 2.png | 128.65 KB | lewiking |
#151 | Tablet default Browser 1.png | 74.18 KB | lewiking |
#151 | Tablet Chrome browser 2.png | 120 KB | lewiking |
Comments
Comment #1
Jeff Burnz CreditAttribution: Jeff Burnz commentedI'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.
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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...
Comment #3
JohnAlbinInterestingly, 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.
Comment #4
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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.
Comment #5
RobLoachThe first step would be to make it use a Grid system to manage the column widths seamlessly.
Comment #6
watsonerror CreditAttribution: watsonerror commentedthis is a nice grid system, perhaps it can be mimicked or used.
http://cssgrid.net/
Comment #7
Jeff Burnz CreditAttribution: Jeff Burnz commentedNot 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.
Comment #8
jensimmons CreditAttribution: jensimmons commentedI 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).
Comment #9
dOwen-1 CreditAttribution: dOwen-1 commentedI'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?
Comment #10
JohnAlbinI 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.
Comment #11
jpamental CreditAttribution: jpamental commentedI'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 :)
Comment #12
brewthis CreditAttribution: brewthis commentedAgree 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.
Comment #13
tarekdj CreditAttribution: tarekdj commentedHi,
@JohnAlbin: What about this concept ?
For a responsive text we can use fittext
Comment #14
mjohnq3 CreditAttribution: mjohnq3 commentedRe: #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.
Comment #15
Jeff Burnz CreditAttribution: Jeff Burnz commentedYes, 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.
Comment #16
Manuel Garcia CreditAttribution: Manuel Garcia commentedGlad 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.
Comment #17
JohnAlbinThere's some interesting things about navigation in this recent blog post. http://palantir.net/blog/scalable-navigation-patterns-responsive-web-design
Comment #18
JohnAlbinThis should be a priority. There's nothing blocking it. (Unlike other issues in the Mobile queue.) Let's get this done!
Comment #19
JohnAlbinOver 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.
Comment #20
JohnAlbinGood 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.
Comment #21
JohnAlbinLooking 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!
Comment #22
Manuel Garcia CreditAttribution: Manuel Garcia commentedIm 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:
Comment #23
LewisNyman CreditAttribution: LewisNyman commentedI'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.
Comment #24
Manuel Garcia CreditAttribution: Manuel Garcia commentedYep, 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.
Comment #25
JohnAlbinOk, 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?
Comment #26
Manuel Garcia CreditAttribution: Manuel Garcia commentedHere 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:
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.
Comment #27
Manuel Garcia CreditAttribution: Manuel Garcia commentedOOps... forget the last patch, the attached one should apply properly. Note that this is just for testing porpuses
Comment #28
webchickYAY! Awesome to see a patch here! Marking "needs review."
Comment #29
webchickAhem. Actually doing what I said. :P
Comment #30
JohnAlbinI'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.]
Comment #31
Manuel Garcia CreditAttribution: Manuel Garcia commentedOK, 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?
Comment #32
tstoecklerI 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.
Comment #33
Bojhan CreditAttribution: Bojhan commented@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.
Comment #34
mototribe CreditAttribution: mototribe commentedAre 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/
Comment #35
mjohnq3 CreditAttribution: mjohnq3 commentedFor 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...
Comment #36
Manuel Garcia CreditAttribution: Manuel Garcia commentedTwo 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.
Comment #37
mjohnq3 CreditAttribution: mjohnq3 commentedI 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.
Comment #38
tstoecklerNice!!! Looks good.
Comment #39
tim.plunkettCan we see a patch for that? The site looks good.
Comment #40
webchickWow, GREAT job mjohnq3!
Comment #41
Manuel Garcia CreditAttribution: Manuel Garcia commented@mjohnq3 I totaly agree on the source order and the new breakpoint for the sidebars.
Comment #42
Bojhan CreditAttribution: Bojhan commentedComment #43
mjohnq3 CreditAttribution: mjohnq3 commentedPatch for changes noted in #37 -
Comment #44
mjohnq3 CreditAttribution: mjohnq3 commentedOops! Sorry, wrong file name.
This should be correct.
Comment #45
Manuel Garcia CreditAttribution: Manuel Garcia commentedComment #46
mjohnq3 CreditAttribution: mjohnq3 commentedTODO:
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
Comment #47
mjohnq3 CreditAttribution: mjohnq3 commentedPatch for responsive ccs for Triptych and Footer regions.
Comment #49
mjohnq3 CreditAttribution: mjohnq3 commentedTrying again.
Comment #50
webchickBumping to needs review.
Comment #52
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe patch in #44 appears to include HTML5, ARIA roles etc, lets not do that here - just the responsive design please.
Comment #53
mjohnq3 CreditAttribution: mjohnq3 commentedRe-rolled the patch from #49.
Comment #54
mjohnq3 CreditAttribution: mjohnq3 commentedNeeds review.
Comment #56
mjohnq3 CreditAttribution: mjohnq3 commentedDemo site now updated with preliminary changes for all the items mentioned in #46.
http://mjq977.dev4.webenabled.net/
Comment #57
moshe weitzman CreditAttribution: moshe weitzman commentedLooks great on http://iphonetester.com/. I love how the tabs stack.
Comment #58
Manuel Garcia CreditAttribution: Manuel Garcia commented@mjohnq3 Totaly love the responsive navigation
Comment #59
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe 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?
Comment #60
mjohnq3 CreditAttribution: mjohnq3 commentedI'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.
Comment #61
webchickmjohnq3 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!!!
Comment #62
attiks CreditAttribution: attiks commented@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.
Comment #63
attiks CreditAttribution: attiks commentedYour patches in #47, #49 and #53 look incomplete (only 2kb), #44 is 12kb in size. I assume you're missing some files
Comment #64
mjohnq3 CreditAttribution: mjohnq3 commentedI created a sandbox that contains all the changes to date: http://drupal.org/sandbox/mjohnq3/1681742
Comment #65
attiks CreditAttribution: attiks commented@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
Comment #66
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe tricky 32% width main menu items break with long link text.
Comment #67
mjohnq3 CreditAttribution: mjohnq3 commentedYes. 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.
Comment #68
effulgentsia CreditAttribution: effulgentsia commentedFor 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.
Comment #69
mjohnq3 CreditAttribution: mjohnq3 commentedDemo site updated with restructured Primary and Secondary navigation regions.
http://mjq977.dev4.webenabled.net
I'll update the sandbox tomorrow.
Comment #70
Jeff Burnz CreditAttribution: Jeff Burnz commentedWhile 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.
Comment #71
mjohnq3 CreditAttribution: mjohnq3 commented1) 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.
Comment #72
mjohnq3 CreditAttribution: mjohnq3 commented#2 above should say: Secondary links are at the top and will wrap at smaller screen widths.
Comment #73
effulgentsia CreditAttribution: effulgentsia commentedI'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.
Comment #74
mjohnq3 CreditAttribution: mjohnq3 commented@effulgentsia
Thanks very much. It will come in handy for anyone who wants to review the changes.
Comment #74.0
mjohnq3 CreditAttribution: mjohnq3 commentedUpdate to proper issue summary
Comment #75
attiks CreditAttribution: attiks commentedSmall 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
Comment #76
mjohnq3 CreditAttribution: mjohnq3 commented@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.
Comment #77
jessebeach CreditAttribution: jessebeach commentedThe toolbar issue is being addressed separately.
#1137920: Fix toolbar on small screen sizes and redesign toolbar for desktop
Comment #78
attiks CreditAttribution: attiks commented@jessebeach thanks for the link.
Comment #79
sunRemoved all trailing white-space from this patch.
Comment #80
sunbleh. Now for real.
Comment #81
moshe weitzman CreditAttribution: moshe weitzman commentedTo me, this is done. The demo is at http://mjq977.dev4.webenabled.net/ if anyone wants to review it.
Comment #82
mjohnq3 CreditAttribution: mjohnq3 commentedI 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.
Comment #83
Bojhan CreditAttribution: Bojhan commentedComment #84
tkoleary CreditAttribution: tkoleary commentedTried to view the demo on iPhone and got this (attached). Artifact of the demo?
Comment #85
tim.plunkettCross post.
Comment #86
echoz CreditAttribution: echoz commentedOn 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;
Comment #87
jessebeach CreditAttribution: jessebeach commentedThe 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.
Comment #88
jessebeach CreditAttribution: jessebeach commentedThe patch promised in #1192044-87: Convert Bartik's layout to mobile-first and responsive.
Added
left: 0
to.element-invisible
insystem.base.css
.Comment #89
jessebeach CreditAttribution: jessebeach commentedSetting to Needs Review.
Comment #90
mjohnq3 CreditAttribution: mjohnq3 commented@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.
Comment #91
mjohnq3 CreditAttribution: mjohnq3 commentedApplied the fix for the overflow problem in #88 to the demo site.
Comment #92
tkoleary CreditAttribution: tkoleary commentedProblem solved. Displays properly in mobile safari (3Gs).
Comment #93
effulgentsia CreditAttribution: effulgentsia commentedStill needs work per #82, but otherwise I think this is nearly RTBC.
Comment #94
effulgentsia CreditAttribution: effulgentsia commentedDrupalCon 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!
Comment #95
sunSlightly abusing this tag to leverage the @drupalchanges mechanism.
Comment #96
mjohnq3 CreditAttribution: mjohnq3 commentedCompleted 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.
Comment #97
Bojhan CreditAttribution: Bojhan commentedI agree, unless an updated patch is posted lets get this in. This looks really exciting.
Comment #98
mjohnq3 CreditAttribution: mjohnq3 commentedPatch for all the latest changes.
Comment #100
mjohnq3 CreditAttribution: mjohnq3 commentedOk, someday I'll figure it out. <:-|
Comment #101
aspilicious CreditAttribution: aspilicious commentedYou'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:
Comment #102
aspilicious CreditAttribution: aspilicious commentedow wait... your sandbox isn't based on drupal8 but is a custom theme based on bartik...
No idea how to fix that
Comment #103
mjohnq3 CreditAttribution: mjohnq3 commentedAnother try at a patch.
Comment #104
tim.plunkettComment #105
cweagansWhy do we need this?
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.
Trailing whitespace.
Trailing whitespace here too.
Can we take care of this TODO before the patch goes in? Seems like it should be reasonably easy.
Trailing whitespace.
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.
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.
Comment #106
effulgentsia CreditAttribution: effulgentsia commentedSo 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.
Comment #107
cweagansAh, that makes sense.
Comment #108
kattekrab CreditAttribution: kattekrab commentedWow! Great work - just had a look at the demo
http://mjq977.dev4.webenabled.net/
Serious kudos.
Comment #109
aspilicious CreditAttribution: aspilicious commentedDon't feel people akward that they see a different interface wen they turn their ipad?
Comment #110
onco_p53 CreditAttribution: onco_p53 commentedNo 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.
Comment #111
mjohnq3 CreditAttribution: mjohnq3 commented@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.
Comment #112
LewisNyman CreditAttribution: LewisNyman commentedThat 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.
Comment #113
moshe weitzman CreditAttribution: moshe weitzman commentedIn response to cweagans in #105,
left: 0
Comment #114
Dries CreditAttribution: Dries commentedCommitted 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.
Comment #115
effulgentsia CreditAttribution: effulgentsia commentedThose 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.
Comment #116
webchickYAY! :D
Any chance of a D7 backport as a contrib project? :)
Comment #117
cweagansI 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.
Comment #118
tim.plunkettNo way this is backportable. Changing that much CSS is out of the question, and the markup changes are 100% not backportable.
Comment #119
JohnAlbinI 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!
Comment #120
Manuel Garcia CreditAttribution: Manuel Garcia commentedwow this went much faster than I expected, a w e s o m e ! !
Congrats all on a great job, specially @mjohnq3 && testers
Comment #121
webchickThere'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.
Comment #122
tarekdj CreditAttribution: tarekdj commentedThis is a great job thanks everyone. I've found some troubles on RTL display. Patch attached fixes the problem.
Comment #123
tarekdj CreditAttribution: tarekdj commentedHere is an optimised one. Patch size from 405 Bytes to 352 Bytes
Comment #124
tarekdj CreditAttribution: tarekdj commentedPatches #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.
Comment #125
hgurol CreditAttribution: hgurol commentedWe 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.
Comment #126
echoz CreditAttribution: echoz commentedIn #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.
Comment #127
hgurol CreditAttribution: hgurol commentedbowersox, 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.
Comment #128
ro-no-lo CreditAttribution: ro-no-lo commentedQR Code of http://mjq977.dev4.webenabled.net/ for easier testing on mobile devices.
Comment #129
Fannon CreditAttribution: Fannon commentedWorks 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
Comment #130
mgiffordNice 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.
Comment #131
mjohnq3 CreditAttribution: mjohnq3 commented@mgifford
Please see items #110, #111, and #112 above for an explanation of the scaling/zoom problem.
Comment #132
mgifford@mjohnq3 - Thanks! Sorry I missed that when I went to do my quick review.
Comment #133
Anonymous (not verified) CreditAttribution: Anonymous commentedPlease disregard this message.
Comment #134
catchComment #135
Anonymous (not verified) CreditAttribution: Anonymous commentedSome 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.
Comment #136
mjohnq3 CreditAttribution: mjohnq3 commented@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.
Comment #137
tim.plunkettThis 100+ comment issue was already committed and closed, a follow-up for RTL should be just that, a follow-up in another issue.
Comment #138
effulgentsia CreditAttribution: effulgentsia commentedSomeone: 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!
Comment #139
mjohnq3 CreditAttribution: mjohnq3 commented@ effulgentsia
The patch for RTL is here: #1804446: Add Right-To-Left (RTL) CSS to Bartik
Comment #141
fubhy CreditAttribution: fubhy commentedThe 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.
Comment #142
xjmLet's add an "All core themes are now responsive" change notice for these three issues:
#1661814: Make "in maintenance" Seven use a responsive design
#1322794: Make Stark use a responsive layout
#1192044: Convert Bartik's layout to mobile-first and responsive
Comment #142.0
xjmAdded link to sandbox, since its buried in a post and hard to locate when other posters refer to it.
Comment #143
Gábor HojtsyAdded change notice at https://drupal.org/node/2011426
Comment #143.0
Gábor HojtsyAdded link to D7 Backport
Comment #144.0
(not verified) CreditAttribution: commentedEdited: Correct name and link to D7 backport. Sandbox no longer maintained.
Comment #145
enhdless CreditAttribution: enhdless commentedMy 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.
Comment #146
enhdless CreditAttribution: enhdless commentedMy 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.
Comment #147
enhdless CreditAttribution: enhdless commentedComment #148
Shyamala CreditAttribution: Shyamala commented@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
Comment #149
Anonymous (not verified) CreditAttribution: Anonymous commentedhttps://www.google-melange.com/gci/work/download/google/gci2014/52910435...
Comment #150
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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...
Comment #151
lewikingI 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