ok so i put together a little screenshot of a hypothetical structure for the template completly open to comments and suggestions nothing is real just for visual purposes.
granted this would most likely require a lot of back-end work. I am not familiar with the back-end of how the template engine functions so comments and suggestions based on that knowledge would also be of great use.
Prosilver Overhaul/Modernization
Re: Prosilver Overhaul/Modernization
Looks good to me.
Not a whole lot if we let style.php go.granted this would most likely require a lot of back-end work.
Re: Prosilver Overhaul/Modernization
Ok so further analysis of what I am proposing thanks to a suggestion by igorw and a better understanding of the goal of the RFC process after watching the Libertyvasion event I have realized that this project really needs to be broken down into several tickets.
I am however a little unclear as to weather that means separate RFCs or if an RFC can contain several tickets, I would not think so but I am still trying to understand the process myself.
So here is how I think it should be broken up let me add that perhaps making separate RFCs would make discussion and planning for the easier but I shall leave that to the developers to answer.
Planned Break Down
Ok this is yet another massive post and I apologize for that however this should help the discussion of each point. This is not set in stone either so feel free to submit ideas and changes to this as well.
I feel this should make this daunting task a lot simpler in the end as well as make its fruition faster.
I am however a little unclear as to weather that means separate RFCs or if an RFC can contain several tickets, I would not think so but I am still trying to understand the process myself.
So here is how I think it should be broken up let me add that perhaps making separate RFCs would make discussion and planning for the easier but I shall leave that to the developers to answer.
Planned Break Down
- The complete separation of JavaScript from the template.
- What this entails is as follows
- Move all scripts links to the footer. This does not include scripts that are contained within the theme only those linking to external files.
- Comb through the rest of the scripts contained within the templates and extract all that do not make use of template variables and put them into a new JS file titled scripts making sure to comment on what exactly the script does as well as where it was located and how it is being called in the code.
- Once we have all the scripts removed from the template with exception to those that are using template specific variables we need to begin the rewrite into Jquery. For testing purposes the inclusion of Jquery can be added into the footer as well but the actual inclusion for phpbb will be decided upon in the RFC for it.
- Once we have converted the scripts and tested them to make sure they work, we can move on to the scripts within the template that are using variables. We start by making sure that the variables are in fact needed. If not needed once converted to Jquery then extract it and move it to the scripts file remembering to document. If the template variable is in fact necessary then convert it to Jquery while maintaining the variable, document it but leave it in place
- Next since all of the JS has now been converted to Jquery we need to begin working on all the calls to the functions. We start by searching the template for the original calls and documenting them. Then begin the painstaking task of grouping them by what function they are calling. To make things easier after they are all organized by function, we give all of the elements that contain the calls classes based on the function being executed. This will give us our event hooks. Lastly in a separate file we create all the function calls using Jquery and include this in the footer as well.
- Now I understand that not all of the JS is required for every page, That is why I had said to document it so each function in the scripts file should be first grouped by what pages it is used on if not globally required for several different pages then they should be moved into separate files based on the pages they are used on and the function calls that relate to them should be added to the top of each of those files. The functions that are required on numerous pages should remain in the scripts file and the function for those should be moved to the top of that file. The newly created files should be included at in the templates where necessary but should in fact fall at the bottom of the files.
- What this entails is as follows
- Template Prototyping
- What I mean by this is as follows
In order to make the template simpler for users to modify and create there own themes we need to use more of a modular template structure. As the image in my earlier post hints at or relays this is done by having a main template file for each php file in the template engine as well as a single header and footer file. The names of the files simply reflect the name of the template files. This helps the user to figure out which file needs editing based on what page they are on by the url. The files will utilize a page variable defined at the head of each section with an if structure to display the correct content.
However before we can begin working on this we need to Prototype the theme this also helps with the CSS process later.
What is Prototyping basically it is an in depth look at the theme and the various components or elements we analyze the entire theme looking for all the similarities both in look or design and in code or structure anything that is similar across all pages is separated out into its own include file of the top of my head some examples of this would be the paging and sort. These are two of the more obvious ones others may be very difficult to spot, but by doing this it gives us a very modular template and requires less CSS to accomplish the look in the end since we are essentially creating code blocks. Through the use of the page variable I mentioned earlier we can include one file for lets take the paging for example that contains the paging layouts for the entire theme and using if statements we can choose which block of code to use for each page.
This process gives us one type of include file and if need be we can even give them their own sub-directory with in includes to make it even more organized but that's debatable. There are also larger include files the are for the sub-sections, IE the different UCP tabs I am proposing that each Tab be handled with in the main UCP file via if statements and include the necessary file, the individual sub-sections of the tabs will all be handled with in this one file however through the use of the code blocks the actual code in these files should be relatively small if we did our job correctly.
The naming structure for the include files of both types should go something like this. For Sub-Sections it should go ucp-main.inc.html and for the code blocks paging.inc.html
- Create the reusable code blocks not worrying about semantics fully at the moment just rough HTML structure in order to spot the reusable blocks
- Creation of the primary html files
- Creation of the sub-sections
- What I mean by this is as follows
- Theme Updates, Changes, & Modifications
- Here we make any changes to the layout we feel are necessary either aesthetically or for simplicity. IE removing the search box from the header into the navigation bar and generating on a per page basis via an include file using out new template variable.
- HTML Semantics
- In this section we go over all the newly created files and analyze them line by line making sure that they are using proper semantics
- Next we go through the Template variables and modify the back-end to generate semantic code. It should create elements and not containers.
- Themeing
- This is where all the CSS is done we start by going through the code and removing any in-line css making note of what is used and creating styles to accomplish it for example style="display:none" this is used through out the theme and can easily be replaced with a style called hidden. This one makes Jquery's job easier as well.
- Next we need to do a little back-end in making the forum images use styles rather than in-line background calls
- We then begin by setting up the structure or layout of our css file.
- The layout will consist of several sections we have reset, global, utility, structure, and content for the main sections. We declare a section first, the next line is a description of the section, we then skip a line, followed by the CSS, then we skip another line and finally we close the section it should look like so
Code: Select all
/* @group reset */ //description CSS /* @end -reset */
- For those sections containing sub-sections we add an = in front of the name like so
Code: Select all
/* @group =content */
and each sub section with in we add - like soCode: Select all
/* @group -header */
- The sub sections will be added as needed once the css begins to take form.
- All CSS will be contained within the one CSS file.
- We will only be concerned with the CSS for the main structure or layout of the site that is to say we are not working with any colors, images, or specific fonts we will setup a descent font scheme and some standards for the html tags themselves.
- Once we have our reset in place and our base styles for the html tags which will be located within global we then move on to the structure section and begin styling the hd, bd,ft,lt,cn,rt classes as seen fit to rough out the content structure.
- More classes maybe added to finish the structure in the next step.
- The layout will consist of several sections we have reset, global, utility, structure, and content for the main sections. We declare a section first, the next line is a description of the section, we then skip a line, followed by the CSS, then we skip another line and finally we close the section it should look like so
- Next We code some utility classes that are basically plug and play where needed examples would be a set of classes to accomplish the rounded corners at 3, 5, 9 px making sure to keep class names small. The naming scheme for classes is as follows describe what the classes function is then take the first letter of each word for the example above we would use rc3, rc5, rc9 to represent round corners 3px etc... To avoid duplicate/single letter class names, numbers can be used such as bg1, b2, bg-rd, etc... We can also use the last letter of a word to make the class unique as well as with the 3x3 layout class names hd = header so lets say we want different colors for h2 tags we would make classes like h2rd = red, h2b = blue, h2w = white, h2bk = black etc... This will also include the sprites, we will generate them in this step as well. The image in my earlier post about the structure lays out a guideline for the creation of these images.
- In this step we have finalized the structure and have all of our utilities completed. We move on to styling any part of the design that is left over after inserting all the utilities. Again this should be minimal if we have done our job correctly with the use of utilities and the HTML structure.
- Once we have everything styled we double check it by loading every possible view we can and checking it. Make slight changes as needed. Again if we did our job correctly, this step should not be needed.
- In this step we start by compressing the reset section, then section by section running a clean-css on it which alphabetizes classes and selectors as well as attributes within them. We then make sure all the css is contained in the proper sections and that we do not have any duplicate or unused content.
Ok this is yet another massive post and I apologize for that however this should help the discussion of each point. This is not set in stone either so feel free to submit ideas and changes to this as well.
I feel this should make this daunting task a lot simpler in the end as well as make its fruition faster.
Re: Prosilver Overhaul/Modernization
It has been a long time any discussion or progress has been posted here so I thought about doing a small update here on what was decided so far.
Through discussing this with igorw I have come to understand the template system a little better and we realized that the planned structure would not work with the given system. So some changes have been made.
Here is a summary of what could happen.
I have put up a test board for you to test out and make suggestions and point out problems as I go
Testboard
username: test
password: test
Through discussing this with igorw I have come to understand the template system a little better and we realized that the planned structure would not work with the given system. So some changes have been made.
Here is a summary of what could happen.
- The HTML restructure inclusion with PHPBB may be put off until 4.0 as it may be too much of a change to implement in a minor update and would cause all of the themes in the database to need serious overhauls. I will still work on the theme and finish it but it will most likely be submitted to the database as an additional download for the time being so authors can get used to the changes and plan for them in 4.0 if it is added in.
- The JS portion is going to be handled in the thread created by igorw on jQuery this will be completed hopefully for the release of 3.1 and then I can implement it with the theme then.
- As for the speed improvements to the theme some of them can be implemented to the current theme for transition over to the new version later. Therefore no reason to wait for these they can be added to any of the minor updates as they are completed. However new tickets and RFCs need created for them.
This includes:- Image sprites for forum/post/topic/contact/other icons
- Round corners via CSS3 [MAYBE]
- Header Gradient via CSS3 as a posed to image [MAYBE]
- Forum Gradient via CSS3 as a posed to image [MAYBE]
- Forum Buttons via CSS3 as a posed to image [MAYBE]
- Form Buttons via CSS3 as a posed to image [MAYBE]
- Tabs via CSS3 as a posed to image [MAYBE]
- Backend changes to reflect proper semantic code IE: latest post icon link, approval icon, reported icon, posted by icon, pagination etc....
I have put up a test board for you to test out and make suggestions and point out problems as I go
Testboard
username: test
password: test
- DavidIQ
- Customisations Team Leader
- Posts: 1904
- Joined: Thu Mar 02, 2006 4:29 pm
- Location: Earth
- Contact:
Re: Prosilver Overhaul/Modernization
Looks very odd in IE9:
Looks lots different in FireFox. I'm wondering if maybe the properties you're using just aren't supported.
http://www.impressivewebs.com/css3-support-ie9/
Looks lots different in FireFox. I'm wondering if maybe the properties you're using just aren't supported.
http://www.impressivewebs.com/css3-support-ie9/
Re: Prosilver Overhaul/Modernization
If I had to guess (without looking at the code), there probably a closing tag missing in forumlist_body.html (or whichever file contains the forumlist loop).
A teacher is one who says, "Stand on my shoulders and reach higher."
Honored supporter of the phpBB Group!
phpBB Support: Search
My Blog: Technology Edition
Honored supporter of the phpBB Group!
phpBB Support: Search
My Blog: Technology Edition
Re: Prosilver Overhaul/Modernization
i have not got around to doing the cross browser fixes yet still finalizing the css in firefox and the fonts need completely redone, i copied a lot of values over for temporary purposes
ahh looks like i accidentally hooked in the old tweaks file for ie that might have been y
ahh looks like i accidentally hooked in the old tweaks file for ie that might have been y
Re: Prosilver Overhaul/Modernization
I note that this proposal would imply a switch to sprites which I would support.
In terns of JS marshalling, I have used an approach with another product TinyMCE, which employs a marshaller/ compression callback technique and this seems to work well. (See here for a discussion of this).
I also see that the above hierarchy has dropped the A / A+ /A++ styles, which I also support. I just really don't see the need to load three extra style sheets which simply change the base font size -- something that all current browsers allow you to do anyway, unlike the ability to select custom style sheets. Most users know how to zoom browser windows; I doubt that many know about (changing) custom styles. Drop these.
One last comment. Most boards use one or possibly two languages, so why not embed the language into the generated template? So instead of styles/prosilver/template/viewtopic_body.html generating tpl_prosilver_viewtopic_body.html.php, it generates tpl_prosilver_EN_viewtopic_body.html.php which the language-specific content embeded as literals? That way horrible constructs like can be evaluated once in the compilation process and be replaced by the simple text literal.
In terns of JS marshalling, I have used an approach with another product TinyMCE, which employs a marshaller/ compression callback technique and this seems to work well. (See here for a discussion of this).
I also see that the above hierarchy has dropped the A / A+ /A++ styles, which I also support. I just really don't see the need to load three extra style sheets which simply change the base font size -- something that all current browsers allow you to do anyway, unlike the ability to select custom style sheets. Most users know how to zoom browser windows; I doubt that many know about (changing) custom styles. Drop these.
One last comment. Most boards use one or possibly two languages, so why not embed the language into the generated template? So instead of styles/prosilver/template/viewtopic_body.html generating tpl_prosilver_viewtopic_body.html.php, it generates tpl_prosilver_EN_viewtopic_body.html.php which the language-specific content embeded as literals? That way horrible constructs like
Code: Select all
<?php echo ((isset($this->_rootref['L_LOCATION']))
? $this->_rootref['L_LOCATION'] : ((isset($user->lang['LOCATION'])) ? $user->lang['LOCATION'] : '{ LOCATION }')); ?>
Forum Admin OpenOffice.org User Groups
Re: Prosilver Overhaul/Modernization
I have modified the original post as this RFC has been restructured, simplified and re-scoped. Please read the first post.
Re: Prosilver Overhaul/Modernization
I am admin of the WHATWG discussion forums (forums.whatwg.org). The general consensus is that we naturally want to implement a HTML5/CSS3 standards compliant BBS.
I would be very interested in testing out the forums with redone HTML5/CSS3 markup for use with the WHATWG community.
I am very interested in this effort. Using the newer semantic elements of html5 is a great idea.
<section>, <aside>, <article>, <nav>, <footer> etc. are definitely the way forward and easy to implement.
I also think that web fonts (such as the Google fonts API) and CSS3 transitions are a nice touch, although there is limited support they degrade gracefully.
I think 3.2 is definitely a good time to start the work with new semantics, this will mean a better transition to phpbb4 (as newer elements will already be used).
If anyone has information on potential testing of this modernization effort, please hit me up and I will be happy to test drive it.
Also for reference: http://www.whatwg.org has links to a lot of information on the html spec. And there is a nice spec document designed for the web developers perspective:
developers.whatwg.org
I would be very interested in testing out the forums with redone HTML5/CSS3 markup for use with the WHATWG community.
I am very interested in this effort. Using the newer semantic elements of html5 is a great idea.
<section>, <aside>, <article>, <nav>, <footer> etc. are definitely the way forward and easy to implement.
I also think that web fonts (such as the Google fonts API) and CSS3 transitions are a nice touch, although there is limited support they degrade gracefully.
I think 3.2 is definitely a good time to start the work with new semantics, this will mean a better transition to phpbb4 (as newer elements will already be used).
If anyone has information on potential testing of this modernization effort, please hit me up and I will be happy to test drive it.
Also for reference: http://www.whatwg.org has links to a lot of information on the html spec. And there is a nice spec document designed for the web developers perspective:
developers.whatwg.org