Validation XHTML / CSS of the main piwik code

[matt]

The main piwik code should validate XHTML / CSS. The CSS validation should be checked once all the CSS code is inside the CSS stylesheets.

* XHTML =  http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fpiwik.org%2Fdemo%2F%3Fmodule%3DHome%26action%3Dindex%26idSite%3D1%26period%3Dday%26date%3Dyesterday

* CSS =  http://jigsaw.w3.org/css-validator/validator?profile=css2&warning=2&uri=http%3A%2F%2Fpiwik.org%2Fdemo%2F%3Fmodule%3DHome%26action%3Dindex%26idSite%3D1%26period%3Dday%26date%3Dyesterday

The first logical step I can think of would be structure of templates for modularity

• how do other successful open source projects handle their templates?
• how to make it possible to add new themes?

see also #177

[maetrus]

I'm starting work here ... should it be "XHTML 1.0 Transitional" or "XHTML 1.0 Strict"? And also the question is what css version should we use?

I would propose in every templates folder subfloders for css, (local used) js source and images. (With local I mean only this js source which is needed in this special module - for example in Home there is some JS Code in the tpl file.)

[matt]

XHTML transitional is enough. CSS version 2 is enough.

For this ticket the templates and CSS shouldn't be moved or changed more than needed to pass the validation. The patch should only be simple fix to ensure the validation is passed.

After the changes are done it is important to use the UI checklist to make sure everything is still working well.

Have you done some work on this ticket? thanks

[maetrus]

Yeah I did start work on this problem, but it is such a mixery of css, js and html! I will not work on this base of source code if it is not allowed to get a better structure, because if we will work on this way we will have the next ticket for separating the code ...

There have to be a guidline to structure the existing and the code that will be appear in future time.

[matt]

The idea was to simply validate the main index page and the XHTML templates, not the html generated and added with Jquery. This would be a first step :)

[hass]

Here is an example how to make the Flash Applets valid.

<object type="application/x-shockwave-flash" width="100%" height="250" data="<?php print $url ?>" >
  <param name="movie" value="<?php print $url ?>" />
  <param name="allowScriptAccess" value="sameDomain" />
  <param name="quality" value="high" />
  <param name="wmode" value="#ffffff" />
</object>

[milianw]

Hi devels!

I just stumbled upon your project. Main site looks nice with the embedded widgets. But as soon as I tried to run the demo it crashed my browser (Konqi 3.5.9 - already reported on bugs.kde.org). But the crash made me suspicious and I checked the markup in firefox:

What a mess!

Reading through this ticket makes me wonder: If there are developers willing to put their energy into producing better markup, i.e. by using sematic code, putting js+css in external css files etc. etc. - would this even be desired? I mean saying something like

"For this ticket the templates and CSS shouldn't be moved or changed more than needed to pass the validation"

doesn't sound like you are interested at all in these issues. But proper HTML markup is a first step towards cross-browser support (opera didn't work for me eiher).

I'd really like to help here, since the visuals and features look pretty promising. I could even try to work with maetrus in a second branch and we'd merge our work back in later (though that would be last-resort imo, direct work in trunk would be mush saner).

So give me a heads up if you need help in this regard. If otoh you decide to stick to your "we don't care about HTML markup" attitude that's fine with me and I'll search for an alternative.

PS: As I don't know wether I get notified about replies to this thread, make sure to ping me i.e. via email: mail@…

[matt]

milianw, I think I was not clear earlier, and I was sounding too pessimistic :) However I don't believe in "we'll fix this ticket" approach. This is a large ticket, too big actually.

The first logical step I can think of would be structure of templates for modularity

• how do other successful open source projects handle their templates?
• how to make it possible to add new themes?

Then once you come up with a clear idea on how to do things in a proper way:

• organize the templates / CSS

Then only we could start fixing the xhtml issues. My point is that, because we have a bad file/logic templates structure, it's too early to start fixing problems.

If you guys want to be owner of this change, that would be very useful. Let me know!

[milianw]

Ok, so where should such ideas be formed? On the wiki? In this ticket? Where do you guys usually talk about development? Only mailinglists? Or do you have an IRC channel - I could not find one on freenode.

Since I'll have exams the next four weeks or so I won't be able to put 100% into this issue. But afterwards I'd really like to get more into it. And planning etc. can start right now, please just tell me where I should do this.

[matt]

milianw , if there is discussion involved, it's better to post on the mailing list piwik-hackers. If there are pure findings and analysis, this ticket could do. Hope you can come up with good solution for managing piwik templating :)

[milianw]

Ok, lets start:

structure/inspiration

The best template structure I worked with so far is the one of Drupal. If you have never worked with Drupal before, read  http://drupal.org/theme-guide to get a glimpse. Essentially the most important features are:

* core/modules/plugins are shipped with default CSS + template markup * via inheritance and overloading mechanisms I can explicitly change the parts I want. If we have solid, valid, semantic markup users could simply create new CSS-only themes. But if one small thing needs to be changed, no problem - overload the theme function and you are done. Same goes for template files. * pluggable theme interpreters (i.e. Smarty etc.) - not needed for Piwik imo.

how to apply to Piwik

So how could this be integrated with Piwik? The basic directory structure seems to exist:

/themes/default /plugins/home/templates etc.

Yet, most of those HTML files will need to get updated to be valid and semantic. Things like <b> inside some error messages for example should be replaced with <strong> etc.

The only thing what you guys need for modularity is an inheritance / overloading mechanism similar to the one described above. Additionally I'd propose that a few common things get moved from the plugin templates to themes:

- page skeleton / header + footer - navigation - basic widget wrapper: title with close button, buttons at the bottom - possibly more

The first two should be used in both - Home and AdminHome. to get a consistent look.

CSS / JavaScript

CSS and JavaScript files of plugins should be included in the page skeleton / header. It is simply forbidden HTML to load CSS via <link> or <style> inside <body> tags! A simple function call in the controller similar to Piwik_View should be all we need here. In future these files could be aggregated to reduce HTTP requests and make the Piwik backend perform better. Gzipping would be an added bonus.

A special note to JavaScript: It is allowed to include scripts outside of <head> and a best-practice is even to include them right before </body>.

General Cleanup

To get started I'd like to do some cleanup, i.e. fix glaring omissions of alt attributes in images, replace ampersands inside links with their proper &amp; encoding and so forth. Where can I apply for an SVN account? Or do I have to paste my patches on your mailing list to get some trust built up?

[matt]

(In [525]) - improved echo output of DataTable (now showing user friendly output of datatable_Array) - refs #208 hopefully fixed by limiting the number of levels in the Actions table hierarchy - refs #124 started cleaning html code (patch by milianw)

[matt]

milianw, are you still interested to work on the css/xhtml improvements in Piwik? Let us know, thank you.

[milianw]

interested: yes. But it's the old story - I don't have much time. I'll see what I can do, maybe I'll spend some hours on this on the upcoming weekend... but anybody else who wants to do it - step up, don't wait for me ;-)

[matt]

all, if anybody would like to work on this please shout. In the meantime I close the ticket as this is not something we will roadmap as scope is not well defined at this stage. we would be glad to have a contributor investigating this issue though!