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

Jon Phillips jon at rejon.org
Mon Jun 28 16:23:14 PDT 2010


On Mon, Jun 28, 2010 at 2:00 PM, chovynz <chovynz at gmail.com> wrote:
> 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".

Cool. small and fast great.

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

hahaha :) I actuallly and literally am doing that now.

Go for it chovynz!

Jon

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



-- 
Jon Phillips
http://rejon.org/
http://fabricatorz.com/
http://status.net/
http://rejon.status.net + skype: kidproto
+1.415.830.3884 (sf/global)
+86.187.1003.9974 (china)



More information about the clipart mailing list