[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Re: table vs div



I'll wholeheartedly say 'yes' to this!

In HTML5 there are plenty of extra input options to help us too (type="email", type="url" etc.).

It would be one thing to rewrite all the 'render' functions to not use tables, but I'm not sure how much there is in the javascript that would need changing.

It's interesting to see how you've approached the jQuery integration.
I'm doing it a slightly different way, calling it in the template and using the 'noConflict' approach:
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"; type="text/javascript"></script>
<script type="text/javascript">jQuery.noConflict();</script>
<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"; type="text/javascript"></script>

I'm not sure which is best!

As for adding id's, this may be tricky to do at a high level (you have a non-repeatable field, id is OK. I have the same field but it's repeatable: id is bad. One approach to this would be to have something in the workflow format to allow adding class/ids to stage/component/field (rubbish example - sorry!):

  <stage name="type" id="eprint-type" class="workflow-start">
    <component class="list-with-explanations"><field ref="type" required="yes" id="eprint-field-type" /></component>
  </stage>

All-in-all though, a big 'yes' to looking at this.
I'd happily take a handful of files and strip tables out of them. Possibly an idea for a distributed JISC project..?

Cheers,
John


-----Original Message-----
From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Denis Pitzalis
Sent: 15 August 2012 20:27
To: eprints-tech at ecs.soton.ac.uk
Subject: [EP-tech] table vs div

Dear all,

I would like to start a discussion about EPrints theming.
I am working on many different installation of EPrints (thanks EPrints 
team for all the support you give to me!) and for every installation the 
question from the final user is always the same: "it is nice, all those 
functionalities and so on, but can you now make it look better?".
Obviously yes, but customizing EPrints in the web2.0 world require lot 
of effort because of the hard coded elements: many of them are tables 
and many of the tables does not have ids nor classes to identify them.
I would propose for the futures version of EPrints to move to a more div 
oriented approach, identifying every item via a class and a unique id, 
in the way modern css works.

This will improve the way the final user create custom themes 
(http://test.michael-culture.org/ a installation I'm working on, with a 
look and feel heavily customized, in alpha test).

I know you guys are working hard in making more substantial changes and 
improvements, but I am ready to help for this kind of changes that does 
not requires advanced perl knowledge. I am also working in replacing all 
the prototype javascript with jquery.

Maybe we can have another branch in your svn to help you guys with those 
changes, adding divs, classes, ids and so on.

Just my two cents and thanks again for the great tool you are working on,

Denis
*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/