BETA feedback for Responsive-Classic in v155-beta

[dbltoe]

Sorry that I haven't had time to investigate this myself.
I was basically wondering if anyone out there has tested the effect of using any solution from the CSS_read_me.txt in a responsive setup. And, if so, what measures needed to be taken (if any) to maintain responsiveness. Does the responsive.css eliminate the need to add any responsive calls to a p_??.css driven page? Do we need a p_??_mobile.css and p_??_tablet.css with the responsive_classic template?
We don't have a test site or customer using any of these and we start our round of rodeos next week through mid- to late-April.
Even if nothing is needed, wouldn't it be beneficial to have the file there? With or without responsive-driven additions, knowledge is power.

[rbarbour]

This is the easiest answer I got!

All the responsive CSS files:

responsive.css
responsive_default.css
responsive_mobile.css
responsive_tablet.css

are loaded via the html_header so they get loaded on every page with the exception for the popup_image and popup_image_additional pages.

On Desktops the popup_image and popup_image_additional window will resize to the images full width, for tablet and mobile devices the page simply open in a new window.

The above responsive CSS files are loaded via the html_header so that they are loaded last and can override any and all rules within the normal stock CSS structure, so no, you do not need separate p_??.css, p_??_mobile.css and p_??_tablet.css files. Simply adding your css to manipulate elements on specific devices should be put in the responsive_default.css file and device specific responsive_mobile.css or responsive_tablet.css file.

I do agree, better documentation is needed.

Sorry that I haven't had time to investigate this myself.
I was basically wondering if anyone out there has tested the effect of using any solution from the CSS_read_me.txt in a responsive setup. And, if so, what measures needed to be taken (if any) to maintain responsiveness. Does the responsive.css eliminate the need to add any responsive calls to a p_??.css driven page? Do we need a p_??_mobile.css and p_??_tablet.css with the responsive_classic template?
We don't have a test site or customer using any of these and we start our round of rodeos next week through mid- to late-April.
Even if nothing is needed, wouldn't it be beneficial to have the file there? With or without responsive-driven additions, knowledge is power.

[picaflor-azul]

This is the easiest answer I got!

All the responsive CSS files:

responsive.css
responsive_default.css
responsive_mobile.css
responsive_tablet.css

are loaded via the html_header so they get loaded on every page with the exception for the popup_image and popup_image_additional pages.

On Desktops the popup_image and popup_image_additional window will resize to the images full width, for tablet and mobile devices the page simply open in a new window.

The above responsive CSS files are loaded via the html_header so that they are loaded last and can override any and all rules within the normal stock CSS structure, so no, you do not need separate p_??.css, p_??_mobile.css and p_??_tablet.css files. Simply adding your css to manipulate elements on specific devices should be put in the responsive_default.css file and device specific responsive_mobile.css or responsive_tablet.css file.

I do agree, better documentation is needed.

Yes, what he said

There is a great readme with some helpful hints included that was included with the new version of the DIY template default. Maybe Raymond can post this or it can be included in the package?

Thanks,

Anne

[rbarbour]

Anne,

The newest version of the DIY template default hasn't been submitted yet, The dev team is still making changes in git so I was going to wait so I could change the readme if needed.

I guess I could submit a 1.5.4readme version and add 1.5.5 later.

Yes, what he said

There is a great readme with some helpful hints included that was included with the new version of the DIY template default. Maybe Raymond can post this or it can be included in the package?

Thanks,

Anne

[lucidlee]

In the stylesheet_colors.css I'm finding what appears to be duplicated elements. e.g.

/*bof background colors*/
#mainWrapper, #headerWrapper, #contentMainWrapper, #logoWrapper, #cartBoxListWrapper, #ezPageBoxList, #cartBoxListWrapper ul, #ezPageBoxList ul, #mainWrapper, #popupAdditionalImage, #contentMainWrapper, #headerWrapper, .sideBoxContent, .rightBoxContent, .rowOdd, #productQuantityDiscounts table, #accountLinksWrapper {background:#fff;}
input:focus, select:focus, textarea:focus, #mainWrapper, .specialsListBoxContents:hover, .centerBoxContentsSpecials:hover, .centerBoxContentsAlsoPurch:hover, .centerBoxContentsFeatured:hover, .centerBoxContentsNew:hover, .categoryListBoxContents:hover, .sideBoxContentItem:hover, .productListing-odd, #pinfo-right, #sendSpendWrapper {background:#f4f4f4;}

In the first instance three ids including #mainWrapper appear to be styled twice as background:#fff.
In the second instance #mainWrapper is now styled background:#f4f4f4

This can't be right, right?

[picaflor-azul]

In the stylesheet_colors.css I'm finding what appears to be duplicated elements. e.g.

/*bof background colors*/
#mainWrapper, #headerWrapper, #contentMainWrapper, #logoWrapper, #cartBoxListWrapper, #ezPageBoxList, #cartBoxListWrapper ul, #ezPageBoxList ul, #mainWrapper, #popupAdditionalImage, #contentMainWrapper, #headerWrapper, .sideBoxContent, .rightBoxContent, .rowOdd, #productQuantityDiscounts table, #accountLinksWrapper {background:#fff;}
input:focus, select:focus, textarea:focus, #mainWrapper, .specialsListBoxContents:hover, .centerBoxContentsSpecials:hover, .centerBoxContentsAlsoPurch:hover, .centerBoxContentsFeatured:hover, .centerBoxContentsNew:hover, .categoryListBoxContents:hover, .sideBoxContentItem:hover, .productListing-odd, #pinfo-right, #sendSpendWrapper {background:#f4f4f4;}

In the first instance three ids including #mainWrapper appear to be styled twice as background:#fff.
In the second instance #mainWrapper is now styled background:#f4f4f4

This can't be right, right?

Thank you for the catch. I'll get an update submitted.

Thanks,

Anne

[DrByte]

The newest version of the DIY template default hasn't been submitted yet, The dev team is still making changes in git so I was going to wait so I could change the readme if needed.

I guess I could submit a 1.5.4readme version and add 1.5.5 later.

I think the core components that affect the templates in v155 are pretty much completed in git ... unless you've got further suggestions we should incorporate. At this point we have no scheduled plans to make further changes in that area.

[lucidlee]

Ah while in OCD mode here's a few more

/*bof background colors*/#popupAdditionalImage {background:#f1f1e0;}
#popupAdditionalImage {background:none;}


/*bof font colors*/
.productListing-rowheading a {color: #ffffff;}
.productListing-rowheading a {color: #ffffff;}


.productPriceDiscount {color:#333;}
.productPriceDiscount {color:#ff0000;}


#navCatTabs li a:hover {color: #ffffff;}
#navCatTabs li:hover {color: #ffffff;}
.categoryListBoxContents a:hover {color:#05a5bc;}
.categoryListBoxContents:hover a {color:#05a5bc;}

Not sure about the last two.

[dbltoe]

Ran into a problem with additional images being larger than the productMainImage when viewed on an iPhone6 in portrait. I noticed that the portrait portion of the responsive_mobile.css has

.additionalImages img{width:90%;margin:0 auto;}
.additionalImages{float:left !important;} 

on line 382 while the landscape did not.
Commenting out those two lines fixed the problem.
It would be nice to have them side by side but, that's a horse of a different waterhole.

[rbarbour]

Thanks for the update!

I do have further suggestions but not specific to this template nor even the template system or this particular version of zen cart. More to do with future extensions to the core to better handle 3rd party frameworks and mobile only features. I will fork 1.5.5 and submit the pull requests for those as time permits but I will fork and submit the pull request for the readme later today.

I think the core components that affect the templates in v155 are pretty much completed in git ... unless you've got further suggestions we should incorporate. At this point we have no scheduled plans to make further changes in that area.