[Clipart] Web standards with OCAL (+Aiki / OCAL development)

[chovynz]

If you say such things, then identify to me the areas that need their 
own styles - be specific, not general.

What I'm seeing is that we have a bunch of css coding on their 
individual pages, that could be fixed by putting them into one. One, not 7.
<p> should be uniform, no matter where it is used on OCAL. Right now we 
have 7 different <p> styles, that are exactly the same, or just slightly 
different enough that they should be the same. I was working on the 
Pre-Beta Version with Michael and Vera so I'm aware of a number of CSS 
that are in our current site, that should have been cleaned up when 
switching to Aiki.

There are a bunch of other css that can be merged into one style as 
well. From my point of view I'm working towards what you are asking for 
- small css file, and fast access. On properly coded css the file size 
can be small, compact, and fast. There is no valid reason for the way 
OCAL's css is currently used, and if you say "for the display" then I 
counter with "cssZengarden", or "Bluerobot".

I will discuss the solutions with the mailing list; I'm just gearing up 
in finding out specifically where the problem areas are. You can help by 
pointing out to me, those ones you know of that need their own display.

Have a cup of tea and relax. :)



On 29/06/2010 4:03 a.m., Jon Phillips wrote:
> Ok, please don't make all the CSS in one place. There should be a
> global style css, but it is necessary for modules to have their most
> custom css for display.
>
> Its a good system.
>
> Yes, creating test pages is a good idea, especially if you are making
> them not accessible to normal users during testing.
>
> Bassel, I wonder if there is a preview or duplicate function we could
> introduce that would make a lot of sense. Also, some form of
> versioning would be quite helpful.
>
> Jon
>
> On Sun, Jun 27, 2010 at 1:39 PM, chovynz<chovynz at gmail.com>  wrote:
>    
>> Thanks for your reply. Mine below. I've stripped out the irrelevant parts of
>> the email.
>> What I intend on doing from here is:
>>
>> Identifying things that can be turned into their own modules, instead of
>> being combined parts of coding in the individual pages.
>> Identifying the same css that can be applyed to different parts. These would
>> go in the styles.css I would think? These should include basics that woudn't
>> change such as
>>
>> body,h1,h2,h3,h4,h5,h6,p,ol,li,
>> any custom divs we do
>>
>> Eventually I want to end up with all the css in one place.
>> Removed redundant css, cleaned them up, and using longhand version so that
>> others can learn quickly by using the source code if need be.
>> At the end I'm intending on having good clean nice source code, without the
>> individual styling I see currently,
>> Css and code structures that validate properly (Note to self : Automatic
>> style sheet will disappear after css removal from widgets. This will fix at
>> least one validation error.)
>> Emailing you and Jon, and clipart, on this thread so that we can check "my
>> work" and all can collaborate on this, and to raise awareness of what is
>> being done, and what needs doing.
>> Do we have a test site? I can work on the live site or the test site, and
>> there are benefits to both ways. I think Jon would prefer we use a test
>> site, or maybe some background pages that people don't have access to,
>> actually, then would be good too, since....
>>
>> Ok, Jon and Bassel, would you be happy if I set up a "mock-test-site," under
>> the actual OCAL? What I'm thinking is making a copy of a widget page, for
>> example the "Upload page", then renaming the copy as "MOCK TEST PAGE". One
>> person would use this page that only has a direct link for now, or only
>> admins/librarians/site developers have the link to test their changes on the
>> live site, without modifying the actual pages themselves. Then we gain the
>> benefits of being live as well as not needing to set up another actual
>> server for testing. I hope that made sense.
>>
>> On 27/06/2010 9:27 p.m., Bassel Safadi wrote:
>>
>> Hey Chovynz,
>>
>> On Sun, Jun 27, 2010 at 8:32 AM, chovynz<chovynz at gmail.com>  wrote:
>>
>>
>> @ Bassel : For CSS, how do we apply global css? I can't figure out why:
>> 1) aiki is collating all the style sheets into one output based on widget (I
>> mean , I can and understand why it is doing that, but can we do css a
>> different way? currently it breaks the validator since there is no tag
>> called "widget" and the stylesheet reference is invalid.)
>>
>>
>> this is only one way of doing css by adding it the CSS field inside
>> the widgets, the reason this type of css is used because it's easier
>> to build each section's widgets and style them in the same place, but
>> then when one finish building a site it's easy to move the css to
>> global css, but in case of ocal there was a lot of crapy css code
>> inside the first mockup that was imported to aiki ( like thousands of
>> lines ) , I totally agree with you that we should clean up the code..
>> to fix this we should first (hight priority) clean up the css, then
>> move the whole css ( automated process) to style.css ( more on this
>> bellow)
>>
>>
>>
>> 2) The *about *page has css, then *participate *has its own exact same css,
>> then the other pages and div's have inline css, rather than a global css.
>> e.g.<p>  is defined about 10 times in the collated amount, instead of one
>> parent<p>  with a good style applied once.
>>
>>
>> totally agree, this is wrong and it can easily solved by moving the
>> whole css to one place
>>
>>
>>
>> 3) why are there two stylesheets in the meta?
>>
>>
>> the auto-generated style.php?widget and style.css which is actually a
>> widget that contains the cc, once we don't have any css inside the
>> widgets the auto-generated one will vanish
>>
>>
>> That's actually pretty cool! I like automation.
>>
>>
>>
>> 4) How can me, a "normal non-programmer" add global css to the site? Nothing
>> I tried worked with *style.css *or with *global_css*. I input css code both
>> into the content of the widget, and into the style of the widget, at
>> different times. I was expecting the change to happen straight away. Is
>> there a delay in CSS and database updating or is it instant? If it is
>> instant, then something might be either broken, or I don't yet know how to
>> do this seemingly easy task. (I should mention local-inline- css is fine and
>> works ...sort'of.)
>>
>>
>> yes you can add to (style.css) widget but there is cache system that
>> need purging before the changes show up, if you have server access you
>> can type nc localhost 8181 then purge.url style.css*
>> otherwise please just give me a notice on irc or by email and I'll
>> empty the cache for you each time you do changes. or if you want to
>> work continually on that widget for one session tell me before and
>> I'll disable the cache for this until you finish.
>>
>>
>> Ok. I thought as much, but I wasn't sure. How can I gain server access since
>> I'll be working the css over many times and it would be more prudent for me
>> to be able to do that myself. Or would you rather I ask each time? - in one
>> sense you doing the disabling is good because of accountability. I can work
>> with what I have at the moment, so I don't need server access and that would
>> be fine too.
>>
>> Actually, don't give me server access, I'll just ask for a block of time,
>> each time. Can you please disable the cache for three days starting from
>> this email? Can I do that? Is that safe to do, and what would be the side
>> effects of disabling the cache?
>>
>>
>>      
>
>
>