<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The bug wasn't invalid because it was affecting many pages on the public site, and that needed to be addressed. The solution of removing default styling from list items was correct & is backed up by common web standards & practices.<div><br></div><div>I understand that you want to make things easier for everyone who's interested in contributing to OCAL. That's absolutely the right mindset to be in, but, in that instance, you were trying to rely on default styles (which is bad practice, no matter the element) that not only didn't exist on OCAL prior to the pages you created (so it didn't fit in line with current site style), but, in so doing, also broke styling on many pages that anyone could see.</div><div><div><br></div><div>Please file a bug on the launchpad, Chovynz, that describes the list item issues you're having. It's much easier to learn and make progress when you tackle one idea at a time, rather than just throwing a bunch of fastballs and hoping something sticks. I'll be happy to offer solutions to the styling issues your'e having.</div><div><br></div><div>Again, I can safely say that all of us appreciate the time & energy you put into OCAL.</div><div><br></div><div>Cheers,</div><div>+Brad</div><div><div><div><br></div><div><br><div><div>On Feb 15, 2011, at 11:16 PM, chovynz wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">Opened a discussion on mailing list because I agree with you that the bug is closed, but only in terms of it "looking" like it is closed - visually.<br>The far more serious underlying bug is that there is disagreement about how to go about issues like these.<br>
<br>On Wed, Feb 16, 2011 at 4:26 PM, Brad Phillips <span dir="ltr"><<a href="mailto:719544@bugs.launchpad.net" target="_blank">719544@bugs.launchpad.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I don't think changing html structure is necessary either, especially<br>
for styling purposes. They should be separate beasts. All html does is<br>
group elements together, whether it's a list item or a div or a span or<br>
anything else.<br></blockquote><div><br>Ok, answer me this then. Why is the upload button grouped with nothing else? <br>Why is the upload button even a ul il? It need not be wrapped in such, and IMHO should not have been from the beginning - In my view, it is broken structure from the start of OCAL 2.0. The fact is, that when OCAL was ported to aiki, it was un-ready and rushed. Now we need to deal with such things. For these to work, we need some discussion on how to approach them. <br>
<br>I provided a partial solution, and was moving forwards on getting things actually both, good structurally, and good in terms of css.<br>I view what you and Jon having done as having moved backwards in terms of all the things I said on that bug. <br>
<br>What you have effectively done is said "No, Chovynz, don't do that." and undone what I did, without giving me an alternative, and without understanding where I was headed towards it. I want solutions that work. If you say no to something that I am working towards you must give me another way. Not just a No.<br>
<br>That bug was invalid, because the solution (which I provided in the css cleanup) is to style those individual (once off used mostly once per page easily fixed by styling) lists, according to class, or ID that are being used in the incorrect structurally way. The bug and "fix: was rushed through to make the site look good, to achieve the 2.9 milestone, without thought to how it works when there is no styling applied, as to what the actual structure of the site IS. Look at it in firefox sometime, without styling and you will see what I mean. Things are used in lists that shouldn't be. <br>
<br>You say that a structure overhaul isn't necessary, but you are ignoring the structurally wrong way of the widgets and html that are being used. Aiki and css (and php for that matter) is supposed to make things easier on developers, not harder.<br>
<br>Yes, you are correct that html groups things. That is what I am doing, grouping things to logic, where there is not much logic at the moment. Things that don't need lists should be removed from lists, and positioned via css, as well as positoned in teh correct order structurally. That is a structural issue, and a display issue ravelled up. At the moment they are interlinked, and it is my hope that we can unravel the two. <br>
<br>I told Jon there was a partial fix, and I said what the solution was (two sets of ul, one for standard textual lists - unformatted for now, until someone comes up with an alternative, and one for the other ways we use them which removes all bullets and margins + paddings.) I already did all the hard work for achieving what you guys wanted to do, but <i>that solution was ignored</i>, and I don't know why. It's sound, it works, it removes unecessary work, and makes it easy for anyone to make a<i> textual list - of which there will be lots.</i><br>
<br>By the way, I'm not suggesting that ul li can only ever stay unstyled, what I am saying is <br><ul><li>Textual lists need to be lists. In structure, heirarchy, and in display. I can achieve that (at the moment) by leaving that up to the browser. It does no harm, it is flexible in all browsers, and it works. Every browser that I know of will show an unstyled list as a list, with the correct heirarchy - therefore you assertion that it is not good to leave this up to the browsers is incorrect. This is the correct way to go about it structurally. This is the first step in unraveling the css and structure.<br>
</li><ul><li>At a later date, we can style it so that it displays the same on every browser. If that is ever actually needed. (if you were to say that XYZ browser lists lists as what we see currently in the sitemap, then your point would be valid, but for the argument of browser displaying lists correctly or not, your assertion is not valid.) <br>
</li><li>Bullet points and headings/titles make things easier to read. Fact. They lead the eye. In large blocks of text, we need bullets. (or some other visual indicator and eye-line breakup.<br></li></ul><li>Other types of lists, need to be ALSO structurally sound, AND display correctly (i.e. how we intend it to display.) The nav menu list needs the bullet points removed, and custom margins put on. I provided a way to do that. Use it. Don't blanket all lists, without styling the textual lists themselves.<br>
</li><li>Things that should not be in lists, should be removed and these should be styled appropriately, otherwise you are relying on structure things for display. That is the part I don't understand why you are pushing your method. Your method forces others to use certain things and to do extra work, and relies on the css skill levels of others. Mine does not, and allows for future development in the direction of separation of presentation and content, by someone who knows what they are doing, and also allowing anyone to use the html list. Upload button is not grouped with anything, should not be a ul li, and needs to be structurally removed from the list format, and all the unecessary css removed from it. It can be a div, or something else, by why a list item? That doesn't make any sense. Doing so just creates spaghetti css. <br>
</li></ul>What am I not saying clearly? <br>Am I misunderstanding something?<br>Am I saying too much all in one email, or being too generic in my statements?<br>Can you ask me questions so that I can show you my thoughts and goals with OCAL?<br>
I want us to find an agreement on how to go about these things, then we follow that. At the moment there is lots of different "programmer styles" that are not meshing well. <br>
<br>I've worked long and hard on OCAL. I want understanding on both sides, not a brush-off, as was done in the bug. I'm willing to learn, if need be.<br>I've also worked long and hard on OCAL constantly for quite awhile now, so I'm entitled to talk more at this stage - during my rest time. :-)<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div>
--<br>
You received this bug notification because you are a member of<br>
openclipart.devel, which is subscribed to openclipart.<br>
<a href="https://bugs.launchpad.net/bugs/719544" target="_blank">https://bugs.launchpad.net/bugs/719544</a><br>
<br>
Title:<br>
List Items unstyled in various portions of OCAL<br>
<br>
Status in openclipart:<br>
</div> Fix Released<br>
<div><div></div><div><br>
Bug description:<br>
I noticed, when making a new page (/packages-presidents) that certain<br>
elements on the page that had been styled in previous instances of<br>
similar pages were no longer styled. Mainly, the images that are list<br>
items seem to default to basic list-item styles.<br>
<br>
For current examples of this, see any clip art's detail page. I<br>
assume this is related to the css overhaul that is taking place.<br>
Solution is to place "list-style: none;" in the global css files on<br>
ocal so that each <li></li> element won't default to basic styles.<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Cheers<br>Chovynz<br>
</blockquote></div><br></div></div></div></div></body></html>