gnuherds-app-dev
[Top][All Lists]
Advanced

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

Re: <div>s based layout -- HTML 4.01 Strict


From: Davi Leal
Subject: Re: <div>s based layout -- HTML 4.01 Strict
Date: Thu, 1 Nov 2007 10:58:09 +0200
User-agent: KMail/1.9.5

Antenore Gatta wrote:
> I'm thinking to a compromise.
>
> 1. Save as HTML
> 2. Cleaning where possible the actual layout.
> 3. As soon as we will satisfy,
> 4. apply changes to templates
>
> again
>
> 1. Save as HTML
> 2. from <table>s to <div>s layout
> 3. ...
> 4. ...
>
> And again with the design and so on

Any step carried out in such way will be OK. I agree.

Just note that IMHO the first step we should realize should be the one we are 
working on, with the Save-as of the home page, to remove the 'main' <table>s 
based layout, which is used by all pages.



> > 2. Logical divisions of content.

> Mine was not a critic about the current division, I think that the
> login/registration menu and the lang menu would be improved.

Great! Obviously any improvement will be good.



> > 3. Look and feel.

> I think that the language menu it's not the best solution because:
>
> - With <div> layout we can keep it on the right, but whit font resizing its
>   position will change.

The relative position of the <div> areas of the www.gnu.org page are kept with 
any font size. So, it can be done! We just have to learn how to do it.

> - If you have a great number of languages the layout will be broken.

It can be true. However, IMHO, we can work on such problem when we have such 
great number of languages.  Now it is working OK, and when we remove 
the 'Beta' flag there will be more room to add more language links. There is 
physical space at least for 7 additional languages.

> IMHO would be better to have a combo box or a menu with hidden elements
> (using css).

A ComboBox will force us to use too a button due to we can not use JavaScript 
to manage the state-change event of such ComboBox.

Showing a ComboBox and a Submit button at any webapp page will raise a worse 
look&feel.

Advantages of the current implementation, which: list explicitly all possible 
languages, and flag the one which being used:

  1. Listing all possible languages the project show to the users and
     sporadic visitors how 'strong it is. Additionally, any user will
     not the possible languages, they will not hidden in a combobox, so
     [s]he can say it to is German friend, via email or chat, "such
     site support too German!".
     Anyhow, more readability.

  2. Just a click change the language. No need to select a combo box and
     click a submit button. So, better usability.

  3. As exposed by Victor, not always a ComboBox is the right solution.
     The current solution offers a better usability.


> I just want to highlight the fact that mine was not a critic about the
> current layout!!! :-)

I am sure there are a lot of things that can be improved!
I will just expose my personal opinion.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]