Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to HTML5 #32

Open
ghost opened this issue Feb 8, 2016 · 9 comments
Open

Move to HTML5 #32

ghost opened this issue Feb 8, 2016 · 9 comments

Comments

@ghost
Copy link

ghost commented Feb 8, 2016

Currently there are issues with the html that gets generated. It would be good to move to HTML5 and make sure we are following the w3 specs.

When doing this, we should also make extensive use of class="" to make CSS theming easier.

@alexlance
Copy link
Contributor

Yeah sure. It's probably just a matter of changing the doctype and running it through the validator a few times.

Can you elaborate on what you mean by using class="" to make theming easier?

@ghost
Copy link
Author

ghost commented Feb 9, 2016

If you use class="" lots, it makes CSS theming easier by having simple 'classes' to theme.

In the HTML. e.g.:

<div class="diagram">content here</div>

In the CSS e.g.:

.diagram {
  /* Let's use pink text to be odd. :) */
  color: pink;
}

Is that what you wanted elaborated on? :)

@alexlance
Copy link
Contributor

Ok cool I understand CSS classes, and alloc uses lots of them, no dramas there.

Re theming (and believe me I am open to new approaches eg SASS, LESS whatever), but the way the current themes work is that there is a file css/src/style.tpl which is a template that contains placeholders for the different themes, eg:

table.alloc_calendar td.absent {
    background-color:(CALENDAR_ABSENT_BACKGROUND);
    color:(CALENDAR_ABSENT_COLOR);
}

And when make css is run, it goes through each of the .ini files in the css/src/*.ini, sets the vars, and spits out a theme-specific CSS file in the css/ dir.

So when CSS modifications are required the only files that should be manually edited by a human are in css/src/.

@ghost
Copy link
Author

ghost commented Feb 9, 2016

OK, cool. I've never used SASS or LESS, but they may be worth a look I guess. :)

@cjbayliss
Copy link
Contributor

I feel the best path forward for this is first move our css to SASS. Then port one module at a time to HTML5, e.g. the login page, then the task module, etc, etc.

@cjbayliss
Copy link
Contributor

I've just realized that alloc uses it's own template engine. We should move to a 3rd party template engine as part of this effort, e.g. Smarty or Twig

@alexlance
Copy link
Contributor

Heh, I think you might be biting off more than you imagine.
Ideally it would use a well-supported template engine like one of the ones you mentioned.
Realistically, there is so_much_code that would need to be changed and tested that I don't think the effort is really worth it.
Don't get me wrong, you're welcome to try... but holy shit that energy could surely be pointed in more worthwhile directions!

@cjbayliss
Copy link
Contributor

That is a very good point.

My reasoning to shift to a 3rd party template system (not sure if I'll do this or not, but putting the reasoning here anyway) is:

  1. Security. Smarty and Twig are actively developed with security issues fixed relatively quickly. We don't have the resources to constantly maintain every aspect of alloc and deal with security issues quickly. Using well maintained 3rd party libraries is ideal.

  2. Potential contributors already know either Smarty or Twig, and can contribute faster. There is public documentation. I feel if we can make alloc easy and a nice experience to contribute too, we may end up with more users and contributors.


Another problem that I noticed when working on PR #49 is how the html is mixed between templates and PHP files. Figuring out where I had to make the change took me about 1hr, that can be quite off putting for new contributors. Regardless of whether we use a 3rd party template engine or not, we should try to keep the main PHP code and html templates as separate as possible with the switch to html5


Oh, the other thing, I looked into SASS and LESS. Personally I prefer the way SASS works, are you in favour of using SASS or LESS? Both Debian and Fedora have sassc in their repos, and since most distros are based on them, we can probably uses sassc as the compiler.

@alexlance
Copy link
Contributor

All good - totally reasonable reasons.

Re CSS compiler, I'm happy to defer to your expertise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants