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

[chovynz]

Well it's good to know we can do it right, however I think you 
misunderstood what I was saying. :)
I wasn't blaming anyone, or rather I wasn't intending to. What I'm 
looking for is a common thread and ways forward on how to use aiki.

@ 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.)
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.
3) why are there two stylesheets in the meta?
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.)

Again, I'm not blaming, just wondering how to go about "fixing" the 
things I've found, since it's not as easy as I first thought. I was 
surprised to see how much spaghetti code there is, that's where my 
comments below came from.

Looking forward to an even faster OCAL. :)
Chovynz

On 27/06/2010 5:02 p.m., Jon Phillips wrote:
> Well, the only bad html is the html humans write. So,right, using a
> validation checker and then fixing the problems it points out is the
> right approach.
>
> Aiki doesn't force the html on the user, its up to the user.
>
> So, all these bugs can be fixed inside of aiki.
>
> Yes, simple is so much better and why we switched to aiki.
>
> Go ahead and file a bug about html validation and css validation, but
> even better is figuring out where to fix the bugs in aiki
> installation, and fixing them there...
>
> Jon
>
> On Sat, Jun 26, 2010 at 8:32 PM, chovynz<chovynz at gmail.com>  wrote:
>    
>> Are you guys interested in following web standards for OCAL?
>> Check these out. Some stuff I came across while trying to find out what AIKI
>> was doing to OCAL.
>>
>> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.openclipart.org%2Fbrowse&charset=%28detect+automatically%29&doctype=HTML5&group=0&user-agent=W3C_Validator%2F1.781
>> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.openclipart.org%2Fpackages&charset=%28detect+automatically%29&doctype=Inline&group=0&user-agent=W3C_Validator%2F1.781
>>
>> I suggest we start using aiki with the way web standards are intended.
>> CSS into a collective area, instead of all spread out in their individual
>> pages.
>> Any Librarian should be able to able modify the site as needed, just by
>> adding the basics of
>> <h2>header for below</h2>
>> <p>blah blah sentence being modified</p>
>>
>> The way OCAL is currently written is horrible for webstandards and will
>> inhibit other people becoming Librarians, since they have to know HTML, and
>> CSS, and PHP, AND the AIKI framework usage, to be able to modify the site.
>>
>> Simple is best. Can we make OCAL simple to modify?
>> With CSS and HTML and now with the capabilty of php + Aiki, there's no
>> excuse for sloppy web-coding. Especially now that we are not linked to
>> CCHost in any way.
>>
>> If there are gaps in my knowledge about why this isn't possible with php or
>> aiki please let me know. :-)
>>
>> Cheers
>> Chovynz
>>
>>      
>
>
>