Re: [WSG] IE7 b1 :/

2005-08-01 Thread Jeroen Visser | vizi


On Jul 31, 2005, at 3:19 PM, Justin Carter wrote:


IE7 will be far from a disappointment. Sure Beta 1 doesn't seem to
give us anything much new and the UI is a bit topsy-turvey but I think
it's mostly due to the fact that it has come straight out of Longhorn
(Vista).

From the IMPRESSIVE list of fixes and newly supported features posted
on the IE blog I think that IE7 is on the right track, and the fact
that Microsoft have shared this information with the community is one
of the most positive things to come out of Redmond in a long time.

As a developer I'm quite satisfied with what I've seen so far, and if
they can get the UI right then the end-users might be quite satisfied
as well! I can't wait for Beta 2 to give it a real workout :)


Hear, hear!

I agree that the recent communication from the IE development team is 
exemplary. These people have convinced me more than Robert Scoble has 
done in his still pretty MS-tainted approach to blogging.


It's time for the o so sceptical standards missionaries to wait for the 
proof of the pudding. They might be surprised at the taste of the new 
browsing Microsoft is cooking.


Jeroen

**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Longhorn Avalon - seismic shift for web standards?

2005-07-15 Thread Jeroen Visser | vizi


On Jul 15, 2005, at 2:54 AM, Paul Ross wrote:

[From a PC mag article]


In a nutshell, Avalon means developers are now free to code without
considering the resolution of users' monitors. This ensures that apps
developed in this environment will work on just about any display,
from mobile phones and PDAs to wide-screen notebooks and high-end
desktop systems.


I would say that this statement is not the complete story. The 
available canvas still is of interest to web developers and coders -- 
whether the OS works with pixels or Bezier curves. Basically, the 
users' human factors, combined with the monitor's width, height and 
resolution, determine how many menu items (or icons) will fit next to 
eachother. A 23 widescreen display still would offer a lot more space 
to organize content, branding and navigation than a typical handheld 
device. Don't throw your dedicated handheld-optimized version out of 
the window yet.



What does all this mean for the web standards community? Am I reading
too much into this by thinking this is a seismic shift in the way we
could be building websites in the future? In particular - what are the
implications in the XHTML/CSS path versus something like Flash?


If you want scalabale vector graphics online, I'd still go with Flash. 
It'll take some time before a version of IE with the necessary 
XHTML/SVG/CSS support has a strong enough user base to warrant a switch 
from plugin to browser-only.


Jeroen

**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**



Re: [WSG] Need some MAC screen grabs

2005-02-17 Thread Jeroen Visser [ vizi ]
Jacobus van Niekerk wrote:
Hi all,
I need the MAC girls  guys ;) to help me out. Can you please send me a
screen grab of the following url
http://www.parachute.com/te/smallbusiness/
Heard of http://www.browsercam.com/ perhaps?
Jeroen
PS: your character encoding is going bazerk (windows-1250?), better to 
fix that on an international mailing list. ISO-8859-1 will do just fine.

--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] DTD is a formality?

2005-02-15 Thread Jeroen Visser [ vizi ]
Kornel Lesinski wrote:
The issue at hand is that [productname] is completely
compliant, but is more modern than HTML 4.01.  If you
remove the doctype tag, all your rendering issues
should be resolved.
This is sooo untrue. If they require invalid HTML,
their product is NOT compiliant.
Funny you reach that conclusion just on the OP's mail (in which te 
makers of the menu state it to actually be compliant!). If the menu at 
hand is written in valid XHTML strict, for instance, putting a 
HTML4.01/trans DTD in top of the html _will_ cause validation issues and 
_might_ cause rendering issues.

If you remove doctype, browsers emulate
IE5 invalid CSS interpretation. Far from being modern.
I would dare say that this is at best partially true. Opera sure tries 
to emulate IE when it is told to do so (and even emulates some parts of 
IE's behaviour while in 'Opera' mode), but I'm not so sure that a Gecko 
in quirks mode mimics IE on purpose.

Removing the tag will
solve your rendering problems.
...will cause...
Why?
I'd get rid of that menu. It *needs* browser *bugs* in order to work!
Is this menu accesible when:
- javascript is off?
- styles are off?
- styles and js are off?
- keyboard is used to navigate?
The sequence of your advice and questions suggest you are assuming all 
answers to be 'no' beforehand, whilst you haven't seen any line of the 
menu code whatsoever.

I'm sorry if my reaction feels a bit harsh, but jumping to conclusions 
like this just doesn't help the standards' case, does it? ;-)

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] DTD is a formality?

2005-02-15 Thread Jeroen Visser [ vizi ]
Sam Brown wrote:

The issue at hand is that [productname] is completely
compliant, but is more modern than HTML 4.01.  If you
remove the doctype tag, all your rendering issues
should be resolved. Using one of our older and
backwards compatible menu packages might be the only
solution if you must have the doctype tag. However the
doctype tag is really a formality used for checking
compliancy and nothing more. Removing the tag will
solve your rendering problems.

I was not aware that a DTD was a mere formality. In my
experience, operating without a DTD puts most browsers
into Quirks mode which, by its very definition, isn't
a standards compliant rendering mode.
Basically, my purpose for sending this is to acquire
more understanding of the purpose of the DTD. Is it
there to set the rendering mode, or is it, as this
support person purports, simply a formality?
Russ's response covers the purpose of adding a DTD to your HTML code 
(DTD meaning Document Type Declaration in this situation - not to be 
mistaken for Document Type Definition, to which the declaration actually 
refers).

A now common 'feature' of DTD's is that it puts modern browsers into a 
specific rendering mode (quirks, almost-standards or 
standards-compliant). [2]  You already know this part, I understand, but 
this effect of a DTD is not what DTD's 'are there for'. It's just a 
handy way for browsers to deal with the fact that the _large_ majority 
of web pages is a 4th generation legacy that just isn't going to go 
away. And it's pretty hard to market a browser that renders only a 
handful of real-world sites (apart from all the geek webdev blogs ;-).

So -here it is- the world is not perfect, the majority of web users 
still surf with IE5.x or 6, the latter possibly having more issues with 
standards-compliant code than with tagsoup. [2] Some web developers 
purposefully keep IE6 out of standards compliance mode, because this 
saves you from coding two separate IE css files in some cases.

In this particular case, you may want to:
- try and find out to which standard the menu is coded and use that for 
your own code as well;
- or try and convince the makers of the menu to provide you with a 
HTML4.01 version (could be hard to achieve ;-);
- or ditch the menu (which apparently is out of your reach);
- or ditch the doctype.

I'd try the first option, but when that fails, stick with the last. 
Pursuing standards is not the way to go if this could result in a 
majority (!) of your visitors not being able to use the menu normally.

[1] http://hsivonen.iki.fi/doctype/
[2] http://www.positioniseverything.net/
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Advantage of word-wrapping? (was: Re: [WSG] double space after period)

2005-01-23 Thread Jeroen Visser [ vizi ]
David R wrote:
I do have a relevant question relating to this problem: Is there any 
advantage in word-wrapping markup'd paragraphs?
The most important situation in which word-wrapping is useful is with 
justified text. Good word-wrapping prevents awkward word spacing in such 
text, rendering it more legible.

There are a few pittfalls though, with word-wrapping: it is language 
dependent and browsers are basically morons with regard to text-handling 
in general and word-wrapping in particular.

The only element I know to provide predictable word-wrapping is [wbr], 
but this is a non-XHTML element, thus needing a modified DTD which 
includes this element. And then again: [wbr] doesn't add a hyphen when a 
word is actually wrapped, so it is mainly useful in wrapping URL's and 
the like. The soft-hyphen (shy;) is sometimes used for wrapping 
purposes, but it was never intended for such use and produces 
unpredictable results across browsers.

Word-wrapping will only become a viable online typesetting option when 
browsers are capable of tapping into an OS provided spelling/wrapping/ 
grammar system. In such a situation, I can imagine a browser actually 
picking up [lang=] attributes in mark-up to switch between wrapping 
rules and authors only needing to specify 'on' or 'off' for 
word-wrapping, e.g. through: p { word-wrap: (auto|no-wrap); }.

Until then, I just don't use any justified texts online. ;-)
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] empty named anchors

2005-01-20 Thread Jeroen Visser [ vizi ]
David R wrote:
Andy Kirkwood | MOTIVE wrote:
I have come across a couple of instances of this where headings have 
been enclosed in an anchor, i.e.

   a name=anchor id=anchorh1Heading text/h1/a
This causes the text colour of the heading to change when moused-over 
(although not a link). From an interface perspective this can be quite 
confusing. (A feedback cue that suggests interaction is possible when it 
is not).
This is why a:link:hover and a:visited:hover are preferable over simple 
a:link

:)
Maybe I've missed some standards or accessibility point, but I'm 
accustomed to coding as follows:

h2a name= id=/aSome heading/h2
Jumping works like a charm, and no hyperlink behaviour other than that 
ever shows up. Afaik, there are no problems with this method whatsoever, 
plus you don't rely on CSS to prevent a particular GUI behaviour.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Non-validation and web standards

2004-12-28 Thread Jeroen Visser [ vizi ]
Lyn Patterson wrote:
Bert and Jeroen
Your advice much appreciated.
You're welcome.
Am blushing as I report that when I removed ALL the hacks, the site 
stayed the same and it now validates perfectly.  I think those hacks 
came from a very early attempt  at css and I just kept putting them into 
stylesheets. I haven't tested in older browsers yet but it looks OK in 
current ones.
No problem, I've been there myself. Next to writing CSS rules, deleting 
them can also prove to be very enlightening. ;-)

Good luck with the site,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] pop quiz: calculating specificity of group selectors

2004-12-15 Thread Jeroen Visser [ vizi ]
John Allsopp wrote:
OK,
thanks for all the answers, I buy them :-)
That would be four cents then, please. Anything else?
;-)
Jeroen Visser
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Learning to design Accessibility

2004-11-26 Thread Jeroen Visser [ vizi ]
David McDonald wrote:
Try the W3C as a good starting point:
http://www.w3.org/TR/WAI-WEBCONTENT/
http://www.w3.org/TR/WCAG10/
http://www.w3.org/TR/WCAG10/full-checklist.html
http://www.w3.org/TR/WCAG10-TECHS/ 
And possibly --as 2.0 is in its final stages--:
http://www.w3.org/TR/WCAG20/
This second version of WCAG is set up in a somewhat different way than 
WCAG1.0 so it may be of interest to learn about them before it actually 
becomes a W3C recommendation.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] 88x31 WSG Buttons?

2004-11-24 Thread Jeroen Visser [ vizi ]
Peter Tilbrook wrote:
[request for a 88x31px WSG button]
Get. A. Life. 
I always find it funny that people who post such replies do not seem to 
grasp the inherent reciprocal nature of them. Make my day! :-)

For Mike: if no button in that particular size exists, you could do a 
proposal based on the 88x15 version. I doubt that our fellow WSG members 
would disagree --just make sure the 'WSG style' is sustained.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] forcing IE6 into quirks mode

2004-11-20 Thread Jeroen Visser [ vizi ]
Gunlaug Sørtun wrote:
Wayne Godfrey wrote:
Enjoy your upcoming Mac, I know you will.
So I've been told by many. Hope to have an iMac up and running before
x-mas (have already paid for it). Now I only have a dual-processor high
speed multi-tasking workstation with multiple screens, and support-units
with more screens-- all running win2K-pro.
Not bad for a carpenter. ;-)
I think your iMac will fall silent in such company. :-D
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] forcing IE6 into quirks mode

2004-11-19 Thread Jeroen Visser [ vizi ]
Gunlaug Sørtun wrote:
Jeroen Visser [ vizi ] wrote:
Gunlaug Sørtun wrote:
I know of no limitations in IE6 when doing this, and it saves some 
coding too. The improved box-model isn't reason enough to debug 
several versions of IE/win. IE/win can be made to almost behave like a 
good browser should-- in quirks mode.
It's really weird. On one side (Robert Scoble's IE wishlist entries) 
developers are screaming that IE should adhere to standards (box model, 
XHTML as application/xhtml+xml etc), but when there's actually some 
progression, you stick to the nineties' quirks approach. ;-?
I don't belong to the group of screaming developers.
Hi Georg,
Sorry for this misunderstanding --I didn't mean to group you in any way. 
  It's just that I was a bit amazed about your view when in general, 
the web standards 'society' regards IE as the largest obstacle in 
standards-compliant webdesign. To me it seems that 'we as webdesigners' 
 (pro or amateur doesn't matter) should show some appreciation towards 
MS for steps they do take, not just complain about what they don't do.

I _stick to_ the 
browsers which are giving me what I want; Opera, Moz/FF, Safari...
If Scoble wanna know what I want, he can surf over to W3C and take a 
look. The rest is just noise-- to me.

I only support IE/win because I can, not because it matters to me. IE6 
is less of a problem in quirks mode, because it doesn't need so many 
alterations to a page that works well when developed in Opera and the 
other good browsers. I don't like to kill browser-bugs in more versions 
than I have to. Guess I'm lazy. :)
I can understand that you want to minimize the number of hacks and time 
invested in them, but I don't think a designer's opinion on a browser 
matters. If a majority of visitors to his clients' site use IE/win, then 
he should cater for that. And in my opinion he should do that in the 
best possible way (i.e.: use IE6 standards mode whenever possible).

Also; it's easier to code for Lynx when I don't have to change things to 
make IE6 happy. _That_ matters to me.
Could you explain this to me? In the end, the website visitor matters. I 
think we agree on that. But if I were to choose between using an extra 
hour to improve a design for 80% (or more) of the visitors or using that 
hour to improve it for a browser like Lynx (or Omniweb, or iCab, for 
that matter), I'd go for the 80%.
Don't get me wrong: I'm all for semantically correct, usable, accessible 
and standards-compliant sites that look great and degrade gracefully. 
But practice --as usual-- is far different from such theory, and every 
designer has a limited supply of time and money for any given project, 
so you have to choose how and where you invest your resources. I think 
those resources should go where they have the largest impact on the 
largest audience.

If / when some software are reasonable in line with the standard code I 
use, it will be supported by me. That includes everything Microsoft 
launch-- but only if it is up to the job.
Can you point to a case where IE is not 'up to the job'? What 
constitutes 'not up to the job'?

Once again; my preference is Opera-- latest stable version available at 
any one time. Those of you who make a living out of web design may, 
reasonably enough, have other preferences and priorities.
Which browser I use is not that important (other than that developing in 
Mozilla is faster and more reliable than in IE, for instance). What the 
people out there use, who visit the site I design, that's important.

Thanks for the example. I'll look into it. Maybe I'll use it-- if IE6 
will behave on all the rest.
For more background information on the exact differences between IE6 in 
standards mode and IE5+ quirks:

http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Usability dogma's [was Re: [WSG] Font size]

2004-11-18 Thread Jeroen Visser [ vizi ]
Felix Miata wrote:
David Laakso wrote:
 
Jeroen Visser [ vizi ] wrote:

I myself set a base size on the body element (most of the time 76%
like Owen Briggs) and then use em's to set up the rest of the typography.

Hmm, 76% on the body element, thats 24% smaller than my default? Kinda
tough on us older folks.
David, you understate the problem.
I don't know why there's this 'designers who reduce browser base font 
size are evil' attitude. I go with Owen Briggs, who relates browser 
default size to general OS GUI elements' font size.

If I follow your and Davids train of thought, I can bet that I get 
several reactions by visitors 'complaining' that the type is so large, 
and if I can't make it smaller (no, I'm not kidding).

Bottom line: there's no general _rule_ you should apply as a designer, 
other than that for every design decision you should have a good reason. 
I.e.: you never should apply something just because 'you feel like it', 
but instead have arguments why you do it that way --be it usability 
concerns, market or site audience analysis, or conceptual/design aesthetics.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] forcing IE6 into quirks mode

2004-11-18 Thread Jeroen Visser [ vizi ]
Gunlaug Sørtun wrote:
Terrence Wood wrote:
Does anyone on this list deliberately force IE6 into quirks mode?
Yes, always... :)
No, only if it's necessary and unavoidable, e.g. in Eric B. Bednarz's 
fixed-positioning solution: http://devnull.tagsoup.com/fixed/.

I have seen this done on a couple sites (ok...one), where the site has a 
comment in the first line before the doctype ( = quirks mode ).the 
notion of doing this seems attractive  at first glance because you can 
lump IE5, 5.5 and 6 together and develop for a single IE box-model.
If you want to flip IE6 into quirks, the only way would be to place an 
XML declaration before the DTD. As far as I know, no other elements are 
allowed before the DTD.

Are there any other benefits/limitations of doing this?
IE6 seems to be more stable and predictable in quirks mode than in its 
almost standard mode. I use IE-expressions to get 'max-width/min'- 
imitations to work in IE6, and they are almost always killing IE6 in 
almost standard mode.
My gamble: you're referring to 'document.body.clientWidth', whereas this 
object doesn't exists in IE6/standards mode. Instead, IE6 then uses the 
DOM-compliant 'document.documentElement' approach. If you use 
expression() in CSS rules for IE, you should check for IE6 to be in 
'CSS1Compat' mode before choosing element notation:

width:expression(((document.compatMode  
document.compatMode=='CSS1Compat') ? 
document.documentElement.clientWidth : document.body.clientWidth)  780 
? 780px : auto);

(Just an example.)
I know of no limitations in IE6 when doing this, and it saves some 
coding too. The improved box-model isn't reason enough to debug several 
versions of IE/win. IE/win can be made to almost behave like a good 
browser should-- in quirks mode.
It's really weird. On one side (Robert Scoble's IE wishlist entries) 
developers are screaming that IE should adhere to standards (box model, 
XHTML as application/xhtml+xml etc), but when there's actually some 
progression, you stick to the nineties' quirks approach. ;-?

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Font size

2004-11-17 Thread Jeroen Visser [ vizi ]
Javier wrote:
I'm trying to develope a site with proportional font size.
I've seen people that apply a font small in body and then use em's in all
other settings. I've seen people that apply a 65% font-size in body, others
a 100%, etc.. and then use em's in other settings but others use
percentage...
Now I'm really confused...
Hi Javier,
All the trouble of font-size in a nutshell:
http://www.thenoodleincident.com/tutorials/typography/
I myself set a base size on the body element (most of the time 76% like 
Owen Briggs) and then use em's to set up the rest of the typography.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Site-Check:

2004-11-17 Thread Jeroen Visser [ vizi ]
Felix Miata wrote:
Kristof Rutten wrote:
http://www.sportopolis.be
12px body is bad, bad, bad.
You make it sound like Kristof is your little puppy who has just taken a 
leak on your precious new carpet. ;-/

A little explanation or a link to background info would've been nice.
For Kristof:
http://www.thenoodleincident.com/tutorials/typography/
This pretty much covers the issues involved: typography, design 
decisions, browser hick-ups and usability.
You can also check out the font-sizing page at the CSS-discuss wiki:

http://css-discuss.incutio.com/?page=FontSize
Good luck,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] (another) Site Check :)

2004-11-17 Thread Jeroen Visser [ vizi ]
Dave Elkan wrote:
Fellow WebStandardites,
I've just finished my first site since moving over here to the UK from 
Australia.
Unfortunately for that reason I don't have all of my equipment with me 
and to make matters worse we don't have a mac testing station here at 
work.

Is there any chance someone could have a look at this site in ie5 for 
mac and tell me/take a screenshot so I can see how horrid it looks?

The URL is http://www.wallpaper.com
Thanks for your help!
Hi Dave,
Wellcome to Europe for starters, then. :-)
It must be really a treat to design a site for Wallpaper*, or am I too 
biased by the style of the magazine? ;-)

I've looked to your page in IE5.1.7/MacOS8.6 and Mozilla1.3.1 (same OS), 
and there are a few problems:

http://www.vizi.nl/temp/wallpaper/ie517.png (28 KB)
http://www.vizi.nl/temp/wallpaper/mozilla131.png (102 KB)
So the searchbox is a problem in Mozilla, causing the layout to be 
stretched broader than you probably intend. In IE, the footer section 
floats beside the header, so the page gets really wide.

IE/Mac is notorious in floats, so I guess a little bit of googling 
should give you a hint for a solution.

Ciao,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] The Lindsay Method, version 2

2004-11-15 Thread Jeroen Visser [ vizi ]
Lindsay Evans wrote:
In order to stop Russ from hassling me about it every time I see him,
I've thrown together a small demo/explanation of the latest  greatest
image replacement method (well, 'fancy heading method', really):
http://lindsayevans.com/experiments/lindsaymethod_2/
Just to be somewhat annoying: what are the advantages of your method 
over sIFR2? Despite (or thanks to) its dependancy on Flash, it has a 
broader support (IE/mac, Opera, Gecko, Safari). If I would be a frantic 
typography guy, I'd use sIFR. ;-)

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] pt, em and ex

2004-11-15 Thread Jeroen Visser [ vizi ]
Felix Miata wrote:
Jeroen Visser [ vizi ] wrote:
 
'px' is the worst unit to define
font size in, as Internet Explorer still cannot increase or decrease the
size of fonts set in pixels.
pt is worse. IE can't resize it either, and it depends on both DPI and
resolution, not just resolution, making its ultimate size even more
difficult to predict.
Ack.
Common accessibility and usability practice
is to allow visitors the freedom to adapt font sizing to their personal
preferences.
I don't think common is the best choice of word for that sentence,
unless you take the word common to mean something merely more than rare.
It really isn't that common yet except among students of accessible
design. Best or good would be better choices.
Obviously you're right. Consider it wishful thinking on my part. ;-)
Pixels are not a relative unit; they're as absolute for screen rendering
as point sizes are for the printing press.
IOW, the problem is that px is not relative to anything inside a browser
viewport, the only place the term relative has relevant meaning in the
world of CSS. Unfortuately, the CSS spec makes people think px is a
relative unit :-(
http://www.w3.org/TR/CSS21/syndata.html#value-def-length
Reminds me of a discussion on Bugzilla covering a rounding error that 
Gecko introduces while computing layouts because the engine internally 
works with a smaller virtual 'pixel' which gets converted to screen 
pixels only afterwards. :-)

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] The Lindsay Method, version 2

2004-11-15 Thread Jeroen Visser [ vizi ]
Lindsay Evans wrote:
No Flash, works with scripting turned off, text is selectable (yes, I
know you can select the individual sIFR bits, but that just ain't the
same :)), colours, size, etc. are easily manipulated via. CSS,
As I have understood, you can select large text blocks with sIFR also; 
you just don't see the headings being selected (this is a serious flaw, 
dont' get me wrong, but you can select textblocks).

probably has a better chance of being understood by screenreaders that
are in use today.
Would be nice if someone could test this (sIFR vs @font-face) with Jaws 
and a tactile viewer (braille). This is especially interesting as most 
accessibility applications tap into IE's rendering engine.

I'm sure there are ways around it in sIFR, but from what I can see it
doesn't scale the text according to user font size preferences, or
obey user style sheets.
sIFR scales headings to the box available at script execution, basically 
allowing you to set the size in the stylesheet. It doesn't do dynamic 
scaling (i.e. scaling after document load), however, which is a pity.

Plus it just doesn't feel as 'hacky' to me :)
Anyway, it's just an idea, if you want more control over typography,
then go with sIFR (or get Quark  start doing print design :p)
Am there, doing that. ;-)
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Question to the others ...

2004-11-14 Thread Jeroen Visser [ vizi ]
Marilyn Langfeld wrote:
Hi folks,
My first post, since I've worked in print longer than web. In print, an 
em (and en) are mostly used to describe dashes (of the width of M and N) 
in a font. So they are appropriate to the task when used for that. They 
have been slightly redefined for the web (since an en is not always half 
an em).
Hi Marilyn,
To add to your posting: and the capital M or roman m are nowadays not 
really an em or en wide.

An em is a unit of measurement defined as the point size of the 
font12 point type uses a 12 point em. An en is one-half of an em. 
http://www.alistapart.com/articles/emen/
An excellent explanation of the em and en units:
http://css.nu/articles/typograph1-en.html#Ch23
As always, someone has dug up al the idiosyncrasies that made id from 
the physical world to the digital space. :-)

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] pt, em and ex

2004-11-14 Thread Jeroen Visser [ vizi ]
Mary Krieger wrote:
Barring browser weirdness for a brief utopian moment, is this the way it is 
supposed to work.?

In order for any text to appear, someone somewhere has to have chosen a 
font face and size. So choosing to use relative rather than absolute units 
for font size moves where the decision occurs.
Precisely. This also is the reason why 'px' is the worst unit to define 
font size in, as Internet Explorer still cannot increase or decrease the 
size of fonts set in pixels. Common accessibility and usability practice 
is to allow visitors the freedom to adapt font sizing to their personal 
preferences.

If the stylesheet belonging to the page uses an absolute unit like pt to 
set the size of the base font, the browser will attempt to use the page's 
stylesheet to set the default font size.
The specified author stylesheet will almost always be used; only an 
!important in a user or browser stylesheet will override this. See:

http://www.blooberry.com/indexdot/css/topics/cascade.htm
If the stylesheet belonging to the page instead uses the relative unit % or 
ems to set the size of the base font, then the browser will set the default 
font size relative to the local machine's default stylesheet's font size. 
Here 1 em behaves the same way as 100%.
What happens is that instead of forcing an absolute reference font size 
(in px or pt), you take the user's font size as the basic type size..

If the stylesheet belonging to the page instead uses the relative unit px 
to set the size of the base font, then the browser will set the default 
font size relative to the local machine's resolution.
Pixels are not a relative unit; they're as absolute for screen rendering 
as point sizes are for the printing press.

If the remainder of the font-sizes in the stylesheet are set with relative 
units, the page should retain the size relationships of the page's 
stylesheet no matter where the decision about default font size occurs.
Unless the user declares he wants to see h1 elements at 400% of the base 
font size. ;-)

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Site Critique

2004-11-14 Thread Jeroen Visser [ vizi ]
Laurie Keith wrote:
Hi,
If any of you busy people have a spare 15 minutes, can you give me an honest
evaluation on our new corporate web site.
http://www.createwith.com
Hi Laurie,
Others have cracked down on the Flash thing, so I'll focus on some other 
issues. Basically, it's a clean, neat site, but it has some problems:

- The site doesn't show the usual 'hand' cursor when hovering a link. 
While this may look cool at first, it is a serious usability problem. 
The hand cursor is the single most effective way to say: 'this is a link'.

- The scrollbar on the Press page is a bit 'under designed'. :-) If you 
choose to use Flash, make the scrollbars blend in with the overall 
design; a standard Windows bar just is out of place, so it seems.

- Why the arrow in the top right? Why not maximize the width of the 
Flashmovie in the first place? Bonus: it looks better, too.

- The small type in the portfolio sections (the text under the images) 
is pretty hard to read; I'd suggest to (a) increase the font size, or to 
(b) take a lighter weight _and_ to make the type pitch black, or to (c) 
disable anti-aliassing for that type.

- The placement of the submenu is not really logical. I understand the 
design choice to place the menus on top of each other, but I'm a graphic 
designer, so that doesn't really count. ;-) My guess would be that the 
feedback (I click on Work and there's a submenu for this 'Work' section) 
would be much stronger if the menus would be next to eachother, or if a 
line or other visual clue would connect the highlighted menu-item with 
its submenu in the bottom half.

The portfolio is pretty neat, so it's a pity the rest of the puzzle 
doesn't really fall in place to convince people to stay and click around 
(and that's what this site needs, right?).

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] 10,000 posts, we have a winner...

2004-11-12 Thread Jeroen Visser [ vizi ]
russ - maxdesign wrote:
OK, we have decided to give the person who did the 10,000th post a prize
(thanks to Core member David McDonald for the idea).
Re: Web Standards Eye Candy: http://www.scottschiller.com/
By Nick Lo - Fri 12 Nov 2004 at 10:33 PM
So, what does Nick win? One free copy of Apache Essentials: Install,
Configure, Maintain from Friends of Ed:
http://www.friendsofed.com/books/1590593553/
Congratulations to Nick!
(Just wondering: what if Nick is an IIS developer? ;-)
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Re: It's all in the MIME

2004-11-11 Thread Jeroen Visser [ vizi ]
Alan Milnes wrote:
So does anyone have a link to an article which can tell me how to
properly serve up application/xhtml+xml using PHP?

Jeroen Visser shared
http://www.workingwith.me.uk/articles/scripting/mimetypes/ as a link
before... that tells you how. The datestamp on the message was Thu, 11
Nov 2004 01:48:36 +0100 if you want to read the original.
Thanks - unfortunately it seems to have some errors - no content type is
sent and Firefox seems to have problems with it as well.
Why is the content-type not sent? What errors or warnings does PHP 
display? What content-type _is_ sent? What problems does Firefox have?

Some possible reasons for this script not to work:
- headers are already sent out by PHP;
- one ore more conditions are too narrow or wide (especially if regular 
expressions are used, as in the above example);
- your application conflicts with the output buffering in the script.

The script on the above URL is not something to just cutpaste into an 
exisiting PHP application. I guess it would need some tuning and work to 
integrate it into an exisiting site. For example, this script also 
buffers all PHP output to transform it into HTML4.01 for IE and other 
non-XHTML-savvy user agents. For most sites, you could strip that part 
and serve XHTML1.0 corresponding with the HTML4.01 compatibility 
guidelines. In that case, you only need to switch the content-type 
header and need not tweak the actual HTML document.

Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Re: It's all in the MIME

2004-11-11 Thread Jeroen Visser [ vizi ]
Alan Milnes wrote:
Why is the content-type not sent? What errors or warnings does PHP
display? What content-type _is_ sent? What problems does Firefox have?
Some possible reasons for this script not to work: 
- headers are already sent out by PHP; 
- one ore more conditions are too narrow or wide (especially if regular 
expressions are used, as in the above example); 
- your application conflicts with the output buffering in the script.
Thanks for your feedback.  I put it into a test site to try it out -
I've actually tried a lot of these scripts but not gotten any of them to
work satisfactorily yet!
My pleasure! I know it's sometimes frustrating when a script doesn't 
work the way you would dexpect it to, but also that it is very 
satisfying when you get it to work and see the results. :-)

I have now gone back and spotted a mistake that I made and it now seems
to be working fine!
That's good news!
For some additional info: I usually perform three tests to make sure 
these content-type things work properly:

- Firefox infopanel should show 'application/xhtml+xml';
- IE/Win shouldn't pop a 'save as' dialog but show the site
  (the dialog is the sign you're serving application/xhtml+xml to IE);
- the following testpage of a friend of mine shows 'text/html':
  [http://sandbox.bednarz.nl/http/get.html?host=www.google.comuri=/]
(Just to be concise: fill in the host and uri of the page to check 
instead of the 'www.google.com' and '/'.)

Good luck,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Vertical Alignment of Relatively Sized Text

2004-11-11 Thread Jeroen Visser [ vizi ]
Paul Farrell wrote:
I have a series of floats in a header. In particular I have a string of text
on the right marking the spot for a date script output. I would like to know
if anyone knows a way I can maintain an alignment where the bottom of the
date string is aligned to the bottom of the text in the logo as a user
increases/decreases font size.
Hi Paul,
You might want to check out Doug Bowman's article on the positioning 
solution for the menu at http://www.adaptivepath.com:

http://www.stopdesign.com/articles/absolute/
In this article is the answer to your question. While it might not be an 
exact 'baseline' match, I think you can get very close if you tinker 
with the technique Doug describes.

(For something totally different: I would advice against using [h3] for 
your date script output. Use a [span] or [div] instead, maybe a [p], but 
reserve [h3] for a real heading at the third level of a document structure.)

Good luck,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Creating Nice Pop-Ups

2004-11-10 Thread Jeroen Visser [ vizi ]
Mark Harwood  wrote:
Hey list,
Right im using the good old methord of nice pop-ups as shown by
by idol youngpup (http://youngpup.net/2003/popups) now as soon
as you use onClick in your HTML WebXACT and Bobby throw up a fit
saying that it does not pass AA thanks to 9.3 Make sure event 
handlers do not require use of a mouse.
Now that is why I don't like these automated 'get yourself a Johnny 
Accessibility approval' sites. I can't see what is wrong with extending 
the plain href= with an extra feature for able UA's with 'onclick'. 
Just make sure you get the thing to fall back gracefully.

Which my links dont require, now what im wanting to know is there away
to call onClick form a external JS and then apply it through another 
function? Allowing us to have Accessible Pop-ups?
An excellent article on ALA covers just this:
http://www.alistapart.com/articles/popuplinks/
It is a bit complicated, as it uses the long route to connect a function 
to an event bubbling through the DOM, but it covers the things you describe.

I've written a smaller, dedicated piece of script to add popup behaviour 
to links. It's not as elegant as Caio Chassot's solution, but still:

// Start when XHTML document is loaded completely...
//
window.onload = function() {
  if (document.getElementsByTagName)
  {
var allLinks = document.getElementsByTagName('a');
// Loop through all hyperlinks in the document.
//
for (var i = 0; i  allLinks.length; i++)
{
  switch (allLinks[i].className)
  {
case 'popup':
  // Define onclick event for this hyperlink.
  allLinks[i].onclick = function ()
  {
// Fetch ID for this link.
var thisPopupVars = this.id.toString();
// Fetch params from id attribute.
var thisPopupWidth = thisPopupVars.substring(1,4);
var thisPopupHeight = thisPopupVars.substring(4,7);
var thisPopupScroll = thisPopupVars.substring(7,8);
var thisPopupName = 
thisPopupVars.substring(8,(thisPopupVars.length));

// Fetch URL from href attribute.
var thisPopupURL = this.href;
// Prepare string for popup.
var thisPopupParams = 'width='
  + thisPopupWidth + ',height='
  + thisPopupHeight + ',location=1,menubar=1,scrollbars='
  + thisPopupScroll + ',status=1,toolbar=1,resizable=1';
// Check if a popup already exists and close that popup.
if (popupWin) { popupWin.close(); }
// Open the popup with the defined parameters  URL.
var popupWin = 
window.open(thisPopupURL,thisPopupName,thisPopupParams);

// Prevent the event from bubbling on.
return false;
  }
  break; // End of first-and-only case in this switch.
  } // End of switch.
}
  }
If you include the above script through an external .js file or in the 
head, you can use an XHTML syntax such as:

a href=http://www.google.com/;
   class=popup
   id=x4003001GoogleGoogle/a
With the ID attribute you set some params for the popup:
x  - ids should start with [a-zA-Z], useful to make multiple
 links with the same params (e.g.: 'y4003001Google').
 This first letter is neglected by the routine.
400- Width of the popup (100-999).
300- Height of the popup (100-999).
1  - Toggle for scrollbars: 1=yes, 0=no.
Google - Name of the popup window; no spaces I guess.
Maybe you'll find this useful. I have taken this from a larger routine, 
so the warranty ends at the front door. ;-)

Good luck,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] discussion at juicy studio: It's all in the MIME

2004-11-10 Thread Jeroen Visser [ vizi ]
[EMAIL PROTECTED] wrote:
I have been following this discussion (belatedly)
 It's all in the MIME
http://www.juicystudio.com/all-in-the-mime.asp
first paragraph:
 There have been a lot of articles recently about web standards; in
particular, using XHTML and serving it as text/html. Personally, I'm not
that bothered whether people serve XHTML as text/html, but think it's
important that authors understand why this is wrong. Although I'm not
bothered about content developers serving XHTML as text/html, I don't agree
with people encouraging content developers to deliver XHTML as text/html. 
I  wondered what other memebrs on the list thought about it and its
implications?
Others have written about it and about server-side solutions to cater 
for IE while still sending application/xhtml+xml to the likes of 
Mozilla, Opera and the W3 HTML validator:

1 - The issue
[http://www.hixie.ch/advocacy/xhtml]
2 - The parsing consequences (old, but still valid):
[http://www.hut.fi/~hsivonen/test/xhtml-suite/xhtml-index]
3 - The solution (PHP)
[http://www.workingwith.me.uk/articles/scripting/mimetypes/]
4 - The solution (.htaccess, can't recall the source):
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
RewriteCond %{REQUEST_URI} \.html$
RewriteCond %{THE_REQUEST} HTTP/1\.1
RewriteRule .* - [T=application/xhtml+xml]
Ciao,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**


Re: [WSG] Well since everybody...

2004-11-04 Thread Jeroen Visser [ vizi ]
Kim Kruse wrote:
[sitecheck on http://www.mouseriders.dk/]
Hi Kim,
It's a clear and easy to navigate site. Some small remarks:
* In my Mozilla, the subheadings are smaller than the copy text. I 
assume that is not your intent, but if it is I'd advice against it as 
(descending) font-size is a key aspect in recognition of page structure 
(title, subheading, text).

* I see a one pixel difference after hovering over the menutabs (the 
bottom 2px blue line becomes a 1px line). This usually is a result of 
sub-pixel rounding in Mozilla, and most of the time this can be solved 
by explicitly setting a value for line-height on the pundits.

* I think your logo in the top right could use some more whitespace; 
it's a little close to the tab 'Kontakt os' (to my taste).

* It would seem more logical to use bold (emphasis) for the selected tab 
and normal font-weight for the others (just the other way around ;-).

I thought a lot about tab index. Is there any need for them... unless 
you want to direct tabbers a certain way round the pages?
If the underlying code results in an odd 'natural' tab sequence (for 
instance due to floats), you could use tabindex to restore a logical 
behaviour. Otherwise, don't bother. ;-)

I'm also very unsure about the access keys. (I have one skip to 
content - accesskey=S)  I read a lot about access keys and most of it 
was actually negative! What to do?
Certainly 'S' as an accesskey is not a very fine idea, as it can be 
easily 'mistaken' for Save, instead of Skip. Because the implementation 
of accesskeys varies from browser to browser and from OS to OS, it's 
best to be cautious. I've heard of accesskeys conflicting with 
widespread shortcuts for cut, copy and paste, for instance --can't 
recall the browser in which this happened though.
An blind friend of mine told me once he almost never uses accesskeys to 
navigate through a site, because of these conflicts and because there's 
no clear and common usage on websites.
For 'heavy' users, accesskeys sometimes come in handy (e.g. on forums or 
community sites), but then you'd have to signal that you've provided 
accesskeys by underlining the relevant character in menu items (just as 
Windows does).

Just my two cents. Good luck,
Jeroen
--
vizi fotografie  grafisch ontwerp - http://www.vizi.nl/
**
The discussion list for  http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list  getting help
**