12 replies to this topic

[squeekit]

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

Edited by squeekit, 07 November 2006, 08:09.

[squeekit]

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'));

[Harald Ponce de Leon]

Accessibility reasons.

[squeekit]

hpdl, on Nov 7 2006, 10:06 AM, said:

Accessibility reasons.

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...

Edited by squeekit, 07 November 2006, 15:45.

[squeekit]

i guess i'm asking for a little education

Edited by squeekit, 07 November 2006, 15:43.

[squeekit]

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

[RL2000]

First off, codewise is much easier on the eyses the way it is now, secondly, having it in a list makes life fun giving more options CSS wise.

My question to you is: Why is this a problem?

[squeekit]

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...


--------------------------------------------------------

RL2000, on Nov 9 2006, 09:20 AM, said:

First off, codewise is much easier on the eyses the way it is now...

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>';

--------------------------------------------------------

RL2000, on Nov 9 2006, 09:20 AM, said:

secondly, having it in a list makes life fun giving more options CSS wise.

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...

hpdl, on Nov 7 2006, 10:06 AM, said:

Accessibility reasons.

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....


--------------------------------------------------------

RL2000, on Nov 9 2006, 09:20 AM, said:

My question to you is: Why is this a problem?

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...

[squeekit]

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.

[squeekit]

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....

Edited by squeekit, 10 November 2006, 02:25.

[RL2000]

Well, I'm not gonna go into whether CSS should be important or not, but you're right that a class should be defined instead of the style being placed in the code, that's very unflexible.

As for having a list, try putting "display:block;" on the links in the box, and you'll see why simply "<br>" won't cut it.

[squeekit]

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


the info in this post is all for fun -- RL2000, you put me in a good mood - thank you for your consideration

Edited by squeekit, 10 November 2006, 14:47.

[RL2000]

Hehe, no problem

I do believe it's a very concience decision to make a CSS tableless theme, but I also think that there's a theme that uses tables, so I think there's something in it for everyone.

Also, I think a good deal of the internet cannot support visually challenged users, due to several reasons, being it lack of knowlegde og simply that the sites do not consider such people part of their userbase.

But no matter if it's a list or break or a span, style should be defined in a class and not hardcoded.