RE: [WSG] hr won't turn black

[michael.brockington]

I thought that this 'discussion' had been done and dusted a week or two
ago, but it seems not.

In some cases (though certainly not all)  an HR  _does_ have semantic
value, that is why its name is being changed to 'seperator' in HTML5,
apparently.
By the sounds of it, the poster is using  an HR as a seperator,
therefore it has more than just presentational value. As a comparison,
try removing all of your P tags, and see if the white space they give
you is purely presentational!

Regards,
Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mordechai Peller
> Sent: Tuesday, February 20, 2007 5:58 AM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] hr won't turn black
> 
> >   
> So granted, hr is /purely/ presentational, but if your 
> objective is to 
> show a separation between two sections, I can think of a 
> better element 
> to do that. In fact, I can think of six elements which can do 
> that and 
> all of them are much more semantically valuable then an hr, namely h1 
> through h6. Now you can hae the best of all worlds: text browsers get 
> text, screen readers get words, and graphical browsers can 
> get a textual 
> separator, a graphical separator, or both.
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Living With Legacy

[michael.brockington]

Lachlan,
You are only half answering my point - if you are correct about HTML5
support, then the question is whether the majority of browsers will
_also_ support XHTML2  If the answer is negative, then no matter how
much better it is, the choice will be between HTML4  and  HTML5, only.

Regards,
Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt
> Sent: Saturday, February 17, 2007 6:32 AM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Living With Legacy
> 
> [EMAIL PROTECTED] wrote:
> > I can't help feeling that a lot of people are missing the 
> point here. It
> > really isn't anything to do with us developers whether to 
> use XHTML2 or
> > HTML5 - that will be governed by which specifications are 
> supported by
> > IE and Safari in the future. It may be that they disagree, 
> and then we
> > will be stuck on HTML4 for ever and ever!
> 
> In theory, that's a possibility, but in reality, it's not.  Apple, 
> Mozilla and Opera have already decided that they will be supporting 
> HTML5 and have already begun implementing many of its features.  The 
> chances of IE deciding to support XHTML 2.0 instead are 
> extremely slim. 
>   In fact, there's more chance of IE refusing to implement 
> either, but 
> then pressure from web developers would eventually get to them and 
> they'd be forced to implement HTML5 anyway.
> 
> -- 
> Lachlan Hunt
> http://lachy.id.au/
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Site check andrewingram.net

[michael.brockington]

Lisa,
For a blind user, it is very annoying for a new window to open, breaking
the back button. If you want further evidence, there is plenty out
there, and pretty much all of it says "don't use new windows"
 
Mike




From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of lisa fox
Sent: Sunday, February 18, 2007 3:34 AM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Site check andrewingram.net


Tim,
Agreed.  However, from a user-friendly perspective, it is very
annoying to close a window and realise that you have lost where you
were.  This is where you make the decision on the purpose of the
website, whether it is purely to display that you can comply with strict
or whether it is for the user. 
 
Lisa
 


 
On 2/18/07, Tim <[EMAIL PROTECTED]> wrote: 

Lisa,

You can't open new windows and still have  a Strict
DOCTYPE as Andrew
has!

Personally I think pdf are annoying and would I prefer
to see the 
content in a webpage, maybe an option to download the
pdf.

Tim

On 18/02/2007, at 2:04 PM, lisa fox wrote:

> Hi Andrew
> You are better to open the pdf and Word document in a
new window.
> Most viewers would click on the link,the pdf/Word
opens in the same
> browser window. They would finish reading and out of
habit close the
> window forgetting that it is the same window. If the
documentsopen 
> in a new window the viewer can close the window and
remain on your
> site.
> 
> Lisa
> 
>
> 
> On 2/18/07, Andrew Ingram <[EMAIL PROTECTED] >
wrote: Hey all,
>>
>> It's been a long week, but i've got my basic site
template integrated
>> with Expression Engine (from scratch, in my wisdom I
decided it would
>> be 
>> a good idea to delete all the default templates and
build everything
>> from nothing :/)
>>
>> So I invite you all to check for accessibility,
semantics and all that
>> jazz.I welcome any suggestions provided that the
suggestion isn't to
>> switch to a liquid or elastic layout :)
>>
>> Basically, anything you can think of (especially
things that are an
>> easy 
>> fix) would be most welcome.
>>
>> http://www.andrewingram.net/
>>
>> Thanks,
>> Andrew Ingram
>>
>>
>>
***
>> List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
>> Unsubscribe:
http://webstandardsgroup.org/join/unsubscribe.cfm
>> Help: [EMAIL PROTECTED] 
>>
***
>>
>
>
>
***
> List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe:
http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
>
***
The Editor
Heretic Press
http://www.hereticpress.com
Email [EMAIL PROTECTED]




***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm 
Unsubscribe:
http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED] 

***






***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]

*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Living With Legacy

[michael.brockington]

I can't help feeling that a lot of people are missing the point here. It
really isn't anything to do with us developers whether to use XHTML2 or
HTML5 - that will be governed by which specifications are supported by
IE and Safari in the future. It may be that they disagree, and then we
will be stuck on HTML4 for ever and ever!

As with XHTML1.1 there is no point in producing stuff, no matter how
'well formed' if nothing can read it.

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ingram
> Sent: Friday, February 16, 2007 4:44 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Living With Legacy

>  There seems to be a lot of 
> argument about how 
> the two will be going head-to-head and only one will win, I 
> think this 
> is the wrong approach.  I think it'll be more like having a choice of 
> programming languages, there's a range of choices but you 
> pick the one 
> most suited to the job.  I agree with your assessment that 
> this applies 
> to current HTML/XHTML too.
> 
> What I normally do is develop in XHTML so that I benefit from 
> the much 
> stricter validation, then I switch to HTML at the end.  
> Probably a weird 
> approach but I agree with the opinion that XHTML should be 
> served with 
> the correct MIME type or not at all.
> 
> 
> - Andrew Ingram
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] option to open newwindow inside the link !!

[michael.brockington]

If you feel able to give them  a choice, then leave them with their
normal choice, as it clearly _isn't _ essential to your application.

Regards,
Mike 


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gaspar
> Sent: Thursday, February 08, 2007 4:11 PM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] option to open newwindow inside the link !!
> 
> Hello everyone,
> 
> I know open new windows should be avoid, but sometimes we need that to
> to prevent confusion.
> 
> Iam thinking in some way of warn and give the option in each link to
> the user chose or not to open in new window.
> 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] is html done? [was semantics]

[michael.brockington]

 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson



 
> > The physical structure of a page will often be entirely 
> > different to the
> > logical structure
> 
> This is true, of course, but at the end of the day both versions still
> have some meaning, depending on context.
> 

You must be drunk too, if you are agreeing with me! (Apparently.)

The example that I was trying to describe went more like:



 Para 1
 Start of Para 2 ...
  

 end of para 2
 foo
  
 


Appearing as:

Para 1  end of para2
Start of Para 2... foo



Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] is html done? [was semantics]

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson
> Sent: Thursday, February 08, 2007 1:00 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] is html done? [was semantics]
> 
> On 2/8/07, Geoff Pack <[EMAIL PROTECTED]> wrote:
> 
> > Lachlan Hunt wrote:
> > > Div doesn't have any semantics, it's a structural element only.
> 
> > And since when does structure not have meaning?
> 
> I don't have to read any dictionary or the spec to agree with you
> Geoff. Structure in and of itself IS semantic to an extent. Structure
> allows us to understand such concepts as beginning and ending,
> internal organization, and compartmentalization.
> 

I think you are taking that too far - imagine trying to create the look
of a newspaper on the web, with blocks of text that break off at
specific points to continue in the next column, where the blocks
themselves are more or less randomly distributed.  Does the end of one
DIV in that case tell you anything whatsoever about the content? Often
it isn't even the end of a word!

The physical structure of a page will often be entirely different to the
logical structure; in my opinion DIVs and SPANs should _only_ be used
for presentational purposes, and conversely the remaining HTML should
_only_ be used for content.

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] No. abbreviation glyph

[michael.brockington]

I'm afraid your test doesn't answer the question that (I think) you were trying 
to ask, which is whether Google et al are able to _index_ these characters 
correctly. Your test merely shows that Google ignores them in an input query, 
not in the index itself. Perhaps some use of the advanced search options would 
allow a better test?

A site search engine that I work with regularly does have difficulties with 
this, but mainly because it is hard to define the correct behaviour for all 
possible situations: should an accented character be stored as different to the 
same character without the accent? The answer is basically 'which will the user 
search for?'  In one case it is necessary to treat all accented characters as 
though they were the same base character, and in the other case they must be 
kept distinct.

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Baranovskiy
> Sent: Thursday, February 08, 2007 5:52 AM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] No. abbreviation glyph
> 
> >> > Actually in both cases you shouldn't use 'x', but × 
> or ×
> >> Good point. But will a screen reader find '×' and say  
> >> 'times', or for
> >> that matter Andrew's unicode alternatives?
> >
> > There's a key question. Anyone got a screen reader handy to test it?
> > Sadly I don't...
> 
> Add to this “Will search engines correctly understand such a  
> symbols?” The answer is “No”.
> 
> Compare:
> 
> 3×4   
> http://www.google.com.au/search?hl=en&q=3%D74&btnG=Search&meta=
> 3x4   
> http://www.google.com.au/search?hl=en&q=3x4&btnG=Search&meta=
> 3 4   
> http://www.google.com.au/search?hl=en&q=3+4&btnG=Search&meta=
> 
> As you can see first and last results are equal, which means that  
> Google ignore × symbol. Try this two links as well:
> 
> fl as ligaturehttp://www.google.com.au/search? 
> hl=en&q=flickr&btnG=Search&meta=
> fl as two letters http://www.google.com.au/search? 
> hl=en&q=flickr&btnG=Search&meta=
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] How to mark up my dvd list?

[michael.brockington]

Do you intend to have more than one data column/row (plus headings?) if
so, then it is clearly a table, but if only one, then a list of some
kind is more appropriate. I would suggest that in this case there is
nothing wrong with a table whichever direction you choose to lay it out.
Another 'trigger' question would be whether any one cell will need to
contain more than one paragraph of text, if so, then you are getting
into layout territory, and the associated accessibility problems of
tables will start to creep in.  
 
Mike




From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of morten fjellman
Sent: Wednesday, February 07, 2007 3:59 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] How to mark up my dvd list?


Thank you for the suggestion, I really appreciate it :)
I'm somewhat torn between the two (dl vs. table). I can see the
logic behind the dl, but I guess it's tabular data as well as a list.
Can someone tip the balance here? 

Kind regards
Morten






I'd definitely stick to the table. A table is still a
list of rows and 
columns, and would make the universal nature of the
attributes (name,
entry date, tagline) clearer and easier to input/manage.

If you decide you would rather have it displayed as you
just have, you
could always use CSS to make it appear that way (you
could even allow 
users to switch between views).

My suggestion in code:


  
   
Name
Entry date 
Tagline
Genre
Director
Starring
Language
Runtime
Summary
   
   
Cool Hand Luke
2007/2/6 
"What we've got here is failure
to communicate"
Drama
Stuart Rosenberg 
Paul Newman, George Kennedy,
J.D. Cannon, Lou
Antonio, Robert Drivas, Strother Martin, Jo Van Fleet,
Clifton James,
Morgan Woodward, Luke Askew, Marc Cavell, Richard
Davalos, Robert 
Donner, Warren Finnerty, , Dennis Hopper
English
126min
Luke is sent to a prison camp,
where he gets a 
reputation as a hard man. The head of the gang hates
him, and tries to
break him by beating him up. It doesn't work, and he
gains respect. His
mother dies, and he escapes, but is caught, escapes
again, and is caught 
again. Will the camp bosses ever break him ?
   
  


CSS for list presentation:

#DVDlisting td
{display:block}
tr.columnHeadings
{display:none} 
tr.filmEntry
{margin:2em 0 0 0}
tr.filmEntry td:before
{font-weight:bold;
  content:attr(class)}
td.Name:before
{content:""}
td.Name
{font-weight:bold;
  margin:0 0 1em 0}

That would make it appear pretty much as it does in your
email, but you 
can retain the ease and functionality of cross-reference
by reverting to
standard table-cell display.

I think a DL is a lot more ambiguous and messy for
something that is
clearly tabular data. Remember, it's only layout
purposes that make 
tables unpopular!





***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]

***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] semantics : was-[HR tag and Semantics]

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Martin Heiden
> Sent: Wednesday, February 07, 2007 2:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [WSG] semantics : was-[HR tag and Semantics]
> 
> Michael,
> 
> > No, no, no!  A DIV is semantically neutral, ie has no meaning
> > whatsoever. The addition of a class name does not change 
> that. So how
> > can a pair of DIV's have more meaning than a specific HTML element?
> 
> Yes a DIV is semantically neutral, but it has a structural meaning.
> And HR doesn't have a semantic meaning either, it's just visual with a
> structural implication.
> 

Would you care to back that up by explaining what 'structural meaning' a
DIV has?



> I prefer the DIV because it shows beginning and end of the structural
> group. HR doesn't do that, it just marks the end.

No, a DIV 'marks' the start and finish of an arbitrary block, in the
'markup' sense of the word 'mark'
By default, nothing about a DIV is visible, even in a visual browser. In
an aural or text-only browser a DIV might as well not exist.


> But one should consider that HR has an advantage: some text-browsers
> and screen readers will render it, the DIV is simply ignored if it
> isn't addressed by css.
> 

Agreed, only I think it is really 'all'  not just 'some'

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] semantics : was-[HR tag and Semantics]

[michael.brockington]

> > Even if you could answer that correctly, the above example 
> is completely
> > inaccessible, whereas a distinct element used correctly 
> cannot possible
> > be more accessible.
> 
> I beg your pardon? If paragraphs inside classed divs are 
> inaccessible, 
> we've got a bit of a global disaster on our hands.
> 
> 
My comment was in relation to the semantic meaning that the Author was
trying to atribute to the DIVs, not to the bum-basic Ps within:
The 'seperation' is completely inaccessible, as it is only represented
by CSS.

Though exactly how obvious a paragraph is outside of a purely visual
environment is a discussion in itself!

Regards,
Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] semantics : was-[HR tag and Semantics]

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of liorean
> Sent: Wednesday, February 07, 2007 12:47 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] semantics : was-[HR tag and Semantics]
> 



> > 
> >   
> >   
> >   
> > 
> > 
> >   
> > 
> >
> > .grouping + .grouping:before{content: "[separator]"}
> >
> > This is better than Rob's and your examples because it 
> doesn't assume
> > the separator is incidental to the presence of other objects, which
> > cause some kind of separation anyway.
> 
> In fact, that is exactly the use I think my example was indicating was
> a better idea - semantically. It's a bit more code, true. It's a bit
> more hassle, true. It's a lot more descriptive semantically.

No, no, no!  A DIV is semantically neutral, ie has no meaning
whatsoever. The addition of a class name does not change that. So how
can a pair of DIV's have more meaning than a specific HTML element?

Even if you could answer that correctly, the above example is completely
inaccessible, whereas a distinct element used correctly cannot possible
be more accessible.

Regards,
Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Form Widgets

[michael.brockington]

One of the reasons that Mac Users do so, is the relatively consistent
interface, resulting in greater ease of use than the random artistic?
efforts of developers on other platforms.
For reference, it is basically only Firefox that has the audacity to
break those guidelines - Safari, iCab and Camino all play nicely, hence
their greater acceptance by the Mac community.

As an aside, are you the kind of person who likes to style the scroll
bars in IE/Win?

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of TomGou
> Sent: Wednesday, February 07, 2007 5:23 AM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] Form Widgets
> 
> Greetings All,
> 
> Can someone explain why Mac browsers seem to have a more 
> restricted styling of form elements? For example (as I asked 
> in an earlier
> message) the Input with a type=submit, Safari uses the Aqua 
> interface styling and ignores Author based CSS styling. Why is this
> considered a good thing? What's the harm in allowing authors 
> to style input buttons, so they're not limited to one look?
> 
> I'm truly curious.
> 
> -TIA
> 
> 
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] HR tag and Semantics

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Rimantas Liubertas
> Sent: Tuesday, February 06, 2007 11:46 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] HR tag and Semantics
> 
> > > Ok, let's take . In
> > > visual media it will be horizontal rule, aural browser 
> will announce
> > > it as "image: horizontal rule". Is it any worse than just 
> "Horizontal
> > > rule"?
> >
> > First, move beyond screen reading technology - web 
> accessibility is way more
> > than web pages for the blind.
> 
> Believe or not, I am aware of it.
> 

Then why does everyone seem to be ignoring users of Lynx et al?
These will not display any CSS adornments, nor any clever images,
whether foreground or background.

Surpisingly enough, the HR element will be rendered, in some manner,
such that it is the only one of the methods described that will pass on
to the user the Authors intention.

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] HR tag and Semantics

[michael.brockington]

Tim,
As several other people have tried to explain, an HR is always used,  in
printed media, as a separator or divider of some sort.  It may be abused
for visual effect on the web, but in print it always has a semantic
meaning, even if it can be a little subtle and hard to define. Nobody
appear to be arguing that an HR should appear in every document, but
where it is used in the same manner as it is used in print, it cannot
adequately be simulated by CSS, and should not be either or the semantic
meaning would be lost to text-only browsers, etc.
 
I agree that words are important on the web, but they are not
everything, and should not be. I am sure you are aware of Google's
attempts to improve its image categorisation for example, and Video has
ever-increasing importance. Therefore your implication that nothing can
be added to bare words to create meaning is simply ridiculous.
 
Regards,
Mike
 





From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of Rob Kirton
Sent: Tuesday, February 06, 2007 3:32 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] HR tag and Semantics


Tim



On 06/02/07, Tim <[EMAIL PROTECTED]> wrote: 


It seems to me that what some people are really
concerned about is that
you cannot stuff keywords into a HR tag?


That is not the real concern from my perspective, it is simply a
fact that it adds nothing other than a visual effect that can be
achieved by other means in CSS.  Words are everything on the web,
without them we have no content and no meaning, and certainly things are
being debased by people who keyword stuff - one of Barney's original
points (display:none) . 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Compliant pop ups

[michael.brockington]

Forget detecting screen readers - it is not possible: some of them sit
entirely on top of a standard browser, without affecting it directly.
You would have more chance detecting if a user was colour-blind!

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Brad Pollard
> Sent: Tuesday, January 30, 2007 8:31 AM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Compliant pop ups
> 
> Still nutting this issue out. I found this a good read: 
> http://www.sitepoint.com/article/ajax-screenreaders-work
> 
> Tending to think though that one of the following approaches 
> is the best way 
> forward (until such time as we have the hooks necessary to 
> gain a readers 
> attention) :
> 
> 1) As Joseph suggested: detect for screen readers and attach 
> rel=lightbox[] 
> if not a screen reader, leaving content URL in href (for 
> screen readers). 
> But how to detect for screen readers, anyone?
> 2) Forget about displaying dynamic content and instead link 
> to another page 
> that displays the content ie large image, terms and 
> conditions. Maybe add an 
> extra 'Back' button into the page so that the user can easily 
> navigate back 
> to the referring page
> 
> But, forgetting about displaying dynamic content that's 
> tough, I don't 
> think I can do it! Anyone know how to target screen readers?
> 
> -- Brad
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Legitimate uses of and

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of russ - maxdesign
> Sent: Wednesday, January 17, 2007 1:10 PM
> To: Web Standards Group
> Subject: Re: [WSG] Legitimate uses of  and 
> 
> Might be worth looking at the work on the Microformats site for more
> detailed citation markup
> 
> 
> 
>  operties>
>  wn_of_Citation
> _Elements>
> 
> HTH
> Russ
> 


No, that doesn't really help - their candidate list of attributes is
ginormous! Doesn't look like they are very close to completion, so right
now it is a choice between inventing a micro-format and hoping that it
is compatible, or just doing it the easy (visual only) way. Since the
_only_ advantage of a micro-format comes from standardisation, going it
alone does not seem very useful.

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Legitimate uses of and

[michael.brockington]

 
> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke
> Sent: Wednesday, January 17, 2007 2:38 PM
> To: wsg@webstandardsgroup.org
> Subject: RE: [WSG] Legitimate uses of  and 


> > A suitable micro-format would be great, but the point is 
> that regardless
> > of what non-sighted users require, a visual user requires a visual
> > distinction.
> 
> Which can then be provided by styling the separate spans. 
> Unless under  
> "visual user" you also mean "visual user in a text-only or otherwise  
> CSS incapable browser", which again would bring us back to the core  
> problem of this argument.
> 
> P
> -- 



I quite agree - I was merely trying to refute the argument that  and
   _entirely_ replaced  and 

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Legitimate uses of and

[michael.brockington]

  is a single element.

A full bibliographic reference will typically contain a selection from:
Article name
Journal name
Authors name(s)
Editors  name(s)
Date of publication

and probably a few other things. As you can see, each item needs to be
kept distinct from each other, so a single container is not enough. A
suitable micro-format would be great, but the point is that regardless
of what non-sighted users require, a visual user requires a visual
distinction. Clearly each item is of fairly equal importance, so neither
 or  is appropriate, semantically speaking.

Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke
> Sent: Tuesday, January 16, 2007 8:35 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Legitimate uses of  and 
> 
> [EMAIL PROTECTED] wrote:
> > A very similar example would be bibliographic citations
> 
> What's wrong with  then?
> 
> P
> -- 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Legitimate uses of and

[michael.brockington]

A very similar example would be bibliographic citations, though I
believe there are as many variations in common use as it is possible to
have!

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ingram
> Sent: Tuesday, January 16, 2007 4:56 PM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] Legitimate uses of  and 
> 
> I know these tags are only supposed to be used for 
> presentational rather 
> than semantic emphasis, but i've been struggling to come up with 
> examples of when they would be used.
> 
> The only situation I can think of when there is an established visual 
> standard for certain things that don't really have a semantic 
> emphasis.
> 
> For example, when listing somebody's academic qualifications the 
> standard is to display the institution in italics but i'd say 
> that it's 
> not appropriate to use .
> 
> A. Ingram, MEng Warw
> 
> Does anyone know of any other legitimate uses of these tags?
> 
> - Andrew Ingram
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Using "cursor:default;" on the whole page but links

[michael.brockington]

First things first - what makes you think that Steve Krug designed the
cover of that book? My father has authored several books, and I can tell
you that he has a fairly low regard for the designers that produce his
covers, and routinely place items upside down etc.
 
To answer your query, I would suggest that buttons have a different
action to hyperlinks (most of the time) so your argument that they
should have the same curser does not seem valid to me.
 
Mike




From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of James Crooke
Sent: Wednesday, January 10, 2007 11:26 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Using "cursor:default;" on the whole page but
links


Here's one for you.
 
OK, we are all in agreement that its not a good idea to change
the default cursor.
 
But even Krug's "Don't Make Me Think" has a pointer (the finger
cursor) hovering over a button on the front cover of his book - yet in
IE and Firefox buttons have the cursor.
 
Personally I think that all buttons should have pointers, the
same as hyperlinks.  I always apply "cursor:pointer" to my buttons -
partly because my boss tells me too, but I also agree with him (and
Krug, it seems) that it helps usability. 
 
Who disagrees?

 
On 1/10/07, Anders Nawroth <[EMAIL PROTECTED]> wrote: 



Patrick H. Lauke skrev:
> Quoting Anders Nawroth <[EMAIL PROTECTED] >:
>
>> There are people who have problems to spot the cursor
when it's the
>> vertical bar. That would be a reason to use the
arrow.
>
> Some people have very specific problems, but will have
to learn how to 
> adapt their user agent, or themselves, to cope with
them. Breaking
> default functionality in browsers to "aid" these users
is not a
> sustainable solution...and in an attempt to help these
people, you're 
> creating problems for an other section of users who
actually rely on the
> browser's default behaviour.

OK, I have now changed the "text marker" cursor on my
own system, much
easier to see it now :-) 

/anders



***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm 
Unsubscribe:
http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED] 

***






-- 
James 

***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]

***



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Visited Links and Accessibility

[michael.brockington]

I read quite an interesting conversation on a similar topic recently
(was it here? I'm not sure.)
One of the main things that came out was that in some circumstances a
visited link should be downplayed - no need to go there again, whereas
in other cases they should be played-up - to emphasise regularly used
links. The difference between the two will tend to vary according to the
nature of the site, but also by the nature of the user.

What this all means, is that you do need to be careful that link schemes
are not too radical, regardless of the context. A little used method is
to attach suitable icons, though suitable images are hard to think of,
and tend to run counter to what you were asking for initially!

Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ingram
> Sent: Wednesday, January 10, 2007 2:26 PM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] Visited Links and Accessibility
> 
> I'm not entirely sure if this query falls under the scope of 
> this group, 
> apologies for that.
> 
> One of the points in accessibility checks is that information 
> conveyed 
> using colour is also conveyed without.  The most common way of doing 
> visited links is to have them be a slightly different colour. 
>  It's my 
> opinion that in a purely visual sense (because I don't know 
> how screen 
> readers announce visited links) this approach is inaccessible.
> 
> What are your accessible methods of styling visited links? 
> I'd imagine 
> there'll be some votes for bold/normal, underline/normal.  Is total 
> inversion of background and foreground colour accessible?  
> You can use 
> fancy checkbox images (but obviously requires images which raises 
> another issue) you can use :before or :after and content to add a 
> unicode tick to any visited links (requires that your browser 
> supports 
> the pseudo-classes).  Some people might not even bother 
> styling visited 
> links.
> 
> There's a more to this than i'd previously thought and it'd 
> be great to 
> get some opinions.
> 
> - Andrew Ingram
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] accessible form labels across a group of fields?

[michael.brockington]

You do need to consider your audience though - most of the world puts
the day of the month before the month itself, the format you showed
would be confusing to many. This is one area where a date-picker is much
more useful, as it does not require the user to understand the date
format that you want to use. 

Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Emma Sax
> Sent: Tuesday, December 12, 2006 10:24 AM
> To: wsg@webstandardsgroup.org
> Subject: RE: [WSG] accessible form labels across a group of fields?
> 
> 
> It has been found that javascript widgets are extremely difficult, if
> not impossible, for a screen-reader user to use.  Although 
> they will be
> able to hear that a new event has been triggered, they may not be able
> to locate or access the new content.
> 
> I would say, for finite controls (i.e. months/days of week 
> etc) that it
> is best to use drop-down menus.  The "perfect" solution would be to
> cater for all users and to use a combination of drop-down and 
> javascript
> widget.
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Background image rendering

[michael.brockington]

Just a thought - is the content overflowing the body - you have the body
defined as 100% so wide text should not stretch that box?
 
Mike




From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Livingston
Sent: Tuesday, November 21, 2006 7:44 PM
To: wsg@webstandardsgroup.org
Subject: [WSG] Background image rendering


Hello all,

I am noticing an issue in all browsers that I am testing in that
a background image on the body doesn't render correctly after scaling up
the font size to the point of getting a horizontal scroll bar and then
scrolling horizontally. The background image is not rendered off screen
- revealing itself upon horizontal scrolling. It ends at the edge of the
viewport. The rest of the content is rendered off screen and shows
itself as expected.

Any thoughts? Follow what I am talking about?

My CSS is:

html, body{ position:relative; font:100%/1.2 Verdana, Arial,
Helvetica, sans-serif; background-color:#fff; color:#888; width:100%;
height:100%; padding:0; margin:0;}
body#home, body#company, body#clients{
background:url("../images/home_bgimage.gif") 50% 0 no-repeat;}

TIA


-- 
Tom Livingston | Senior Multimedia Artist | Media Logic | 
ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com


***
List Guidelines:
http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]

*** 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] inside - bad practice?

[michael.brockington]

If you are placing this between two words within the H3 then I can see
little wrong technically - if it is at the end of the text of the H3
then you should make use of some kind of CSS margin.

There was a debate (here?) very recently about whether there was any
valid use for BR's within a P, and opinion was divided, but I don't
recall there being a clear winner. I would think the same applies to
headings - it might be better to constrain the width of the element so
that it breaks naturally?

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll
> Sent: Wednesday, November 22, 2006 10:01 AM
> To: wsg@webstandardsgroup.org
> Subject: [WSG]  inside  - bad practice?
> 
> I have a particular design where I want to put a  inside an h3 
> element - now I know that in theory brs are redundant when using 
> paragraph (or is it phrase?) elements, because they happen 
> between one 
> and the next.
> 
> Is it inherently wrong to do this though? I can't help 
> feeling like I'm 
> doing something very sneaky.
> 
> Regards,
> Barney
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Safari DOM inspector

[michael.brockington]

On the other hand, one of the major plusses for Camino is that it is
more tightly integrated with the OS than FireFox is, so it also uses the
OSX form elements au-naturale. (And pays attention to the proxy settings
in the OS, which is rather handy on my laptop.)  I think what you really
meant to say is that it treats the abuse of its own chrome with
disdain... many of us still believe that styling of Chrome is a Bad
Thing(tm)

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons
> Sent: Thursday, November 16, 2006 4:33 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Safari DOM inspector
> 
> On 16 Nov 2006, at 11:41:40, Barney Carroll wrote:
> 
> >
> > I do know that generally it [Safari] treats the styling of forms  
> > with disdain (plus I'm using javascript on them for display  
> > purposes, oo-er). Is there any other significant 'bug' I should  
> > know about?
> >
> 
> Long, long ago - well, within the last few years - there was a  
> general belief that styling of form controls was a Bad Thing from a  
> usability perspective, as it meant the user got an experience with  
> web form controls that wasn't consistent with the appearance of such  
> controls within their operating system. A number of cutting-edge and  
> utterly horrible examples of over-the-top styling of form 
> controls by  
> too-enthusiastic designers helped to reinforce the idea that it  
> shouldn't be done.
> 
> In particular, Safari has always enforced the idea that a checkbox  
> (for example) is going to look-and-feel exactly the same in a web  
> page as it does in any other part of the OS user interface.
> 
> Now that we've all grown up a bit, and (much more importantly) we  
> also know that (with appropriate usability considerations by  
> designers) users don't have a problem with pretty form controls, it  
> is generally accepted that it is an OK thing when done in 
> moderation.  
> Even Apple/the Safari team have accepted this, and the next version  
> of Safari will be much more permissive of widget styling, by  
> providing a mechanism to relax the enforcing of OS conventions  
> through the W3C standard method of providing vendor-specific CSS  
> extensions.
> 
> Dave Hyatt, who left Mozilla to become lead developer (or 
> something -  
> don't know his actual title) on Safari, has blogged about it:
> 
> 
> Regards,
> 
> Nick.
> -- 
> Nick Fitzsimons
> http://www.nickfitz.co.uk/
> 
> 
> 
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Safari DOM inspector

[michael.brockington]

Barney,
Have a look at the second link on the left hand side of that site -
Surfin' Safari Blog - lots of references to Apple in there. Not 100%
sure of the exact relationship between WebKit and Safari releases, but
I'm sure you can find out if you look (I could have sworn it was in the
'About Safari' screen, but I don't see it know on my machine!

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Safari DOM inspector

[michael.brockington]

Barney, 
I am confused by this - did you download WebKit, or some other utility?
If it was just WebKit, then at least you know that the bug will be gone
from a future version of Safari !

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll
> Sent: Thursday, November 16, 2006 10:49 AM
> To: Barney Carroll
> Subject: [WSG] Safari DOM inspector
> 
> 
> Today I found this fantastic utility [http://webkit.org/]. 


> Can anybody suggest a useful alternative?


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Replacing target attribute in form

[michael.brockington]

What is the point of leaving out the 'target' attribute if you are then
going to put it in via JavaScript? If it shouldn't be there then don't
use it - sneaking it in via a script seems rather pointless to me.

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andy Woznica


> Essentially it's a  script to open all external links in a 
> new window with a
> slight modification to recognise a substring in a form tag 
> and do likewise.
> Anyway, here's the JavaScript:
> 
> // JavaScript Document
> function externalLinks() {
>  if (!document.getElementsByTagName) return;
>  var anchors = document.getElementsByTagName("a");
>  for (var i=0; ivar anchor = anchors[i];
>if (anchor.getAttribute("href") &&
>anchor.getAttribute("rel") == "external")
>  anchor.target = "_blank";
>  } 
> 
> var forms = document.getElementsByTagName("form");
> for(var i = 0; i < forms.length; i++)
>  { 
>var form = forms[i];
>if(form.getAttribute("id").substring(0, 6) == "paypal")
>{ 
>   form.target = "_blank";
>} 
>  } 
> } 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Using JS to expand Abbreviations

[michael.brockington]

I think it is a little early to be claiming consensus on this!

Correct me if I am wrong, but without this fix, most users will never
see the full form of the abbreviation. That seems like a little more
than just styling to me.

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll
> 
> Without the measures being discussed, the consensus is that it is all 
> styling. How the abbreviation element is styled will, short of 
> javascript, dictate how the abbreviation's full form will be 
> made available.
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Using JS to expand Abbreviations

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kepler Gelotte
> Sent: Wednesday, November 08, 2006 2:38 PM
> Subject: RE: [WSG] Using JS to expand Abbreviations
> 
> 
> I tend to disagree. I think trying to manipulate your HTML output by
> buffering it and processing it on the server side is 
> overkill. 
It does depend on what server-side stuff you have available - I'm not
saying this is a bad idea, just that it is probably better done on the
server.

> JavaScript
> works nicely here because the HTML is going to be parsed and 
> loaded into the
> DOM client side anyway. 
Not for everyone - I do a lot of work in JavaScript, but it is
unavailable on 5 - 10% of clients.

> I also think what Thierry is 
> proposing is a simple
> solution 
Agreed

> which will degrade nicely if JavaScript is 
> unavailable or turned
> off. 
No it won't degrade, it will stop working.
This is more of a fix for broken presentation than an enhancement - an
abreviation should always be presented in full the first time that it is
usen in print, (with the abrev. following in brackets). I don't see any
reason why this is different on the web, though I admit it is not common
practice.

> You could fall back to the CSS styling of your 
> abbreviations in that
> case.
This is not about styling.

> 
> I also think this technique may also have value in the presentation of
> microformats as in vCard. You could put a little business 
> card icon next to
> names which could show the contact information on a hover over.
Agreed, but that is a whole other idea, which I believe has already been
covered, and which is purely presentational.


> This is really not a print issue, since Thierry is dealing 
> with an attribute
> in a tag () it wouldn't show up on a print out. 
I haven't tried this technique yet, but someone has already stated that
since this manipulates the DOM it _will_ appear in print - the whole
point is that it would not have appeared without this script!

> A 
> similar instance is
> where print outs don't show the URL (href attributes) to links.
Which has been adressed frquently in the past, in a number of ways, with
good reason.

Regards,
Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Using JS to expand Abbreviations

[michael.brockington]

 Thierry,
I don't know of an existing solution, but where static pages are
concerned, anything that can be done with JS can be done with PERL, PHP,
JSP or whatever. In this case, I am in two minds as to whether this
counts as 'progressive enhancement' or not. If it is, then JS is
acceptable (not necessarily best) solution. On the other hand, this
solution has already been discussed in the context of final print
output, and would seem beneficial to all users, regardless of
technology, which makes server-side manipulation much more effective.

Regards,
Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz
> to it from my
> article.
> IMHO, it's not a "server-side vs. client-side" thing, but a 
> simple matter of
> what's available to authors.
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Using JS to expand Abbreviations

[michael.brockington]

Is there a good reason for doing this with JavaScript rather than doing
it server side?

Regards,
Mike 

> -Original Message-
> Subject: [WSG] Using JS to expand Abbreviations
> 
> Demo:
> http://www.tjkdesign.com/articles/TJK_abbr_demo.asp
> Article:
> http://www.tjkdesign.com/articles/how_to_expand_abbreviations.asp
> 
> I'd appreciate any comment that would help me improve this solution.
> 
> ---
> Regards,
> Thierry | www.TJKDesign.com


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Additional space between sentences ?

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Designer

> Agreed, naturally.  But can you point to an actual example of 
> how to do 
> this?  Apart from the (complex) problems of avoiding Mr. Mrs. etc, I 
> often use PHP and this is riddled with 'periods' where I don't want 
> spaces.  

And you normally serve up raw PHP to parsed by client-side JavaScript?

While I agree that style information should primarily be held in CSS, if
it is to be kept out of the HTML then the next best option is in
JavaScript. The suggestion here is to use 'progressive enhancement'
which has been welcomed every other time it has been suggested on this
list.

Again though; double-spacing is wrong. Don't do it.

Mike



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Accessibility Trustmark

[michael.brockington]

This looks little better to me than an advertising piece 
for another (poor quality?) commercial service. I have no experience of this 
company, but SiteMorse are probably the leaders in this field, and have courted 
plenty of controversy along the way. 
Any testing is better than no testing, but badges appear to 
have as many negatives as positives. The latter point has also been extensively 
covered in relation to the W3C accessibility icons.
 
Finally, the value of a paragraph stating why the site is 
accessible is negligible - if it is true then who cares, and if false then of no 
use.
 
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Emma 
  SaxSent: Tuesday, October 31, 2006 10:21 AMTo: 
  wsg@webstandardsgroup.orgSubject: [WSG] Accessibility 
  Trustmark
  
  
  What are the Groups thoughts on 
  ‘trustmarks’?  
   
  http://www.e-consultancy.com/news-blog/361985/accessibility--are-trustmarks-the-answer.html
   
  Are they a waste of money or are 
  they really better than in-house testing and a paragraph on how the site is 
  accessible?
   
  Thanks
   
  Emma

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: [WSG] Flash is more accessible than CSS?

[michael.brockington]

Where do we send this?

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Rob 
  KirtonSent: Monday, October 30, 2006 2:15 PMTo: 
  wsg@webstandardsgroup.orgSubject: Re: [WSG] Flash is more 
  accessible than CSS?
  
  FAO Katie LedgerI (undoubtedly along with others) found your 
  article "designing a more accessible web" to be of great interest.  My 
  particular interest lies in the field of accessibility and standards, and I 
  feel compelled to contact you with respect to material inaccuracies in your 
  report that may have given the wrong impression.  An ideal situation 
  would be for you to maybe publish another article that is more factually 
  accurate, further clarifying the situation.  
   

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: [WSG] Accessible Multi-Column List

[michael.brockington]

Have you considered styling your s so that they sit side-by-side
within the list? Then you would have one single list, with list items
taking up 49% of the width of the list, giving the appearance of two
columns on screen, but only one physical list for accessibility.

I am sure there are many different ways of doing this, but the most
obvious starting point would be to style the s as 'display:inline'
and take it from there.

Regards,
Mike 


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Novitski
> Sent: Thursday, October 26, 2006 10:35 AM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Accessible Multi-Column List
> 
> At 10/26/2006 01:44 AM, Sarah Peeke (XERT) wrote:
> >Basically I need to show a list of links in two columns, alphabetical
> >vertically (one column will not suffice as the list is too long).
> >


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Access key does not work in Firefox browser?

[michael.brockington]

I think that you may want to read articles 
like:
http://www.wats.ca/show.php?contentid=32
before you decide that access keys are useful - from memory 
there are only three keys that do not clash with something else. In my opinion 
the basic idea is flawed anyway - they are an attempt to fix a variety of 
browser issues via a single HTML construct, which is not a good idea. It is our 
job to 'aid' user agents by providing clean, valid, semantic code; not to 
fix every conceivable problem that they have caused or failed to 
address.
 
Regards,
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Mihael 
  ZadravecSent: Tuesday, October 24, 2006 5:00 PMTo: 
  wsg@webstandardsgroup.orgSubject: Re: [WSG] Access key does not 
  work in Firefox browser?
  I realize that it is not a nice thing to use accesskeys that are 
  used by browser software.. that is why I used accesskeys like "1", "2", "3"... 
  I belive that is still usefull...
  On 10/24/06, Horst 
  Gutmann <[EMAIL PROTECTED]> wrote:
  -BEGIN 
PGP SIGNED MESSAGE-Hash: SHA1Mihael Zadravec 
schrieb:> http://www.nsk-slo.si/>> 
--->> On 10/24/06, 
* Frances Berriman* <[EMAIL PROTECTED]> 
[EMAIL PROTECTED]>> 
wrote:>> URL of site? 
>> On 10/24/06, *Mihael Zadravec* < 
[EMAIL PROTECTED]> 
[EMAIL PROTECTED] 
>> 
wrote:>> Is it 
possible that in Firefox 2.0 Accesskey does not 
work???>> In 
IE 7 works fine but with Firefox 2.0 it just does 
nothing...> Any ideas 
why? >Works for me in Mozilla/5.0 (Macintosh; U; PPC Mac OS X 
Mach-O; en-US;rv:1.8.1) Gecko/20061023 BonEcho/2.0. The numeric 
accesskeys, right?Regards, Horst-BEGIN PGP 
SIGNATURE-Version: GnuPG v1.4.5 
(Darwin)iD8DBQFFPhnBe3xiN2SrYecRAnxOAJ4kGHDkmrgQr9R/oNHrdbz/nZsHRgCeJtA2IjRGAr3qZNgcPJPUuhHfjDc==mSHG-END 
PGP 
SIGNATURE-*** 
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: 
http://webstandardsgroup.org/join/unsubscribe.cfm 
Help: [EMAIL PROTECTED]***-- Mihael Zadravectel: 00386 51 808136email in msn: 
  mihael.zadravec na gmail.comSkype kontakt: 
  mihael_zadravec---Toasted 
  Web http://www.toastedweb.com---Miss 
  G. / bloghttp://missg.toastedweb.com 
  ***List 
  Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: 
  http://webstandardsgroup.org/join/unsubscribe.cfmHelp: 
  [EMAIL PROTECTED]***

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: [WSG] Getting the layout to work and with all browsers

[michael.brockington]

Very few large businesses have finished rolling out XP 
yet!
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Navjot 
  PaweraSent: Friday, October 13, 2006 6:45 AMTo: 
  wsg@webstandardsgroup.orgSubject: Re: [WSG] Getting the layout to 
  work and with all browsers
  "working towards blocking the automatic update" - does this also 
  mean that such businesses won't be upgrading to "vista" 


***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: [WSG] Getting the layout to work and with all browsers

[michael.brockington]

I can't find the reference now, but I saw a report recently by someone
of the likes of Gartner, that reckoned it would take a year or so before
IE7 overtook IE6. All the same, no other browser release will have such
an immediate impact.

Mike 

> -Original Message-
> Kevin Murphy wrote:
> > I'm still seeing only a very small percentage of users with 
> > IE 7, but 


> as long as i run win2k, i'm still with ie6.  ie7 won't run on w2k - 
> that's what ms says.
> dwain


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] swift - only windows browser with a webkit?

[michael.brockington]

That would appear to be a completely different beast, despite the
similarity of name.  

When I tried the Safari-based Swift a month or so ago, I was able to
install it okay, but there seemed to be no way to configure a proxy,
which made it completely useless.

Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Felix Miata

 
> I was able to download from http://getswiftfox.com/
>  , but not get it installed, and found the help forum of no 
> value in trying.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] In the 'Wow, if only everyone did this" category...

[michael.brockington]

Actually, the reason that you can't see the text in any other browser is
due to the use of a drop shadow - something else that only Safari and
its siblings renders.

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of John Faulds
> Sent: Tuesday, October 10, 2006 1:01 AM


 The reason you can't 
> see anything  
> is because the text is set to white - with a bg-image, you'd 
> be able to  
> see it.
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] In the 'Wow, if only everyone did this" category...

[michael.brockington]

Title: In the 'Wow, if only everyone did this" category...



Sorry, too busy to reply - got to figure out how to work 
this into one of my designs...

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
  LivingstonSent: Monday, October 09, 2006 4:52 PMTo: 
  wsg@webstandardsgroup.orgSubject: [WSG] In the 'Wow, if only 
  everyone did this" category...
  View this in WebKit 
  browsers only. (Hence the subject of this post):http://decaffeinated.org/archives/projects/multibg/background-image.html-- 
  Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 
  518.456.3015x231 | fx: 518.456.4279 | 
  mlinc.com***List 
  Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: 
  http://webstandardsgroup.org/join/unsubscribe.cfmHelp: 
  [EMAIL PROTECTED]*** 


***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: [WSG] looking for site-ot

[michael.brockington]

As far as I can see, DL's are not deprecated, but they probably should
be, as the vast majority of use cases are semantically incorrect. The
one you describe included; surely a vCard or other microformat is more
appropriate - the _definition_  of a particular company is a difficult
concept to define, but I'm fairly sure its not their contact details!

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Kevin McMonagle
> Sent: Wednesday, October 04, 2006 4:58 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] looking for site-ot
> 
>  
>  
> it  joshuaink.com that i was looking for.
> 
> BTW I thought that his current emotional blog post about 
> web2.0 and a profitable business model  would strike a chord 
> with a project manager i know.
> 
> Also a question raised by his post - Are dl's deprecated?  
> they work well for displaying business listings from a 
> database and seem semantic to me.
> 
> Thanks all,
> -Best
> Kevin
> 
> 
> 
> 
> 
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: [EMAIL PROTECTED]
> ***
> 
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] obj.style.backgroundImage

[michael.brockington]

Since no-one else has replied, perhaps I may ask why you would want to
do this?

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz
> Sent: Wednesday, October 04, 2006 2:05 AM


> I'm curious to know if anyone here have successfully applied 
> a background
> image to an IMG element through scripting?
> I can apply a background color but I can't make 
> "style.backgroundImage"
> work.
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Accessability Reading Of WebPages Need Help

[michael.brockington]

It is also good etiquette to make sure that you understand what the
author meant, before you attack them, however nicely.  In this case, I
believe the intention was to point out a mis-written (bad) link, not as
you assumed a (properly written) link to an unsuitable site.  While the
reason for the bad link was not explicitly stated, the alternative,
correct link was.

Regards,
Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Christian Heilmann
> Sent: Thursday, September 28, 2006 6:44 PM


> Sorry if that sounded like chastising Christian, it wasn't meant to.
> Just a good mailing list etiquette reminder: If you attack something,
> provide proof why and give an alternative.
> 
> -- 
> Chris Heilmann


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Validates only EN?

[michael.brockington]

I don't think that there is anything wrong in what you are suggesting here. 
Apart from the fact that no normal browser is going to do anything with your 
modified DTD. Some browsers will behave differently depending on what DTD you 
specify, but I do not know of any that actually bother to retrieve (still less, 
understand) any DTD.  

I note that you did mention an SGML parser in your message - was that relevant? 
(IE, Firefox, Safari  are not SGML parsers.)

Regards,
Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Niels Fröhling


>  1) I'm going to write my only new complete DTD
>  2) I'm going to write (better: declare) it to be written in spanish
>  3) I'm copying the XHTML1.0 Strict DTD into my suppose to be spanish
> new written DTD
>  4) I'm serving my DTD as:
> 
> PUBLIC "-//W3C//DTD XHTML 1.0 Strict//ES"
>   "http://www.spania.com/docutipo.dtd";>
> 
>  5) I could rename all tag-names to spanish
> 
>  Please name me a reason why that is invalid! (and again besides the
> sense, I know it's stupid and missleading, ... to declare english as
> being spanish).


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] The Perfect Site WAS Site Review - intrep

[michael.brockington]

 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Katrina
> Sent: Saturday, September 16, 2006 4:51 AM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] The Perfect Site WAS Site Review - intrep
> 


> I'm beginning to think that making websites is like a 
> logarithmic curve, 
> the biggest changes towards the ideal[2] are made in the beginning of 
> the turn to web standards, and as time goes on, you do get closer and 
> closer to the ideal, but never reach it. (My father refers to this as 
> the Law of Reduced Returns).

More commonly known as the 'Law of Diminishing Returns'


> So at what point is it smart to give up the effort on creating the 
> 'perfect site'? At what point is the ROI not covering initial 
> investment? How do we make that decision?

This is a matter of priorities - if you have nothing else to do, then
that tiny tweak is worth doing; if your boss wants a complete e-commerce
system built by lunchtime then nothing short of a complete system outage
is likely to get your attention. Nobody else's opinion matters if you
are a professional.


> 
> Could there ever be an occasion where there is a greater ROI on using 
> deprecated or non-standard elements? And if there is, how do we 
> recognise it?

Absoltutely.  I disagree 100% with the WCAG ruling that you must not use
deprecated elements. You should not _rely_ on them, but I see no problem
at all in using them in a belt-and-braces approach to back up features
that are not supported on older browsers. For example, I still tend to
use   border=0   on images within a link - in addition to controlling it
with CSS. If anyone shows me a situation where this causes a problem for
a major browser I will stop, but at the moment I cannot see any harm,
only benefit.  And more benefit than certain other WCAG rules provide!

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Replacing part of a quote with an ellipsis

[michael.brockington]

Then in that case I think you can do it with pure CSS: what you need to
do is ensure that you have a construct similar to:
...Literal
Text

Then you just need:

.ellipsis { display:none; }
 on one page
 
and
.literalText { display:none;}
on the other

Adjusted as appropriate of course...

Mike



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Replacing part of a quote with an ellipsis

[michael.brockington]

Why do you have to use pure CSS? I would assume that you are trying to
do some sort of reveal later - a job that would probably be much better
handled by JavaScript.

Mike 

> -Original Message-


> I'm trying to work with the following:
> 
> One plus two plus three plus four plus five 
> makes fifteen.
> 


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] XHTML Marquee

[michael.brockington]

Richard,
I would say my vision was basically perfect - no need for 
glasses even, but that was sore on the eyes! 
Perhaps you could make the text a little larger, and 
possibly reduce the contrast slightly?
 
Mike

***List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfmUnsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfmHelp: [EMAIL PROTECTED]***

RE: class names and IDs (was Re: [WSG] p:first-line)

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons
> Sent: Wednesday, September 06, 2006 9:13 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: class names and IDs (was Re: [WSG] p:first-line)
> 
> 
> > for example:
> >
> > 
> >
> > .noPrint   has only one simple rule, which I know will never change.



> Surely the question of whether .navBar will print or not has nothing  
> to do with the content, and has no place in the markup?  
> Assuming .noPrint means "Don't output on a printer", a print  
> stylesheet containing
> 
> .navBar {
>   display: none;
> }
> 
> will make explicit what you are doing, and means you don't have to  
> put information about how the document is presented _in certain  
> circumstances_ into the document itself. Otherwise you could finish  
> up with your document littered with classes for handling its  
> presentation on a wide variety of media (screen, handheld, aural,  
> projection, not-yet-invented), which is exactly the kind of creeping  
> presentationitis CSS was specifically designed to avoid.
> 


I fully agree with what you are saying, but only in some circumstances. 
Sometimes an entire site gets written, and then a designer styles the
finished site.
Sometimes a designer creates a template, and developers fill those
templates, and create new modified templates etc.

Sometimes sites are developed entirely by one person, in one go.
Sometimes sites require teams working at many levels - with HTML being
created by Designers, Java devs, and even by SQL devs who are working in
different cities.

I have been involved in all of the above, and therefore use different
styles at different times. At times, this conversation appears to have
assumed the one-shot/single developer  system to be the only one in
existance, and has not been very pragmatic.

The perfect example of this is the CSS Zen Garden, which not only
applies id's and classes to everything, but even throws in a few empty
divs for the sake of it as well. Sometimes this style is required in
commercial development too.

Mike



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: class names and IDs (was Re: [WSG] p:first-line)

[michael.brockington]

I often find myself using 'functional' class names for a handful of
specific tasks, but often these are used in parallel with semantic class
names, for example:



.noPrint   has only one simple rule, which I know will never change.
Similarly I occasionally use  .leftAlign & .rightAlign but again only
with very simple rules that won't change: visually styling is done by
other means.

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] font standards today

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Tony Crockford
> Sent: Friday, September 01, 2006 7:35 AM


> yes, but even they specify a font-family:
> 
> html, body, h2, h3, h4, div, p, ul, li, input {
> font-family: "Gill Sans", "Trebuchet MS", "Gill Sans MT", sans-serif;
> }
> 
> Why is that?
> because they didn't like the *look* of the defaults!!!
> 


Or was it because they have seen one of  the readability studies on the
web, and decided that Sans-serif was better on-screen than Serif?

Mike


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

RE: [WSG] Safari Rendering on Windows / MacPro

[michael.brockington]

I agree - about the only reason I ever fire up Safari (for testing) is
to check whether I have got a drop-shadow correct.

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dani 
> Nordin | 401.787.5178
> Sent: Wednesday, August 09, 2006 2:56 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Safari Rendering on Windows / MacPro
> 
> As a PC/Mac (primarily Mac) user, I've also found this to be 
> true. Safari
> has had a tendency to look fine no matter what I've thrown at 
> it; the one
> that tends to break is IE for Windows.
> 
> Cheers,
> 
> Dani


**
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] Custom Bullets

[michael.brockington]

Sounds like you may have a problem with either one of your other CSS
rules or with the HTML structure - do you have an example page online?

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Able Net Design
> Sent: Tuesday, August 08, 2006 7:40 AM
> To: wsg@webstandardsgroup.org
> Subject: [WSG] Custom Bullets
> 
> Hi,
> 
> For the first time I am using custom bullets image. Just to try 
> something different. Anyway FF displays it correctly but when 
> viewing it 
> in IE6 i can still see the default "disc" bullet then my 
> custom bullet.
>
> ul li {list-style-image: url(images/tick.png); margin-left: 20px;}
> 
> I have tried most of the examples on the web of setting a background 
> image for li but still no luck?
> 
> Thanks.
> 


**
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]

[michael.brockington]

What is this doing that is incorrect? Are you using the 
same tag more than once on a page and expecting a different random 
number?
 
Regards,
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  nishakSent: Tuesday, August 08, 2006 8:07 AMTo: 
  wsg@webstandardsgroup.orgSubject: [WSG] 
  
  
   
   
  Hi All,
   
  I want 
  to add the src of img tag dymanically, which I m building in my js file. 
  
  document.write("

Re: [WSG] Opera Bug? (Table-displayed, left-floated, min-width content)

[michael.brockington]

Of more interest to me is why you are trying to  float  an inline
element ( a )? 

Mike


**
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] Displaying page in different resolutions

[michael.brockington]

Peter,
Could you please explain this comment? I understood 
that ID's and classes were used for different purposes, and I find that the use 
of multiple class names within a particular element can make the CSS more 
manageable.
Mike

  
  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Peter 
  GoddardSent: Wednesday, July 26, 2006 3:46 PM
   
   
    Also, why have you 
  given your divs both id's AND classes? Is this semantically neccessary or is 
  it a functional thing. Try working with just one attribute where possible. it 
  keeps the code leaner, does not confuse readers with audio browsers and is 
  more to the spirit of Standards!#
   

**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] target=_blank

[michael.brockington]

Thierry,
To quote from the resource you linked to:
"Authors may wish to define additional link types not described in this
specification. If they do so, they should use a profile to cite the
conventions used to define the link types. Please see the profile
attribute of the HEAD element for more details."

Therefore the use of 'made-up'   rel values is perfectly legal.

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Thierry Koblentz

...  I'd agree with "rel" if "external" 
> was a link-type
> 
> [0] http://www.w3.org/TR/html4/types.html#type-links
> 


**
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] Rounded Corners

[michael.brockington]

Bob,
I know that you didn't intend any offence, and I appreciate that I did
not give the answer that the poster was hoping for, but do I need to
remind everyone of the title of this forum?
As long as we fail to implement existing standards such as
border-radius, IE can legitimately say there is no need for them to
support it.
Developing a hack (however elegant) is not _promoting_  web standards,
semantic mark-up, or accessibility.

Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Designer



> > If at all possible, stick with the standards - CSS3 includes a
> > declaration for rounded corners, which has been supported 
> by Mozilla for
> > a long time.
> >
> > Mike
> >  
> >
> >   
> -
> Good idea - then the majority of web users won't see them at all!
> 
>  :-) 
> 
> - 
> Best Regards,
> 
> Bob McClelland


**
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] Rounded Corners

[michael.brockington]

None of these solutions have much to do with semantics, and none of them
appear to be fool-proof.

If at all possible, stick with the standards - CSS3 includes a
declaration for rounded corners, which has been supported by Mozilla for
a long time.

Mike
 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Janos Hardi
> Sent: Saturday, July 22, 2006 1:06 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Rounded Corners
> 
> Hi,
> 
> This solution has nothin to do with common semantics - not 
> recommended.
> 
> Janos
> 
> On 7/22/06, Al Kendall <[EMAIL PROTECTED]> wrote:
> > try these   http://www.html.it/articoli/nifty/index.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] Hungarian notation for JavaScript and ActionScript?

[michael.brockington]

I think that JavaScript has more need of this notation than other languages, 
precisely because of the weak typing. However, those who try and use the same 
notation rules for say Java as for JavaScript are going to have trouble. I find 
objNAME   arrNAME   etc useful, and things like  txtNAME   and   slctNAME   
when dealing with the DOM
I do not generally use   intNAME   or  fltNAME  unless there is a very good 
reason.

Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Carl Reynolds
> Sent: Friday, July 21, 2006 5:28 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Hungarian notation for JavaScript and ActionScript?
> 
> Roberto Gorjão wrote:
> 
> > Hi!
> >
> > I would like to know how you feel about the use of the Hungarian 
> > notation in JavaScript. As this language does not 
> distinguish between 
> > variable's types, this seems to me a "good practice" as it 
> helps one 
> > to avoid errors and maintain code consistency. What's your 
> opinion? Do 
> > you use it?
> 
> I think Hungarian notation should be avoided in any language, but is 
> seems to me that it just becomes an extra annoyance with no 
> added value 
> in a typeless language like JavaScript.
> 
> 
> 
> --
> Carl.
> 
> 
> 
> 
> 
> **
> 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] Preparing accessibility policies/standards in readiness for WCAG2.0

[michael.brockington]

If no-one else is going to answer, then (at the risk of 
starting a war) I will: 
At this point in time I have no intention of even 
acknowledging the existence of WCAG 2
I don't understand the rationale behind the main changes, 
and don't think that anyone in WCAG understands how their guidelines are 
currently used. Some people will inevitably jump on this new 'standard' - once 
they have found their feet I will re-evaluate, but for now I see less that is 
wrong with version 1.0 than with version 2
 
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Scott 
  BryantSent: Wednesday, July 19, 2006 1:05 AMTo: 
  wsg@webstandardsgroup.orgSubject: [WSG] Preparing accessibility 
  policies/standards in readiness for WCAG2.0
  
  Hi all,
  I'm interested in the experiences of other 
  universities/organisations preparing internal accessibility policies or 
  standards in readiness for WCAG2.0.
  
  If you were to update your policies/standards, what 
  would be the major changes?
  
  What sense have you made out of the guidelines and 
  how would you interpret them for you developer base? What resources would you 
  provide?
  
  (I know all of this is a little premature given 
  WCAG2.0 is still in draft but if you were to start updating your existing 
  policies/standards, what would your priorities be?
  
  
  Scott

**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] Form check

[michael.brockington]

Please, please, please do NOT break this single entity into separate
pages - pagination is the job of the browser and the physical printer,
with some input from the user, and should not be messed about with by a
designer. And before anyone points out that this is an online-submission
form, ask yourself if you would submit a job application without keeping
a record of it? 
In addition, there is little that is more frustrating than having to
wait for each page to load (on a slow connection, or from a slow server)
to then only fill in two fields and move on. 

Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Christian Montoya

> 
> Please please please consider breaking this form into multiple pages.


**
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] Alphabetical Listing Buttons - What are you thiinking???

[michael.brockington]

I'm afraid the link below proves quite the opposite:  in IE6  there is
always a gap at the right hand side, even when the row has wrapped
around, which it does at random widths. Clearly a rounding error is
causing problems, which is exactly what most of us expected. 

Incidentally, I have yet to hear anyone state a reason why this
construct would be inaccessible to anyone - the simplicity of a
single-row table ensures that it can correctly be linearised by any
screen reader worth its salt, so (leaving semantics to once side for a
moment) what is the harm in terms of practicalities?

Mike

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Joe


> Gaspar already showed us that it is completely possible (and 
> easy) to do!  
> 
> http://artideias.com/lab/css/listAlfa.html
> 
> Jough


**
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] Access Keys and large sites

[michael.brockington]

I am not a lawyer, but my understanding is that an employer 
must make reasonable adjustments to accommodate specific problems affecting an 
existing or new employee. For an adjustment to be required at that point, one 
must assume that it is not necessary to fix problems that have no effect on an 
employee, or to stretch the point a little, to problems that have not been 
notified.
I am not advocating that web standards be ignored on an 
Intranet, but trying to clarify Patrick's earlier question. 

 
Mike

  
  
  From: listdad@webstandardsgroup.org 
  [mailto:[EMAIL PROTECTED] On Behalf Of Matthew 
  PennellSent: Monday, July 03, 2006 12:31 PMTo: 
  wsg@webstandardsgroup.orgSubject: Re: [WSG] Access Keys and large 
  sites
  On 7/3/06, [EMAIL PROTECTED] 
  <[EMAIL PROTECTED]> 
  wrote:
  
  Patrick,In 
the same way, accessibility in general is always less of an issue onan 
Intranet, as you only need to worry about actual problems with 
yoursite/UA combination, not all potential problems with all 
possiblecombinations.And presumably your 
  company's HR department know that they must avoid hiring anyone with a 
  disability, as they might have trouble using your intranet, yes? 
  **The 
  discussion list for http://webstandardsgroup.org/See 
  http://webstandardsgroup.org/mail/guidelines.cfmfor 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] email stripping out the css from tables?

[michael.brockington]

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Harris
> 
> Can I be the fly in the ointment here and say "don't!"? (That 
> is, don't 
> do HTML email)
> 

> 
> Email is SMTP or POP3  - (X)HTML is web.  The servers are 
> different, the 
>   protocols are different - everything is different.
> 

You spoil your argument entirely there by mixing your network layers:
HTML is NOT a protocol, it runs on top of HTTP, which is an equivalent
transport protocol to SMTP.

The default transmission on HTTP is plain text, just as it is for SMTP,
it is only the relative conformity of the user-agents that make HTML
safe to use on the web.

For more info on how to do it successfully, try Sitepoint:
http://www.sitepoint.com/search/search.php?ps=10&q=email+format

Regards,
Mike


**
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] Access Keys and large sites

[michael.brockington]

Patrick,
I'm sure you are aware that the problem with Access Keys is not the
principle, but the potential interference with user agents. With an
Intranet you normally have control over which user agents are in use,
and can therefore ensure that the actual Access Keys that are used do
not interfere. You may still not have a usable set of keys, but at least
things are predictable, and any unwanted effects can be handled
directly. 
In the same way, accessibility in general is always less of an issue on
an Intranet, as you only need to worry about actual problems with your
site/UA combination, not all potential problems with all possible
combinations.

Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Patrick H. Lauke
> Sent: Friday, June 30, 2006 10:54 PM
> To: wsg@webstandardsgroup.org
> Subject: Re: [WSG] Access Keys and large sites

> And why would an intranet warrant different treatment from 
> any other web 
> content?
> 
> P
> -- 
> Patrick H. Lauke


**
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] Access Keys and large sites

[michael.brockington]

Well if no-one else is going to say it, then I will have to:
Don't use Access Keys except on an Intranet site.

IF you do a quick Google search for 'Access Keys' and 'Bad'  you should find 
several articles which have researched the number of such keys that do not 
clash with a Browser, OS or AT function. If I remember correctly, there are two 
of them, and I'll give you a tenner myself if you can find either of them on 
your keyboard without looking!

Mike



Cole Kuryakin wrote:
> Hello All -
> 
> I'm pretty new to the whole accessibility thing but I'm trying.
> 
> The latest question mark that arose in my mind regards to access keys: since
> there's only 10 numeric keys (including "0") what does one do if you're
> building a site that exceeds 10 pages? The one I'm working on now looks like
> it's going to top-out at over 50 pages with some sections containing 2
> different "drill-down" levels

Food for thought:
http://www.wats.ca/show.php?contentid=32

BTW Firefox in Linux has assigned the numeric keys to the tabs. Pressing 
Alt + 1 takes you to your first tab. Pressing Alt + 2 takes you to the 
second, and so on. Just FYI.

Kat


**
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] Opera 9 and standards support

[michael.brockington]

I believe that Safari was the first browser to pass the acid test?
Mike 

> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andy


 
> Acid2 is a test page, written to help browser vendors ensure proper 
> support for Web and related standards in their products.
> 
>  http://webstandards.org/action/acid2
> 
> Opera is the only browser so far to pass this test ,  


**
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 statement

[michael.brockington]

Correct me if I am wrong, but 'Accessibility Statements' seem to be
trying to do two different things a lot of the time:
1.  Listing the standards and accreditations that have been attained.
2. Explaining to the user how to use their own browser

The first point is little more than a nod to the Lawyers in an attempt
to say 'We did our best'

The second is doomed to failure by the march of progress, and the fact
that those that write them generally only access the site with IE on a
PC.

Am I alone in thinking that deciding which version you are trying to
write, and sorting out the inherent issues is more important than
tweaking  a word here and there?

Mike


**
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 & Usability problems?

[michael.brockington]

> -Original Message-
> [mailto:[EMAIL PROTECTED] On Behalf Of Terrence Wood



> Underlined text should be reserved for links, and I think 
> this should  
> extend to the printed version of a web page.
> 

I disagree - printed output is completely non-interactive. Links should
display the full URL wherever possible, but there is no need to
underline them.
In print, the underline has been a method of providing emphasis for
hundreds of years, I don't think computers change that at all. This does
also mean that I agree that abbreviations have no need to be underlined,
unless they need emphasis for some other reason, but that is really a
judgement call on the page designer. Bold or italic text might serve a
better function anyway.

Mike


**
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] Accessible Forms - Columnar and Grid Does anyone have an example of some accessible forms

[michael.brockington]

I also realised last night that no-one had mentioned that one of the
major reasons that the mark-up for the 'grids' of form elements is that
they have been layed out with a table.  Two little hints there: 'table'
'layout' - need I say more?

Have a look at:
http://www.accessiblecontent.com/online/v2n1/index.php?view=forms2
for a more in-depth analysis of why this is a bad idea.

Mike


**
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] Accessible Forms - Columnar and Grid Does anyone have an example of some accessible forms

[michael.brockington]

Jon,
If you read that spec yourself you will see:
"To associate a label with another control implicitly, the control element must 
be within the contents of the LABEL element."

However that is the HTML4 spec of what is valid, not the WCAG spec for what is 
advisable (which I have quoted before) and shall paraphrase again:  "Use 
explicit labels with all input elements"  

The purpose of markup is NOT just to convey structure, it is also sometimes 
used to convey functionality, which as I said before is why forms are more 
difficult than plain content.
I agree that the semantic purpose of a label is as a description, but here the 
funtional purpose is more important, and that is (again quoting the HTML spec): 
 "When a LABEL element receives focus, it passes the focus on to its associated 
control."
In Internet explorer, clicking on an explicit label does this, but not for an 
implicit label. Can you explain why you think that you can ignore the behaviour 
of what is (unfortunatly) still the dominant browser, on which plenty of AT 
products rely?

Regards,
Mike



-Original Message-
From: listdad@webstandardsgroup.org on behalf of Jon Gunderson
Sent: Wed 14/06/2006 14:31
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Accessible Forms - Columnar and Grid Does anyone have an 
example of some accessible forms
 
Michael,
You may also want to check the W3C specifications on the use of the LABEL
element:
http://www.w3.org/TR/html4/interact/forms.html#edef-LABEL

There is no concept in the specification of implicit relationship between a
LABEL element being "next to" a form control.  You need to use the FOR
attribute or encapsulate to define the relationship between a LABEL and a
form control.

Jon



On 6/14/06, Jon Gunderson <[EMAIL PROTECTED]> wrote:
>
>
>
>  On 6/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] >
> wrote:
> >
> > Jon,
> > I think you mis-understand me, most of your form controls do have a
> > label, just not properly used.
> >
> > What you are calling 'encapsulation' does not work in IE, as another
> > member pointed out after me; the association with the form element is due
> > only to proximity, so is merely 'implicit'.
> > Some of the other labels use what you are referring to as 'label by
> > reference' which tells the browser 'explicitly' which form element the label
> > refers to, but for some reason not all of the labels have been done this
> > way.
>
>
>  I am not sure what you mean "does not work".  What does not work in IE?
>
> The purpose of markup is convey structure and IE is not the only browser
> in the world.  Screen readers use encapsulated labels.
>
> In the case of the checkbox grids for question 10,11,12, the labels have
> > been hidden, which prevents them being useful for anyone not using a sub-set
> > of AT browsers - a tiny percentage of users!
>
>
>  The hidden lables are again for compatibility with screen readers and for
> technologies that do not support stylesheets or tables (i.e. LYNX).
>
>
>
>


**
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] Display Inline Problem

[michael.brockington]

This looks to be working okay in IE6 on XP except for note number three, which 
is failing to overlay the text of the following paragraph, making it virtually 
unreadable.

(Screen shot attached)

Mike


-Original Message-
From: listdad@webstandardsgroup.org on behalf of Paula Petrik
Sent: Tue 13/06/2006 19:56
To: wsg@webstandardsgroup.org
Subject: [WSG] Display Inline Problem
 
I am having problem figuring out where I'm going wrong or if I'm  
going wrong. On the following page:

http://www.archiva.net/footnote/csspopup2.htm

with the following CSS:

http://www.archiva.net/footnote/csspopupscreen2.css

The CSS rollovers and inline display work exactly as I want in FF 1.5  
(Mac) in all paragraphs. On Safari 2.0.3, the first paragraph works  
as it should, but the rollovers in the third paragraph display at the  
default position--left top for no discernible reason! In Opera 8.5  
(Mac), the rollovers work pretty much as they should (acceptable)  
except for note 6 which seems to have a mind of its own. No idea  
about the Windows versions of same.

Can anyone explain what is happening in Safari? Is there a CSS fix  
that would solve the problems in Safari and Opera? Does the technique  
work in IE 6? (Incidentally, both XHTML and CSS validate.)

Thank you,
Paula
http://www.archiva.net







**
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] Accessible Forms - Columnar and Grid Does anyone have an example of some accessible forms

[michael.brockington]

Jon,
I think you mis-understand me, most of your form controls do have a label, just 
not properly used.

What you are calling 'encapsulation' does not work in IE, as another member 
pointed out after me; the association with the form element is due only to 
proximity, so is merely 'implicit'. 
Some of the other labels use what you are referring to as 'label by reference' 
which tells the browser 'explicitly' which form element the label refers to, 
but for some reason not all of the labels have been done this way.

In the case of the checkbox grids for question 10,11,12, the labels have been 
hidden, which prevents them being useful for anyone not using a sub-set of AT 
browsers - a tiny percentage of users!

Sorry if this all sounds negative, but now maybe you understand why very few 
accessible form examples are out there - because real world examples are much 
harder than they sound, and this is just a passive form - do anything dynamic 
with it and you are completely stuffed!

Regards,
Mike


-Original Message-
From: listdad@webstandardsgroup.org on behalf of Jon Gunderson
Sent: Tue 13/06/2006 17:57
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] Accessible Forms - Columnar and Grid Does anyone have an 
example of some accessible forms
 
Mike,
All of the form controls in this example 5 use either label encapsulation or
label by reference techniques.  Can you tell me exactly which form control
does not have a label?

http://www.cita.uiuc.edu/html-best-practices/nav/forms-example5.php

Jon



On 6/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Unfortunatly your first example breaches Web Content Accessibility
> Guidelines 12.4 !
> Many of the form elements, such as the Radio buttons and checkboxes are
> not keyboard accessible, as the  has not been explicitly associated
> with the element. Curious, as some of the other elements do have
> the  for="name"  label atribute that is required.
>
> Mike
>
>


**
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] Accessible Forms - Columnar and Grid Does anyone have an example of some accessible forms

[michael.brockington]

Unfortunatly your first example breaches Web Content Accessibility Guidelines 
12.4 !
Many of the form elements, such as the Radio buttons and checkboxes are not 
keyboard accessible, as the  has not been explicitly associated with the 
element. Curious, as some of the other elements do have the  for="name"  label 
atribute that is required.

Mike


-Original Message-
From: listdad@webstandardsgroup.org on behalf of Jon Gunderson
Sent: Tue 13/06/2006 14:59

Here is an example of form controls in columns:
http://html.cita.uiuc.edu/nav/forms-example5.php



**
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] UPDATE TO: Using PHP to hide email, script made, testing needed

[michael.brockington]

 I think the most recent stats quote a figure of only 75% or so - 1 in 4
are not going to be happy!

Mike


> -Original Message-
> From: listdad@webstandardsgroup.org 
> [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Street

  Lachlan's
> solution seems pretty effective for the 98% of us with JavaScript on.
> 
> -- 
> Joshua Street
> 
> http://joahua.com/blog/
> +61 (0) 425 808 469
> 
> 
> **
> 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] XHTML Strict

[michael.brockington]

Surely any conforming user agent should ignore any markup that it does
not understand, so is there really any need to stop using name, where it
is being used for 'belt and braces' compatibility?

Sure, we shouldn't be relying on it for anything, but is there any harm
in doubling up?

Mike
 

> -Original Message-



> > 
> > Actually, I believe you should use both (id *and* name).
> 
> Not in XHTML 1.1, where name doesn't exist. And it's 
> deprecated in XHTML 
> 1.0, so you shouldn't use it there either.
> 
> -- 


**
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] Print style sheets - still struggling!

[michael.brockington]

They do come into it if you print things any other way - many users
don't trust 'print links' for various reasons, and the appearance of the
full page is not exactly great if all frames are printed on one page -
scroll bars aren't very useful on paper!

Mike 

> -Original Message-



> P.S. Forgot to say : the frames aren't relevant to this, because 
> clicking the 'click here to print this page'  sends the page, 
> plus print 
> style, straight to the printer. The frames don't come into it!
> 


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

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