W3C home > Mailing lists > Public > public-qa-dev@w3.org > May 2005

Re: (late follow-up on) New proposed styling

From: Terje Bless <link@pobox.com>
Date: Wed, 11 May 2005 13:43:19 +0200
To: olivier Thereaux <ot@w3.org>
cc: QA-dev Dev <public-qa-dev@w3.org>
Message-ID: <r02010500-1039-DFB95B28C21111D9B3FA000D9348908C@[193.157.66.12]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

olivier Thereaux <ot@w3.org> wrote:

>On Jan 6, 2005, at 18:54, Terje Bless wrote:
>>For lots of reasons enumerated previously, I am absolutely and
>>completely against artificially constraining the width of pages.
>
>That was only present in an early sketch, the current version does use
>some margins around the main body of information, but the page width is
>not fixed. Des that put your concern to rest?

Without reviewing the style in depth, if page width is no longer artifically
constrained then that adresses this concern.


>>Yes, use of units in px immediately lands you on the bad-boy-no-dessert
>>list.
>
>At the moment px units are only used for a few
>margin/padding/positioning rules, and not for font sizes. I assume you
>meant "px bad" for fonts only, right?

I meant “px is bad, period.”

“px” is meaningfull only on pixelated media; i.e. on computer monitors. It
scales horribly for even “computer” screens that fall outside a narrow range
of sizes (forget about cell phones, PDAs, and even small laptops and tablet
PCs, or very large monitors). It's an absolutely-specified but media-relative
unit, meaning it has all the drawbacks of not being a relative unit, whilst
also amassing all the drawbacks (unpredictability) of relative units.

The only place it is appropriate to use “px” units is when you're working
relative to an object that is inherently pixel-based such as an image. Given
the root element of URLs on v.w.o is “html” and not “GIF89”, use of “px” units
is not appropriate.


>>Also, the new boxed design breaks the previous design for headers and
>>footers; which were designed to fade into the edge of the window and
>>the background. With the new boxed in design this just looks jarring.
>
>There is room for improvement, here, I agree, although I don't find the
>current situation too horrible.

I stand by my original comment on this.


>>The fonts have suddenly become «fly-shit» (isn't that the term Nick?
>>;D) and hard to read (as they usually do when “designers” get their
>>hands on them).
>
>Probably not applicable anymore, as the main CSS now has:
>font-size: 1em; /* setting base font to user's prefered size */
>line-height: 130%;
>which is, by my standard at least, far from "fly shit"-y.

No, this is fine.

BTW, you're somewhat liberal in your use of line-height. In particular,
line-heights in percent are relative to the inherited value, so “line-height:
110%” is relative to “line-height: 150%” and ends up as “line-height: 165%”
(calculated; relative to base element font size of 1em).

Depending on how these nest and inherit from eachother, of course.


>>The blue navigation bar looks weird; just screaming at you.
>
>I already answered this, I think it's a feature, not a bug. We'll see
>what the feedback gives.

But we still have at least different 4 shades of blue in the header portion of
the page. And the “reverse video” white-on-blue is hard to read. It's offset
into the page so your attention is focussed on that instead of the actual page
content. The interaction with the gif-of-text on the left distracts you so you
look at the header, then to the gif-of-text, and then go looking for the rest
of the page; which, being fairly tones down compared to this stuff, actually
takes concentration.


>>The bakground picture is of dubious value compared to a simple solid
>>color for the background (or even the original white).
>
>yes, and it's been removed. Case closed?

Yes.



>>The orange headings on white are hard to read, and the orange seems to
>>be picked out of the air (where do we use that color in our color
>>scheme)?
>
>I have taken the color scheme from the new WAI design. I don't find it
>illegible, but if it is, I do appreciate the irony of it :)

Not having seen the new WAI design I can't comment on its appropriateness or
lack of; but it's hardly a given that a style design for the WAI pages makes
sense for WMVS.

In particular, and as I mentioned originally, the (orange) color in use is not
a part of the color palette in use — and thus clashes with that palette — and
orange text on a light orange-tinted background is not the most legible
combination.


>I think the current result is visually more appealing that what we have
>on vwo, without being miles away from it

Sure, but there are a number of issues with it.


>(for those allergic to change), and it also tries to be consistent with
>the style being worked on in several areas of the W3C web site.

Not being privvy to these changes I cannot comment on this (sensing a trend
here?).

I'll reiterate that “style being worked on in several areas of the W3C web
site” is not automatically appropriate for v.w.o. By and large the style of
w3.org sucks in so many ways, it's not good enough to be “consistent” with it
without also being _better_ than it.

( “sucks” here being a relative unit of measure; it's always been miles ahead
of the average “design” exhibited on the web! )


>said at the meeting yesterday, except for the comments on this
>mailing-list (almost all of which I have taken in consideration in
>subsequent changes), the response to the design changes have been
>unanimously positive.

So far, all the responses that _I've_ seen have been reserved or outright
negative.


>I think this is a good change. It was not, as you noted, a change  we
>had initially planned for 0.7.0. So what?

The plan for 0.7.0 was to implement Tabtastic — and I had a few other design
changes in mind to improve result pages — but this was brought up in a QADev
meeting __and_voted_down__! The consensus — and, as I recall, this was more or
less unanimous! — was that we should not fiddle with the style more than
absolutely necessary for 0.7.0.


>The plan for 0.7.0 was a hopeful quick merge, a few fixes, and move on,

This was the _hope_, and I'm fairly certain I warned, repeatedly, that this
might not be possible to pull off.

But let me stress that my concern here is not the possibility that style
changes would hold up a release, but rather that we make gratuitous style
changes for every release. The UI should be as stable as possible for human
interface reasons, so in the tradeoff with progress we need to be carefull
that we not let “new => pretty” sneak in as a consideration.


>2) in spite of a few reminders sent, help from "pros" […] never came.

And I believe I warned then — to both you and the “pros” — that experience
shows that such help tends not to materialize once the realization that
changes must be incremental, and you need to committ to long-term maintenance,
sets in.


- -- 
By definition there is _no_way_ any problem can be my fault. Any problems
you think you can find in my code are in your imagination. If you continue
with such derranged imaginings then I may be forced to perform corrective
brain surgery... with an axe!                            -- Stephen Harris

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.2.2

iQA/AwUBQoHv1KPyPrIkdfXsEQLVoQCggPhehdPsxR/7HIbCv9wiKEEDyvEAniyj
enu87nP3RgiXWucWmw5npVsQ
=J15E
-----END PGP SIGNATURE-----
Received on Wednesday, 11 May 2005 11:43:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:45 GMT