Re: [WSG] Was given a shocker this week ...

2009-04-06 Thread Geoff Deering
Geez, if only I was so lucky to get such an easy project... this is 
project from heaven compared to most of what comes my way


Geoff


Mike Kear said the following on 7/04/2009 2:42 AM:


You might be amused to learn about the site I was given to rebuild 
this week. It was built by a photographer who had a mac and some free 
software, and the client said the problem was she had to get someone 
to update it for her every time she changed anything in her business. 
She wanted a content management system.


That’s no problem for me – that’s mostly what I do . But I was 
appalled when I saw the site she was asking me to rebuild .. . here’s 
what I found – the work of a woman who was claiming to be a 
professional web designer:


[A] the site consisted of 8 html pages

[B] each page consisted of some invalid html code produced by a 
WYSIWYG app, presumably used incorrectly since most WYSIWYG apps are 
CAPABLE of producing valid code.


[C] the content on each page consisted of a single image for the 
header 1169px x 168px and another jpg image with all the text, photos 
etc 702px x 961px


[D] because of the sizes of the header image and the body image, none 
of the pages could ever possibly line up across the page without a lot 
of tinkering about.


[E] the html contained no content whatever, except the name of the 
designer


[F] all links inside the pages were using image maps – something I 
haven’t used for about ten years. I don’t think I’d even remember how 
to do that now if I had to.


[G] the layout problems caused by the different widths of the header 
and the image in the body were corrected by nesting tables with lots 
of cells and a transparent spacer gif to stretch the cells out. I 
didn’t bother working out why there were so many of these spacer 
tables, I knew at a glance I wasn’t going to be needing anything in 
this code!


[H] because my client has had such trouble getting her site updated on 
a timely basis, she has taken the site away and is hosting it with me, 
which has sparked off a war between my client and her former web 
designer, complaining that I have taken her site by using a web 
archive, in violation of her rights to copyright. (As a first step, I 
used a browser to copy the files from her existing site, so I could 
see what’s in there, just in case the former designer decided to take 
it off line. Which she did. So it was a good precaution. Then while my 
client and I are discussing her new site, I put the existing one up in 
her new hosting space with me just so the site stays alive while we 
work out what to do. You can almost hear the former web designer 
frothing at the mouth as she rants and raves on the phone DEMANDING 
that I pull everything down off the web within ONE HOUR – OR ELSE!!)


It’s like a cat fight. I’m expecting to see them both pulling each 
others hair, biting, and rolling in the mud any time soon.


Anyway, I’d done quite a few sites now that I’ve enhanced by making 
them standards compliant, but I think this is the most extreme case 
I’ve seen – well since I tried Frontpage v2.0 all those years ago.


Maybe I can write it up as a case study later when the new site is up. 
If the client agrees.


Cheers

Mike Kear

Windsor, NSW, Australia

0422 985 585

Adobe Certified Advanced ColdFusion Developer

AFP Webworks Pty Ltd

http://afpwebworks.com

Full Scale ColdFusion hosting from A$15/month


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
*** 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***



Re: [WSG] Website Directory Structure - Best Practice

2006-03-18 Thread Geoff Deering

Joseph R. B. Taylor wrote:


Greetings Friends,

A topic I haven't seen posted here yet, that I feel is relevant when 
it comes to working to have a standard way of doing things.


When it comes to website directory structure, I'm curious to know how 
you gurus out there set up yours.


I myself, have been using this set up:

root web folder
-images
-main.htm
-events.htm
-bio.htm
etc, etc

Recently I was hired to do some cleanup on a site I hadn't built and 
the directory was set up like:


root web folder
-main
--images
--main.htm
-events
--images
--events.htm
-bio
--images
--bio.htm
etc, etc

Looking at these two layouts, I first notice that the 2nd layout has 
multiple images folders, one for each page in fact.  This sort of 
organizes the images better, but now there's images all over the place.


How do YOU set up your directories?



Hi Joseph,

I was nearly not going to reply to this as I am not a guru of any type 
or qualification, so I didn't think it was addressed to me, but here is 
a non guru reply;


I think that before you address this as a basic design issue, you need 
to look at the web site as a whole, what is it, how how it may possibly 
evolve, who contributes to the content, how are users managed, how is 
the web site categorised into topics, and all the rest of it.  Once you 
have done that you may find A may be more appropriate than B or visa 
versa.  For instance, if you have a lot of groups contributing content, 
then B may be a better way of managing the user permissions, it may also 
allow a section to be moved more easily or run and developed on a local 
file system, whereas A and modifications of A may be more suited to a 
smaller (even a large) site that do not require complex content 
management rules.


I also would like to be able to discuss usability issues with standards 
based developers on this list, but maybe that is a topic for another 
list or forum.


Regards
Geoff Deering
**
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] .net question

2006-03-16 Thread Geoff Deering

kvnmcwebn wrote:


hello,

i just went to a lot of  trouble style a form, fieldsets, legends and 
all.


The visual studio programmer whos taking over the next phase says it 
will be coverted into tables.


we can't control database content all we can do is contain it

that was his argument.  why cant he contain it with css.
can somebody help me educate him?

maybe i should have this on the cms list.

-best kevin mcmonagle




If you are working in an organisation or any sort of structure where 
there is a web development team the best thing to do is to raise an 
issue with the manager of the team to discuss the development processes.


In my own experience, even developers who know about and appreciate the 
benefit of standards may be limited in what they can do via the tools 
they *have* to use.  When it comes down to the bottom line, using the 
IDE for that particular environment, for all other productivity 
purposes, may outweigh any requirement to comply with standards.  If you 
can work out a methodology to work with this situation you could offer 
it at such a meeting.  That's quite possible, but it would have to fit 
in with the SDLC and budget.


Regardless of whether you can solve this situation or not, it should be 
bought to the attention of the web and project manager that they should 
address this concern in their SDLC, because if they don't, the designer 
is going to spend their time coding to standards, which is all lost in 
the next phase.  Not very good project management or ROI, but very few 
web teams I have seen refine their SDLC to address these issues.


Regards
Geoff
**
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] Do you still support 4.0 browsers?

2006-02-27 Thread Geoff Deering

James Bennett wrote:




I think the time has long since come to stop having disclaimers about
browser support; make sure the content of the site is accessible
whether people are using new browsers, old browsers, non-visual
browsers, or just shouting into tin cans with strings attached. Then
build on top of that any fancy styling or effects you like, so long as
they don't get in the way of non-supporting user-agents accessing the
content.

--
 



I feel that is the crux of the issue too.  If you are a standards based 
developer, you shouldn't have locked anyone out with your design 
implementation, but your design may degrade gracefully on older 
browsers.  The content should still be accessible.


--
Geoff Deering
**
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] AIMIA Awards

2006-02-27 Thread Geoff Deering

Kat wrote:



Gday,

I find this list filled with dynamic, inspirational people. I come 
away being motivated and energised. I love youse guys. :)


Today, I came across AIMIA (Australian Interactive Media Industry 
Association - http://www.aimia.com.au/) that are having their 12th 
Annual AIMIA awards. Is anyone a member of this group? Does anyone 
know anything about them? Is anyone a finalist?



Used to be a member when it first formed.  Went to the first conference 
way back in the early 90's.  It was quite good actually, very 
interesting discussions, very informative on many levels.  But after 
that, I didn't find any reason to follow up on it.  Taken a look from 
time to time, and find the web standards based community much more 
interesting, informative, and addressing the issues I'm focused on.  But 
like a lot of things, I may have missed a lot of good things going on 
over there just because they dropped out of my focus.  Only have two 
eyes, hands, etc.





I had a look at some of the finalists and although they seem to 
require WCAG Priority 1 Accessibility, to reach that, don't your 
websites need to actually validate (at least some of their finalists 
don't)? Have I misunderstood?




Valid documents is a P2 checkpoint - 
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-grammar



I rather think it's a good idea - but I think it misses a certain 
something (tableless design, validation, accessibility, etc). There 
are so many designers/developers on this list (and elsewhere) doing so 
many amazing things - why don't they ever get recognised for the good 
things they do? They deserve it more!! Would there be a way to give 
them the recognition they deserve?


Kat



If WSG members contribute to it, great, but does it provide value for 
membership? http://www.aimia.com.au/i-cms?page=1.3.329.8



Regards
Geoff.
**
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] Converting the heathen: never again

2006-02-26 Thread Geoff Deering

Christian Montoya wrote:


On 2/26/06, SunUp [EMAIL PROTECTED] wrote:
 


Hi folks,

I hereby publicly declare that my days of complaining to website
authors that I cannot view their site at 800x600, and then opening my
big mouth about other dubious issues I notice on their site, are now
over.
   



Ah, but when annoying little standardistas like me tell others to make
their sites accessible and validate their XHTML, I'm being too harsh.
/rant

I think you have come across a key lesson for the standards community:
techies know about standards, they are not ignorant, they just have
their own reasons (however lame) for not following them.

 



I also think there are a lot of people who work in big organisations, 
companies and even universities, that know that to raise these issues is 
to put their job on the line.  Some developers who have a good 
understanding of these principles will just shut up for their own sake 
as they have a mortgage and family to feed... the consequences of 
raising such issues are that great.  And even if you do become 
successful, just watch yourself get shafted by the person further up the 
ladder, who takes the credit for it.


There are also developers in these large organisations that make their 
living from writing code patches to address the short comings in the 
core approach.  They have a vested interest in the problems not being 
solved.  They love such challenges.  And if you raise too many issues to 
say their needs to be a fundamental overhaul of the approach and system, 
you are basically told to STFU by everyone, not because of lack of 
credibility of your argument, but because it is stepping on too many toes.


There is more than simple reasoning at play here.

--
Geoff Deering

-
Geoff
**
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] Converting the heathen: never again

2006-02-26 Thread Geoff Deering

Lea de Groot wrote:



On 27/02/2006, at 4:08 PM, Ben Buchanan wrote:


Not to mention the fact that the people who implemented those
bohemoths can't always separate standards advice from personal
vilification - no matter how polite, rational, independently
verfiable...



I think its important to understand that, for a lot of people who  
actually work on a site, when you say your site doesn't validate/   
isn't accessible/ doesn't work in my browser what they hear is your  
skills are no good / you don't know how to do your job/ say goodbye  
to that next payrise
It takes incredible tact to tell people what a problem is without  
making it feel to them like a personal attack - and I don't know  
about you, but I'm a geek; tact isn't on my strong list :)


I'm not saying don't confront - no way! But I am saying that if you  
can't reach the right audience (the people who sign off on the bills,  
quite often, not the developer) then don't be surprised when they act  
like you have hit them in the face with a wet fish.


Actually, Sunny, have you thought about maybe you hit a home run and  
got all the guy's hot buttons?
Maybe (s)he knew all those things were a problem and couldn't bear  
them being brought up by (cough, splutter) a *customer*

g

Lea
~ although I still can't believe the gall of a response like that:  
'your problems with our site are your own problem.' Amazing! Can you  
imagine going into a supermarket and, upon asking for help finding  
the eggs, being told that the supermarket layout is your problem;  
find them yourself? g



There are so many ins and outs to this.  Basically, even if you have a 
very good client interface protocol, and you are not finding fault with 
their work, even when they are working with you and you are refining 
their design, everyone has so much *personal* investment in their 
design, it's very hard to be constantly presenting the business case for 
why you are doing what you are doing.


I find myself constantly inheriting the hidden web wannabe in projects 
lately.  They are not there during the initial discussion and signoff 
with the client, but somehow the client manages to bring them on board, 
and they seem to live in a world of complete creative freedom where 
there are no basic engineering principles to adhere too (accessibility, 
standards, usability, topography, etc).


What makes it worse, is that when you have to cover the basics in this 
area they want a private 24/7 mentoring relationship, or the whole thing 
transmitted to them in a day or two, when it takes ages of practice and 
study to get to this level, and when you say there are undergraduate and 
post graduate degrees on these topics, and they are so large it takes 
lots of dedicated time to understand, they are left highly offended.


Oh, and just as a pointer on supermarket design, there are many 
deliberately seemingly irrational locations of items in a supermarket so 
that it does not aid the user to easily find what they want, so that 
they have to walk past many other items, which they may not usually walk 
past, in the hope that they will purchase more items just buy the 
distance walked and items browsed.  That is why milk, which is one of 
the most commonly purchased items is in a shelf usually the most further 
from the checkout.


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

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



[WSG] CSS Liquid Design Header

2006-02-22 Thread Geoff Deering

Hi,

Can any one point me to a good example of how to do a css header with a 
background image 100% wide, while having two distinct images on the far 
left and right and they behave in a liquid manner as the browser window 
is resized, so that both images maintain being far left and far right.


Regards
Geoff
**
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] CSS Liquid Design Header

2006-02-22 Thread Geoff Deering

russ - maxdesign wrote:


Do you mean like this?
http://www.maxdesign.com.au/presentation/liquid-background/

Russ
 



I wish it was that simple.

I need something like



#headerbanner {
   color: ;
   background: #1C3959 url(/images/banner.jpg) repeat-x top;
   display: block;
   height: 145px;
   width: 100%;
   border: 0;
  
}


#bannerleft {
   padding: 0;
   margin: 0; 
   float: left;

   background: #1C3959 url(/images/lbanner.jpg) no-repeat top;
   clear: both;
}

#bannerright {
   padding: 0;
   margin: 0; 
   float: right;

   background: #1C3959 url(/images/rbanner.jpg) no-repeat top;
   clear: both;
}

#headerbanner h1  {
   padding: .5em 1em .5em 1em;
   font-size: 140%;
   text-align: center;
   color: #F0;
   background: transparent;
}


So #headerbanner has a 1 pixel width image and the left and right banner 
have to sit on top of that so they behave in a liquid way keeping to the 
left and right.  There's probably a simple solution, but it's something 
I normally don't deal with.


G.
**
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] CSS Liquid Design Header

2006-02-22 Thread Geoff Deering

Charles Eaton wrote:



On Feb 22, 2006, at 4:50 AM, Geoff Deering wrote:


I wish it was that simple.

I need something like



How's this:
http://www.eatons.net/test2/test3/index.html

Note: Float in your setup worked against the nature order of how 
computers read code, top down - left to right.




Thanks for the suggestions and also the code corrections and 
improvements.  This is like the jello mold that Tom suggests isn't it?


It doesn't quite fit what I wanted, but I can actually achieve the same 
result with a bit of image manipulation, and will be able to be close to 
back on track with being close to the clients design (which has a lot of 
image layering).


Nothing like a trip to the dentist in the morning to distract one from 
web challenges.  Highly recommended when in need of other perspectives 
(on anything).



Thanks
Geoff
**
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] CSS Liquid Design Header

2006-02-22 Thread Geoff Deering

Tom Livingston wrote:



On 2/22/06 5:04 AM, Geoff Deering [EMAIL PROTECTED] wrote:

 


Can any one point me to a good example of how to do a css header with a
background image 100% wide, while having two distinct images on the far
left and right and they behave in a liquid manner as the browser window
is resized, so that both images maintain being far left and far right.
   



Have you tried jello mold? You can set a min width, so your images won't
crash together. And have a bg color in between for wide pages.

Just a thought...
 



Yes, tracked that down.  Think it's the same principle as what Charles 
recommended.


Thanks for that.

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

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



[WSG] Feedback on ISO Standard Version of Access For All Metadata

2006-02-13 Thread Geoff Deering



 Original Message 
Subject:reminder about new standard...
Date:   Sun, 12 Feb 2006 23:12:50 -0700
From:   ozewai [EMAIL PROTECTED]
Reply-To:   ozewai [EMAIL PROTECTED]
To: [EMAIL PROTECTED]



(Mailing List Information, including unsubscription instructions are 
located at the end of this message)


Time is running out for us with the ISO standard version of AccessForAll metadata. This is just a reminder that you could help by testing our forms and commenting - please --- 


See http://dublincore.org/accessibilitywiki/DiscussionOfFcd

Other's comments are also available for you to peruse on that page.

Liddy

http://www.ozewai.org/

**
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] Google and HTML5

2006-01-25 Thread Geoff Deering

Geoff Pack wrote:


I like the idea of the nav and the aside elements:
http://whatwg.org/specs/web-apps/current-work/#the-nav
http://whatwg.org/specs/web-apps/current-work/#the-aside

So instead of:

html
head/head
body
div id=header/div
div id=nav/div
div id=content/div
div id=sidebar/div
div id=footer/div
/body
/html

We could have:

html
head/head
body
header/header
nav/nav
article/article
aside/aside
footer/footer
/body
/html

Which is cleaner and more semantic. But it would take years to get it 
implemented by the browsers and to grow the installed base to the point where 
we can actually use it. Better to just standardise the id and class names - the 
web patterns / microformats approach.

cheers,
Geoff.

 



Do others feel there are *elements* of presentation creeping back into 
the structure?


The first approach keeps the semantics of the document whilst providing 
handles to present the sections of the document.


The second does this by the semantically defining the presentation 
structure. (IMHO)


I'd prefer to see a direct jump into the xml world (which would drag the 
soupsayers into the standards world).  Maybe it's time for a better 
semantic language.


Regards
Geoff Deering
**
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] Correct MIME types for non-standard file formats

2006-01-23 Thread Geoff Deering

Peter Levan wrote:

Is there a good reference site that lists correct MIME types for 
various file formats? or is there a general rule to follow for 
non-standard file types?


Specifically I'd like to know what MIME type should be used for SPSS 
portable (.por) files and in the past I've seen many variants for some 
file types (eg. MS office file types).  Currently we are sending the 
MIME type application/por which I am fairly certain is incorrect, but 
it does give the browser behaviour that we want. 

Without the MIME type set the file displays like a text file in the 
browser window, however we want the download requestor to appear when 
accessing a file of this type as the file is useless when viewed as 
straight text as it is a data file designed to be used with SPSS.


__

Peter Levan   



Have you tried

http://www.google.com.au/search?hl=enq=MIME+type+SPSSbtnG=Google+Searchmeta=

Geoff.
**
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] what cms system

2006-01-18 Thread Geoff Deering

Romeo-Adrian Cioaba wrote:

try joomla.org http://joomla.org. Joomla is the best open source CMS 
in the web. i'm working with it for over 1 year and all my clients 
were happy with it :)



Does it handle standards based templates okay now?  It used to insert 
it's own code in the Mambo days.  Have they addressed that, as they were 
intending too.  Can you build Strict DTD tableless designs with it?  Do 
you have any example sites you have done?


This discussion should be over at [EMAIL PROTECTED]


Geoff
**
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] CSS Driven?

2005-12-12 Thread Geoff Deering

russ - maxdesign wrote:


I don't know about anyone else but I often use angry mobs to control my web
pages - though it is hard to get them to exhibit blind hate.

:)
Russ

 



Could I please request a tutorial on this method please Russ...

-
Geoff
**
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] *Why* doesn't Google validate? was New logo scheme was talking points for standards

2005-12-10 Thread Geoff Deering

Lea de Groot wrote:


On 10/12/2005, at 1:53 PM, Brian Cummiskey wrote:


I wonder how many visits google gets in a day...



Probably in the billions - plenty of people have it as their homepage.
Of course, there'd be a lot of caching happening...

Lea



http://www.google.com.au/intl/en/press/funfacts.html

http://en.wikipedia.org/wiki/Google_platform

What's interesting is how they have set up their server cluster (15,000 
back in 2003), which doubled from the 18 months before.  If you google 
on that you'll find many articles.


G
**
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] *Why* doesn't Google validate? was New logo scheme was talking points for standards

2005-12-10 Thread Geoff Deering

liorean wrote:


Consider the entire www.google.com site. Or at least the search part
of it. You probably want to create one stylesheet file and one
javascript file for the entire thing, probably sent compressed if
client supports it, so it gets cached and not requested again in that
browser session.

Also, how many users access the main page once but searches several
times in a row, or move beyond the first listing page? How many access
it from the Google bar or browser search fields instead of coming
through the main page?  The main page is just a part of the
application, not the whole thing.

These considerations probably make CSS layout an even better choice
for reducing bandwidth consumption.
--
David liorean Andersson
 




There's no doubting the arguments here, but you are dealing with large 
organisations.  Anyone who has worked within one of these large 
organisations as a web developer knows not to raise these issues or else 
they could find themselves without a job, even if their intention is 
only to benefit the organisation.


Zeldman pointed out Yahoo's problems in DWWS, but it had little impact.  
*Jakob* Nielsen was utilised as the usability design person for Google's 
initial design, which has changed little from it original.  I don't know 
if he's still on their payroll.


Even take a look at an organisation like Telstra and it's implementation 
of Standards (http://telstra.com.au/standards/index.cfm).  They have at 
least put an effort into this, but the people on this list will see the 
flaws in it's implementation, and it's assumptions.  This movement has 
been going on for half a decade at Telstra, and the version 6 templates 
are at least 4 years old.


It's almost impossible to effect these types of changes in these 
organisations, unless you have a position of authority.  The only way to 
do it (so far) is to lead by example, and when there is enough evidence 
of good standards design implementation, then these large organisations 
may be willing to adapt best of practices.



Geoff Deering
**
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] Newcomers and Web Standards

2005-12-03 Thread Geoff Deering

Christian Montoya wrote:


Lori, don't give up on us so fast. I can assure you that Lachlan's
comments were not meant to be sexist, and I think the discussion that
ensued has been helpful for us all. Even if someone on this list does
say something you don't like, don't let it discourage you, because
there are still a couple thousand other people that can be useful in
answering your questions. And yes, there are women here.

As far as editors go, I still use Notepad and Wordpad... maybe I
should look into something new too.

--
--
Christian Montoya
 



I second these comments, and although debate sometimes ensues, 
generally, everyone is trying to be helpful and contribute, and quite 
often there are valid points on both sides (if that makes sense).


Other text editors to look at;

http://www.vim.org/

and http://webstandardsgroup.org/go/resourcecat30.cfm

TopStyle Lite is the free cut down version of TopStyle Pro 
(http://www.bradsoft.com/topstyle/tslite/)



Geoff Deering
**
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] Mambo Accessibility

2005-12-02 Thread Geoff Deering

Lloyd wrote:


Guys,

Thanks for all the feedback! Backend is important as one of our
content providers is blind. Does anyone know much more about Joomla?
They are possibly prepared to upgrade (As they see this is just the
same thing). I want to know whether its possible to do this with
either Mambo or Joomla but I guess otherwise it will need be something
else so your suggestions of other good CMS's are welcome!

Thanks again.

Regards,

Lloyd

 



Just as a point of interest, Mambo, before it split into Joomla, said 
that the next major release (5.x) would aim to generate web standard 
compliant code, they had taken on board as a core developer the 
person/people who takes Mambo, and fixes it to produce XMambo 
(http://mamboforge.net/projects/xmambo/).  I don't think that will 
happen of itself, and will need web standards developers to work with 
the various teams to provide feedback.  I don't know what has happened 
with these initiatives since the Mambo/Joomla split.


The Typo3 people have said the same thing about Typo3 V4.x, which is in 
alpha 
(http://typo3.org/?tx_newsimporter_pi1%5BshowItem%5D=0cHash=e4a40a11a9).  
Again, it will require web standard developers to work with them on that.


So I think there's the opportunity to work with and provide feedback to 
bring these products up to a standard where we can maybe*enjoy* good web 
content management tools.


--
Geoff Deering
**
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] Standards and Aesthetics

2005-12-01 Thread Geoff Deering

[EMAIL PROTECTED] wrote:

Not a question so much as a discussion topic -- is there a particular 
look to standards websites? Is there an aesthetic developing from 
the technologies we use?


Many standards websites have subtle gradients in backgrounds -- is 
this because designers are confident in using PNG files which do 
gradients better for smaller file sizes? Standards websites tend to 
use rounded corners -- is that because of moz-border-radius? And of 
course we see fewer designs these days which are just Photoshop files 
locked into a complex table -- designs with DIVs are more likely to 
have breathing space than try to be pixel-perfect.


So, is the technology dictating the look, or are all these things just 
accidents of history because some major relaunch like the 
stopdesign/AdaptivePath redesign of Blogger looked that way?



Maybe this can be identified as a trait in the many designs of 
developers who implement web standards, but I can't see how these 
attributes form marks of identification of attributes of adopting web 
standards (I realise this is not necessary what you are saying).


I think it's more to do with what is achieved by following web 
standards, and what pitfalls are avoided.  I would tend to say that 
developers that adopt web standards are much more aware of both the 
pitfalls of poor web development process and the benefit of better SDLC 
process and also are much more focused on real world usability and 
accessibility issues.


http://www.maxdesign.com.au/presentation/benefits/
http://www.webstandards.org/learn/reference/web_standards_for_business.html

etc, etc.

---
Geoff Deering
**
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] Standards and Aesthetics

2005-12-01 Thread Geoff Deering

Ted Drake wrote:


Hi John

Sites look similar because the early standards-based web developers were so
influential. CSS-based design is different beast than table hacking and
people feel more comfortable riffing off a successful site than learning a
new technique with a design out of their head. 

 



Yes, the ones who had good design aesthetics did.  There were a lot of 
early practitioners of standards back in the late nineties, but they did 
not have the same design sense to drive this movement.  It was only when 
the better designers came along that there were examples of standards 
implementation that really showed a path to follow.


Also, I don't think that five years ago you could market tableless 
designs with any success.



As standards-based design matures, you will see new varieties that table
hacking never dreamed of. Personally, I'm hoping to have some time to begin
exploring CSS3 layouts much more. IE7 isn't that far off in the future and
we can begin using more sophisticated behaviors now with Safari, Opera, and
Firefox.
 



Yes, I think that standards based designs are going to show marked 
better usability than those who stick with the old path.  I choose to 
live in the countryside, no broadband, it's a good reminder just how 
frustrating some sites can be to use on dialup, a frustration rarely 
experienced with sites properly implementing standards.



Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-18 Thread Geoff Deering

Herrod, Lisa wrote:

for the record, I'm still following the thread. 


this isn't even close to finished.

 



I think it's best if I take a time out and write a thorough article.  If 
it is a topic worthy of more discussion, I think that is the best way to 
serve that purpose.


---
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-18 Thread Geoff Deering

James Bennett wrote:


On 11/17/05, Patrick H. Lauke [EMAIL PROTECTED] wrote:
 


Linking back to my philosophical question at the beginning: is web
development a subset of software development, or is it - for lack of a
better term - the development of an experience. A related point from
that: should web applications (functional, intranet-type apps) still
have their own feel or integrate seamlessly (from a visual standpoint)
with the OS?
   



I think part of the problem here is that, despite any wishes we might
have to the contrary, web browsers don't consistently integrate with
the look and feel of the OS. Internet Explorer uses Windows' form
controls, yes, and Safari uses the Mac OS' controls, but (for example)
Gecko-based browsers have their own set which, while reminiscent of
older versions of Windows, really isn't native to anything. And
despite much progress on the OS-integration front, Firefox still
doesn't really feel like a native application on any platform. Opera
occasionally has the same problem; here on Linux, even though it uses
the Qt toolkit (or did last time I checked), it doesn't use the
default Qt widgets for form controls.
 



That's an absolutely spot on observation, and it does impact the user 
experience. Some applications style the look and feel of various system 
resources by compiling their own resource design into their own 
application, rather than purely passing it to the OS. 


And even if there were perfect consistency of browser form widgets
with OS widgets, we would still be stuck with a fundamental problem:
web applications, by definition, run in web pages, and no OS in
widespread use has an application paradigm which matches that of web
pages. So despite consistency of the widgets used for certain parts of
web applications with widgets used in certain parts of traditional
applications, we would still be working in a fundamentally different
medium. And I think that web users, on the whole, have come to
understand and expect that things on the web work differently from
the other applications they use, so striving to be as much like the
OS as possible would be a futile and counterproductive task.

 



But the web developer still has to keep in mind that their application 
is being rendered on multiple devices for which they do not know how 
each are configured.  Also, there are units of measure and design 
implementations that these device will be able to translate directly to 
suit the display of these devices, and there are others that will 
clash.  If nothing else, WCAG is a very good basic check list to help 
the designer avoid many pitfalls.  It can only help to be mindful of 
these things while designing.



Which, I guess, leads us to the latter of your two options; as I see
it, a web application ought to have a simple, intuitable interface (or
experience) which is consistent within that application, because
ultimately that is all the control the web application's designer
will ever have. This does not mean that conflicts with widespread OS
interface conventions should not be avoided when possible, but it does
mean that consistency with the OS interface should not be valued more
highly than consistency, simplicity or intuitability within the web
application.

 



Yes.  This is probably so important it is an issue the both UAAG and 
WaSP should drive home to user agent developers.


-
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-17 Thread Geoff Deering

Patrick Lauke wrote:


Geoff Deering
   



 

Okay, so if this was implemented in user agents, what would be your 
educated estimate of percentage of users who would configure this and 
therefore avoid this problem of interpreting the incorrect 
state of form 
controls?
   



I'd estimate it to be roughly the same as the percentage of users that have 
reconfigured their OS to use different default colours which would make them 
get confused by *judiciously* styled form controls.

Patrick
 



And what percentage of users that access those web pages would you 
expect that to be?


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-17 Thread Geoff Deering

Patrick Lauke wrote:


Geoff Deering
   



 

I'd estimate it to be roughly the same as the percentage of 
 

users that have reconfigured their OS to use different 
default colours which would make them get confused by 
*judiciously* styled form controls.
   



 

And what percentage of users that access those web pages would you 
expect that to be?
   



You tell me...as they're the ones that you mentioned as a group
that would potentially have problems with designers styling form
controls in the first place, if I recall correctly...

 




No, you tell me, because this is your suggestion on how it should be 
handled.




it just says it changes the background color, because this is
under the control of the custom settings of the users desktop
   



Anyway, I think we've bored the rest of the WSG list enough with
this fundamental philosophical difference. You advocate not
styling form controls at all to avoid any potential problems;
I say that judicious styling, combined with more refined and obvious
browser controls (it should be fairly easy to find the overrides, not
buried under 3-4 levels of options), plus possibly alternate
style sheets / site preferences, should not be a major problem as
long as designers are made aware of the potential problems and
don't just make arbitrary design choices (which anybody who calls
hHimself a designer shouldn't anyway). There's probably no way to
get our two views closer, so I'll agree to disagree once again :)

P
 



I think that people on this list are intelligent enough to know that if 
they are bored with this thread they can easily ignore it by identifying 
it by it's subject heading.  But it may just be, if anyone is still 
following it, that this discussion may at least provoke thinking more 
deeply about the impacts of such design implementations.


I think that is one of the characteristics of the people on this list; 
they approach design in this medium with a real care about the user 
experience.  I feel their intention comes for a real desire to be the 
best possible designers, implementing great design, and try to emulate 
best of practice within that context while understanding why there are 
standards conventions to aid the user experience, accessibility, 
appropriate use of markup etc.


It's not a philosophical difference here, it amazes me that this is the 
perspective you draw, because it's clearly a difference of understanding 
and interpreting the impact of standard interface design elements when 
they clash with interface design conventions for communicating the state 
of the user interface.  It's not a philosophical issue, it's clearly a 
functional issue.


No, you are completely misunderstanding what I am saying if you have 
drawn the conclusion that; You advocate not styling form controls at 
all to avoid any potential problems.  I know my English expression 
could be improved, but if you draw this conclusion, you have completely 
missed the point, and I think I have covered enough ground to make that 
clear enough.


And the final solution you provide, which definitely has potential 
merit, has many problems right at this point of time.


No user agent I know of currently has this capacity to abstract form 
elements styles.  So this isn't something one can recommend.


If designers are depending on users to override designs elements that 
conflict with standard interactive design conventions, I feel their 
fundamental approach to design is flawed, because they are not putting 
the basic principles of the design of the interface of device interact 
as a primary consideration.


As for your last statement, are designers well aware of this particular 
issue?  It seems from the discussion here they are not, and as I have 
mentioned before,  it is therefore important to highlight this problem, 
because many designers try follow standard so they don't inflict 
miscommunication on users, and the sad thing is that this particular 
issue, I feel has not been address properly in web standards.  It's not 
designers fault.  It's just been overlooked.  How do you feel when you 
have been designing something with all the best intention, then find out 
you have unintentionally implemented a design that conflicts with user 
interface principles?  Software development and particularly web 
development are rich in history of these types of misunderstandings and 
implementation.


--
Geoff Deering


**
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] Accessibility: Default placeholders

2005-11-16 Thread Geoff Deering

Patrick Lauke wrote:


Geoff Deering
   



 

Secondly, by this recommendation you are actually addressing the flip 
side of the problem I am trying to address.


The case you are addressing here is
1) A recommendation of how to deal with styles that may 
conflict with a 
form element that is in an activated state.
2) What I was addressing was dealing with styles that may 
conflict with 
a form element that is in a non activated state.
   



Aeh...I don't see how recommending that users should have the ability to 
override the designer's style suggestions if they're proving to be confusing 
only addresses 1 and not 2.
 



Yes, you are right, it does cover both scenarios I highlighted.  But as 
I said, there seems no feasible way to technically implement this 
recommendation.


 

Either way, that these recommendation could be feasible in 
practice, is 
for the functions within the user agent being able to detect at least 
two conditions;
   


[...]
 

I can't see how this type of functionality will ever be added 
to a user 
agent because it goes against the fundamental interface principles of 
OSs.  The WAI/UAAG would come under scrutiny if they did 
this.  And with 
all the bugs and unimplemented recommendations in user agent 
development, I can't see this ever seeing the light of day.
   



Maybe I wasn't clear, but this functionality *already exists* in user agents 
(although it's a tad on the crude side, I'm hoping to see a more granular 
control)

As for UAAG, this is an implementation of guideline 4 Ensure user control of 
rendering
http://www.w3.org/TR/WAI-USERAGENT/guidelines.html#gl-user-control-styles
Ensure that the user can select preferred styles (e.g., colors, size of rendered 
text, and synthesized speech characteristics) from choices offered by the user agent. 
Allow the user to override author-specified styles and user agent default styles.

Are we now talking completely across purposes?

Patrick
 



No, I don't feel we are.  This recommendation does not address the 
problems raised by this specific issue, according to my understanding.


So I would  very much appreciate if you could explain in thorough 
technical detail and functionality how this works and how it addresses 
the problems (I see) this specific issue raises, or at least show how 
you would address this issue in functional specifications.



Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-16 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

No, I don't feel we are.  This recommendation does not address the 
problems raised by this specific issue, according to my understanding.


So I would  very much appreciate if you could explain in thorough 
technical detail and functionality how this works and how it 
addresses the problems (I see) this specific issue raises, or at 
least show how you would address this issue in functional 
specifications.



In thorough technical detail and functionality? Functional 
specifications? Why do you have to make this issue sound so inflatedly 
complex?


Taking Internet Explorer as an example, at the moment you have access, 
under Tools  Internet Options...  General  Accessibility, to three 
checkboxes: ignore colors specified on Web pages; ignore font styles 
specified on Web pages; ignore font sizes specified on Webpage. My 
proposal: why not add a further one ignore form control styles 
specified on Web pages? Technically, the browser should then simply 
ignore any author defined styling of form controls.


There...sorry if it's not in functional spec or technical detail...

P



Okay, so if this was implemented in user agents, what would be your 
educated estimate of percentage of users who would configure this and 
therefore avoid this problem of interpreting the incorrect state of form 
controls?


-
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-15 Thread Geoff Deering

Andy Kirkwood, Motive wrote:


Hi Kevin,

Nice example, top marks ;).

Sometimes these discussions can get a little abstract and one (real world) 
example can help make the discussion less murky.

Geoff, I understand your pain with regard to traditional (print) designers and 
the often rocky transition to screen-based design. (Although there's also no 
guarantee that a developer is any more aware of interface semantics.) By way of 
confession, back in '97 I coded a form using radio buttons as found them more 
satisfying aesthetically than checkboxes. Hopefully education or general 
awareness means that up-and-coming web designer/developers have more of a 
community to draw on.

I often think the root cause of many issues with website usability come down to 
the mock-it-up-in-Photoshop-then-hand-it-over-to-the-tech-people-to-be-built 
approach. Ideally there would be meaningful dialogue between the brand/visual 
and the interface/usability.
 



Yes I agree.  And one of my points is you can't really go blaming 
designers for doing this.  I'm just looking through some of my 
collection of Web Standards/Design References and I can't find any where 
that addresses this area explicitly, and that is probably because no one 
thought the need to state it explicitly, because who of us has 
omniscience to see this phenomena now starting to appear.  I didn't.  So 
if any one is to blame, it is someone like myself, who was aware of this 
and I should have maybe contributed this a long time ago, I was on the 
WAI GL and ATAG for a few years, a while ago, so I should have added it 
to the Techniques knowledge base. 

I don't think any designer is to blame, it is just an issue that should 
be in the knowledge base, but isn't.  But I think it just important to 
draw peoples attention to it.


I have for a long time thought of putting up a wiki, because no one 
here, IMHO is the holder of all the knowledge.  I learn stuff all the 
time and am amazed at what everyone can contribute.  I just think that a 
wiki would probably be the best way to represent the fantastic group 
knowledge that is here, but it would be a challenge just to structure it.


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-15 Thread Geoff Deering

Patrick Lauke wrote:


Geoff Deering
   



 

The problem is that web designers are now implementing designs that 
convey meaning to form controls, that they are not intending 
to imply in their design,
   



Which, again, is a sign of a bad designer, and a problem that should be solved by 
educating the designer, not simply saying that inputs should not be styled. A far more 
open recommendation would be along the lines of feel free to style form controls, 
but ensure that you maintain clear and unequivocal visual clues as to the type, state, 
etc of the individual controls, in sympathy with system defaults and user 
expectations.
 



That sounds absolutely nice and clear.  Wonderful.  But please explain 
how to execute this as a recommendation; but ensure that you maintain 
clear and unequivocal visual clues as to the type, state, etc of the 
individual controls, in sympathy with system defaults and user 
expectations? 

How do you know what device configuration is receiving your design?  
Because if you do not, and cannot be absolutely sure your design is not 
clashing with this principle, you cannot *ensure* you have succeeded.  
Unless you know for sure how users have configured their interface you 
are swimming in the sea of uncertainty.  There is no guarantee you have 
not miscommunicated the state of the control.  If accuracy of 
communicating the true state of the elements and attributes of your 
design is a primary principle to your design philosophy, you cannot be 
sure you have not interfered with this process if you overlay this type 
of css on these form elements.


I don't mind going on debating this, but I would like to state clearly 
here;  just as long as designers are aware that there is an issue here, 
and if they choose to do so, then there is no guarantee that their 
design may not clash against this functional convention. Just as long as 
they are implementing their design without ignorance, then I feel I've 
contributed all I want too.  That's my issue. 

Once this is raised, and they realised that such recommendations, no 
matter how well intentioned (as the above), will not save them from the 
possibility that their design may clash somewhere, then they can make 
their own decisions empowered by knowledge, not hedged in ignorance.


As an extended note; this could happen with any input field background 
color, but the likely probability that it impacts, would probably be 
very minimal, IMHO.  But the minute I began to see grey becoming the 
default for conveying the presence of input fields in designs (which 
basically isn't a bad idea in many designs, in fact, when you look at it 
it appears to give better cognitive enhancement), *except* for this 
problem of this being the default reserve interface for conveying state 
to users on many major OSs.


And if we are trying to future proof, who knows what wonders of 
usability research will lead to designing the next generation interfaces 
for operating systems.  Then you have to go back and correct your styles 
to address this.  And how many of use actually get a chance to go back 
and correct these on sites we have done years later.  Your lucky if you can.


It's just raising the issue.  If designers what to go ahead and do that 
in full knowledge, that is their decision.  I just feel it is important 
to discuss the issues, and not misled them into feeling there is any way 
around this.  Nothing I have seen so far offers a solution to style 
input controls in this manner and be free of concerns of clashing with 
conveying interface state.



 

this will degrade the user experience because of purely visual 
design degrading the inherent meaning of a standard interface between 
user and form element state.
   



Carefully considered, as opposed to purely visual, design (and yes, there IS a 
difference, despite the general feeling evident in certain factions of the WAI that all design is 
just bad) has its place in enhancing and visually integrating form controls in an 
overall site design.
 



I know many people feel that about the WAI GL, but I have never felt 
that.  People complain about the WAI police and the lengthy drawn out 
debate that goes on there, but I mostly see a lot of people concerned 
*not* to write recommendations that restrict design.  I know others see 
it differently, but I know lots of them that actually see accessibility 
and liberated design as interdependent.  Is CSSZG not a great show case?


I love it that by far the majority of the people on the Working 
Guidelines Group have a vision of incredible compassion and lack of self 
interest.  I learnt *heaps*, not only from the knowledge and opinions of 
those on it, but also by their manner as people and as a group when 
discussing issues.  I'm really grateful to have had an opportunity to 
work with them a little.  I know it has driven some people to 
exhaustion, but still there remains a real integrity amongst those that 
work on it, and those

Re: [WSG] Accessibility: Default placeholders

2005-11-15 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

How do you know what device configuration is receiving your design?  
Because if you do not, and cannot be absolutely sure your design is 
not clashing with this principle, you cannot *ensure* you have 
succeeded.



But that is true of pretty much any element and situation where you're 
applying style.  And that's why we have separation of content and 
presentation: if the presentation does present a problem to the user, 
the user agent should provide the user with a simple way of 
overriding, or completely ignoring, the styles suggested by the designer.




Firstly, this still does not address the initial problem.

Secondly, by this recommendation you are actually addressing the flip 
side of the problem I am trying to address.


The case you are addressing here is
1) A recommendation of how to deal with styles that may conflict with a 
form element that is in an activated state.
2) What I was addressing was dealing with styles that may conflict with 
a form element that is in a non activated state.


Either way, that these recommendation could be feasible in practice, is 
for the functions within the user agent being able to detect at least 
two conditions;


for your condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue)   
(FormElement == active) then do {apply correct display of state};


and for my condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue)  
(FormElement != active) then do {apply correct display of state};


I can't see how this type of functionality will ever be added to a user 
agent because it goes against the fundamental interface principles of 
OSs.  The WAI/UAAG would come under scrutiny if they did this.  And with 
all the bugs and unimplemented recommendations in user agent 
development, I can't see this ever seeing the light of day.


I'm really not up to date with CSS behaviour at all, but if someone can 
show me a real world example of this recommendation and how it could be 
applied, without programming the user agent functionality, and therefore 
changing the UAAG specs, I'd be happy to see it. 

You could probably do it with client side scripting, but then that 
breaks when it's turned off.



Unless you know for sure how users have configured their interface 
you are swimming in the sea of uncertainty. [...] If accuracy of 
communicating [...] is a primary principle to your design philosophy,


 you cannot be


sure you have not interfered with this process



With my intentional omissions (not trying to misquote you, just making 
it generic), I'd say this applies to any styling, not just the 
specific case of form elements.




If you are suggesting this is to be handled by the user agent, how are 
you going to implement it?  I'd like to know your suggestions on this, 
and the functional logic.





I know many people feel that about the WAI GL, but I have never felt 
that.  People complain about the WAI police and the lengthy drawn out 
debate that goes on there, but I mostly see a lot of people concerned 
*not* to write recommendations that restrict design.



Fair enough...I'm probably thinking of some of the more radical (and 
possibly most vocal and entrenched) elements here.



Yes, I know, but the way they are still worked with and appreciated for 
their input is inspiring.  I used to play the devils advocate there 
because in the long run it helps to apply as much scrutiny and analysis 
as possible for the most clear and comprehensive outcome.  It's 
incredibly hard work to develop accurate standards that are also free of 
unnecessary restrictions.  It requires that type of process.


---
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Patrick Lauke wrote:



 


Geoff Deering wrote:
   



 


With all due respects this is the way default graphical user interface
on operating systems are designed to function.
   



 


From page 158 of The Windows Interface Guidelines for Software Design;
   



But we're talking about the design of web sites, not software that should
visually integrate with, and adhere to, the OS defaults.
 



It would be very strange indeed if web based user agents did not conform 
to the programming conventions for software interface guidelines.  The 
minute that happens there is a breakdown in a system to be able to 
communicate its state clearly with the user, through whatever 
application or device it is running.


This is a web standards based group, and I feel that web standards based 
developers can gain a deeper appreciation of the work that has gone into 
these standards if they are more aware of the relationship with the 
principles of software interface design and the interrelationship of 
user agents and digital devices.  Understanding this, and it's history, 
can only help.


The user agent has a completely interdependent relationship with the OS, 
its system environment and resources, it actually uses these system 
resources, where described in markup, and are then placed on the browser 
canvas as operating system resources (form controls).


The people that worked on the various drafts of HTML are well aware of 
this, because the state of form controls are change via the markup.  
This shows that markup-user agent-OS have an interdependent relationship 
via software handles, and that the user agent is requesting the OS to 
communicate it's state to the user.  This has a universal meaning across 
multiple devices.


So I cannot see how your argument applies, to me, it doesn't stand up.  
A designer should not implement a design element where their design 
falsely indicates to the user that the form control is in another state 
than it is actually in.  This is misrepresentation of state.



 


This also leads to another problem, in that if users configure their
operating system to a custom scheme, unwittingly the web designer may be
indicating to the user that a field may be read only even if it is not 
grey.  How does the designer know whether to use grey or not?  They 
don't.  All they know is the majority of users probably do not customise 
this setting.
   



 

This is why I believe that it is best to not style form controls (or at 
least minimally)
   



Taking this thought further, they shouldn't style the size, typeface, colour
of body text, or any other aspect of the web page either, as it may unwittingly
clash with, or go against, user defined settings?

 




No, I'm not saying that at all.   That is different than what I have 
stated.  This has to do with a standard way of communicating state in 
both OS and user agent.  The point is that these design standards have 
reserved meaning, and if the designer does not pay heed to this they may 
not communicate the correct state of the control to the user.




Personally, I still think don't style form controls is far too sweeping a
rule to catch certain edge cases. As you said yourself or at least 
minimally...
which is very difficult to quantify, and depends on the specific situation.

 




It may be, I agree with that.  My point is, just be aware of this and 
make sure you do not inadvertently create an unintentional conflict of 
communication of state of form control because of a lack of awareness 
this standard way of representing state.




Oh well, I guess we'll have to agree to disagree on this one,

P
 



It's a free world, and I do appreciate reading your opinions.

-
Geoff
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Hassan Schroeder wrote:


Geoff Deering wrote:

 


This also leads to another problem, in that if users configure their
operating system to a custom scheme, unwittingly the web designer may be
indicating to the user that a field may be read only even if it is not
grey.  How does the designer know whether to use grey or not?  They
don't.  
   



Erm, well, actually, they do :-)

 http://www.w3.org/TR/REC-CSS2/ui.html#system-colors

:: or at least, they know what color to use...

 



Yes, thanks for pointing this out.  I'd say the system defaults do these 
anyway, I can't think of anything off hand where you'd need to 
explicitly declare these, but I guess there possibly are...


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

So I cannot see how your argument applies, to me, it doesn't stand 
up.  A designer should not implement a design element where their 
design falsely indicates to the user that the form control is in 
another state than it is actually in.  This is misrepresentation of 
state.



The interpretation of the state a form control is currently in also 
depends on the surrounding context. To pick up the earlier don't use 
grey at all example: that may well be true if the surrounding 
background is very light, but on a page with a very dark or black 
background I'd posit that it would not immediately trigger that 
grey=disabled/read-only association. As a sidenote: it's been a 
while since I've actually come across any read-only inputs, and can't 
really think of a scenario in which I'd want to use one (and 
therefore, maybe I'm not thinking along the same lines - the need to 
differentiate between writable and read-only inputs?).
But basically what I think I'm getting at is: just because there is a 
chance that designers may not be judicious in their style choices and 
confuse the user is not a strong enough reason to give a blanket we 
shouldn't style inputs at all recommendation.




I think you are missing the whole point.

You find these types of web environments mostly on intranets.  For a lot 
of people in large organisations, these are primary interfaces they have 
to work with.  To neglect to address this issue correctly could easily 
impact the integrity of data because the interface is not communicating 
*state*, because if the designer is unaware of this, and overrides this 
visual communication of state that the user agent is conveying, with 
their own arbitrary design implementation, it would be miscommunicating 
the state of the data.  In this case, it would be a major design blunder.



--
Geoff
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

You find these types of web environments mostly on intranets.  For a 
lot of people in large organisations, these are primary interfaces 
they have to work with.  To neglect to address this issue correctly 
could easily impact the integrity of data because the interface is 
not communicating *state*, because if the designer is unaware of 
this, and overrides this visual communication of state that the user 
agent is conveying, with their own arbitrary design implementation, 
it would be miscommunicating the state of the data.  In this case, it 
would be a major design blunder.



But is the solution to make a sweeping don't style inputs 
recommendation, or to actually educate the designers not to just make 
arbitrary decision, but decisions firmly based on usability (including 
expected behaviour/presentation of state)? And, assuming that a design 
has been implemented which does not exactly match OS conventions but 
is nonetheless clear, understandable and usable, is it not just as 
valid, as long as the interface design within the pages themselves is 
consistently applied?




No, because what you are saying here is a whole heap of criteria that 
does not address the priority issue, and that is not doing anything by 
design that will override the user agent visually representing the state 
of the data (controls) to the user.  I'm talking explicitly about 
misrepresentation of state.



--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Terrence Wood wrote:


Patrick H. Lauke said:
 


But is the solution to make a sweeping don't style inputs
recommendation, or to actually educate the designers not to just make
arbitrary decision, but decisions firmly based on usability (including
expected behaviour/presentation of state)?
   



Yes, this is indeed the correct approach.

kind regards
Terrence Wood.
 



That's a good general rule of thumb.

But I am talking about something that is very specific here that is 
currently being implemented incorrectly, and if general rule of thumb 
overrides what is a standard primary mode of communication of the true 
state of the interface, the designer has failed to provide the correct 
interface.



--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Andy Kirkwood, Motive wrote:


Hi Geoff,

(To pick up on Patrick's point.) Have you come across a scenario on a 
website where  it seems appropriate to use an input element to 
indicate that an option exists but cannot be edited by the user?




Yes I can (domain registrars).  In various states fields are often read 
only.  Also control panels, Webmin, SWAT, etc, workflow in CMSs where 
you can see certain data but don't have the rights to modify it.


Perhaps it's preferable to show such content as text rather than as an 
input? (Seems like an instance of yes, we have no bananas: yes this 
is an input, but no you can't.)




No, populating form elements is the correct method for displaying such 
data if there is need for any input.  Sure you can render all the 
content onto the user agent canvas without any form controls.  But the 
minute you put a form element like input there, you are inviting 
interaction from the user.  If you represent that in a way that says to 
the user this is in a read only state, then of course the user will 
not regard it as a data field that they can input data.  In this 
instance, form elements are designed to represent the state of the data 
according to that level of users rights to view, modify and delete.


Now it is not the correct use of these that is the issue here.  This has 
been a standard in GUI interface design for a decade and a half or more, 
and the web inherited these standards, but it seems they really have not 
been documented properly and web designers have not been educated in 
these fundamentals.  It's not their fault, it's just one thing that has 
really been overlooked. 

The problem is that web designers are now implementing designs that 
convey meaning to form controls, that they are not intending to imply in 
their design, and I am seeing this spreading at a rapid rate, and before 
to long, this will degrade the user experience because of purely visual 
design degrading the inherent meaning of a standard interface between 
user and form element state.


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Rebecca Cox wrote:


Could be useful depending on the context.

For example, if you wanted to show that a field was editable content (within the whole application), but not on the particular screen you are on right now (especially if the user knew that by clicking on edit or some other option they would be able to edit those particular fields.) 


You could even fine tune this so that if some users were able to edit a limited subset of 
the fields, they would only be only shown the disabled input for those they 
would be able to edit.

As with the bananas, knowing that a shop usually has them but not today could 
be useful to someone.

Cheers,
Rebecca
 



Yes, that's it, in the given context, it has implicit meaning, given the 
data set it is being applied too.


---
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-14 Thread Geoff Deering

Kevin Futter wrote:


On 15/11/05 3:20 PM, Andy Kirkwood, Motive [EMAIL PROTECTED] wrote:

 


Hi Geoff,

(To pick up on Patrick's point.) Have you come across a scenario on a
website where  it seems appropriate to use an input element to
indicate that an option exists but cannot be edited by the user?

Perhaps it's preferable to show such content as text rather than as
an input? (Seems like an instance of yes, we have no bananas: yes
this is an input, but no you can't.)

Best regards,
   



I actually used read only input fields recently for our online subject
selections. Compulsory subjects were pulled out of a database and displayed
as read only input fields, while other fields were normal select elements.

Why not just display the compulsory subjects as plain text? Because then
there is a visual and cognitive dissonance between the two information sets
- they can seem unrelated, especially when you consider that high school
students rarely read a web form's accompanying text, no matter how
important. I think in this case the fact that the information was displayed
with as part of the form avoided that problem, while using the readonly
attribute and styling the input text a medium grey took care of the rest.
 



What you are saying is completely logical.  In some contexts, it would 
be much better to show the data retrieved in markup that has more 
semantic value and is more appropriate to styling.


The only problem you have here is when you go to the web programmer and 
suggest your idea (which is a good one), he say Now I have to go and 
write two sets of markup to address those with purely read only access 
(no form elements), and those with access rights for modification 
(requires form elements).  If they are generated by different systems 
from the same data set, as can be the case, then I think that is a 
better option.


But it comes to money, try convincing the web manager, the Ex Director 
of It and all the rest of them... Good luck.



---
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Patrick H. Lauke wrote:


Bert Doorn wrote:

Is it really necessary for accessibility to include default 
place-holding characters in edit boxes and text areas per WCAG 1.0 
Checkpoint 10.4?  Is that an obsolete guideline?



Personally, I'd say it is an obsolete guideline indeed. However, I 
recently heard on the WAI IG list that some braille software requires 
at least a space as a placeholder, otherwise it just does not expose 
inputs to the user. I'd argue that this is a fault of the 
software...but it's something that might have to be taken into 
consideration.


http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/0034.html



Why can't the braille software detect an empty form element and inform 
the user it requires data?  Is this an authoring tool problem or a 
problem with the way standards are prescribed?


I agree with this from two perspectives

1) that to address this to the nth degree, where it is actually a 
problem with either the way the software functions or is a bug.  How 
much of our time do we spend addressing bugs in user agents?  Isn't so 
much of the information on lists like this sharing insights into how to 
address bugs in user agents.  I think this is what turns non standards 
developers off standards development.  Admittedly tag soup has it's own 
set of bugs, but being a standards developer means, to me, you have to 
be prepared to work with lots of buggy software, far more than should 
reasonable be expected.



2) often I feel place holders are not good usability, because the forms 
themselves should be designed well enough to represent the data sets 
required.  I think it can add to all sorts of cognitive problems in 
complex screens.


Regards
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Jonathan O'Donnell wrote:



Leaving it there can be a problem.  I have seen a demonstration (at a 
Melbourne WSG meeting, no less) where the agent placed the cursor at 
the end of the place-holding text without reading it.  There is a real 
danger that the user will enter text without knowing that the 
place-holding text is there.




Yes, I'm not surprised at this observation at all.

---
Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Herrod, Lisa wrote:


I ran a usability evaluation last week where some (few) of the form elements
had place-holding text and others didn't.

This caused problems as you might expect as users scanned over those fields
thinking that as they were already populated, they were therefore optional.
Of course they were mandatory and caused validation errors.

This was more an issue of inconsistent design, though it does illustrate
possible usability/accessibility issues.

Lisa

 



Exactly, and how many users make the same mistake on complex pages where 
the form fields are pre populated, thinking that the system has added 
the appropriate data or is not inviting the user to add data.


*Another* thing I see that is happening in design a lot lately is that 
input fields are in greyed background by design, not function.  What 
this is telling the user is that that field is *read only*.  That is the 
standard way operating systems manage read only data, and the same way 
it is done on web based systems.  It's absolutely sending the wrong 
message to users, when the input field is open to accept data input.


If users are used to working on complex data retrieval systems, where 
there is a lot of read only data, then they will be confused by this 
because this type of design breaks the standard by which GUI's 
function.  If this type of design continues, it will only confuse users 
more.


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Herrod, Lisa wrote:


Yes this is an interesting point. And it differs from visually highlighting
a field once the user has encountered a form validation error. For example,
a user misses or incorrectly fills out a mandatory field and when the form
is re-presented, those fields are visually highlighted with a background
colour. In this example, I find users actually like this method and find it
useful/helpful.

 



This may work okay for visual users, but it has no means of 
communicating with those who cannot rely on visual indicators.


This leads to something that has not enough attention has been drawn to;

Mandatory data fields, Required data, fields that require correct data 
after validation should all be grouped together with a 
*fieldsetlegend*.  This informs all users of the requirements of that 
data.  Leave fields that do not meet this criteria outside this group, 
either in a separate group or ungrouped.


This standard of putting an asterisks * after (or before an input field) 
does not only not inform an unsighted user, it often gives the 
indication after they have tabbed through the field, to late for them to 
manage their input without back tracking.


It is a much better practice to group all these fields together.  Not 
only is it better accessibility practice, I feel it offers better 
usability by design.


--
Geoff Deering
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Derek Featherstone wrote:


On 11/14/05, Geoff Deering wrote:

 


Why can't the braille software detect an empty form element and inform
the user it requires data?  Is this an authoring tool problem or a
problem with the way standards are prescribed?
   



Agreed, Geoff. We really do need to know more. We'll need to add this to
the hitlist for the WaSP Accessibility Task Force. It is something that
is of concern to all - I'll see about running some tests with a local
braille display user and see what I can determine from his tests... 

 



See my previous post to Lisa.  I think this actually needs a major 
article on ALA or somewhere where it gets a lot of exposure.  Your blog 
would be okay too.  I encourage you or Patrick to write something 
addressing this.  Also need to address this issue of greying input 
fields (which indicates read only status).


---
Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Bert Doorn wrote:

Geoff, I know exactly what you mean with the greyed out fields. Came 
across it myself only yesterday - a form where all inputs had a grey 
background.  It wasn't until I clicked in one of them that I realised 
the field was not disabled.



Yes, someone please, who writes for some of the major design magazines 
or ezines, please address this before it gets too out of hand because I 
feel a lot of people are implementing this, not realising that it does 
have a standards based meaning as an interface design attribute.



Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

*Another* thing I see that is happening in design a lot lately is 
that input fields are in greyed background by design, not function.  
What this is telling the user is that that field is *read only*.  
That is the standard way operating systems manage read only data, and 
the same way it is done on web based systems.  It's absolutely 
sending the wrong message to users, when the input field is open to 
accept data input.



The problem with this is obviously that it's difficult to say *how* 
grey an input has to appear before a user thinks it's read only. Do we 
sit down and define a required luminescence/contrast to the 
background? In my mind, hard to quantify other than to say: be 
careful, don't make it too dark/grey, otherwise some users may think 
they can't use them.




I think it is quite simple, don't use any scale of grey at all.  Grey is 
reserved for meaning *read only*.



Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Derek Featherstone wrote:


Agreed.  Putting them after *visually* and leaving them before in source
order, and as part of the label can be really useful - its semantically
meaningful, can be emphasized (using label em /em/label) as
shown in the second example on that page is useful. You could easily use
the same technique to emphasize the text required instead of an
asterisk.


 



Yes, I agree, doing both is probably a better option as the asterisks 
has become a standard flag for marking  required fields visually.  It's 
too hard to go back now.  I'm a minimalist, so I'd just use the 
fieldset, but I think your solution offers better overall usability (and 
accessibility).


-
Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

I think it is quite simple, don't use any scale of grey at all.  Grey 
is reserved for meaning *read only*.



With all due respect, that sounds a tad too draconian for my 
tastes...and it's exactly the kind of talk that will make web 
*designers* simply stop listening to anything we say about standards 
and accessibility.


It's a design and usability issue (with obvious accessibility 
implications stemming from it) that cannot be boiled down to a simple, 
one size fits all rule. It needs to be evaluated on a case by case basis.




With all due respects this is the way default graphical user interface 
on operating systems are designed to function.  This is what the user 
agent should adhere too, the basic principles that form GUI standard 
software design, and it is something that designers should understand 
when implementing their design, because if they fail to do so, it most 
likely will cause both usability and accessibility issues.


If you set any input control to read-only this is how it will behave, 
this is how it communicates to the user; This field is read only.  
That is what it means visually, it is greyed by default.


From page 158 of The Windows Interface Guidelines for Software Design;

   You can also use text boxes to display read-only text that is not
   editable, but still selectable.  When setting this option with the
   standard control, the system automatically changes the background
   color of the field to indicate to the user the difference in behaviour.

Notice it doesn't say greyed, it just says it changes the background 
color, because this is under the control of the custom settings of the 
users desktop.


This also leads to another problem, in that if users configure their 
operating system to a custom scheme, unwittingly the web designer may be 
indicating to the user that a field may be read only even if it is not 
grey.  How does the designer know whether to use grey or not?  They 
don't.  All they know is the majority of users probably do not customise 
this setting.


This is why I believe that it is best to not style form controls (or at 
least minimally), they can differ dramatically, not only over various 
operating systems, but over various versions and implementations of 
those operating systems, and the various custom desktop that the 
designer has no idea is being superimposed over their design, or visa versa.


If you don't style form control I think it is less taxing cognitively.  
I used to style them, but I have abandoned that long ago because I think 
users become so used to seeing the standard controls of their operating 
system, that on complex pages, it begins to become too difficult to 
easily recognise them, IMHO.


--
Geoff Deering






I think Bert D
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Philippe Wittenbergh wrote:



This makes kind of good argument for *not* styling form inputs at all, 
and leave it to the OS. On most of my OS X browsers, disabled form 
fields are not really greyed out, but rather use opacity reduction to 
indicate read-only.


Philippe
---



I agree with this observation exactly Philippe.  I addressed this 
somewhat in my post to Patrick.


-
Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Terrence Wood wrote:


Philippe Wittenbergh said:
 


This makes kind of good argument for *not* styling form inputs at all,
and leave it to the OS. On most of my OS X browsers, disabled form
fields are not really greyed out, but rather use opacity reduction to
indicate read-only.
   



A quick test of unstyled input type=text on winXP and IE6 reveals there is
*no indication at all* that a field is disabled. Nice one IE6. Oh, I lie
or I'm tired, the outline may have an indiscernable gaussian blur into the
field.

FF is grey, as is Opera.

kind regards
Terrence Wood

 



Yes, I'd really like to know the usability studies that changed the 
design of form controls so dramatically when MS designed XP.  The 
buttons I think are fine, but the form fields... I'd just like to know 
how they were scene as an improvement?


There are both *readonly* and *disabled* attributes in input elements.  
My main exposure to this was an Intranet application I was working on in 
2000, aimed at IE5.  Like many things that aren't major issues, I don't 
think it is well supported.  I haven't done a general check on this for 
ages, to see how well it is supported these days.


--
Geoff
**
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] Accessibility: Default placeholders

2005-11-13 Thread Geoff Deering

Graham Cook wrote:


Geoff Deering wrote:

Mandatory data fields, Required data, fields that require correct data
after validation should all be grouped together with a
*fieldsetlegend*.  This informs all users of the requirements of that
data.  Leave fields that do not meet this criteria outside this group,
either in a separate group or ungrouped.
   



I can't agree with this Geoff. There are many examples where some fields are
mandatory and others optional but need to be in one fieldset group. Some
examples include; first and surname mandatory, middle name optional, home
phone mandatory, fax or mobile optional,  addresses where extra optional
fields are added for long or complex addresses.

 




Yes, I agree with you on that.  Maybe there is a better way to approach 
those problems.  Don't have an answer to it.  In general though, I'd try 
and stick with what I have said before, but as you have pointed out 
here, there are obvious cases that don't easily fit to be able to 
present a logical flow of information.




This standard of putting an asterisks * after (or before an input field)
does not only not inform an unsighted user, it often gives the
indication after they have tabbed through the field, to late for them to
manage their input without back tracking.
   



The standard that I had used for the past several years was to place a
statement at the start of the form explaining the significance of the
asterisk. These are then included within the field labels and are read by
screen readers (use text asterisk not an image). Any errors identified upon
validation are listed at the top of the form (after the asterisk
description) and preferably include a link to go to the offending field(s).
The fields in error should also be identified both visually and textually
(ref http://telstra.com.au/standards/docs/accb_03001.doc page 27).

 



I think this is good implementation, but I think it makes it much less 
taxing on non visual users if such form fields can be clearly grouped 
together, but when this can't be done, it's fine.  This also helps 
visual users.


At lot of work went into the Telstra standards, it's a shame they never 
utilised the knowledge within Rob Pedlow's Research team, because those 
set of standards, that have been in use for almost half a decade, are 
full of holes and misunderstandings.


--
Geoff Deering
**
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] Naked metadata

2005-11-05 Thread Geoff Deering

Jonathan O'Donnell wrote:


Hi WSG'ers

In general, data (including metadata) should be stored in one place 
only. This prevents drift: if it is only stored in one place, it can 
only be updated in that place.


Often, the information that we want to store as metadata already 
appears in the Web page.  Examples include the title, description 
(especially as opening paragraph) and the author's name.  In footers, 
we often find rights information, the URL, and date information.


If this information already exists in the data, and we replicate it in 
the metadata, there is the danger of drift. Perhaps pointing to the 
data from the metadata fields is a way of preventing drift, and 
ensuring that the metadata is as up-to-date as the data.


** Method **



Hi Jonathan,

Given what you have said here, and what I would expect to see in serious 
authoring tools and CMSs, I think this area is generally neglected in 
most publishing tools (last time I looked).


Quit a few CMS's say that they are DC compliant, but as you mentioned, 
do they actually store the data in one place, and not in the web pages?  
Is it part of the work flow and version control of the documents?  I 
don't think so.  I'd be glad if anyone can point me to a product that 
does address this need.


For a CMS to address this properly, it needs to have incorporated a 
normalised schema based on DC into it's database.  This was all the 
pages published from this system can incorporate the various metadata as 
well as alt and longdesc for images.


Many organisations have legal requirements where they require snapshots 
of published data from any given time.  A publishing system based on DC 
not only allows this features, but allow a complete analysis of all the 
subcomponents of a document and the various contributors.


That also leads to problems with document management systems that manage 
their meta data from properties within the documents and network 
environment variables.


Last time I tried to extract metadata from MS Word, using Perl and 
Python, I could only get the standard set of properties, any data in 
custom properties was unretrievable (at least by me).  I don't know what 
OO or the latest MS Office offers.


But I don't think asking users to maintain this data will work, unless 
they are librarians.  I think that it has to be as automated and as 
transparent to the user as possible, because most users are just not 
interested in this level of site QA, unless it is an important component 
of the job.


Regards
Geoff Deering
**
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] Avoiding the evil br

2005-10-09 Thread Geoff Deering

Vlad Alexander (XStandard) wrote:


Hi Hope,

There is nothing evil about the br element unless one is using it for visual effect. In your 
example, you are using br correctly. For addresses, you might want to use the address 
element instead of p.

Regards,
-Vlad
http://xstandard.com
 



I agree with you about br, but address should only be used when it 
refers to the author or owner of the document

http://www.w3.org/MarkUp/html3/address.html
http://www.w3.org/TR/2002/WD-xhtml2-20021211/mod-text.html#sec_8.2.

Regards
Geoff
**
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] Avoiding the evil br

2005-10-09 Thread Geoff Deering

Mordechai Peller wrote:


Graham Cook wrote:


If BR is good enough for W3C, it's good enough for me.

Refer: http://www.w3.org/MarkUp/html3/address.html
  


Sure, back in March 1995 when HTML 3.0 was released as a recommendation.



It hasn't changed.

http://www.w3.org/TR/WD-html40-970708/struct/global.html#h-7.1.4.4
http://www.w3.org/TR/2002/WD-xhtml2-20021211/mod-text.html#sec_8.2.

-
Geoff
**
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 em and reseting within

2005-08-25 Thread Geoff Deering

Lea de Groot wrote:


On Thu, 25 Aug 2005 14:51:00 -0700, Janelle Clemens wrote:
 


If you are using em with font-size is there is a way to clear the font-size
of a box element (stop the inheritance)?
   



No, not really.
I normally get around this by only setting font-size in two places, as 
a general rule (which always has exceptions, but very careful ones :))

The two places are:
- on the body tag, eg
body {
 font-size: 90.1%;
}
- on leaf elements, ie. I will rarely set something like:
#wrapper {
 font-size: 0.9em;
}
I am more likely to put:
h1 {
 font-size: 1.6em;
}
and
div.subnote {
 font-size: 0.9em;
}
Both of these will be 'leaves' in the DOM, ie they will not have any 
children (except maybe a span)


HIH!
Lea
 



I'm just wondering how people handle the IE text resizing problem, where 
IE handles percentages much more accurately than em?


It would be more ideal to us em, but it seems more practical to use 
percentages for better accuracy of font scaling?  What do others think?


see
http://www.clagnut.com/blog/348/#c790


Geoff
**
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 em and reseting within

2005-08-25 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

I'm just wondering how people handle the IE text resizing problem, 
where IE handles percentages much more accurately than em?



You can safely use ems as long as your highest font size is 
something else, like %.

For instance, as long as you have something like

html { font-size: 100%; }

you can do anything you like with ems after that, like

body { font-size: 0.9em; }
etc

Can you give a technical explanation of what is going on there?  What is 
happening inside the user agent that once it sets it basic 
initialisation through such declarations, after that it can then render 
relative units correctly?



Geoff
**
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] Accessibility, the possibilities

2005-08-24 Thread Geoff Deering

Stuart Sherwood wrote:

Are any of the validation tools: Bobby, Cynthiasays, Watchfire...more 
respected then the others?


Regards,
Stuart.



You can use any of these, and all of them, but you should combine them 
with your own knowledge base and common sense.  I also use Marc Gueury's 
HTML Validator(http://users.skynet.be/mgueury/mozilla/).  There's no 
tool that I trust explicitly, but if you arm yourself with some basic 
knowledge, then even if a tool has it's short falls or faults, and you 
are aware of them, you can still use what it renders correctly to assist 
you.


Tabindex:  one piece of advice, if you code tabindex, don't use 
intervals of 1, use something like 10, 20 or even 50;


tabindex=10
tabindex=20
tabindex=50
whatever.

If you have to go back and change the order or add items, it's a pain in 
the arse if you have to change every tabindex in the document.  Tabs 
will naturally flow to the next highest value, it doesn't matter if the 
interval is 10 or 100, whatever, this allows you to insert other items 
later on, without having to edit the rest of the document.


What I usually do is break the document down into sections, and within 
the section increase at intervals of 10, but when I go to a new section, 
jump either one hundred or even a few hundred, even a thousand.  Gives 
breathing space... phew.


But in general, if the document is well structure, and still reflects 
that structure when styles are turn off, the tab flow is often the same 
with or without coding tabindex.  If that is the case, why bother coding 
tabindex (I realise there are exceptions like using an initial tab to 
set the focus/skip navigation)? 


---
Geoff
**
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] Accessibility, the possibilities

2005-08-23 Thread Geoff Deering

Stuart Sherwood wrote:


Hi All,
First, I'd just like to check I understand something correctly.
Validation for WAI AAA = WCAG 1.0 Priority 3. Is this correct?

Ok, we can validate for:

   * W3C HTML/XHTML
   * CSS
   * WAI
   * Section 508

And I've recently learnt about accessibility checks for:

   * Colour blindness
   * Contrast
   * Flicker/strobe

If you pass all these test, does this exhaust all accessibility issues 
or are there more?


Regards,
Stuart



http://www.w3.org/TR/WCAG10/full-checklist.html
http://www.w3.org/TR/WCAG10/checkpoint-list.html

I think there are P3 checkpoints that are not covered here that you 
would need to check manually.


Just as a side issue, there is a lot of debate in the accessibility 
community about the merit of using accesskeys, tabindex, etc.   
Sometimes there is no clear cut path to take regarding these issues, in 
some places, accesskeys can cause problems in the way they are 
implemented by user agents and also how they fit the site design, at the 
same time they can be of great help in forms on intranets where users 
are doing a lot of repetitive tasks.  Similar debates surround tabindex, 
sometimes it's best to leave this to the natural flow of tabs managed by 
the user agent, sometimes not.


IMHO, many accessibility practitioners aim for WAI-AA, whilst 
incorporating the most practical of the WAI-AAA checkpoints to aid 
accessibility. 

What I'm talking about here is a basic set of checkpoints one implements 
for all sites, in such cases, with ROI in mind.  My general target is 
WAI-AA with what I would call the essential AAA checkpoints.  Some sites 
(or clients) warrant all of P3/AAA, which is what is required to certify 
it as AAA.


My 2 cents worth.


Regards
Geoff


**
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: Staying on topic (was RE: [WSG] Accessibility, the possibilities)

2005-08-23 Thread Geoff Deering

John Foliot - WATS.ca wrote:


There are in fact checkpoints under all three Priorities which require
brain intervention - they simply cannot be tested mechanically.  Try
running a page through something like Cynthia says
(http://www.cynthiasays.com) will quickly show you what needs to be
manually checked.  Cynthia says also provides a fairly extensive chart
of what and how their tests are run
(http://www.cynthiasays.com/Standards/CynthiaVersusBobby.htm)

 



I'm glad John picked up on this thread and illucidated and expanded on 
it (and that the JF accesskey parser is working well ;-) ).



--
Geoff
**
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: Staying on topic (was RE: [WSG] Accessibility, the possibilities)

2005-08-23 Thread Geoff Deering

John Foliot - WATS.ca wrote:


There are in fact checkpoints under all three Priorities which require
brain intervention - they simply cannot be tested mechanically.  Try
running a page through something like Cynthia says
(http://www.cynthiasays.com) will quickly show you what needs to be
manually checked.  Cynthia says also provides a fairly extensive chart
of what and how their tests are run
(http://www.cynthiasays.com/Standards/CynthiaVersusBobby.htm)

 



I'm glad John picked up on this thread and elucidated and expanded on it 
(and that the JF accesskey parser is working well ;-) ).



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

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



[WSG] Evaluating Web Sites for Accessibility with Firefox (article on Chris Pederick's FF ext Web Developer toolbar)

2005-08-23 Thread Geoff Deering

Hi,

I know this article was bunched in with a reference to Ariadne back on 
10th August by sunny, but given it's relevance and importance in 
building a toolbox for evaluating web accessibility, and the recent 
question by Stuart Sherwood, I'll mention it prominently here, because 
it's a shame to not mention it.


Patrick H. Lauke has written this article 
(http://www.ariadne.ac.uk/issue44/lauke/) on Chris Pederick's Web 
Developer toolbar 
http://www.chrispederick.com/work/firefox/webdeveloper/, a tool Derek 
Featherstone also mentions as a great aid for web standards development.


--
Geoff Deering
**
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 Geoff Deering

David Pietersen wrote:


Sorry, trying to be aware of the request to stay on topic, but...
 
 You shold be more forward-thinking if you're responsilbe for .gov 
web site. (No offence, please.)
 
I never said my site was not compliant.  Every page of anything I 
serve (apart from the legacy apps) works perfectly in FireFox and 
Opera, and has at least a 1 A rating.  The content even works on my 
pda, which is Pocket PC of course ;-)
 
My whole point is... why bother?  Why spend the massive amount of time 
(and therefore 'the peoples' money) making it work across all these 
technologies when practically everyone who is using it has access to 
IE.  It is JUST a browser, heck, you don't even need to pay for it.  
Years ago, in a different organisation I worked for we made a piece of 
'Windows Only' software available for free.  The 'Apple People' 
screamed their heads off for three months until we also made their 
version available (at GREAT expense to the organisation).  I left 
about nine months later, and at that point 0 (zero) people had 
actually downloaded it.  Not one.  Zilch.
 
I respect everyones right to be different, but there comes a point 
when kowtowing to the vocal minority is just not fiscally responsible.
 
Anyway, I did not mean to hijack your list.  This is my last post on 
the subject.  Have a good day :-)
 
 



IMHO, it seems to me that everything you are saying here are basically 
all the same reasons to adopt web standards as part of the systems 
development lifecycle.  It does take more effort to learn to apply web 
standards, but the whole point is that there is less pain for both the 
user and developer in the process.  If you can't see that then why 
bother, and I'd have to agree with you, just go back to being happy with 
tag soup.


But there is also something else at play here, in that if it is a 
government department, there is probably some form of CMS involved and 
all the government procedures for managing digital documents, and that 
may or may not allow easy upgrades in the design, and some systems/CMSs 
are a nightmare to try to deploy standards compliant web sights.


In regards to large organisations, you are right, if the site is quite 
workable and accessible, it may create more problems than it's worth to 
try and implement a fix. 

But at the same time I think the experience of people on this list is 
that they achieve everything you aim for in accessibility and multiple 
deployment, and maybe more so, by using web standards, at least in the 
environments they work in.  Not only that, when you want to redesign 
your site, in any way, let alone upgrade it to address future 
technologies or devices, there is a lot of evidence to show that there 
is a big difference between those who do so with a base of standards 
compliant documents and those whose ones are marked up in tag soup.


This is something that quite often cannot be solved just by developing 
in web standards.  In large organisations the real problem is systems 
that are able to transform documents whilst maintaining the document 
structure, semantics and metadata.  There are hardly any systems out 
there that can do that.  But those who are looking to solve these 
problems, and have a keen eye to making sure the architecture and 
systems they are using will be able to accommodate such changes, along 
with being able to quickly adopt new technologies like SVG, AJAX, etc, 
will be in a far better position than those systems that are not trying 
to address these problems.


Also, IMHO, I feel that the overall quality of solutions offered as a 
web standards approach as opposed to tag soup will always offer 
superior advantages when do well.


Regards
Geoff Deering
**
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] HTML Codes - Characters and symbols

2005-07-12 Thread Geoff Deering

jackie reid wrote:

this is handy for people like me who dont know the  HTML Codes - 
Characters and symbols off by heart or even 1% by heart
 
http://www.ascii.cl/htmlcodes.htm
 
cheers
 
Jackie



If you are like me, looking for short cuts and wanting to economise on 
how much information is stuffed into your brain, you can use something 
like Tidy (http://tidy.sourceforge.net/) to do these conversions for 
you.  Many good web tools have a tidy interface, you just have to make 
sure you keep up to date with the most recent version of Tidy.


Regards
Geoff Deering
**
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] help or web standards group?

2005-07-11 Thread Geoff Deering

Lea de Groot wrote:


On Tue, 12 Jul 2005 09:26:22 +1000, Richard Czeiger wrote:
 

Perhaps there should be two lists - one for discussing 
standards/accessibility/best practice and one for how do I fix my 
float/site check please.
   

Having multiple lists also starts lots of flame threads on 'to which 
list topic X belongs'.
Given the number of tech lists with large membership and large traffic, 
I don't think anyone has solved the problem :(


I think the flip side is that a) newbies need to see the 'advanced' 
stuff to learn by osmosis and b) its really good for gurus to see the 
newbie questions (and maybe occasionally answer them?  Hint, hint 
people ;)) to keep them grounded.


warmly,
Lea
 



It's a huge Help when the Subject line clearly defines the topic, that 
way you can quickly identify threads where you may want to participate.  
It also helps when browsing archives.  Russ has covered this in the 
intro, and most lists do, but people still persist with Help Needed 
and equivalent vague and general subject titles.  If the subjects are 
titled in clear descriptive language, then a lot of these list problem 
are solved, and you may more readily attract people on the list who can 
contribute to that thread.


Regards
Geoff
**
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] help or web standards group?

2005-07-11 Thread Geoff Deering

Jason Foss wrote:


If I can chip in too - I don't have a problem with newbie posts, nor
more advanced posts. But I don't even open Help Needed type subject
lines. A descriptive subject line is all that's needed; you can
quickly decide if you want to read or get involved in the thread.

My 2c, anyway... :D

 



Exactly

Regards
Geoff

**
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] help or web standards group?

2005-07-11 Thread Geoff Deering

Joshua Street wrote:


There's a minor problem with this, though I agree with your core
argument.  Newbie posts requesting site reviews can't very easily bear
a descriptive subject line when all they want is advice on
semantics/markup and best practises.  There isn't a core problem they
want addressed, nor a core problem we as a group should seek to address.

 



I think Subject :Site Review Request/Help indicates what that post is 
all about, and I think the help people get on this list from those posts 
is really helpful, even for those of us just reading them.. 


There is, however, scope for refinement here.  If someone requests a
site review and an aspect of this website is found wanting, the way in
which this is discussed should not need to be confined within the
original thread.
 



I agree.


For example, if the subject line was Please review - example.com in
the initial request, and example.com used definition lists (just because
everyone loves to argue about the application of those!), then it may be
appropriate, when (inevitably) the scope of the discussion broadens to
bear a highly tangential relation to the originally referenced website,
to alter the subject line - RE: The undefined definition list (WAS:
Please review - example.com).

I'm aware this happens, though perhaps not as often as it should.

 



I agree with this, but some lists don't.  The trouble is when the thread 
is hijacked rather than a new sub thread is started to address the need 
to seperate discussion on a number of topics within the thread.



I think we need to accept that some subject lines are never going to be
descriptive in the way some members desire - and this isn't anyone's
fault, but it is something we can work to correct as the thread of
discussion progresses.

Kind Regards,
Joshua Street
 



Agree, if there is this level of thoughtfulness applied, I can't see 
any/too many problems as long as there is a reasonable effort to make 
the subject line descriptive.


Maybe enough said on this, at least from my part.

Regards
Geoff


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

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



[WSG] Call for Review: Working Draft of WCAG 2.0

2005-07-01 Thread Geoff Deering
Apologies for cross posting, but here's your chance to provide feedback 
on the W3C WCAG 2.0


http://lists.w3.org/Archives/Public/w3c-wai-ig/2005JulSep/.html

Regards
Geoff
**
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] Dumbing Down Validation in WCAG

2005-06-20 Thread Geoff Deering

Steven Clark wrote:


Has everyone read Gez Lemon's post on Validity and Accessibility?

http://juicystudio.com/article/validity-accessibility.php

Validation got moved down from level 1 to level 2 in the WCAG...

Steven Clark



I understand why it was given P2 status in WCAG 1.0, as that was way 
back in 1999, but for all the reasons we try to adopt standards, and for 
all the reasons we try to support them, I cannot find any good arguments 
for dumbing them down. 

I feel the W3C WAIGL may be trying to be helpful here, they are trying 
to be as expansive and inclusive as possible to all, they really do work 
hard at that, but what I think most people here understand, is that the 
standards themselves are meant to be inclusive.  Isn't there evidence 
enough on lists like this that shows a community of developers working 
together to solve such problems whilst still working with standards?  I 
mean, surely the only reason one would do that is out of the benefits, 
and not out of any dogmatic propensity to just abide by a set of 
standards.  If that is the case, why is there need to be regressive?


What I feel is happening here is that they are catering for the ATAG 
(http://www.w3.org/WAI/AU/) and UAAG (http://www.w3.org/WAI/UA/) world, 
who are trailing behind the web standards based developers, and WCAG is 
trying to accommodate that.  I don't really know, it's just outsider 
looking in. 

There are a lot of tools and user agents that need to be applauded for 
the efforts to better support W3C standards, but at the same time there 
are some, well many, that really need the ATAG and UTAG tests applied to 
them to show them for what they are.  Unfortunately very few people are 
willing to do this, and I can understand why, along with time and 
everything else, who really wants to be a web standards reviewer of 
tools and user agents?  I have thought about doing this myself, but I 
have found that the inner voice of criticism far outweighs the inner 
voice of complements when approaching such subject matter, and it seems 
just such a waste of time to get involved in if that is the outcome, 
even if it does help prompt some companies to address issues in their 
products.  But maybe it is time to do so.


I have thought about setting up a wiki to address this issue (I have the 
web server space to do it), and others regarding accessibility, because 
even if you go ahead and put Dreamweaver and FrontPage, and the rest of 
them, to the ATAG test, there should also be some knowledge base to show 
people who want to work with those products, or who are locked into 
working with those products, ways, means and methods to use these tools, 
in conjunction with other techniques and tools, to produce standards 
compliant web content.


If WCAG2 allows validation to be watered down to L2, I can only see this 
as being soft on ATAG and UTAG sectors of the industry, again making it 
much harder for developers.  Really, isn't so much of our time, 
knowledge and development now spent on working with the many user agent 
and tool bugs and shortcomings?  It's ridiculous to keep pandering to 
these weaknesses in our industry and actually accommodating their 
lethergy to do anything through the actual standards.


Maybe there should be either collective letter of protest written or 
individual voice their public concern over this to : 
[EMAIL PROTECTED]


Regards
Geoff Deering
**
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] small and big : accessibility usage?

2005-06-15 Thread Geoff Deering

Alan Trick wrote:


Acording to the WHAT-WG the small element does have semantic meaning.
I don't have the link though. They basically said that it was good for
things like 'small print' and such cases. I think small is an unusal
case here and is meanigful and useful.

Alan Trick

 



I think that when we are trying to apply accessibility principles we 
need to try to keep in mind the notion of device independance, and to a 
blind user small and big have no relevant descriptive meaning, 
because that element is then telling them that the word or phrase is 
either *small* or *large* in size, which isn't a true semantic markup, 
it's presentational.


I like Tim Bray's discussion on Descriptive markup as opposed to 
Semantic markup.


http://www.tbray.org/ongoing/When/200x/2003/04/09/SemanticMarkup

Geoff Deering
**
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] Character encoding (HTML Tidy)

2005-06-05 Thread Geoff Deering

Gene Falck wrote:



Tidy is one of the programs I have been thinking
of getting, so I would like to hear about any
bugs and bug fixes.

Regards,

Gene Falck



Tidy has evolved from it's beginning with Dave Raggett.  Like many 
tools, it's great when you learn how to use it, and to work with it's 
bugs.  I haven't had to use it recently, but will so again soon.  It's 
available in many forms


http://tidy.sourceforge.net/

Here's the reference on Encoding
http://tidy.sourceforge.net/docs/quickref.html#char-encoding

Programs like Homesite and TopStyle use Tidy, but it is your 
responsibility to make sure you are using the latest version of Tidy.exe 
(from SF.net), which is located in each programs root directory.  In 
Homesite it is dated 16 June 2001, so it's pretty old and out of date.  
TopStyle is 8 Aug 2004, where the latest version on the SF.net site is 
22 May 2005.  Just download it and update it.


I remember there used to be a bug that drove me nuts where it would 
escape characters it shouldn't, but can't remember what the situation 
was.  Probably been fixed, it was a while back.  It has got better and 
better, with less bugs.


I find it a great tool to have in the kit.

Regards
Geoff
**
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] Character encoding

2005-06-04 Thread Geoff Deering

Matt Thommes wrote:


What benefits or problems avoided do you perceive by doing this and
what other characters are you escaping?
   



Lea, I'm not sure why I always escape the dash - perhaps because I can??? :)

I am assuming the dash will someday cause me problems, so I just
escape it now, to avoid a lot of re-work.

Other than that, I escape a lot of usual characters, such as single
quotes, double quotes, and ampersands.

For some reason, I feel I have to escape every character that is not a
letter or number.

 



I think this is quite an interesting discussion, and I'm sure some of 
the members of this list can shed more light on this, but I do think 
developing with the best of practice forsight of the day does at least 
help to future proof web sites to address evolving technology.  We never 
know if the search engines or parsers of the future are going to have a 
hard time or easy time making sense of our sites.  I know I have 
developed sites in the past that I have felt pretty confident have been 
a good attempt at best of practice, but age sure shows their vintage, 
and I am not talking about the CSS, just thinking of the (X)HTML.


Tidy can help with transforming characters, but it does screw some pages 
up (don't know if those bugs have been fixed).


So what about Q or quote (XHTML2)?  Who bothers to use it? 


References
http://www.w3.org/TR/charmod-norm/#sec-WhyNormalization
http://www.w3.org/TR/charmod/

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

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



[WSG] FYI: Web Accessibility Engineer position open at W3C/WAI

2005-06-02 Thread Geoff Deering
From memory, this position has come up time and time again over many 
years.  I don't know if it has ever been filled.


 Original Message 
Subject:Web Accessibility Engineer position open at W3C/WAI
Resent-Date:Thu, 02 Jun 2005 03:52:57 +
Resent-From:[EMAIL PROTECTED]
Resent-CC:  recipient list not shown: ;
Date:   Wed, 01 Jun 2005 23:41:13 -0400
From:   Judy Brewer [EMAIL PROTECTED]
To: WAI Interest Group [EMAIL PROTECTED]



Dear WAI Interest Group Participants:

The Web Accessibility Initiative (WAI) at the World Wide Web Consortium 
(W3C) is currently seeking a Web Accessibility Engineer. Please feel free 
to circulate this notice, avoiding cross-postings where possible.


The job description is listed below, and is also available on the MIT/CSAIL 
Web site along with instructions on how to apply. Please note that any 
correspondence related to the position should be sent via the contacts on 
the MIT/CSAIL site, not in reply to this email.


Regards,

- Judy

Job description and application instructions:
   http://www.csail.mit.edu/contact/jobs/2002.html

Job Description:
Title: Web Accessibility Engineer
Req Number: mit-2002

WEB ACCESSIBILITY ENGINEER, Computer Science and Artificial Intelligence 
Laboratory, to
ensure that core web technologies support accessibility for people with 
disabilities as part of the World Wide Web Consortium's (W3C) Web 
Accessibility Initiative (WAI). Will assist in developing guidelines, 
techniques, and test suites for authoring tools, browsers, and media 
players; provide staff support to W3C WAI (http://www.w3.org/WAI/) working 
groups; assist in reviewing W3C technologies while under development to 
ensure their support for accessibility and develop and negotiate technical 
solutions for accessibility requirements; manage issues lists for comments 
received on working group documents; edit working group documents; and 
maintain working group resource pages. Will also give presentations on 
W3C/WAI technical work, provide technical assistance on implementation of 
WAI guidelines, and liaise with organizations pursuing related work.


REQUIREMENTS: computer science or related degree; a minimum of two years' 
experience working in team settings; and in-depth knowledge of W3C 
technologies and WAI guidelines, including WCAG, ATAG, UAAG, XAG, and EARL. 
Must be familiar with the web industry, accessibility support in mainstream 
web technologies, assistive technology, disability communities, and the 
accessibility research community. Excellent oral and written communication 
skills needed. Must be available to travel. Knowledge of project 
management, W3C process, web applications, QA procedures, CMS, user 
interface design, VoiceXML, RDF, Semantic Web, and DOM preferred.




--
Judy Brewer+1.617.258.9741http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G530
32 Vassar Street
Cambridge, MA,  02139,  USA





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

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



[WSG] EDS embracing Web Standards

2005-05-25 Thread Geoff Deering
Had cause to visit the EDS.com web site tonight.  I used to work for 
them years ago.  They had one of those absolutely horrible corporate 
sites last time I visited, but shock horror... 
http://www.eds.com/site/standards.aspx  AMAZING.


Regards
Geoff Deering

**
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] best way to approach markup of an address

2005-05-22 Thread Geoff Deering

Lea de Groot wrote:


On Mon, 23 May 2005 06:48:55 +1000, Geoff Deering wrote:
 

The first is correct, but address should only be used when 
referencing the author of a document.


http://www.w3.org/MarkUp/html3/address.html
http://www.w3.org/MarkUp/html-spec/html-spec_5.html#SEC5.5.3

It's not used for general contact information, which is kind of waste 
of a good element.
   



Happily, both of the examples you cited contradict you.
Do put street address in ADDRESS tags :)

warmly,
Lea
 



What I meant was that it is not used for general contact information as 
in using it for any sort of address.  It is specifically for the contact 
of the person responsible for that document.


The *ADDRESS* element is not appropriate for all postal and e-mail 
addresses; it should be reserved for providing such information about 
the contact people for the document.


see
http://htmlhelp.com/reference/html40/block/address.html
which is probably a much better reference.

That is the semantic meaning of address on a web page.

Regards
Geoff Deering
**
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] best way to approach markup of an address

2005-05-22 Thread Geoff Deering

Patrick H. Lauke wrote:


Geoff Deering wrote:

The first is correct, but address should only be used when 
referencing the author of a document.



Arguably, though, if these are the contact details of the company 
whose site you're on, then it *is* correct (as they would, in the 
wider sense, be the authors of their site - and not Bob down in the IT 
department). So establishing whether or not it's correct obviously 
depends on context, which Bruce didn't provide in his question.



Yes, it can be anyone responsible for the content on those pages, such 
as the address of the real estate agent on a house for sale page, but I 
couldn't use it (correctly) to make a list of addresses of places I 
visited during my holidays, whatever.  In other words, if you use the 
address element on a web page, that is telling a parser that that is the 
contact address information associated with the content of that document.


Thanks for the HTML4 reference.

Regards
Geoff Deering
**
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] make poverty history website

2005-05-20 Thread Geoff Deering
Patrick H. Lauke wrote:
And now I just realised that the original question was not about 
accessibility, but about specifications in general (such as the 
XHTML/CSS/etc ones). In which case, even more of a reason why the W3C 
can't release a spec for Flash: it's not their technology. They can't 
release a spec if it's owned by a commercial company.Of course they'd 
only be releasing *their* specs, as they relate to *their* official 
technologies. It would be a bit like saying Why don't Microsoft 
release a spec for Quicktime movies...

It's actually the other way around, companies and organisation 
developing technologies are encourage to develop them according to W3C 
recommendations.  So

1) Web developers are encouraged to follow WCAG,
2) Authoring Tool developers are encouraged to follow ATAG 
(http://www.w3.org/TR/ATAG10/)
3) User Agent developers are encouraged to follow UAAG 
(http://www.w3.org/TR/UAAG10/)

The UAAG applies to Flash.  http://www.w3.org/WAI/UA/
The current versions of Flash have improved their accessibility to some 
degree, thanks to both pressure from groups like this, and a fair bit of 
working behind the scenes by W3C accessibility people.  Bob Regan is the 
accessibility product manager for macromedia 
(http://www.markme.com/accessibility/).

I notice that Macromedia is not on the UAAG participants list 
(http://www.w3.org/WAI/UA/wai-ua-members.html), but I think they are on 
the authoring list (http://www.w3.org/WAI/AU/), but not currently in 
good standing.

If you really want to chase up the current state of companies working 
with ATAG and UAAG it's best to ask Matt May 
(http://www.w3.org/People/Matt/), he's the guy working with these 
companies (last I checked).  He's be a good person to throw 10 questions 
at for the WSG:-)

Regards
Geoff
**
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] W3C and Flash

2005-05-20 Thread Geoff Deering
Prabhath Sirisena wrote:
Until Flash becomes an open specification, we'll have the song and
dance. Making it an open spec won't happen because Adobe won't really
benifit from the deal.
Prabhath
http://nidahas.com
 

I don't think it has to be an open specification at all.  It can remain 
closed and do it's own thing on a proprietary basis, but it needs to 
comply with UAAG to meet the W3C standards compliance we are trying to 
work with to make our web sites as standard and accessible as possible.

We don't ask IE or Opera to be an open specification, or JAWS, or 
anything else, but we do encourage them to meet W3C UAAG, so that we can 
then use them and incorporate them into our web content with full 
confidence that they meet web standards and accessibility guidelines.

Regards
Geoff Deering
**
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] make poverty history website

2005-05-20 Thread Geoff Deering
Patrick Lauke wrote:
Geoff Deering
   

 

It's actually the other way around, companies and organisation 
developing technologies are encourage to develop them 
according to W3C 
recommendations.
   

That still does not detract from the fact that the Flash format
is not a W3C technology.
 

The UAAG applies to Flash.  http://www.w3.org/WAI/UA/
   

True, but that does mean that the W3C is in a position to release
a spec for the *format*.
 

I can't see what the point is.  The W3C has no control over Java or many 
other technologies that are proprietry or closed, but that does not stop 
them from becoming or meeting W3C standards or compliance.  But it is 
still a headache for us developers, because then we have to deal with 
plugins.  It would be far better to be living in a world where the user 
agent run everything native; SVG, SMIL, etc.  But how far are we from that?

One thing that gets my observation about watching discussions on lists 
like this, is not so much the education and learning of standards, which 
is enough to do as is, but the huge amount of time and investment in 
learning all the user agent bugs and gotchas.  I just wonder, if we 
really had to cost our development time, how much of it is dealing with 
both authoring tool and user agent bugs?

And another thing, the effort developer put into dealing with this is 
not recipricated, in my view, by many of the companies producing the tools.

If you really want to chase up the current state of companies working 
with ATAG and UAAG it's best to ask Matt May 
(http://www.w3.org/People/Matt/), he's the guy working with these 
companies (last I checked). 
   

Unfortunately, Mayy is leaving (or has already left) the W3C
http://www.bestkungfu.com/archive/date/2005/04/quittin-time/
 

That's sad.  He doen't say so, but I think a lot of them get W3C burnout 
trying to deal with those companies.  They can't speak freely, but I 
suspect a lot of the companies have their token member on W3C working 
groups, where back at HQ the project manager really doesn't give it much 
priority.

Regards
Geoff
**
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] make poverty history website

2005-05-20 Thread Geoff Deering
Patrick Lauke wrote:
Geoff Deering
   

 

True, but that does mean that the W3C is in a position to release
a spec for the *format*.
 

I can't see what the point is.  The W3C has no control over 
Java or many 
other technologies that are proprietry or closed, but that 
does not stop 
them from becoming or meeting W3C standards or compliance.
   

Geoff, don't misunderstand me. I'm not advocating that only W3C technologies
should be used, and that Flash is in any way bad. I was merely replying to
the do the W3C have specs for Flash question that was originally
posted.
 

Thanks for clarifying that, now that I look back at the discussion I see 
the thread of the logic now:-)

I see your point (unless I'm misunderstanding): the W3C should provide standard
and compliance requirements for any type of content, be it Java, Flash, PDF, etc
But this does seem well beyond the W3C's remit, and yes it goes against their
utopian but we have all these wonderful technologies of our own...SMIL/SVG/co
view.
 

I think it is the best of both world.  If it is an open specification 
developed by the W3C then that is obviously going to provide a better 
premise to work from, but if it is proprietry, then it's also okay as 
long as it meets the various standards.

But the W3C has become so complex that anyone working in one area may 
not realise that they may possibily be not working properly with other 
standards.  At the same time, from what I have seen, they really do work 
hard at trying to be inclusive of everyones needs.

And another thing, the effort developer put into dealing with this is 
not recipricated, in my view, by many of the companies 
producing the tools.
   

Very true.
 

sigh:-(
Geoff
**
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] Playing a sound file - what is the best way?

2005-05-17 Thread Geoff Deering
Mike Foskett wrote:
I completely agree, use Flash.
I'd say the same for video too, for the same reasons.
Why:
 One solution multiple platforms.
 Saturation on all computers is over 90%. That's more than any browser.
 

What data is this statistic based on?
Regards
Geoff Deering
**
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] Playing a sound file - what is the best way?

2005-05-17 Thread Geoff Deering
Tom Livingston wrote:
On Tue, 17 May 2005 14:13:50 -0400, Mike Foskett  
[EMAIL PROTECTED] wrote:

Stat based on these figures from Macromedia:

I might add that these are merely posted on MM's site. The study was  
independent.

http://www.macromedia.com/software/player_census/flashplayer/
There is a link that speaks to the company that did the survey...
Can someone please educate me to the claim here;
http://www.macromedia.com/software/flash/survey/
that;
In March 2005, NPD Research, the parent company of MediaMetrix, 
conducted a study to determine what percentage of Web browsers have 
Macromedia Flash pre-installed. The results show that 98.3% of Web users 
can experience Macromedia Flash content without having to download and 
install a player.

1) I have never come across a browser, which installed with Macromedia 
Flash pre-installed.
2) I never knew that 98.3% of Web users can experience Macromedia Flash 
content without having to download and install a player.

If they are coming from the standpoint that Flash was already installed 
(by someone), that to me seems to not be clearly stating the whole 
picture they are basing their scenario on and not presenting it in a 
true objective fashion.

Last time I did a check on a series of browsers for the accuracy of 
HTTP_ACCEPT (a few years ago), it was quite unreliable.  I had flash 
installed on all browsers, but not all of them reported this to the 
server, yet it was registered in their plugins.  If there are more 
reliable methods of detecting plugins I appreciate people sharing them.

Then there are the users out there that have flash installed and other 
3rd party software to stop Flash from playing, so that they can control it.

I agree with the suggestions to the various implementations of Flash to 
solve the original problem posted to this site, I think when all is 
taken into account, usability, design, accessibility, that is the best 
strategy.

But statistics can be used to serve misinformation, and what I see on 
the Macromedia site gives me no reason to have any confidence in an 
accurate evaluation via clear and thorough methodology.


Geoff
**
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] Playing a sound file - what is the best way?

2005-05-17 Thread Geoff Deering
Kay Smoljak wrote:
On 5/18/05, Geoff Deering [EMAIL PROTECTED] wrote:
 

1) I have never come across a browser, which installed with Macromedia
Flash pre-installed.
   

IE6 comes with Flash player pre-installed.
 

All versions, or a specific implementation/installation?
Geoff
**
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] Playing a sound file - what is the best way?

2005-05-17 Thread Geoff Deering
Kay Smoljak wrote:
On 5/18/05, Geoff Deering [EMAIL PROTECTED] wrote:
 

IE6 comes with Flash player pre-installed.
 

All versions, or a specific implementation/installation?
   

I can't say for sure, but my feeling is that it's all versions. 

 

Well, I have installed WinXP (initial release) and the recent release 
with SP2, and downloaded IE6 on a number of occassions and installed it 
on other versions of windows, and not one of them has had Flash 
installed.  It may come with an OEM install, but I have never seen it 
come with IE6.

Also, I have found that even when it is installed, and the user has 
installed something like Crazy Browser so they have a tabbed version of 
IE, for some reason Flash does not load.

Geoff
**
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] mutli language websites

2005-05-16 Thread Geoff Deering
sam sherlock wrote:
Hello WSG List Members,
I am delveloping a website that can switch between english and 
itallian.  I am wondering if I should be using en-GB or en-gb for my 
lang attributes
and also for the meta http-equiv=Content-Language content=en-GB 
/ are these attributes sensitive to casing? or should I just have en

also is the charset iso-8859-1 OK for italian content?
I would also appreciate any links to web standard sites using multiple 
languages?

thanks in advance, Sam

Does anyone use transparent content negotiation to handle multiple 
language sites?  I get the feeling this is hardly ever used, if so, why not?

Regards
Geoff Deering
**
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] mutli language websites

2005-05-16 Thread Geoff Deering
Robin Berjon wrote:
The problem IME is that when you use it you have to also provide a way 
for the user to pick her language which will override the negotiation 
(I've been accessing the Web a lot from computers localized in 
Japanese recently, and they're probably not sending Accept-Language 
headers that reflect the reality of languages I can really accept 
:). It's not complicated to mix both together but the extra feature of 
negotiating the default language rarely seems worth it.

Yes, these are some of the problems I would have expected using this 
approach.  Let alone if you are in some other country, in a net cafe and 
it is defaulting to another language, as what often happens with Google, 
which can be annoying for the user.

Regards
Geoff D
**
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] mutli language websites

2005-05-16 Thread Geoff Deering
sam sherlock wrote:
I am using ip2couuntry class in PHP to decide the default lanuage.
Thanks to Evandro who sent me a link to his site in Portugese and 
English.  The site in question does not use the language attribute as 
inteneded (as far as I understand) all Lan attributes are set to en 
for Portugese, Itallian and English.

What is the web standards best practise for multi-lingual sites
   1. Should I use en or en-GB is the casing important?
   2. What charset should I use for the Itallian version the same as
  english or other?
   3. Are the any link available to webstandard best practise examples?

Maybe you will find some of the info you are looking for here
http://www.w3.org/International/geo/html-tech/resources/
G
**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Geoff Deering
 Andy Budd wrote:
 So what do they believe the accessibility advantages of XHTML Strict
 are? As far as I'm aware valid and semantically correct HTML is just as
 accessible as XHTML strict. And I'm guessing they probably aren't
 serving their pages up as XML so strictly speaking they are serving
 their pages up as HTML anyway.
 
 This kind of pettiness and misunderstanding of accessibility really
 gets my goat.
 
 It's a damn shame if you ask me ;-)
 
 Andy Budd
 
 http://www.message.uk.com/

There are a number of advantages to using HTML/XHTML Strict.

Firstly, the term strict implies the strict separation between content and
presentation.  This is meant to have benefit for both user and developer (in
an ideal world).  It is meant to free up both the user and designer.

Normally with think STRICT, those W3C Nazis (like I saw recently on
another list:-), but the whole idea behind Strict is the strict separation
of content and presentation, ultimately aiming for both users and designers
worlds to be much more free and flexible.  That's the point.

Using strict frees the markup of attributes that are bound to the content
layer.  This ideally frees the web pages to accommodate more flexible
designs.  With strict you could develop alternate style sheets, one with
absolute units (to satisfy client requirements), and one with relative units
(to satisfy accessibility requirements), whatever you want.

If you use transitional, that is exactly what you are doing, and you may
need to do it, strict may not work for your design because of current lack
of support and other things, but you are using a DTD that is transitional
between the aim of separating content and presentation, and mixing them
together.  It's basically a compromise.

From a developer's point of view, in large content systems, one of the major
problems is separating content from presentation.  It is very difficult to
regenerate sites with fresh designs if this issue is not addressed at the
foundation level.  This also aids addressing accessibility issues.

We just have to look at any of our own work, when better user agent support
arrives in the future, and the customer requires a redesign, will we be able
to leave the HTML/XHTML as is, and just modify the CSS, or will it require
an overhaul of both?

Regards
Geoff Deering

**
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: XHTML Strict alternative to ol start=11

2005-02-08 Thread Geoff Deering
 Patrick H. Lauke wrote:
 I think what Andy meant (as I've got a feeling he's well in the know
 when it comes to css and separation of content and presentation) is what
 the advantages are if you can effectively write strict code while still
 declaring a transitional doctype. Yes, transitional doesn't make certain
 elements illegal, but that doesn't mean that developers can't do nicely
 separated content/HTML and presentation/CSS which happen to have a
 transitional doctype. There are *no* inherent benefits to tableless, css
 driven layouts in XHTML strict versus tableless, css driven HTML (strict
 or transitional) or even XHTML transitional. 

That is a misconception.  There are differences to the way a rendering
parsing engine will work with the different doctypes.  Just as a C
programmer thinks what will the compiler do with this code, there needs to
be some understanding of what is happening at the parser level.  That's also
why this list exists, because, from what I can see is that most of us need a
list like this so that we can deal with the bugs that are in the parsers and
rendering engines.  But I'm also talking about working with bug free
parsers, even if that is in the future.  In that case there is quite a bit
of difference with the way a parser will work with the same design in Strict
as it will in Transitional.  If we fail to understand that we are failing to
understand what is happening with DOCTYPE parsing and rendering.

I can understand why you'd use Transitional, where you could use Strict, ie
where there may be a lack of browser support for a particular design
implemented in Strict, but not supported properly, so you'd use
Transitional.  But it makes no sense to use Transitional where Strict does
exactly the same job.

 In particular, when served
 as text/html rather than application/xhtml+xml, and when not mixing in
 additional X technologies, for all intents and purposes XHTML is
 simply HTML with a slightly funkier syntax (self-closing elements for
 instance) which older browsers treat like broken HTML. There is no added
 benefit to the user. All the things you mention (switching stylesheets
 for different layouts, etc) can be done fine in transitional.

You are missing my point completely.  Try maintaining or redesigning large
content sites that need to meet web and accessibility standards that are
caught in this dilemma.

I'm surprised both of you, who have more knowledge than I do in the design
area, have not come across this very problem.  I really see it as something
basic that web developers who take accessibility and web standards as their
core approach would understand that to redesign sites that meet valid strict
(either HTML or XHTML), are much easier to rework than Transitional.

And it has very little to do with the deprecated elements.  The real lose is
the attributes for elements found in both DTDs, which are not part of
Strict, because they are presentational by nature.

 XHTML (and strict in particular) being more accessible than HTML (and
 particularly transitional) is a myth. Conscientious coders can use
 exactly the same approach (tableless etc) in both.
 

Please explain why you would use a transitional DTD where a Strict one is
valid and works just as well?

Regards,
Geoff Deering

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

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



[WSG] FW: The list cms@webstandardsgroup.org is a private list

2005-02-02 Thread Geoff Deering
Can someone please clarify what is going on with the CMS list?  I've been
away for a few months, and off list.  I've resubscribed to this one, but get
the error/rejection below when I try to subscribe to the CMS list.  I
emailed info@webboy.net with the problem this morning at 8.45am.  No reply.

http://webstandardsgroup.org/go/resource131.cfm is certainly hidden away
from the main contents.

Geoff

-Original Message-
From: cms@webstandardsgroup.org [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 2 February 2005 8:02 AM
To: [EMAIL PROTECTED]
Subject: The list cms@webstandardsgroup.org is a private list

Sorry, the mailing list cms@webstandardsgroup.org does not allow
subscriptions.



**
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] standards and meta tags

2005-02-02 Thread Geoff Deering
 -Original Message-
 From: Patrick Lauke
  From: designer
 
  After looking at the site mentioned by Anthony (relating to
  standards and
  local government) I noticed a lot of meta tags on that site [
  http://www.salford.gov.uk ] which I haven't seen before
 [...]
  Forgive my ignorance on this, but can meta tags just be
  'invented' and be
  acceptable 'standards'?
 
 Unless I'm mistaken, you can make up your own META if you want,
 for whatever reason you may have (e.g. something specific to your
 own site management / CMS tools, your internal search engine, etc).
 
 Of course, to be truly useful, the META should follow a formally
 published standard (e.g. Dublin Core), but there's nothing stopping
 you from writing your own standard - if people find it useful, they
 may use it. But yes, I'd liken it to the way in which you can make
 up your own elements in XML, but how it's only useful if two or more
 people then agree to use the same format (and then you publish something
 like a DTD or Schema, etc).
 
 The HTML4 spec also mentions the use of the profile attribute in
 a document's HEAD, which can be used to give more context to META.
 http://www.w3.org/TR/html4/struct/global.html#h-7.4.4
 (but again, nobody stops you from making up your own profile).
 
 Patrick

That's right.

There are all sorts of metadata and subsets thereof, the most common
standard being the Dublin Core.  Vocabularies, Qualifiers, etc are used to
extend and further define the core elements via subsets.

And if you just can't get enough metadata, try this

http://dublincore.org/2003/03/24/dces#title
http://dublincore.org/2003/03/24/dces#creator

The Semantic Web (W3C) version is all about metadata.  It's not the same
thing as we refer to when we talk about documents being semantically
correct.  In my opinion the W3C Semantic Web Initiative is an admission that
the efforts to make a semantically rich web via semantically correct
documents has failed.  But I don't think the Semantic Web really addresses
the root of the problem.  The major problem is that metadata is not
maintained at the file system level, and only at the document level.  This
makes it almost impossible to track versioning, history, and regenerate web
sites and document sets, and everything else that is associated with proper
document management.  This is supposed to be addressed in the next version
of MacX and Windows, but I doubt it.  Also no CMS manages metadata at the
filesystem or at the versioning level.

Also see
http://dublincore.org/usage/documents/overview/
http://www.w3.org/2001/sw/
http://www.w3.org/TandS/QL/QL98/pp/dstc.html
http://www.medra.org/en/metadata.htm
http://www.naa.gov.au/recordkeeping/gov_online/agls/summary.html
http://www.edna.edu.au/metadata
http://en.wikipedia.org/wiki/Metadata_%28computing%29
http://home.wlu.edu/~blackmerh/meta/acs12vi.html
http://www.xml.com/pub/a/2003/04/16/deviant.html


**
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] about.com's Web standards article

2004-10-10 Thread Geoff Deering
Back about a year ago about.com were using Movable Type for all there sites.
So they should be in complete control of their code.  If they wanted to save
money on bandwidth why don't they gzip up all their pages and configure the
server to send those to user agents who handle them, which, I think, is
pretty much most these days.

-
Geoff

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

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



[WSG] Mac Tools Kit for Web Standards Developer

2004-10-08 Thread Geoff Deering
Hi,

I'm wondering what tools Mac developers out there use?  I'm basically and
windows and linux person, but will get a small iBook for travelling and
testing on next week.  I'll be OS in Nov/Dec and need to still do some work,
so I need to be able to work pretty comfortably on the Mac.  On Windows I
mainly use TopStylePro.

Appreciate any Mac software tips for standards based development

-
Regards
Geoff Deering

**
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] Is XHTML harmful?

2004-10-08 Thread Geoff Deering

Paul Connolley wrote:

 
 Geoff Deering wrote:
 
  I am talking about CSS applied to HTML and the rendering of the CSS as
  applied to the parsing of the document.  But still, strictly speaking, 
  an
  XML based document is bound to be more semantically correct because it 
  is
  well formed.  This means that the CSS can be applied without fear of 
  the
  parser misunderstanding where a declaration could have finished.  
  There is
  no possibility of any guess work in xhtml as it is well formed.
 
 You are talking about two distinctly different parsers. XHTML is a XML 
 subset, HTML is an SGML subset.
 
 For example:
 
 In XHTML:
 
 ul
liOne item/li
liSecond item
liThird item/li
 /ul
 
 This will throw an error because it is bad XML
 
 In HTML it will not. With the SGML parser it knows that when it arrives 
 at a new li it is the beginning of a new list item. The same would 
 apply, for example, to a p paragraph. Surely you don't believe that 
 it would render
 
 pThis paragraph
 pThis other paragraph
 
 as a paragraph within a paragraph. You need to revise your 
 understandings. HTML is NOT XML. Admittedly, XHTML contains inheritance 
 to certain HTML objects but it is wholly a XML subset. You shouldn't 
 try to argue about parsing when they are parsed by two different types 
 of engines.


But that is entirely my point.


 
  You're missing the point.  Closing tags is being completely accurate 
  with
  punctuation, where markup is the punctuation.  Not closing tags CAN 
  lead to
  ambiguity.  In XHTML there is no syntax ambiguity, in HTML4 there are
  possibilities.  It may not happen when validating against the doctype.
 
 Once again you are arguing  for ambiguity. It is wrong to assume this. 
 SGML allows for the omission of end tags because it follows a different 
 ruleset
 

That's exactly the point I am trying to make.

-
Geoff 
**
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] Is XHTML harmful?

2004-10-08 Thread Geoff Deering
What Dean says so well here are also the reasons I prefer XML defined
markup, and I don't think it negates the arguments that others have been
expressing here for HTML.  I think each on of them have valid points.  But
it seems to me that there are more reasons to use an XML based vocabulary
than have previously been put forward.

I also agree with him about writing parsers and their performances based on
stricter or looser rule sets.

I also try to see XML vocabularies as having a richer and more accurate rule
set to express the content they encapsulate.  I dream of a true semantic web
were I can find content from searches that are based on arguments and
phrases that are derived from clean document tree analysis of content.  Even
if we have those documents out there, current search methods and technology
are far too primitive to understand that.  Not that the search engine
engineers are dumb, it's just that for all the content out there, there are
only small portions of it that can be stored and analysed semantically, so
there is not much point in doing that regarding ROI.  And I don't agree with
a lot of the way the W3C are handling the semantic web.


-
Geoff Deering

Dean Jackson wrote:

 Friday, 8 October 2004 2:23 PM
 On 7 Oct 2004, at 02:09, Vlad Alexander (XStandard) wrote:

  Hi Kim,
 
  Ian Hickson is _not_ saying XHTML is harmful, he is saying that
  serving up XHTML with the wrong MIME type is bad.

 That's right. It's probably not the best title for the
 document, but my feeling is that people using the ... considered
 harmful approach are typically looking more for attention than
 for examination.

 Nevertheless, it's still an interesting read.

  Today, the real benefits of XHTML are on the production side. Say your
  CMS has 1000 documents and you need to change the class name of a
  div tag in all 1000 documents. If your content is in XHTML, you can
  use XML related technologies like DOM or XSLT to process all 1000
  documents quickly and accurately because XHTML can be processed by XML
  parsers.

 I agree.

 Using XHTML over HTML brings some benefits that are hard to measure.
 The way I think of it is that XHTML allows more people to use your
 content in ways that you didn't originally expect. For example, at
 W3C we extract a lot of semantic info from our XHTML pages: building
 calendars, issue lists, relationships between pages, etc. This could
 all be done using HTML, but XHTML makes it easier (much wider range
 of tools in the XML world). The same goes for modifying pages. I have
 a huge range of tools available to do a site wide change with XHTML,
 and these tools are interoperable because they conform to the XML
 specification. If my Web guy gets hit by a truck, then I can
 call up another developer and assume that her XML skills will be
 enough to do the job (even though she may not be familiar with the
 tools).

 Then there is the whole Web Applications trend. Again, HTML and
 XHTML are pretty much the same in functionality here, but if I'm
 using an application on the Web then I want to make sure it is
 well-formed and well-structured. I don't want a typo by a web
 developer (such as leaving off an end tag) to cause my credit
 card to be debited twice. That's an extreme example, but in the
 general case, would you really run an application on your desktop
 that you were not sure was compiled correctly (or had millions
 of compiler warnings)? Allowing sloppy markup in applications
 is a security risk IMHO.

 On the design front, if you are thumping your head against a
 wall trying to wonder why the page is off by three pixels, wouldn't
 you like to rule out as much as possible in order to reduce the
 number of places you look for the bug? In most cases, this is
 easier with XHTML - you can check the document and then focus
 on the CSS.

 While the existing browsers are parsing and rendering HTML faster
 than XHTML, then you can serve XHTML 1.0 as HTML. I'm not sure
 exactly why HTML parsing/rendering is faster than XHTML, since in
 general it is much easier to right a high-performance parser for
 a strict language than a less strict one (and HTML also carries
 years and years of quirks to handle). Maybe it is just that the
 HTML code has been around for so long that it is highly optimized.
 Let's hope the desktop browsers will move into 2001 soon ;)

 To ask the question the other way around, what are the real
 benefits of using HTML over XHTML? I'm interested to hear the
 reasons (and I'm sure they are valid).

 Dean


**
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: Is XHTML harmful?

2004-10-08 Thread Geoff Deering
 From:Of Alan Milnes

   Ian Hickson is _not_ saying XHTML is harmful, he is saying that
   serving up XHTML with the wrong MIME type is bad.

 I've read the article and what I don't understand is that if it is so
 bad why is it acceptable to the Validator?

 I write my pages in XHTML with a XHTML 1.1 doctype and send the content
 type as text/html.  That's how I was taught (doesn't make it right I
 know) and it validates.

 I've tried several methods of sending different headers depending on the
 browser but have yet to find one that works properly.

 Alan
 http://www.gameplan.org.uk

Actually that's a good point.

Most people who are trying to manage this are using TCN (Transparent Content
Negotiation), or similar technology set, on the server side to serve
documents according to the user agent capacity.

-
Geoff

**
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] Mac Tools Kit for Web Standards Developer

2004-10-08 Thread Geoff Deering
 From: Kristof Rutten

 Hi Geoff,

   I've 'switchted' sides in March of this year and haven't returned to
 my old Win-platofrm ;)

Yes, I suspect it could happen to me too, especially when you have the best
of both worlds; Mac front end, and *nix backend, although I really do like
GNOME and KDE.


   Tools I use most while desingning :

   CSSEdit from MacRabbit - http://www.macrabbit.com/cssedit/
   Transmit - a great FTP client -http://www.panic.com/transmit/
   CocoaMySQL - database tool - http://cocoamysql.sourceforge.net/

   Take care, the OS X platform is highly adictive and you are not likely
 to return
   to your old win/linux boxes ;)

 Regards, .K


Suspect you're probably right... thanks for the user friendly warning:-)

-
Geoff

**
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] Mac Tools Kit for Web Standards Developer

2004-10-08 Thread Geoff Deering
I have a 19 and 21 for development, so I'll just KVM the iBook (can't
afford a Powerbook)

Thanks

 Upon a little test run, the live preview of the code (literally 'as you
 type') is neat. This looks like it might be a pain for a small screen
 though. I have a 17 Studio Display, and i wasn't fond of the amount of
 room I had to code in. Still nice though.

 
 Tom Livingston
 Senior Multimedia Artist
 mlinc.com

 Get FireFox   http://spreadfirefox.com/community/?q=affiliatesid=0t=1



 On Oct 8, 2004, at 9:35 AM, Tom Livingston wrote:

  http://www.tumultco.com/HyperEdit/

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

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





**
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] Mac Tools Kit for Web Standards Developer

2004-10-08 Thread Geoff Deering
 From: Andy Budd
 
 Not forgetting Style Master http://www.westciv.com/style_master/
 
 Andy Budd
 

Yeah, I was waiting for that one to come up.

Thanks
Geoff
**
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] Is XHTML harmful?

2004-10-07 Thread Geoff Deering
Chris Bentley wrote:
  Are there any parsers out there you explicitly trust to get it right
  every
  time?  I don't.
 I know of one, http://validator.w3.org/.  Are you say though that User
 Agents are generally better/fast at parsing/rendering valid XHTML than
 they are valid HTML?

No, that is not what I meant at all.  I'm talking about the parser and
rendering engine in user agents.  No, you are missing the point.  Maybe you
need to go back and study parser logic rendering markup a bit more.


  They may well do, but they are still guessing if there are
  no end tags.  I'm much more happy to explicitly declare my design than
  have
  parsers guessing at what I've designed, the performance trade off is
  not so
  great.
 
 I like to write valid markup too, and if your HTML is valid (written
 against the DTD) then the parser doesn't have to guess anything,  I
 don't see your point as to why valid XHTML is technically better than
 than valid HTML.

I am talking about CSS applied to HTML and the rendering of the CSS as
applied to the parsing of the document.  But still, strictly speaking, an
XML based document is bound to be more semantically correct because it is
well formed.  This means that the CSS can be applied without fear of the
parser misunderstanding where a declaration could have finished.  There is
no possibility of any guess work in xhtml as it is well formed.

This may or may not be an obvious problem.  But I would not be surprised to
see complex designs misrendered when transformed from xhtml to html4 with
all optional ending tags taken out.

What I am saying is that with XHTML the designers knows this won't happen,
given the correctness of the parser.


  Now go into the area of accessibility, how are you going to tell all
  sorts
  of user agents and devices the full semantic meaning of the markup.
  What
  about when aural.css becomes mature?  Will complex document in HTML4
  be as
  exact as those following XML syntax?
 
 Yes, if you write it against the DTD and follow accessibility
 guidelines. There is no difference between the semantics or the
 accessibility of HTML4.1 and XHTML1.0.

You may be right, but I don't agree.  It's only a small difference, but it
is there.

   In my view, you cannot fully mark up
  documents with a trusted explicit semantic fullness without and XML
  definition.  The border here might be small, but it's small enough for
  one
  definition to allow for best of interpretation and the other an
  explicit
  interpretation.

 Well-formedness has nothing to do with semantics.


You're missing the point.  Closing tags is being completely accurate with
punctuation, where markup is the punctuation.  Not closing tags CAN lead to
ambiguity.  In XHTML there is no syntax ambiguity, in HTML4 there are
possibilities.  It may not happen when validating against the doctype.  That
is not the problem.  The problem is the CSS container, it's boundaries are
often not certain.


 Except for the reasons give by Peter Ottrey the only technical reason
 for using XHTML is that you need the XML (this being the only technical
 difference between HTML4.1 and XHTML 1.0 ). Any other reason simply
 comes done to a matter of personal preference.


I don't agree with that.

-
Geoff

**
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] Is XHTML harmful?

2004-10-06 Thread Geoff Deering
I think there are valid arguments for both sides of this.

This is also where I agree with the approach of the Apache/Cocoon advocates
in that you serve up the solution which be suits the user agent.

As standards developers we are working in an imperfect world and it's what
frustrates us all.

What I feel actually saves the HTML argument, in this case, is that browsers
actually have very very intelligent parsers in them.  It takes a lot of work
to handle the thousands of cases that quirksmode can throw up.  Thankfully
that also works in our favour when we slip up on our own validation.

If you took all the quirksmode logic out of the parser in the browser and it
only did valid DTDs for HTML4 and XHTML, and spat the dummy like SGML and
XML parsers when it found invalid markup, and where all documents were
valid, I bet you that out of all the designs the XHTML would render more
accurately.  The reason being that if you are not closing all your tags it
can become a guessing game for the parser where the CSS declaration may end
in various parts of the document.

It always strikes me that when using HTML4 you are at the mercy of the
arbitoriness of the parser.  I know there doesn't seem to be any obvious
problems, but just the basics of parsing seem to leave you with the feeling
it is inherently there.

That to me is the main reason to use XHTML over HTML in this argument.

-
Geoff

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

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



  1   2   >