Prosilver Overhaul/Modernization

[hanakin]

ok again with the HTML5, the goal is not to use it but to prepare for it in a semantic way! via <div class="section> or something like that The main point was that CSS3 Should be used, not that HTML5 should. my other post only points out that there are some minor HTML5 features that are safe to use now as they are not required in the first place for the HTML to be rendered correctly only make it easier for novices to obtain browser compatability.

IE the doc-type and no offense /a3 but having to declare a script as javascript every time is asinine there should be no mime-type for a script element since what else do we use the script tag for other than JS in the theme? Check this out for more info on What can be used to simplify code via HTML5 without JS right now

and @ /a3

sorry but what does

Better structuring of the elements IE the forum list as opposed to being individual divs and different types of lists it should be an OL and a serious of ULs, the DL should be used only for the headings and not the row it self. In other words using html tags as they are ment to be used this is what the term semantics means

As per this topic, I do think the forum list should in fact be tables. I think a few people here were confused and thought the proposal was to bring table layouts for all layout purposes back - not true. When I talk about the forum listing, I mean stuff like

Code: Select all

CATEGORY NAME    |   TOPICS   |   POSTS   |   LAST POST
Forum Name            656         3423      by SampleUser
                                              yesterday, 3:30 pm

Have do do with anything? out of context? No one mentioned anything about the linked topic?

As per what you quoted me saying the plan is to use lists and not tables, infact there will be even less tables in the finished proposal as there is really on like 2 or 3 sections in the theme that it really makes sense to use tables. And the memberslist is defiantly not one of them lol

I think we should move javascript files entirely out of the template and have a js directory on the same level as the imageset/theme/template

Ok but how do you want to handle the calls then through the back-end via a variable to the directory like the styles?

we should stick with XHTML meaning we would use XHTML5 (the XHTML version of HTML5).

That kind of goes without saying I thought.

[/a3]

I agree with pretty much all of your suggestions just two things: I think we should move javascript files entirely out of the template and have a js directory on the same level as the imageset/theme/template and we should stick with XHTML meaning we would use XHTML5 (the XHTML version of HTML5).

For XHTML5, you have to serve it as XML, ie. application/xhtml+xml - at least according to the spec. Won't this be a problem for IE8 and below?

Have do do with anything? out of context? No one mentioned anything about the linked topic?

Wasn't this topic about a prosilver overhaul / prosilver semantics?

[hanakin]

I agree with pretty much all of your suggestions just two things: I think we should move javascript files entirely out of the template and have a js directory on the same level as the imageset/theme/template and we should stick with XHTML meaning we would use XHTML5 (the XHTML version of HTML5).

For XHTML5, you have to serve it as XML, ie. application/xhtml+xml - at least according to the spec. Won't this be a problem for IE8 and below?

Have do do with anything? out of context? No one mentioned anything about the linked topic?

Wasn't this topic about a prosilver overhaul / prosilver semantics?

@ HTML5 yes XML and HTML are separated there are no transitional / strict / html / xhtml differences in HMTL5 it all one beast. With the HTML5 doctype it will accept what you do

@ topic it is a topic about a prosilver overhaul / prosilver semantics, yes but your point was not clear. Who said anything about using tables? Prosilver currently does not use tables for its layout and neither do most professional forums for that matter.

[/a3]

@ HTML5 yes XML and HTML are separated there are no transitional / strict / html / xhtml differences in HMTL5 it all one beast. With the HTML5 doctype it will accept what you do

I was just pointing out that using XML in IE8 and below will cause the user to receive a "save file" dialog rather than view the page. So it would be better to stick with XHTML 1.0, or use HTML5 (and possibly attempting to conform with XHTML5 standards as far as possible).

@ topic it is a topic about a prosilver overhaul / prosilver semantics, yes but your point was not clear. Who said anything about using tables? Prosilver currently does not use tables for its layout and neither do most professional forums for that matter.

I'm not suggesting using tables for layout, and I know that prosilver doesn't currently do that. I am saying that it makes sense to use tables in such a context as the forum listing because there are rows and columns of data. That's something that isn't suitable for unordered, ordered, or definition lists, IMO.

[hanakin]

truthfully thats highly debatable as tables are commonly mistaken for grids tables should in fact only be used for displaying tabular data such as the logs and not for structure which is what we are looking for with the layout of the forum list.

[/a3]

The forum listing is tabular data because each forum has its respective post count, topics count and last poster. The data is not flat like in a unordered/ordered list.

Whether a definition list is more appropriate is arguable, however tables do seem more appropriate if the same data is stored in the database in a similar fashion.

You may wish to read this page: Tables vs. Definition Lists.

[hanakin]

U a correct in assuming that two of the fields appear tabular however the primary field and the latest are no as they do not contain tabular data and these are in fact the most critical as they provide links for user interaction from a design stand point truthfully it could all be combined into a two column grid and would flow better. the use of the separate fields is soley aesthetic if we only list the headings in relation to spaced content within a single div we would achieve the same effect. Therefore since the content is not read in a tabular way we should not restrict ourselves to such a rigid form

[/a3]

U a correct in assuming that two of the fields appear tabular however the primary field and the latest are no as they do not contain tabular data and these are in fact the most critical as they provide links for user interaction from a design stand point truthfully it could all be combined into a two column grid and would flow better. the use of the separate fields is soley aesthetic if we only list the headings in relation to spaced content within a single div we would achieve the same effect. Therefore since the content is not read in a tabular way we should not restrict ourselves to such a rigid form

Technically speaking, you do not have to restrict a table to its "rigid" form - you can use the CSS display declaration to change its form. I'm not talking about aesthetics here, I'm talking about semantics. CSS is used for aesthetics.

<div> tags can achieve the same effect, but the data in the divisions is then not related to the other data in the forum listing. This is what tables are for.

[esg]

Minification, compression and caching

Currently...

• nothing is minified
• CSS and JS files aren't served with cache headers
• external JS files are not compressed (forum_fn.js, editor.js and styleswitcher.js)

We can hit three birds with one stone; with minify we can minify, compress and cache all CSS and JS files. Furthermore, we can use Minify_HTML to minify the templates before they're dumped under /cache. Why reinvent the wheel?


Deprecated practices

Expanding on what hanakin has said, I suggest...

• styleswitcher.js and its associated components are removed; zooming comes built-in in all modern browsers
• the style shouldn't be stored in the database, but dumped under /cache if need be, just like the template files (goes towards consistency and reducing SQL queries where they're not needed)
• the style shouldn't be served from a dynamic URL; this prohibits caching
• language-specific imagesets are abandoned, and all text dynamically generated (goes towards getting rid of the dynamic URL and makes things simpler and more manageable)
• back to top buttons are removed; just like zooming, scrolling's best left to the browser

Design improvements

I'd like to see...

• the search boxes combined, with a dropdown to change the scope of the search, similarly to IPB's implementation
• images not used unless they're needed and stats combined to a single column (views/posts/replies); this helps add emphasis on content, rather than glitter; images I'd say are unnecessary are all the buttons (New Topic, Post Reply, etc.), the latest post icon (could be easily replaced with a '&rarr;'), etc.
• the individual post layout reconsidered, e.g., do we really need to have the WLM/ICQ/etc. buttons visible on the post profile?
• the header reconsidered; I think it'd be a good to have the breadcrumbs and search box be position: fixed to the top of the page
• ...as such, we could remove the 'Board index' link from the footer and the 'Return to the board index'/'Return to <the forum's topic listing>' link from the bottom of the topic/post listing, as they'll be quite redundant

[hanakin]

@/a3

Ok now you are referring to relation and that is exactly what I mean for the forumlist there does not need to be any relation between the topics & posts to the others since it is not required. we do not need or have to know this information it is extra, something that could essentially be displayed via a preference.

On the other hand the primary and latest post sections are a necessity and do need relation to each other, however they as I have already stated are not tabular data as they themselves are not simplistic in nature but dynamic in that any number of features could effect what contents are displayed with in them.

for example refer to the structure adopted by another popular forum software http://www.vbulletin.com/forum/forum.php

do not get me wrong I am not say they did everything correct but they do understand that the forums are a list rather than a table and is a good example of this.

Tables should be reserved for simplistic tabular data and not complexities such as this as the structure is to antiquated and for lack of a better term rigid. From a design stand point they simply fail. The syntax is far to verbose and styling them is an utter horror. They simply are not free from and limit the flow of content.

I am not familiar with what your background in web is but mine is a very code/design balanced background, I work with both and have degrees in both. Both should be considered when structuring the site, not one over the other.

Actually we have gotten off to a huge debate on something that is really moot, let me clarify something. The purpose of this topic is not to completely semanticize the theme. The main focus is to update it to use modern coding practices such as CSS3, proper use of JS, stripping out in-line CSS/JS. Decrease the amount of time it takes to load. Reduce HTTP Requests. And simplify the template to allow easier template modification through simplified code and file structure. The semantics aspect is minimal or a sub-point.

@esg I completely agree with everything you have said