[Petal] OT: Re: Javascript and things (was: Another rewrite problem with Petal)

[Jean-Michel Hiver]

> I highlighted with underscores the keywords in the sentence above. That's 
> the difference--we're dealing with different contexts. I'm developing 
> sites for clients who have customers--you're developing a site for 
> visitors interested in your personal info.

True, true, however you'd be amazed to see that all the websites we do
for clients have pretty much the same philosophy. The idea is that what
makes a good website is not the eye candy, but the functionality...


> The site I pointed you to earlier looks and functions fine in IE, 
> Netscape, Opera, and Mozilla with or without Javascript enabled. Yeah, it 
> looks better at 800x600 or 1024x768 than it does at 1600x1200 but it 
> doesn't break at those resolutions. I gear the sites I build towards the 
> average visitor. 

I did look at it in mozilla, and it looks alright... on one quarter of
my screen. Mind you, the good thing is that I can put 4 sites like that
on each of my virtual desktops :-)


> One of the great things about Petal is that I can begin to hone the output 
> even better depending on the client accessing my site. I can now build my 
> content once and distribute in the best format to multiple clients--cell 
> phones, PDAs, or standard desktop browsers.

Yeah, except that if you accept a couple of extra constraints (i.e. no
fixed width tables, no fixed fonts, things like that) then you probably
won't need to maintain all these templates at all. Less work... good :-)

But then I don't really care, I'm not the guy who writes HTML
templates...


> In the meantime, me and my clients would rather the sites to look good on 
> the majority of platforms (i.e., desktops with modern OSs and modern 
> browsers) than to look bad under all.

Well, I believe beauty lies in simplicity, and the web is no exception.
Besides, eye candy tends to distract the user, altering the website's
usability.

It's the same as with cars. The most beautiful ones are functional and
have very simple, pure lines. They don't feature pop-up warning messages
when you exceed speed do they? :-)


> Have you even looked at the site I mentioned with Mozilla? Except for the 
> friggin' Java applets in the header which are outside of my control, it 
> looks and functions just the same as it does on IE. Sure the table is 
> built for an 800x600 screen but that's the majority.

> I didn't design that page format either, but do you really open web
> browsers in full screen on an 1600x1200 screen?

Yes. And I increase the font size. Except that when the tables are
fixed-width it might not always work right.


> What's the point of all that screen real estate if you're still using
> it like a 15" monitor?

But as a matter of fact I'm not. I legitimately want the fonts on my 22"
at 1600x1200 to be roughly the same size than if I was using a 15" at
800x600. Which is why I need to control the font size. Which is why
fixed-width tables are annoying me.


> Point is that most people are looking at web pages like a piece of
> paper. If/when screen sizes become as large as newspapers.

Now I believe that this statement is covered by the new XHTML 2.1 <bs>
tag.

When I was freelancing in Paris I have worked with a graphic designer
who was previously working in the press industry. To design the
webpages, she used to launch XPress first to make up her model, and then
convert it to HTML using dreamweaver.

Of course these people do see the screen as a piece of paper! That's
what they've been doing for the past 10 years, looking at a computer
screen as if it was a piece of paper!

However, if you tell me that the users see the screen as if it was a
piece of paper, then I'm The Queen Of England. I mean, when I'm using my
palm pilot to read an ebook, I'm not flipping through screens... I
_scroll_ through one big page.

My point is that screens and paper, although they have the same purpose
(delivering information to the end user), are different kinds of
technologies. They are not meant to be used in the same way. Therefore,
designing sites for screens by looking at them as if they were paper is
IMHO a big mistake.


> I bet we'll see more columns on websites (as we saw when the avg size
> jumped from 640x480 to 800x600). In the meantime, I find most
> designers build sites in the same style as magazines.

Sure people are going to continue doing that kind of stuff. But my bet
is that the most successful sites will also be very simple to use and
will have the very bare minimum amount of eye candy.

But then again I might be wrong... maybe we'll see the emergence of two
webs. A flashy, candy one with plenty of ads and popups and javascript,
and a more dull one, which would limit itself to delivering content.

Well, if that's the case I want to work with the second one. I like
useful things, not flashy things.

I mean maybe all that stuff is mainly a matter of philosophy...
sometimes I feel like civilization is going backwards. It took humanity
thousands of years to find the secret of writing, and we start using
fucking icons everywhere again! Isn't that bad?


> > Yes. Besides XHTML attributes are supposed to be all lowercased.
> 
> Well, there's the answer then. In building the workaround, my Javascript 
> has now been properly modified to support XHTML. I think 
> that's a fine answer as long as you document it for those of us not as 
> familiar with the X* standards <g>. If you decide to support case-
> sensitivity in attribute names, perhaps that should be an option that by 
> default is turned off for XHTML output since it's not truly valid. I like 
> the idea of Petal enforcing proper syntax although that does create more 
> work for you. Not to mention that it'd be nice to tell Petal *not* to 
> enforce syntax in some cases.

Dunno... maybe I'll need to put up a OAQ (Once Asked Questions) on the
Petal website when I get around to doing it :-)

Cheers!
-- 
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
  Jean-Michel Hiver - Software Director
  jhiver@mkdoc.com
  +44 (0)114 255 8097
================================================================
                                      VISIT HTTP://WWW.MKDOC.COM