Jump to content

squeekit

Members
  • Content count

    228
  • Joined

  • Last visited

  1. squeekit

    Information Box Bloat

    RL2000, thank you... thank you very much... "display:block;" is an excellent point... the idea i presented where a classed span is used instead of a list, the "display:block;" only presents two problems, while it still renders very nicely... problem one: every "<br />" would have to be removed.... $this->_content = '<span class="infolinks"> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</span>'; the CSS then could be... .infolinks a { display: block; background: #f4f6f8; padding: 0px 4px 1px 4px; margin: 1px; border: 1px solid #bbc3d3; } .infolinks a:hover { display: block; background: #ffffff; color: #2266cb; text-decoration: none; } this produces a very nice effect - where the entire block becomes a link, rather than just the text. problem two: however, the removal of "<br />" from the html means that if someone who disabled the CSS or replaced it with their own custom CSS views the page it would cause a loss of this area's structure (links would appear all on one line, and wrap) - this is not really an issue if the fact that by default ms3's entire page structure is lost if viewed under circumstances where the client disables the page's association with the CSS (as i stated before, such is the practice for accessibility reasons) - :) - so in this case yes, having these links in list makes sense, but all that sense is lost when considering the generated page in its entirety... and so it seems that in this case the span is not such a bad idea (i perfer the "display:block;" effect better in the above example than when used in conjuction with a list) - also "display:block;" is a slightly advanced notion and i would think someone who is familar with it and wants to use it would know how to find and edit out those "<br />" - more chance of that than a novice trying to figure out the list format of those links... .............................................................................. don't get me wrong, i love CSS and use it to its max -- but, a balance must be established... fact is i moved more heavy into advanced CSS to replace what i use to do with javascript when blocking script became popular -- and so now you know (or can figure out) why i love php :D the info in this post is all for fun -- RL2000, you put me in a good mood - thank you for your consideration :)
  2. squeekit

    Information Box Bloat

    the bottom line... this is not a BIG problem - but it is a problem - a problem in the direction of the fake borders around the info boxes of ms2, where the "border" is actually a containing table... in ms3 i am not bothered with the border of all the "boxContents" actually being made with "boxGroup" - for this only adds flexibility... - i'm mostly bothered with it being an ordered list - that's just absured - i'm bothered that the code jumps out of html just to jump back into html - that is outstanding unnessicary - i'm also bothered that the links are in a list - particularly since the list format is doing nothing - this is in the direction of what i mentioned about "fake borders" in ms2, because it throws an added loop to the coders - it's just one more thing that someone has to figure out >>> and it does nothing! - but above all, i am bothered that i am taking the time to share and explain my findings while little to nothing is explained to me - at least if i take the effort to try to help, i would hope someone would take the effort to consider what i share or at least to educate me... ---- footnote to previous post ---------------------------- <span class="infoboxlinks"> ... </span> where "..." would be all links so one span surrounds all links....
  3. squeekit

    Information Box Bloat

    ok ok - i'll explainn the CSS stuff a little more... IF the list format is important to preserve (for reasons i do not understand yet) then beyond it should be "UL" perhaps it should have a class instead of inline style - like: <ul class="infoboxlinks"> then you can have tons of fun on the CSS... but if you merely desire to target these links via CSS, then perhaps they should be nested within something like: <span class="infoboxlinks"> ... </span> whatever method is used should: - be easy to target via CSS - should not render structually different when dissassiated with CSS etc. etc.
  4. squeekit

    Information Box Bloat

    yes - in a way it looks like i am over reacting - i suppose that is in part because i'm still slightly overwhelmed by the inferior generated html (and inferior CSS) in ms2.2 - i so very strongly do not want to see anything like that again in ms3's final release... with that being said... it seems to me the list format is doing nothing and can only cause confusion in the long run... -------------------------------------------------------- there is no difference in the way the page appears in the browser between the example i gave and the original - so you must be speaking solely "codewise" - and i can not help but feel you didn't even look at my alternative solution... as it is now: $this->_content = '<ol style="list-style: none; margin: 0; padding: 0;">' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li>' . '</ol>'; a suggested alternative: $this->_content = ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')); codewise, you can see not only is what i offer easier on the eyes (i should know, as i've stated i am visually impaired, and so code being easy on the eyes is very important to me) - but, it is also easier on the brain... [ also note: the example above is the one i supplied to create 'new lines' and such alternatively could be done with "\n" if desired ] FYI - as far as the resulting generated html, my alternative is much easier on the eyes... as is now... <div class="boxContents"><ol style="list-style: none; margin: 0; padding: 0;"> <li><a href="info.php?shipping&sid=xxxxxxxxxxxx">Shipping and Returns</a></li> <li><a href="info.php?privacy&sid=xxxxxxxxxxxx">Privacy Notice</a></li> <li><a href="info.php?conditions&sid=xxxxxxxxxxxx">Conditions of Use</a></li> <li><a href="info.php?contact&sid=xxxxxxxxxxxx">Contact Us</a></li> <li><a href="info.php?sitemap&sid=xxxxxxxxxxxx">Sitemap</a></li></ol></div> alternatively... <div class="boxContents"> <a href="info.php?shipping&sid=xxxxxxxxxxxx">Shipping and Returns</a><br /> <a href="info.php?privacy&sid=xxxxxxxxxxxx">Privacy Notice</a><br /> <a href="info.php?conditions&sid=xxxxxxxxxxxx">Conditions of Use</a><br /> <a href="info.php?contact&sid=xxxxxxxxxxxx">Contact Us</a><br /> <a href="info.php?sitemap&sid=xxxxxxxxxxxx">Sitemap</a></div> IF (and that is a big "IF") - IF there really is a good reason why this is in a list format that has not yet been clearly explained to me, then at the least there are still two bogus things about this particular area: 1 - these links should be in an UNordered list and NOT in an ordered list (as they are now) ------ "UL" should be used instead of "OL" 2 - the code should NOT jump out of html only to jump right back into html ------ the > ' . ' < should be removed between the "</LI>" and "<LI>" so at the least the code should be as follows... $this->_content = '<ul style="list-style: none; margin: 0; padding: 0;"> <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li> <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li> <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li> <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li> <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li></ul>'; -------------------------------------------------------- It is how such interacts with the CSS that is one of my main concerns... being that no class is declared for the list and the style is set inline means the way to access it's attributes via CSS currently would be: ol { however, the above means all ordered list would receive such style and such is very undesired... the only way to target the list we speak of, and only this list, via CSS would be: boxContents ol { and still with that, one would have to wrestle with the inline style... basically, as it is now, a coder has to hunt down the page with this code to edit its inline style. BUT - even more important... the way ms3 currently handles its CSS (by default) could mean big trouble, especially considering Harald's reply above... being that "Accessibility" refers to making aspects of computing accessible to physically challenged, particularly the visually impaired, we should consider a common practrice of visually impaired web clients is to substitute their own stylesheets > replacing the stylesheet the page is associated to with their own custom stylesheet. if you look at the pages ms3 generates without its default stylesheet you notice they turn into chaos - losing most all of their structural logic. the CSS should not be so relied upon - the pages should stand on their own without the CSS i could go on and on - but instead i'll conclude with.... -------------------------------------------------------- this is a problem mainly for reasons i've stated (yes there's more), but basically i really like the ms3 version and am only trying to help - my criticism is my compliment - in a way, i'm saying "hey, this is great, it's worth making better by doing this or that" - to me that is more help than just saying "hey, this is great" for ms2 i had to fix its CSS, its generated html, and its PHP -- i am more than glad to help with ms3 -- i've yet much i can share - however, if in my next few suggestions or questions i find they are met with the same answers that explain little to nothing and replies that indicate a lack of consideration of info i offer then i will have no choice but to stop offering help -- as i stated i am visually impaired and so typing info that explains each and every aspect of topics i raise is out of the question, considering how long it takes me to type i can not continue like i have here and replies should be met with much more consideration - i mean heck, by monday i could improve the current ms3 Alpha 3 by 50% at least, if i were so inclined and not share (i know, i looked into it) -- however, as a big thankyou to dev team, i want to share my findings - i know this is a small issue here but if the lack of communication, explainations, and consideration continues i have no choice but to not share... so in a way this topic is like a test run... and that is why i'm putting a little extra effort into all this. at the least i am only looking for satisfactory answers and have yet to receive any...
  5. squeekit

    Issues after install

    KUDOS to Harald.... r1075 < intended for GD intergration
  6. squeekit

    Information Box Bloat

    for text readers???? i'm not familiar with those... you want a "voice" to read the links as "One, Shipping and Returns. Two, Privacy Notice Three, Conditions of Use ...." is that how it would work????? i don't know, because i'm only visually impaired - and not blind - so i only enlarge text - i don't use 'page readers' but still -- IF that is how a page reader works i think the numbers of if "read" would be confusing -- i am familar with 'books on tape' and so i know how such sounds --- i think it would be clearer without 'numbering'... i don't know - as i said i still need some education on this matter :)
  7. squeekit

    osc_products_images_groups Table

    ahhh... super nice :thumbsup: :thumbsup:
  8. squeekit

    Information Box Bloat

    i guess i'm asking for a little education ;)
  9. squeekit

    Information Box Bloat

    sorry i do not fully understand.... to me accessibility refers to things such as font size (making pages accessible to visually impared - as i am) and i do not see how pulling these links out of a list, that i still don't see what it does, inhibits any accessibilty... even if you meant to say "compatibility" (instead of "accessibility") i still do not see how the list format increases compatibility... maybe i don't see how because as i stated, i am visually impared ;) here's the thing - i stay on these seemingly almost meaningless topics till they make sense to me, particularly after seeing all the nonesense in ms2.2's generated html and the vast amount of headaches it's caused the users - so the way i see it, the more osc v3's generated html strays from being straight forward, simple, and efficient, the more the support forum is gonna get cluttered with confusion... if you would be so kind (or someone) to explain in more detail why the ordered list that does nothing is needed...
  10. squeekit

    osc_products_images_groups Table

    they store the specs for how to size a single image to create different images of different proportions for display in different areas of the osc... i personally feel this is a big plus for the osc - it use to be (ms2.2) that smaller images being displayed on the osc pages weren't really smaller at all - but rather they were all big images just being displayed at smaller sizes - this really ate up bandwidth (and page load time) now that osc is going to actually resize images for display means a lot of bandwidth will be saved (and page load times too) :D kudos dev team... side note to dev team (mentioned elsewhere too) > PLEASE use php GD to process images (or a choice to use php GD instead of image magick).............
  11. squeekit

    Issues after install

    my 2 cents... i strongly feel that setting up OSC to rely on Image Magick should totally be dropped! and instead use the php native GD for image processing... please educate me as to any reasons why this could not be done .......... perhaps if there be any real issue.......... a toggle like switch if there be any desire to use this (image magick) or that (php GD)?
  12. squeekit

    Information Box Bloat

    i mean heck, if you want the generated html to have distinctive lines for each link you can easiely: $this->_content = ' ' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br /> ' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap'));
  13. towards the end of catalog/includes/modules/boxes/information.php why are the links in a styled ordered list that does nothing? $this->_content = '<ol style="list-style: none; margin: 0; padding: 0;">' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '</li>' . ' <li>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')) . '</li>' . '</ol>'; why is the code breaking out of the html only to turn around to re-enter it? '</li>' . ' <li>' why not: '</li> <li>' BUT even more important, WHY are these links in an ordered list that does nothing??? WHY not make it simple? $this->_content = osc_link_object(osc_href_link(FILENAME_INFO, 'shipping'), $osC_Language->get('box_information_shipping')) . '<br>' . osc_link_object(osc_href_link(FILENAME_INFO, 'privacy'), $osC_Language->get('box_information_privacy')) . '<br>' . osc_link_object(osc_href_link(FILENAME_INFO, 'conditions'), $osC_Language->get('box_information_conditions')) . '<br>' . osc_link_object(osc_href_link(FILENAME_INFO, 'contact'), $osC_Language->get('box_information_contact')) . '<br>' . osc_link_object(osc_href_link(FILENAME_INFO, 'sitemap'), $osC_Language->get('box_information_sitemap')); eventually you guys are either gonna hate me or love me - cause i'm gonna be bugging you about possible refinements ;)
  14. Robert, this problem was discussed, and i believed a solution offered, a few pages ago - sorry i can't be more specific - iirc, it's back in an area where Vines was posting a lot of messages (perhaps 5 to 10 pages back - maybe less)...
  15. SaratogaSupply, you can perform a comparision of server software, php version, and anything else you think might be a factor -- i'm sure it's easy enough to get such info from XAMPP - as well, such info should be accessible for your webserver... and oh yeah -- super thanks for the info so far (good stuff)
×