From: Michael H. R. <po...@mi...> - 2006-02-27 08:36:16
|
> I'd personally prefer keeping H1 and H3 instead of introducing H2 > into the templates as the title and sub title, as that will break > less themes and certainly it won't break my themes since I rely on > the templates containing H1 and H3. It's a long established tradition > I don't think we should change. I use sIFR replacement on H1 and H3 a > lot for instance so chaning to H2 will give me crap fonts again. As I recall, I only changed the heading tag in the Skeleton module (I really don't understand why H2 has been left out in the beginning). That said I would never make such a change to any of the other modules. I am well aware that such a change would result in a great impact, that would affect sites like yours, running some sort of replacement for the heading tags. > You've introduced more tables. Generally, that's to be avoided. In > particular, in the comments module, it makes the form wider. Please > be aware that some users are using fixed width themes that may only > have room for narrow layouts of 400px. Creating forms which have the > label alongside the text entry causes problems for those themes. I > also think adding tables to layout forms is retrogressive. > Personally, I'd be inclined to use a definition list for form layout. That's right, I have introduced more tables. But I have also removed some, replacing them with div's. I am trying to go for a design where we use tables for lists (a list of users, a list of links, a list of notes etc.) and tables for input forms (add user, add link, add note etc.). If you look across phpWebsite today you will see 2 different layout standards for input forms: 1) labels and input fields are listed vertical and 2) label and input field are listed horizontal in a grid layout. In the second approach it is rather common to use a table to construct the grid. Generally we should only use one approach, and I have chosen to go for the grid layout. The last time this was discussed I sensed a positive attitude for the grid layout, which is used in a vast number of CVS designs today, and I certainly dont find this to be retrogressive. I know lots of users a using a fixed width theme. That's why I have added the style "formtable" to all of the input tables I have created, and added the class "label" to the first column and "value" to the second. Using those styles, it should be possible to style the input forms so they doesn't break a fixed width layout. I know the change to the comments module is not optimal. I worked with this small input form for hours, trying different approaches. I finally decided to stick with the grid layout, but if you could come up with a more suitable design, please let me know. If there is a great opposition against the grid layout in the phpWebSite community, I will be happy to remove it, and change it to a vertical look. Personally I find the grid layout to be more tempting and I feel it has a more professional look. But this is my personal opinion, and if the majority feels different, then I am more than willing to drop the grid layout. > If it can be avoided, I'd rather not use inline styles if we're > defining a set of classes now. Seems pointless. Well not to me. I personally think that inline styles can be rather useful. In an ideal world, I would have reworked the html design entirely, causing all existing themes to be deprecated, but on the same time added the ability for styling phpWebSite ala csszengarden. This is however not a suitable approach. Like I mentioned in my previous mail, my first priority was to ensure, that almost all of my changes would work with older css files and those themes already developed to phpWebSite. That's why I have used some inline styles, which mainly replaces existing html attributes like valign, align and nowrap. > I noticed you'd added 'datatable', 'label', 'value' and 'formtable' > classes. These need to be formalised and documented so that users who > may have defined them already in their own themes know they are used. > We shouldn't introduce CSS classes without defining a set that we're > going to stick with going forward in to Fallout. Saying that, I don't > know if Matt's defined a set yet for Fallout so now is possibly our > chance. :-) I have introduced the classes you mention hoping that they can give users and designers a more powerful way of styling phpWebSite. It is my plan that I will try to update the majority of existing 0.10.x modules to use the new styles. It is very important to me to stress out, that the new styles are meant to be optional, and that I don't intent to introduce more styles. Once again I would like to point out, that my decision is due to the fact that I don't intend to completely rework the existing design in 0.10.x. I will leave this to Matt and the upcoming Fallout. What I have seen in Fallout so far, Matt has given the user interface an extensive new look and feel. Take the new controlpanel for instance, with the tabbed interface and matching styles. I am a bit worried about the consequences if we try to mix styles between 0.10.x and Fallout. I believe that styling Fallout will be a whole new experience compared to what we have been used to. I have no plans of revolutionize the look and feel of 0.10.x, but only intend to give it a small face lift, trying to achieve a more consistent design between the different modules. In relation to the naming of the few styles I have introduced, I have not come across those names in any of the existing modules or any 3rd party modules. I hope and cross my fingers that it should be safe to go with the new names. I would like to say, that in my years of experience working with user interface and html design, I have realised that this is one of the most sensitive and controversial areas of developing software. I know that some of my changes could cause a lot of commotion in the community, but please keep in mind that I only plan to give phpWebSite a more consistent look and feel. I do not plan change the overall look of phpWebSite and I do not plan to introduce a table-less design. - Michael (TechElephant) |