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

chovynz chovynz at gmail.com
Sun Jun 27 13:39:01 PDT 2010


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
          o body,h1,h2,h3,h4,h5,h6,p,ol,li,
          o 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/clipart/attachments/20100628/80e6405d/attachment.html>


More information about the clipart mailing list