Re: [WSG] minimal use of modernizr?

[Benjamin Hawkes-Lewis]

On Sat, May 12, 2012 at 9:54 AM, coder  wrote:
>
>                pattern="^[A-Za-z0-9](([_\.\-]?[a-zA-Z0-9]+)*)@([A-Za-z0-9]+)(([\.\-]?[a-zA-Z0-9]+)*)\.([A-Za-z]{2,})$"
> required type="email">

Note that's not a safe regex to validate email addresses. It will
exclude legitimate addresses like john.doe+la...@gmail.com.

I suggest just keeping it simple and checking for ^.*@.*$.

See also discussion at:

http://www.regular-expressions.info/email.html

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Expected behaviour of links to external websites

[Benjamin Hawkes-Lewis]

On Thu, Dec 29, 2011 at 3:25 PM, Hassan Schroeder  wrote:
> On 12/28/11 8:08 AM, Benjamin Hawkes-Lewis wrote:

[snip]

>> Since they aren't navigating hypermedia, I'm not sure that's
>> comparable. But typically you have a fine degree of user control of
>> the opening of new windows in such programs. At the very least, it's
>> predictable.
>
>
> Sorry, that's just nonsense.
>
> Take a non-technical-consumer app like Skype. On my Mac, it opens a
> single window when launched.
>
> Some functions change the content of that window; two open new windows.
> Which two functions? Feel free to predict, I'll wait  :-)

Point taken, I'm giving desktop apps too much credit here.

FWIW Apple do provide guidance for how windows in OS X are supposed to work:

http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Windows/Windows.html#//apple_ref/doc/uid/2961-TPXREF21

Not sure Skype is following that guidance …

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Expected behaviour of links to external websites

[Benjamin Hawkes-Lewis]

On Wed, Dec 28, 2011 at 12:49 PM, coder  wrote:
> SO you mean that mr Dreamweaver programmer, or Mr outlook, etc etc . . .
> shouldn't do it either?

Since they aren't navigating hypermedia, I'm not sure that's
comparable. But typically you have a fine degree of user control of
the opening of new windows in such programs. At the very least, it's
predictable.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Expected behaviour of links to external websites

[Benjamin Hawkes-Lewis]

On Wed, Dec 28, 2011 at 9:39 AM, coder  wrote:
> What fascinates me (still) is that a PC (laptop, whatever) works by
> displaying many windows. Hell fire, the OS is called 'windows' . . . (unless
> you are a fruit fan). All the common programs employ 'several' windows to
> make their functionality easier to handle (just look at Dreamweaver or any
> other web design program of that ilk!) So, why do some folk think that's OK,
> but if you are using a browser it's awful?

Strawman.

Being able to open multiple browser windows is great!

Having Joe Random Site Author decide when that should happen is not.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Is it possible to style an attribute?

[Benjamin Hawkes-Lewis]

On Tue, Dec 20, 2011 at 4:38 AM, Grant Bailey
 wrote:
> Hello,
>
> I was wondering if anyone could clarify whether it is possible to style an
> attribute. I realise this sounds odd, so allow me to explain what I wish to
> do.
>
> In my web page there are a number of terms that need to be defined. I like
> the user to be able to hover over the term and get the definition that way.
> For example:
>
> teleportation

teleportation

teleportation

Any deviation from either plain view or simple hyperlinks is going to
introduce unnecessary barriers to consuming your content.

Still, we can think about ways to make your content harder to consume,
if you like. ;)

You could build on the hyperlinks approach by using JS to extract the
HTML in the #teleportation fragment and display it when the term is
hovered.

Alternatively, you could build on the plain view approach with
something more complicated such as:

teleportation, made
famous in the Star Trek TV series

   /* Distinguish the defined term so that users have some sort of hint
  it might be a control. At least this gives users of caret navigation
  a chance. */
   .term-defined dfn {
  border: 1px solid red;
  padding: 3px;
}

/* Hide offscreen left to be read by screen readers. */
.term-defined .definition {
  left: -9px;
  position: absolute;
}

/* Show the definition on keyboard focus or hover. */
.term-defined:focus .definition,
.term-defined:hover .definition {
  position: static;
}

Leaving aside the usability issues raised by your question and
focusing purely on the technicalities, you can extract and style
content in attributes using CSS generated content, e.g.:

dfn:hover:before { content: attr(title); }

However, you can't apply transform punctuation within the raw text
content into italics with CSS alone, for that you'd need JS too.

Hope that helps.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] media queries can't understand body tag

[Benjamin Hawkes-Lewis]

On Sun, Sep 18, 2011 at 4:34 PM, tee  wrote:
> Hmmm, media queries can't understand body tag; a id or class for the tag is 
> needed. Spec on W3C site doesn't indicate though as I see example like so:
>
> @media all { body { background:lime } }
>
> A browser bug?

Works for me in Chrome:

http://pastehtml.com/view/b7qe04of6.html

Do you have a testcase you can point to that fails in a named browser?

--
Benjamin Hawkes-Lewis


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

Re: [WSG] CSS variable navigational menu`

[Benjamin Hawkes-Lewis]

On Sun, Jan 9, 2011 at 2:09 PM, Goku San  wrote:
> I have the following navigational menu bar. The menu has multiple parent
> menu items.

[snip]

> What currently happens is when a user hovers over
> the Parent menu item, the child menu items appear below, horizontally, of
> course. And each time, the child menu items appear to the far left. So the
> problem is when we get to the 5th parent menu item, going across, hover over
> it, the child menu items appear below towards the far left. So it
> cosmetically looks wrong but also causes the user to further navigate their
> mouse to get to the child items. Anyway to position the child menu items to
> appear directly below the parents and not always to the far left?

Make the parents the containing blocks for the absolute positioning of
the children:

#nav .sub {
position: relative
}

http://reference.sitepoint.com/css/containingblock

I hope you'll ensure that users who are not using a mouse (e.g. people
with certain
motor disabilities) can still access the content linked in the child items,
whether via deeper links on hub pages reached via parent items or by ensuring
that child menus are focusable and visible on focus.

Food for thought:

http://www.w3.org/TR/WCAG20/#keyboard-operation

http://www.uie.com/articles/users_decide_first/

http://www.456bereastreet.com/archive/200705/accessible_expanding_and_collapsing_menu/

http://labs.benjaminhawkeslewis.com/rapid-access-hover-menu.html

--
Benjamin Hawkes-Lewis


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

Re: [WSG] how do I declare gradient and image in the background property?

[Benjamin Hawkes-Lewis]

On Fri, Dec 24, 2010 at 9:27 PM, tee  wrote:
>>>        background-image: -moz-linear-gradient(bottom, #57b0d7, #87C9EB);
>>>        background-image: -webkit-gradient(linear,left top,left 
>>> bottom,color-stop(0, #57b0d7),color-stop(1, #87C9EB));
>>
>> One of the above lines will be discarded as an error in Gecko and WebKit.
>
> Which one is that? Gradient effect shows up fine in both Safari and Chrome.
> Trying to find the clue from Validator is not possible as it treated 
> everything as error.
>
>>
>>>        background-image: url(../images/base_images/icon-ui.png) ;
>>
>> This line overwrites the previous value of "background-image" rather
>> than setting "background-image" to be multiple images.
>>
>> http://www.w3.org/TR/css3-background/#layering
>>
>> http://www.w3.org/TR/css3-background/#the-background-image
>>
>> describes the comma-seperated syntax you want.
>
> OK, so I see,  two images are possible in the background, but one for 
> gradient and one for image is not possible especially no browser has native 
> support for CSS3 gradient yet.

Doesn't follow.

moz-linear-gradient() and -webkit-gradient() are effectively alternate
ways to declare an image and could be used wherever url() would be
used in background-image.

See also:

http://dev.w3.org/csswg/css3-images/#gradients

"A gradient is an image that smoothly fades from one color to another."

My point was merely:

background-image: url(foo);
background-image: url(bar);

is equivalent to:

background-image: url(bar);

not

background-image: url(foo), url(bar);

--
Benjamin Hawkes-Lewis


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

Re: [WSG] how do I declare gradient and image in the background property?

[Benjamin Hawkes-Lewis]

On Fri, Dec 24, 2010 at 2:02 AM, tee  wrote:
> I want to add an icon : url(icon-ui.png) to the div but can't find a way to 
> get it working. CSS3 allows two background images so I have the below which 
> however disables the gradient in FF and webkit browsers.

[snip]

>        background-image: -moz-linear-gradient(bottom, #57b0d7, #87C9EB);
>        background-image: -webkit-gradient(linear,left top,left 
> bottom,color-stop(0, #57b0d7),color-stop(1, #87C9EB));

One of the above lines will be discarded as an error in Gecko and WebKit.

>        background-image: url(../images/base_images/icon-ui.png) ;

This line overwrites the previous value of "background-image" rather
than setting "background-image" to be multiple images.

http://www.w3.org/TR/css3-background/#layering

http://www.w3.org/TR/css3-background/#the-background-image

describes the comma-seperated syntax you want.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] disallow IE6 to load the main style sheet

[Benjamin Hawkes-Lewis]

On Sat, Dec 18, 2010 at 11:20 AM, tee  wrote:
> I am finally to begin to stop supporting IE6 starts from 2011 as the usage 
> has fallen below 5%. I don't want the IE6 users to see a broken page due to 
> no special treatment made for the browser, rather, I would like them to see 
> an un-styled page as if the style sheet has switch off.
>
> Can this be done?

Yes. For example, you could:

(1) Use conditional comments to exclude the IE6 (or earlier) engine:

http://reference.sitepoint.com/css/conditionalcomments

or (2) Use the HTTP User-Agent header to serve different markup to IE6.

http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx

User-Agent headers are sometimes spoofed.

On the other hand, they provide a more general mechanism that can be
used to exclude styles/script from other old user agents (e.g. old
Mozilla versions).

Note that when doing sniffing of this sort, it is better to
differentiate the experience for known-bad browsers and assume all
other browsers are fully capable, so that users of capable minority
browsers are not locked out or forced to spoof. In other words: use a
blacklist not a whitelist.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Order of Tags within (XHTML)

[Benjamin Hawkes-Lewis]

On Wed, Dec 15, 2010 at 11:03 AM, Foskett, Mike
 wrote:
> Referencing my own work seems pretty pointless but hey:
>
> http://www.websemantics.co.uk/resources/useful_css_snippets/

Not at all - thanks for the references. :)

> Headings:
>
>        IE refuses to copy or highlight content text

Right, in that case I have heard of this behavior for :

http://www.456bereastreet.com/archive/200608/base_elements_cause_text_selection_problems_in_ie/

"base" parsing in IE6 is very idiosyncratic:

http://weblogs.asp.net/justin_rogers/pages/423843.aspx

I think you'll find this problem doesn't apply to other self-closing
elements, such as "link".

>        Un-styled content flashing up in IE.
>
>
> After reading, perhaps I could of worded the post a little better.

I guess - isn't the second topic an argument for ending with a "link"
as much as not?

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Order of Tags within (XHTML)

[Benjamin Hawkes-Lewis]

On Wed, Dec 15, 2010 at 9:53 AM, Foskett, Mike
 wrote:
> 8. The head section must not finish with a self closing element such as
> link. It may cause copy selection errors and  "Flash of un-styled content"
> issues

This is news to me. Does anyone have a citation or test case for this?

--
Benjamin Hawkes-Lewis


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

Re: [WSG] HTML5 - Marking up forms

[Benjamin Hawkes-Lewis]

On Wed, Nov 10, 2010 at 8:45 PM, Kevin Rapley  wrote:
> I would be interested to gather your thoughts around this solution, using
> progress tags to mark progress through the form.

A possible problem with this is that there is no guarantee that the
user has completed earlier fields before moving on to later fields.
I'd suggest adding a single "progress" element with JS, and tweaking
its value as the user actually completes the form.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] XHTML or HTML?

[Benjamin Hawkes-Lewis]

On Wed, Nov 10, 2010 at 10:34 PM, cat soul  wrote:
> Any thoughts on which we ought to be using,

To cut a _long_ story very short, if you have to ask this question, use HTML.

See also:

http://www.webdevout.net/articles/beware-of-xhtml

http://dig.csail.mit.edu/breadcrumbs/node/166

http://wiki.whatwg.org/wiki/HTML_vs._XHTML

> and what information ought to be
> up at top of an HTML page, along with , etc?

Typically, character encoding information (in case the user saves the
page for offline consumption), page title, links to related resources
(e.g. stylesheets for styling, feeds for feed autodiscovery), page
description (often excerpted in search results pages). Possibly Open
Graph Protocol metadata (http://opengraphprotocol.org/).

--
Benjamin Hawkes-Lewis


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

Re: [WSG] lazyweb://schema.agnostic.URLs

[Benjamin Hawkes-Lewis]

On Wed, Nov 10, 2010 at 3:07 AM, Micky Hulse  wrote:
> I wonder how many folks don't specify the http: part? It sounds like
> there are no drawbacks.

Not quite:

http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Getting my feet wet in HTML5

[Benjamin Hawkes-Lewis]

On 19 Aug 2010, at 11:08, Patrick H. Lauke wrote:
>> http://www.w3.org/TR/html5/content-models.html#annotations-for-assistive-technology-products-aria
> 
> However, with the new outline/sectioning algorithm, you can potentially go 
> well over the classic h1-h6 number of heading levels, while the ARIA 
> additional hints only allow mapping back to those six levels.

Really? Maybe I'm missing something - what's non-conforming about:

  
Foo
  

given that "[t]he value for 'aria-level' is an integer greater than or equal to 
1."

http://www.w3.org/WAI/PF/aria/complete#aria-level

(Those ARIA annotations are strictly unnecessary when UAs implement the "Strong 
native semantics and implied ARIA semantics" from that table.)

--
Benjamin Hawkes-Lewis

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

Re: [WSG] link rel="stylesheet" question

[Benjamin Hawkes-Lewis]

On 17 Jul 2010, at 17:42, Jody Tate wrote:
> In a stylesheet link, does the order of rel, href and type affect how a 
> browser understands, loads, etc. a stylesheet?

It doesn't.

HTML attributes "may appear in any order".

http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.2

> I usually see the rel attribute first, as in the example below, but does the 
> order of attributes matter or is the order convention, convention meaning, 
> "that's what most people do"?

Convention. I guess it puts the /purpose/ of the linked resource (namely, being 
a stylesheet) first.

--
Benjamin Hawkes-Lewis

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

Re: [WSG] Flash video without tag

[Benjamin Hawkes-Lewis]

On 10 Jul 2010, at 16:35, Lesley Lutomski wrote:
> I understood that the  tag is supported by all major modern browsers, 
> and the proprietary  tag is not required, unless one needs to support 
> very old browsers, which I don't.
> 
> I have a Flash slideshow which a client wants included on a site.  The 
> automatically-generated code includes the  tag and makes no provision 
> for a static image in the absence of Flash.  However, when I remove the 
>  section and add the static image, Firefox and Opera show the image, 
> not the Flash slideshow.  IE8, Safari and Chrome on Windows all display the 
> Flash, as do Epiphany and Konqueror on Linux. Galeon, which is Gecko-based, 
> displays the static image.
> 
> I can't believe Firefox doesn't support the  tag, so I assume I've 
> made an error in the code somewhere.

While all the browsers you mention implement "object" (although implementation 
details vary significantly), it may well be that the "automatically-generated 
code" in question targets Firefox with the "embed" element rather than "object".

>  codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0";
>  
> width="500" height="462" id="CC1144627" align="middle">
> 
> 
> 
> 
> 
> 
> 
> height="600">
>  
>  
>  
>
>  
> 
> 

The outer object would only be loaded by Internet Explorer (it's set up to load 
the ActiveX Flash plugin).

When that object fails to load, Firefox should try the inner object. But the 
inner object is not configured similarly to the outer object. In particular:

1. It's set to load a completely different Flash file ("flash.swf" not 
"calasith.swf"). I'm guessing "flash.swf" doesn't even exist.
2. It's not configured with a Flashvars param specifying an XML file. 
(Inner objects don't inherit outer object params).

For a discussion of Flash loading strategies circa 2007 see:

http://www.alistapart.com/articles/flashembedcagematch

For a useful JS library that abstracts a lot of the browser differences see:

http://code.google.com/p/swfobject/

Hope that helps.

--
Benjamin Hawkes-Lewis

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

Re: [WSG] title attribute and semantic data

[Benjamin Hawkes-Lewis]

On Wed, Apr 28, 2010 at 6:07 PM, Dani Iswara 
wrote:
> In some blog machines/engines/themes, title attribute usually has
> the same text as in anchor link. Eg. in post title with
> rel="bookmark".  Redundant information, based on Web accessibility
> point of view. But
> http://www.w3.org/2003/12/semantic-extractor.html, Semantic Data
> Extractor tool built by W3C needs the title information for the
> bookmarkable points.
>
> So, is there a way to make it accessible and semantic properly?

Short answer: omit redundant "title" attributes.

The W3C hosts some formal standards endorsed by its membership
(Recommendations). But they also host a load of tools and documents
that have no special formal status. This tool is one of those.

I think you are being misled by a bad user interface decision on the
part of whomever built the tool.

When the tool says "[Unknown title]", I suspect it is telling you
that you have not added a "title" attribute to the link, not that
you /must/ or even /should/ add a title to the link.

If the developer *did* mean to tell you to add the attribute, then
they were wrong and trumped both by your users' needs (which should
always come first) and also by the formal Recommendations that tell
you how to use the "title" attribute".

The W3C HTML 4.01 Recommendation is clear: "title" provides
"advisory information about the element for which it is set":

   http://www.w3.org/TR/REC-html40/struct/global.html#adef-title

If you don't have any useful advisory information to add, then
"title" should be omitted or empty ("title=''").

In fact, because of the usability problems with common
implementations of "title", even if you do have useful advisory
information, it may not be the best place to put it.

http://www.paciellogroup.com/blog/?p=37

--
Benjamin Hawkes-Lewis


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

Re: [WSG] validator error or my code?

[Benjamin Hawkes-Lewis]

On Mon, Mar 29, 2010 at 7:41 PM, tee  wrote:
> I am giving the benefit of doubt that there might be a good reason.

Hmm. There seems to a bit of confusion here.

Not every document published by W3C is a Recommendation endorsed by
W3C (an official "standard").

Examples of Recommendations include:

   * HTML 4.01: http://www.w3.org/TR/REC-html40/
   * Web Content Accessibility Guidelines 2.0: http://www.w3.org/TR/WCAG20/

Examples of non-Recommendations include:

   * XHTML Media Types: http://www.w3.org/TR/xhtml-media-types/
   * Techniques for WCAG 2.0: http://www.w3.org/TR/WCAG-TECHS/

Techniques for WCAG 2.0 are meant to be an unstandardized, evolving,
technology-specific corpus of examples of how you might pass
(standardized) technology-independent WCAG2 Success Criteria.

The following are distinct (if overlapping) sets:

   * HTML4 validity
   * HTML4 conformance
   * WCAG2 conformance
   * Passing tests for chosen Techniques for WCAG 2.0
   * Real-world accessibility

For example, an individual document might (theoretically):

   * Validate and conform as HTML4, pass all the tests in all the
 WCAG2 Techniques, fail WCAG2 conformance, yet achieve
 real-world accessibility.
   * Flunk HTML4 validation and conformance and fail all the tests in
 all the WCAG2 Techniques but still achieve WCAG2 conformance
 and achieve real-world accessibility.

Total Validator is checking your document for HTML SGML validity
and against some snapshot of machine-testable tests from the
WCAG2 Techniques corpus. You can check which by looking up the Error
in their Error reference:

http://www.totalvalidator.com/support/reference/index.html

None of the distinct sets identified above necessarily require that
labels and fields be descendants of "form" elements *or* any
particular positioning of "label" elements relative to fields.

But if you applying Technique H44 ("Using label elements to associate
text labels with form controls") then "label" elements must be:

* before associated field elements that are "select",
  "textarea", or "input" of type "text", "file", or "password"
* after associated field elements that are "input" of type
  "radio" or "checkbox".

How does this help real-world accessibility?

The before/after distinction reflects a common convention in
Graphical User Interfaces for positioning labels and fields: most
labels go to the left of fields, but labels for checkboxes and radio
buttons go to the right.

Before "label" existed (it was introduced in HTML4), assistive
technology such as screen readers had to infer what text labelled
what control based on such GUI conventions. Continuing to follow
those conventions allows such legacy software to continue to work.

Modern assistive technology *should* correctly associate fields with
labels regardless of label placement if there's a "for"/"id"
association.

But even with modern user agents, following those ancient GUI
conventions helps accessibility because it helps make your interface
immediately understandle to sighted users. This goes double if you
are only poorly sighted and are viewing the page with zoom, or with
your own preferred styles.

See also the W3C discussions at:

  * http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0716.html
  * http://lists.w3.org/Archives/Public/public-bpwg-access/2007Oct/0003.html
  * http://lists.w3.org/Archives/Public/w3c-wai-gl/1998OctDec/0009.html
  * http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0030.html
  * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0168.html
  * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0169.html

As a tangent, tee mentioned the "luxury to perform all sort of screen
readers testing using pricy software".

You cannot freely test with the free JAWS demo thanks to EULA
restrictions, but the following are all free to test with:

   * Window-Eyes Demo (30-minutes-per-Windows-session limit)
   * NVDA on Windows (FOSS)
   * VoiceOver comes with OS X
   * Orca on GNOME (FOSS)

The main hurdle here is not price, but developer inexperience with
with complex assistive technology.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Fw: html vallidation

[Benjamin Hawkes-Lewis]

On 12/09/2009 06:46, Marvin Hunkin wrote:

once i put a  at the end of the last  tag.
i pass vallidation.
now with this last file.
in text pad.
cannot seem to get it to vallidate.


The error is straightforward.

You have inserted a closing tag ("") on line 76. If you backtrack 
through the document, you will find you have already closed the "p" 
element begun with an opening tag ("") on line 57 with a closing tag 
() on line 72. So the validator correctly reports that it has found 
a closing tag for an element that is not open.


--
Benjamin Hawkes-Lewis




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

Re: [WSG] Accessible Forms

[Benjamin Hawkes-Lewis]

On 19/08/2009 20:04, David Dorward wrote:


On 19 Aug 2009, at 19:35, Tom Livingston wrote:


On a slightly related topic, I have wrapped inputs inside of labels
for browser compatibility for the label clickability/focus issue
(based on some research some time ago), but have just read for the
first time recently, that this is not a good idea. Any thoughts?



It isn't really a bad idea. It isn't as well supported as using the for
attribute, so you should use that as well. Beyond that it is a matter of
person taste.


Well, I haven't personally verified this, but there are apparently some 
interoperability drawbacks to nesting inside labels even when you also 
use "for" and "id", i.e.


  
Name:

  

See:

http://green-beast.com/blog/?p=254

More generally, folks, see W3C's Web Accessibility Initiative's advice, 
which includes some reports about poor support for implicit labels:


http://www.w3.org/TR/WCAG-TECHS/H44.html

--
Benjamin Hawkes-Lewis


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

Re: [WSG] table inside a dd?

[Benjamin Hawkes-Lewis]

On 17/08/2009 06:18, Tim MacKay wrote:

I am marking up product nutritional information and am thinking of doing
it like so:



 The Product 

 Paragraph blurb about the product 





<…etc>Tabular data of the nutritional information







Is nesting the table within the def list valid markup?


Yes.

I'd tend to suggest using headings (or headings inside a list) instead 
of a definition list, so that each product has an entry in the effective 
document outline:


The Product
blurb

Nutritional information
...


More practically, this allows non-mouse users of Opera 
(http://www.opera.com/browser/tutorials/nomouse/) or assistive 
technology 
(http://www.freedomscientific.com/Training/Surfs-up/Navigating.htm) to 
skip effectively from one product to another, and surfaces the products 
in assistive technology heading lists.


Some assistive technology does have some support for definition lists, 
but it's not especially pretty, which isn't surprising given the HTML 
spec suggests using the element for "terms" and "descriptions", and also 
for dialogs:


http://www.webaim.org/discussion/mail_message.php?id=11226

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Accessible websites

[Benjamin Hawkes-Lewis]

ed content ends
>> up overlapping other content.
>
> Absolute positioning just doesn't work in the context of user
> defenses

[snip]

> A publisher who cannot or will not remain cognizant of these, and test
> accordingly, is doomed to disappointment.

Indeed. This is a bigger problem than publishers notching down font size 
a little, in the sense that it's much harder for end-users to fix.


>> Or, to use different language, browsers improved their featureset for
>> partnering user viewing choices with publisher suggestions.
>
> Web browsers are user agents, not publisher agents.

These statements aren't in contradiction.

> I guess the meaning you give to pales by comparison is different
> from mine.  What I see is about a 2:1 relationship, twice as many
> complaining about size as about other problems.

I guess so. 2:1 doesn't sound like "pales by comparison" to me.

>> I asked why you wouldn't "describe publisher typeface and color
>> suggestions as an 'offence' against user choice". I find it difficult
>> to follow your answer, but it seems to be that they more rarely cause
>> illegibility than font size suggestions? If I've got that right, this
>> answer isn't very satisfying. Why is an instance of suggesting font
>> size that does not produce illegibility for a particular user an
>> offence against the user's choice when an instance of suggesting a
>> color or typeface that does produce illegibility is not?
>
> I'm not saying face& color are irrelevant WRT legibility.

I understand that.

>> Once you start down the road of saying a given publisher
>> style suggestion is an offence against user choice, it's hard not to
>> conclude that the only legitimate role for publisher styles would be
>> layout hints for semantics that don't exist in (X)HTML (for example,
>> alignment for table columns with different data types).
>
> I don't see that as a necessary result.

/That/ is what I cannot understand about your position.

You appear to be saying publisher body text font-size suggestions are 
bad because:


1. Overriding user choice is bad.
2. The default font size set in the browser constitutes a user choice 
for body text to use that font size.

3. Publisher body text font-size suggestions override default font size.

Therefore:

4. Publisher font-size suggestions override a user choice.

Therefore:

5. Publisher font-size suggestions are bad.

While I think Premise 2 is erroneous, the argument doesn't change if you 
substitute "color" and "typeface" for "font size". It looks logically 
inconsistent to make the argument in the case of font size but not color 
and typeface.


How frequently font size suggestions cause legibility problems compared 
to color and typeface suggestions - and even on the evidence you 
presented color contrast is a common problem (a third of respondents 
complaining about it!) - is irrelevant to the principles at stake.


How do you justify potentially reducing the legibility of content by 
overriding the colors and typefaces Joe Bloggs has chosen to leave at 
the defaults chosen by his browser manufacturer because they help him 
read, merely to satisfy your sense of aesthetics or because you think 
you know better about legibility for Joe than Joe and his browser vendor?


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Accessible websites

[Benjamin Hawkes-Lewis]

On 4/7/09 16:09, Felix Miata wrote:
> On 2009/07/04 10:13 (GMT+0100) Benjamin Hawkes-Lewis composed:
>
>> On 2/7/09 17:07, Felix Miata wrote:
>
>>> Zoom, minimum text size and magnifiers are defense mechanisms. The
>>> basic problem is the pervasive offense - not respecting users'
>>> font size choices by incorporating them at 100% for the bulk of
>>> content. Thus, an even better way to address presbyopia is to design
>>> to make defenses unnecessary in the first place.
>
>> I'm dubious about the rhetoric here:
>
> That you call it rhetoric doesn't make it so.
>
> Too small text is #1 user complaint:
> http://www.useit.com/alertbox/designmistakes.html

That's not quite what the article says. "Bad fonts" was the biggest 
complaint from Nielsen's readers, but that category includes "frozen 
font sizes" and "low contrast", not just "small font sizes".


> W3 recommends 100%: http://www.w3.org/QA/Tips/font-size

"Recommends" has a technical sense when it comes to W3C, and this isn't 
a formal recommendation:


"While the tips are carefully reviewed by the participants of the 
[Quality Assurance Interest] group, they should not be seen as anything 
else than informative bits of wisdom, and especially, they are not 
normative W3C technical specifications."


> As do others, e.g.:
> http://tobyinkster.co.uk/article/web-fonts/
> http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html
> http://informationarchitects.jp/100e2r/?v=4
> http://fm.no-ip.com/auth/bigdefaults.html
> 
http://www.cameratim.com/personal/soapbox/morons-in-webspace#hard-to-read-fonts


The claims I was trying to question were:

Claim 1: Browser defaults always represent "user choice".

Claim 2: Acceptance of publisher font size suggestions is not a valid 
"user choice".


Claim 3: Publisher font size suggestions are an "offence" against user 
choice in some way that typeface and color suggestions are not.


Most of the authorities you cite agree with Claim 1 but none offer any 
argument for Claims 1 or 2.


Most contradict Claim 3. In Nielsen's survey of his readers, a third 
complained about poor color contrast. Oliver Reichenstein discusses how 
bad contrast can reduce legibility, and your own article says "to be 
legible, text needs enough contrast". Toby Inkster and Stephen Poley 
both discuss how typeface choice can render text hard-to-read. Tim 
Seifert's excellent diatribe says "[d]aft colour schemes are a pain" and 
"[s]etting a page to use particular fonts … can make a page difficult, 
or impossible to read".


>> * Why should we treat browser default font size settings, which many 
users

>> seem not to realise that they can change,
>
> Whether individuals know how [snip] is irrelevant

Can you make a choice if you do not realize you have options?

Of the users who do realize they can force font size but choose not to, 
why assume their choice is to use the default size with all designs 
rather than supplying a default size when publisher suggestions are 
absent? Why assume users are always trying to use that browser setting 
to do something it doesn't claim to do?


> You as designer aren't there, so you can't possibly know that what
> they have isn't acceptable or even perfect, much less improve their
> experience by deviating from the default.

Both users and designers operate from a position of ignorance. Users who 
adjust their default font size don't know how their adjusted default 
font size will work with different colors and typefaces; designers know 
how common default font sizes will work with their suggested colors and 
typefaces, but not how the user's adjusted size will work. Because of 
these areas of ignorance, it is possible for designers to happen to 
suggest a more legible size. (The more users who don't adjust their 
default font size, the more likely this is.)


> Personal computers are not made by morons, but by humans who have
> preselected defaults designed to make the majority of users happy with
> most things just as they found them, ready to use as received. To
> think that an eagle-eyed web page designer biased by her giant
> tax-deductible worktool display can impose some other size in order to
> make things better for the majority is a preposterous supposition.

I think the default styles used by popular browsers mainly aim at a mix of:

   1. Making websites look similar to how they look in other popular 
browsers.

   2. Making website controls look similar to those in the desktop widgets.

They aren't designed from scratch to maximize usability by themselves or 
to maintain usability when combined with publisher styles.


Maybe the original design decisi

Re: [WSG] Accessible websites

[Benjamin Hawkes-Lewis]

On 2/7/09 17:07, Felix Miata wrote:

Zoom, minimum text size and magnifiers are defense mechanisms. The basic
problem is the pervasive offense - not respecting users' font size choices by
incorporating them at 100% for the bulk of content. Thus, an even better way
to address presbyopia is to design to make defenses unnecessary in the first
place.


I'm dubious about the rhetoric here:

   * Why should we treat browser default font size settings, which many 
users seem not to realise that they can change, as "users' font size 
choices"? If users want to force a font size everywhere, they can and 
that is indisputably a user choice.
   * Why should we characterize user acceptance with reservations of 
publisher styles for the page, the web, or their entire system as a 
"defensive" measure? I think this language reinforces the popular 
(mis)conception that publisher styles are the natural presentation of 
the publisher's content, rather than a skin the user should be able to 
reject or use with modifications. Why not see this as a partnership 
rather than a battle?
   * Like font size, typeface and colors can radically affect the 
legibility of text and can be overridden by settings in popular 
browsers. Would you describe publisher typeface and color suggestions as 
an "offence" against user choice? If no, then why not?


(As an aside, none of this undermines the clear usability advantages of 
designing for legibility when creating publisher skins.)


I'd suggest that bigger problems in modern web design are the use of 
publisher styles that:


1. Prevent user acceptance of publisher styles with reservations. For 
example, use of "background-image" (which may need to be disabled for 
legibility reasons) to render headers and controls, with their text 
hidden, or positioned off-screen, or overlaid by another element where 
it won't be seen. I've railed against this, but I can't see this getting 
better until we develop a fast and reliable technique for detecting 
whether background-image will be applied with JS or CSS3's modifications 
to "content" are widely implemented:


http://www.css3.info/image-replacement-in-css3/

2. Far worse, prevent user rejection of publisher styles wholesale. For 
example, loading multiple application states (e.g. a form, its error 
messages and sucess messages) into the DOM simultaneously, then using 
the "display" property to determine which get shown to the user - rather 
than using DOM methods to add and remove fragments to the DOM as required.


These do turn turn the partnership into a conflict.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] valid meta tags

[Benjamin Hawkes-Lewis]

On 27/5/09 10:54, designer wrote:

I'm using the one included with Chris Pederick's developer toolbar for
Firefox (3), which is actually www.cynthiasays.com. It fails this:



but not this:



Try it for yourself. Is this validator at fault then?


It's a testing assistant rather than a validator, strictly speaking.

And yes, I'd say it's at fault in this case.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] valid meta tags

[Benjamin Hawkes-Lewis]

On 26/5/09 18:39, designer wrote:

Solved it!






should be



On the whole, this sounds more like a bug in the "validator" you're using.

The first snippet is correct; the second snippet has no specification 
and no meaning to any consuming software AFAIK.


"meta name='language'" certainly isn't among the techniques suggested by 
WAI (who instead suggest the "lang" attribute):


http://www.w3.org/TR/WCAG10-HTML-TECHS/#identify-primary-lang

http://www.w3.org/TR/WCAG20-TECHS/H57.html

Nor is it among the techniques suggested for declaring a document's 
language by W3C's internationalization group:


http://www.w3.org/TR/i18n-html-tech-lang/

If you want to indicate language to assistive technology, put "lang" and 
"xml:lang" attributes on your "html" element and any descendant elements 
where the language is different. This is known to work in actual screen 
readers like JAWS:


http://developer.yahoo.net/blog/archives/2008/03/yahoo_search_re.html

W3C suggests using "meta http-equiv='content-language'" in a subtly 
different way from the "lang" and "xml:lang" attributes:


http://www.w3.org/TR/i18n-html-tech-lang/#ri20040808.101452727

http://www.w3.org/TR/i18n-html-tech-lang/#ri20040728.121358444

--
Benjamin Hawkes-Lewis



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

Re: [WSG] Possible to embed Flash w/out keyboard trap problems?

[Benjamin Hawkes-Lewis]

On 13/5/09 04:32, Rebecca Cox wrote:

I'm wondering if its possible to embed Flash into HTML, using only HTML
(no javascript) and for this to be keyboard accessible (HTML and Flash
content usable by keyboard, no keyboard trap problems, for say A-grade
list at http://developer.yahoo.com/yui/articles/gbs/)

Test page: http://reb.net.nz/greed/index2.html

Seems to be fine in IE, but in Firefox you cannot get keyboard focus
onto the Flash without using the mouse.


I suspect http://bugs.adobe.com/jira/browse/FP-1219 is why you can't 
move focus into the Flash without the keyboard.


The more usual problem in Firefox is not being able to move focus /out/ 
of the Flash object.



Just spotted
http://blogs.adobe.com/accessibility/2009/04/firefox_focus_and_actual_links_1.html
 but
this sounds as if it relies on the actionscript within the Flash itself
being written in a particular way, and possibly on the javascript used
to embed the flash into the HTML page.


Interesting, hadn't seen that before.

I'm not sure the technique is dependent on how you embed it, but it does 
look dependent on the JS DOM focus() method to move focus out of the 
Flash object.


So I'd suggest the answer to your wondering is no. :(

--
Benjamin Hawkes-Lewis



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

Re: [WSG] Image Replacement and Accessabilty

[Benjamin Hawkes-Lewis]

On 17/4/09 03:15, Russ Weakley wrote:

Of course, we'd all prefer to use the correct method, which is
"display:none" - but we have not been able to use this due to issues
with earlier versions of JAWS (content set to "display: none" was not
read aloud by these screen readers) - negatively affecting the very
people we were trying to assist. :(


Note, per the current CSS 2.1 spec, display is not a visual property 
specifically, so it's probably not the correct method.


http://www.w3.org/TR/CSS21/visuren.html#display-prop :

"display" applies to all media types.

http://www.w3.org/TR/CSS21/aural.html#propdef-speak :

"speak: none;" "Suppresses aural rendering so that the element requires 
no time to render" but "descendants may override this value and will be 
spoken. (To be sure to suppress rendering of an element and its 
descendants, use the 'display' property)."


That is to say, "display" might be more clearly named "render" (in 
speech, in print, on screen, in braille, etc.).


If one assumed that screen readers should act as if they were aural or 
braille browsers, then you could make a case that:


@media screen, projection {
.thing {
display: none;
}
}

would be a correct method. But this assumption doesn't really reflect 
the actual approach taken by screen reader developers. All popular 
screen readers ignore speech- and braille-specific CSS.


--
Benjamin Hawkes-Lewis



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

Re: [WSG] Image Replacement and Accessabilty

[Benjamin Hawkes-Lewis]

On 16/4/09 05:56, Gary Barber wrote:

Now it is

h#{

left: -px;

}

that had issues with screen readers.


Interesting. Not in my experience.

What screen readers and versions are you talking about? Do you have a 
test case that demonstrates the problem?


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Semantics: Microformats, RDFa

[Benjamin Hawkes-Lewis]

On 27/2/09 16:12, Andrew Maben wrote:

There seem to be some Microformats proponents on the list, but I don't
recall much mention of RDFa.

I wonder if anyone has any thoughts on their relative merits, both
immediately and in the longer term?


It might be helpful if you described the problem you're hoping to solve 
with either, but anyway here are some thoughts under four headings.


+ Parser interoperability

I don't have first-hand experience with implementing a parser, but I 
suspect how XHTML+RDFa should be parsed into RDF triples is better 
specified than how HTML4 and XHTML1 microformats should be parsed into 
data. The microformats community is still working on parsing specs, but 
the XHTML+RDFa standard includes parsing specs:


http://www.w3.org/TR/rdfa-syntax/#s_rdfaindetail

http://microformats.org/wiki/parsing

+ HTML compatibility

You are supposed to be able to express microformats in conforming HTML 
4.01 as well as XHTML 1.x. This has been partially achieved in the sense 
that no microformat requires you to write HTML 4.01 that does not meet 
its SGML validity requirements, though some accepted microformat 
patterns do (arguably, at least) abuse HTML4 elements and attributes.


By contrast, RDFa has only been specified for XHTML. However, Internet 
Explorer - the most popular browser - does not support XHTML. The 
guidance for how authors should serve XHTML family documents as 
text/html is still being written (by the XHTML 2 WG):


http://www.w3.org/MarkUp/Drafts/#xhtml-media-types

Worse, there is no standard yet for how RDFa should be treated when 
served as text/html rather than XML. This will be defined by the HTML 
WG/WHATWG, who are working on the next version of the HTML standard and 
are currently unpersuaded of the need to support RDFa:


http://www.w3.org/html/wg/

http://www.whatwg.org/

http://tinyurl.com/bbx75q [public-h...@w3.org archives]

http://tinyurl.com/akjzm3 [wha...@whatwg.org archives]

+ Accessibility

Microformats create minor accessibility problems when you need to 
include machine-parseable data that is equivalent or supplementary to 
human-friendly visible information. The microformats community is still 
working on better approaches to including such information.


http://www.webstandards.org/2007/04/27/haccessibility/

http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from_bbc.shtml

http://microformats.org/wiki/machine-data

RDFa does not create the same problems, because it adds extension points 
for this purpose (the "content" attribute on every element, primarily).


http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes

+ Distributed extensibility

You can unilaterally make up your own vocabulary in RDFa, but not 
microformats, which must be developed and standardized through the 
microformats community process. (Of course, you can make up markup 
patterns that can be used to extract metadata - but those aren't 
official microformats.) Whether this is good or bad perhaps depends on 
how widely useful your vocabulary would be.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Accessibility testing

[Benjamin Hawkes-Lewis]

On 11/2/09 05:59, Henrik Madsen wrote:

What similar software / online systems do people use and get reliable
results (if reliable results are indeed attainable)?


Define "reliable results". :)

Such systems are intrinsically limited in what they can test.

If your contract requires you to pass checks with this piece of 
software, fine, but beyond that I recommend using wetware as well as 
software: imagining about the user experience for different user groups 
[1-2], thinking through the application of accessibility guidelines to 
your site [3-5], code reviewing your code line-by-line with fellow 
developers, and if at all possible testing the final product with people 
with disabilities [6-7].


[1] http://www.uiaccess.com/accessucd/
[2] 
http://delicious.com/benjaminhawkeslewis/howPeopleWithDisabilitiesUseTheWeb?sort=alpha&order=asc

[3] http://www.section508.gov/
[4] http://www.w3.org/TR/WCAG10/
[5] http://www.w3.org/WAI/intro/wcag.php
[6] http://dev.opera.com/articles/view/26-accessibility-testing/#usertesting
[7] 
http://www.rnib.org.uk/xpedio/groups/public/documents/PublicWebsite/public_seeitrightaudit.hcsp


--
Benjamin Hawkes-Lewis




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

Re: [WSG] Implication of empty divs

[Benjamin Hawkes-Lewis]

On 9/2/09 02:44, Gerard Hynes (Gmail) wrote:

I'm not expert about screen readers, but I did run a site I upgraded
through JAWS with some interesting results. The site had alot of
   due to the CMS they were using and JAWS would translate
this to/speak out "blank" which wasn't ideal. Am not sure if it would
do the same for  or  or.


Precise behavior will vary with publisher styling of the DOM, platform, 
browser (and version), screen reader (and version), user configuration, 
and the commands used when reading that part of the page.


For example, JAWS 10 has a concept of "blank lines". It will read out 
"blank" as you step through a document if you come to something that 
matches that concept. The following variations:


bar
baz

bar
baz

bar
 
 
baz

bar

baz

bar


baz

are _all_ read:

"bar
"blank
"baz"

It also has a configuration setting for whether "blank lines" should be 
spoken with the "Say All" command. If this is off (as it is by default), 
then the above variations would all be read:


"bar
"baz"

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Implication of empty divs

[Benjamin Hawkes-Lewis]

On 9/2/09 07:45, Chris F.A. Johnson wrote:

How can CSS overflow replace ?


See http://www.ejeliot.com/blog/59

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Implication of empty divs

[Benjamin Hawkes-Lewis]

On 8/2/09 23:33, Ben Lau wrote:

Are there any (seriously) bad implications of having empty DIVs around
your HTML document? I try to avoid using them personally, but there are
cases where the visual design has forced me to add empty divs (or spans)
just to achieve the look.
Apart from adding extra weight and cluttering the document, I understand
screen readers do not pick up divs and spans?


The short answer is that at most they would treat an empty "div" or 
"span" as a blank line or space. I wouldn't worry about it.


The long answer is that it is possible to overload "div" and "span" 
elements with content and functionality in other ways that might get 
picked up by screen readers (using ARIA), but that's not the scenario 
you're describing.



Would I be better off to insert these meaningless decorative tags using
javascript and modifying the DOM, while non-javascript users would see a
more cut down version of the design?


As far as I can see, you would not be helping non-JS users by doing so.


Do screen readers pick up javascript and events?


Popular screen readers are not web browsers themselves. Instead, they 
are system-wide services that provide an aural and/or braille output and 
keyboard input interface to the desktop environment and applications 
like office software, media players, and (most importantly, for your 
purposes) popular web browsers. See links at:


http://delicious.com/benjaminhawkeslewis/howScreenReadersWork

Popular web browsers, of course, can pick up on JavaScript and events. 
But DHTML communication to screen readers users can break down on 
various levels. For example:


1. Failure to bind functionality to standard UI controls like buttons, 
hyperlinks, and form controls might lead to screen readers users being 
unaware that functionality is available or unable to activate such 
functionality.


2. Scripted changes to the page might not be picked up by the screen 
reader. Screen readers often work with a sort of snapshot of the 
structure and content of the web document (a virtual buffer). Sometimes 
this snapshot is not updated when the real document is altered by script.


3. The user might not be alerted to changes to the page or snapshot.

4. The user might be constantly interrupted by irrelevant changes.

For further reading see:

http://delicious.com/benjaminhawkeslewis/accessibility+ajax

And for accessibility best practices generally see:

http://www.w3.org/WAI/intro/wcag.php

http://www.rnib.org.uk/xpedio/groups/public/documents/code/public_wacsitemap.hcsp

Hope that helps.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Opera Targeting?!

[Benjamin Hawkes-Lewis]

On 3/2/09 20:13, Brett Patterson wrote:

I really don't understand what you mean, when you say:

It's a designer-bug. Vertical position of the navigation relies entirely
on font size, which means it is all over the place in my browsers on
first load.

No two browsers calculate font size exactly the same before rendering,
so relying on "pixel-perfect" font size across browser-land is not a
good idea. Add in font resizing and other regular options in browsers,
and it gets a lot worse - for the whole layout.


The problem should not rely on font size, but rather the margin from the
top of the item that margin-top is being applied to, to the bottom of
the item that is directly above the item that margin-top is being
applied to, correct?


I think Gunlaug is referring to this (simplified):




Title here

Tabs here




#hdr {
border-bottom: 1px solid #CC9966;
height: 90px;
}

#pageheader {
float: left;
}

You've floated #pageheader out of the normal flow that determines the 
height of #hdr, and there's nothing in place to force #hdr to contain 
the lowest floated descendant. The logo image is in normal flow but it 
is 85px tall, so what determines the height of #hdr is the "height: 
90px;" setting.


Consequently, the alignment of the bottom of #tabs with the bottom 
border #hdr depends on #pageheader actually being 90px tall. Since it's 
got text inside it, and you can suggest but cannot expect a font height 
(and therefore cannot even make a reliable prediction about how many 
lines a given string will need), that dependency is brittle in the 
extreme. In Firefox 3's Zoom submenu (under the View menu) try ticking 
"Zoom Text Only" and then zooming in twice to watch it break horribly, 
with the title text wrapping to the next line forcing the tabs entirely 
below the border.


For further reading see:

* http://www.w3.org/TR/CSS21/visudet.html#the-height-property

* http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins

* http://www.ejeliot.com/blog/59


I mean I do know that font size across browsers does not render the
same, but if using pixels for a font size, should the pixels (in
relation to size) render the same?


I'm not entirely sure I understand the question ("in relation to size" - 
size of what?).


The size of a CSS pixel is intended to be relative to the resolution of 
the viewport, and is ultimately up to the user agent:


"Pixel units are relative to the resolution of the viewing device, i.e., 
most often a computer display. If the pixel density of the output device 
is very different from that of a typical computer display, the user 
agent should rescale pixel values. It is recommended that the reference 
pixel be the visual angle of one pixel on a device with a pixel density 
of 96dpi and a distance from the reader of an arm's length. For a 
nominal arm's length of 28 inches, the visual angle is therefore about 
0.0213 degrees."


http://www.w3.org/TR/CSS21/syndata.html#length-units

Most desktop browsers make a CSS pixel a monitor pixel, however most 
desktop browsers (Opera, IE7, IE8, Firefox 3) also include a zoom 
function that changes the effective pixel size up or down. Note that 
some zoom functions (Opera, IE8) include fit-to-width reflowing 
capabilities that mean that there's no guarantee that a box width in px 
will remain proportional to a font height specified in px.


Most desktop browsers (IE, Firefox, Safari) allow users to adjust the 
font size up or down in steps. In IE's case, these adjustments do not 
affect font sizes specified in pixels.


In addition, most desktop browsers (IE, Opera, Firefox, Safari) enforce 
minimum font sizes in real pixels and allow users to change them, and 
allow users to disregard publisher suggestions about font size and set 
enforce their own preferences.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] How to hide/show form questions with javascript while meeting WCAG 2?

[Benjamin Hawkes-Lewis]

On 27/1/09 05:19, littler...@internode.on.net wrote:
> I am starting to learn javascript/jquery and would like to use it to
> hide questions on a form dependant on the answer to another question.

Hmm. Can we explore the precise interaction a little bit more before 
jumping to solutions?


How will the same transaction be handled when JavaScript is unavailable, 
if at all?


If a user was to see all the questions all the time, would they still 
understand the form?


If not, would they understand the form if the wording of the questions 
was altered a bit?



I have seen plenty of working examples but am concerned that they
wouldn't be accessible or comply with WCAG 2.0.

Does anyone have an example of best practice or can advise on how
they deal with this issue?


There are three basic approaches to "hiding" and "showing" things that 
you should choose between based on the core WCAG principles 
(perceptibility, understandability, operability, robustness):


1. DOM mutation: remove elements from the DOM (removeChild, or 
innerHTML), store them in a variable, and then add them again later 
(appendChild/insertBefore, or innerHTML). In theory, this should "hide" 
things from all users. It's the most appropriate approach when the 
document would be nonsensical if the elements continued to be shown to 
the user.


2. "display" method: suggest that the elements are styled with "display: 
none;". In theory, this should "hide" things from any user from any 
users that are using user agents that support CSS (not all do), that are 
not rejecting publisher styles (some do), and that are not overriding 
that style. This is the most appropriate approach when the document 
would be understandable even if the elements continued to be shown to 
the user, but hiding them simplifies or prettifies the content.


3. Off-screen method: Suggest that the elements are styled so as to be 
positioned off-screen (e.g. "left: -9px; position: absolute;"). In 
theory this should "hide" things from any sighted users that are using 
user agents that support CSS (not all do), that are not rejecting 
publisher styles (some do), and that are not overriding that style. This 
is the most appropriate approach when the document would be 
understandable if the elements continued to be shown to the user, and 
hiding them from sighted users applying CSS simplifies or prettifies the 
content for those users, but the content must be shown to any group of 
users who are visually impaired or whose user agent or configuration 
does not apply that CSS.


A gotcha with techniques 1 and 2 is that assistive technology may not 
refresh its "buffer" or "cache" of the DOM immediately and so may not 
reflect your dynamic changes when representing your content to the 
end-user. Testing is crucial here. See also:


http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

http://www.gwmicro.com/blog/index.php/all/?title=regarding_web_based_dynamic_content&more=1&c=1&tb=1&pb=1

http://wiki.codetalks.org/wiki/index.php/How_to_use_ARIA_Live_Regions_for_dynamic_content

http://www.paciellogroup.com/blog/?p=65

A gotcha with techniques 2 and 3 is that you must ensure that if a 
"hidden" element receives keyboard focus (whether by pressing an 
"accesskey", or moving through the tab order, or jumping to an element 
of a particular type, or being sent there dynamically), either focus 
must be automatically passed on to a visible element or the element must 
be made visible. ("focus", "blur", "DOMFocusIn" "DOMFocusOut", 
"focusin", and "focusout" UI events and ":focus" and ":active" 
pseudo-classes are the key tools at your disposals here.) Otherwise, the 
keyboard focus indicator will be hidden. That would be confusing to 
sighted keyboard users and a WCAG2 violation:


http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible

Most JavaScript for "hiding" and "showing" content actually uses the 
"display" method, because it's easy, even when it's arguably 
inappropriate. A frequent mistake of this sort is to send the client an 
HTML form with error messages embedded directly in the HTML and styled 
with "display: none;", which are then styled "display: block" if a field 
fails form validation. This breaks horribly when your styling 
suggestions aren't applied, because the user will be confused by error 
messages that do not reflect actual input.


Hope that helps.
--
Benjamin Hawkes-Lewis


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

Re: [WSG] Validating (X)HTML + ARIA

[Benjamin Hawkes-Lewis]

On 20/1/09 23:13, Anthony Ziebell wrote:

because an implementation of ARIA without using
JavaScript to do so would essentially mean a drop of support of legacy
browsers


If all you are doing is adding some unrecognized ARIA attributes to 
_existing_ HTML or XHTML content, then such attributes are 
(realistically) not going to harm users of legacy browsers.


Some aspects of ARIA (such as "tabindex" for all elements and negative 
values of "tabindex") were implemented in some older browsers, even 
though invalid in HTML 4.x and XHTML 1.x, long before ARIA was proposed.


In so far as new assistive technology performs any DOM inspections for 
ARIA attributes in legacy browsers (probably not much), the presence of 
ARIA attributes might help users of those combinations.


So long as you continue to use the same HTML 4.01 or XHTML 1.x elements 
to mark up the same content, I don't understand why the additional 
inclusion of ARIA attributes (say, landmark roles) should make any 
difference to "support of legacy browsers".


For example, if you enhanced a document with you a "Skip to main 
content" link by additionally marking up your navigation area with 
role="navigation" and your main content area with role="main", the net 
effect of adding ARIA attributes on backwards compatibility could be 
positive.


I can see a conflict with backwards compatibility if you let the 
presence of ARIA attributes change how you author your content. For 
example, if you _replaced_ a "Skip to main content" link by marking up 
your navigation area with role="navigation" and your main content area 
with role="main", you'd be replacing a technique that works for a given 
set of older user agent software with a technique that works for a given 
set of newer user agent software. In that scenario, the net effect of 
adding ARIA attributes on backwards compatibility could be negative.


Similarly, if you depended on ARIA to communicate semantics available in 
existing (X)HTML (say replacing "h2" with "div role='heading' 
aria-level='2'") or if you introduce new semantics/functionality 
communicable with ARIA but not existing (X)HTML are essential to 
understanding/using your content rather than an enhancement , you'd lose 
backwards compatibility for your content.


So as you can see, progressively enhancing with ARIA doesn't equate to 
adding ARIA attributes with JavaScript, but rather to using ARIA as an 
enhancement rather than replacement whether dependent on JS or not.


I think the more serious compatibility problem with ARIA is the 
immaturity and rapid pace of change of the draft specifications and 
implementations.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Validating (X)HTML + ARIA

[Benjamin Hawkes-Lewis]

On 20/1/09 22:47, Anthony Ziebell wrote:

It's more of a business decision... do we enhance our sites and make
them a whole lot more accessible, meanwhile dropping support for
older browsers?


Other than an accessibility technology inspecting the DOM for ARIA 
attributes, what makes you think that the presence or absence of ARIA 
attributes in particular makes any (real world) difference to 
compatibility if the user is using a browser that does not implement any 
functionality for those attributes other than inserting them into the DOM?


Surely what makes the big difference to accessibility for users of older 
user agents is the absence of an accessibility infrastructure for 
certain DHTML widgets and behaviours that works in those user agents?



Or do we sit
and wait until older browsers no longer have a market share and leave
our visually impaired visitors in the dark?

Someone mentioned using JavaScript to implement ARIA parameters. This is
a good idea...


Why?


but just how accessible would that be to a vision
impaired visitor with JavaScript turned off?


As accessible as your page normally is with JavaScript turned off to the 
same user.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Microformats & Accessibility

[Benjamin Hawkes-Lewis]

On 20/1/09 08:31, Michael MD wrote:

If something like "February 9th" appears on a page is that really
"human-friendly"?
. what year is that? is it coming up ? ... or am I looking at an old
page about something from last year? ...


Um... depends, look at the surrounding text in this test case:

http://microformats.org/wiki/value-excerption-value-title-test#hCard.231:_An_hCard_bday

it's a birthday, so last year, this year, and every year thereafter. ;)


It would certainly be nice if people were to learn to write "human"
dates more clearly!


I agree with this general point, though the way to write dates most 
clearly in English is "9 February 2009" (or, somewhat worse, February 
9th 2009) not any machine-readable readable syntax.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Validating (X)HTML + ARIA

[Benjamin Hawkes-Lewis]

On 20/1/09 06:24, Anthony Ziebell wrote:

Is it true XHTML 1.1 supports modularization and thus, ARIA, except for
the role attribute / values?


I'm not sure I understand the question.

"Modularization", in XHTML's case, refers to the splitting of XHTML 
itself into modules. This allows the definition of profiles of XHTML by 
adding modules together or the definition of compound "XHTML family" 
schema that mix a selection of XHTML modules with elements, attributes, 
and entities from other namespaces. See:


http://www.w3.org/TR/1999/WD-html-in-xml-19990224/#mods

http://www.w3.org/TR/xhtml-modularization/introduction.html#s_intro_whatismod

XHTML 1.1 is a profile of XHTML defined by adding XHTML modules together.

A strictly conforming XHTML 1.1 document cannot include ARIA attributes:

http://www.w3.org/TR/2001/REC-xhtml11-20010531/conformance.html#strict

http://www.w3.org/TR/xhtml11/conformance.html#docconf

Modularization doesn't mean much either way for ARIA usage, since:

1. If you wanted to mix ARIA and XHTML in an XHTML family schema, all 
modularization would allow you to do is ban existing bits of XHTML (say, 
presentational elements) from that schema.


2. If you just want to mix ARIA and XHTML in an XML document, you don't 
need an XHTML family schema - especially if you want to use XHTML 1.1's 
profile wholesale.



XHTML 1.1 (latest draft) allows XHTML 1.1
to be served as text/html as defined in RFC2854 or application/xhtml+xml
as defined in RFC3236.


The first edition of XHTML 1.1 doesn't mention media types:

http://www.w3.org/TR/2001/REC-xhtml11-20010531/

The latest public draft of the second edition (February 2007) says:

"XHTML 1.1 documents SHOULD be labeled with the Internet Media Type 
text/html as defined in [RFC2854] or application/xhtml+xml as defined in 
[RFC3236]."


The latest editor's draft (January 2009) says:

"XHTML 1.1 documents SHOULD be labeled with the Internet Media Type 
"application/xhtml+xml" as defined in [RFC3236]"


http://www.w3.org/MarkUp/2009/ED-xhtml11-20090106/conformance.html#strict

Note that "SHOULD" has a specific meaning defined in RFC 2119:

http://www.ietf.org/rfc/rfc2119.txt .

Both the drafts refer us to W3C's note on XHTML media types:

http://www.w3.org/TR/xhtml-media-types/

Which has no normative status, but was a summary of the HTML Working 
Group's view of best practice in 2002, and says XHTML 1.1 "SHOULD NOT" 
be served as text/html, "MAY" be served as application/xml or text/xml, 
and "SHOULD" be served as application/xhtml+xml. (Again, these are RFC 
2119 terms).


But this note is itself being revised by the XHTML 2 Working Group:

http://www.w3.org/MarkUp/2009/ED-xhtml-media-types-20090116/

It is still a note with no normative status, and this time "should" etc. 
are not defined with reference to RFC 2119. The note suggests best 
practices for serving XHTML documents as text/html:


* They should "conform" to a set of guidelines, ultimately a reworking 
of the guidelines at the end of XHTML 1.0


* They should not be XHTML Family documents that mix XHTML with features 
from other namespaces (e.g. SVG, MathML, YourMadeUpML).


What rather confuses all this is that there is _another_ W3C Working 
Group that is simultaneously defining how text/html and XML features in 
the XHTML namespace ( http://www.w3.org/1999/xhtml/ ) should actually be 
processed, the new HTML WG:


http://www.w3.org/html/wg/


This is exciting as it looks like we are so close
to being able to implement websites which have a much higher level of
accessibility.


If you think a major barrier to ARIA adoption is that there is no way to 
use ARIA in your document and conform to a W3C Standard, then 
discussions around including ARIA in HTML5, the drafting of XHTML 1.2 
(which includes ARIA), and the gradual standardization of ARIA itself 
are of significantly more interest than any draft of XHTML 1.1.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Website review : http://webprocafe.com

[Benjamin Hawkes-Lewis]

On 16/1/09 16:41, Stewart Griffiths wrote:

Please can you provide feedback on the following website
http://webprocafe.com/

We are looking for thoughts on the design and usability of the site,
plus any general feedback you want to provide.


Hmm.

Just looked at the homepage.

Pointless XHTML formedness errors, lack of heading elements, table 
layouts, presentational markup, inline styles, obtrusive JavaScript, 
unnecessary browser detection, presentational class names, and a layout 
that begins to break with only two text size steps up (at least in 
Safari) may be byproducts of vBulletin but they undercut the site's 
ostensible purpose of discussing professional web development in a way 
that I find hard to overlook given you've adopted a self-hosted solution 
for the forum.


More subjectively, I think the random bits of sans-serif (menu links at 
the side and some of the menu links at the top) look discordant, the 
lack of contrast between the brown backgrounds and darker brown text may 
make the content hard to read for some users (I'd suggesting using 
coffee text on white instead of brown text on brown), and the icons in 
the left-hand navigation menu look too randomly generic.


Sorry that's harsh, but I hope it helps.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] SEO and Flash

[Benjamin Hawkes-Lewis]

On 15/1/09 06:59, Stuart Foulstone wrote:

If the text in Flash is accessible SEs will index it.

Search robots are in effect blind readers.

If text in Flash is accessible, screen readers can read it.


The mechanisms provided for search engines and screen readers to read 
Flash content are very different, not least because screen readers need 
to interact with Flash functionality not just read Flash content.



However, sensible screen-reader users disable Flash.


Not when they want to listen to videos and audio on the web, they don't.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Frames/iFrames [SEC=UNCLASSIFIED]

[Benjamin Hawkes-Lewis]

On 14/1/09 05:31, mary-anne.nay...@medicareaustralia.gov.au wrote:

They are using them to facilitate the menu/header/footer ite,s across a
host of applications which sit on a range of differing servers using a rang
of differing technologies. I suggested SSI's but that is not possible due
to server configuration issues. I think I am going to allow iFrames but
with some stipulations.


My company uses IFRAME elements to share headers and footers with 
partner sites.


The biggest problem with this approach is that you have to specify a 
HEIGHT attribute for the IFRAME. That forces you to make assumptions 
about the height of the IFRAME content, and those assumptions will 
inevitably break down under some conditions. (Try bumping up your text 
size three or four steps and see what happens!)


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Frames/iFrames [SEC=UNCLASSIFIED]

[Benjamin Hawkes-Lewis]

On 12/1/09 07:12, mary-anne.nay...@medicareaustralia.gov.au wrote:

I am just wondering what is the general consensus on the use of Frames or
iFrames these days. WCAG2.0 is not terribly clear on whether we should or
shouldn't be using them.


WCAG 2.0 tries to express the principles of web accessibility in a 
technology independent manner. If you can use frames in consistency with 
those principles, that's compatible with conforming to WCAG 2.0.


Note that the Techniques document for WCAG 2.0 does include some HTML 
techniques relevant to frames:


http://www.w3.org/TR/WCAG20-TECHS/H64.html

http://www.w3.org/TR/WCAG20-TECHS/H70.html


I understand there are usability issues as well as
problems with Search Engines.


The usability minefield with frames described at -

http://www.useit.com/alertbox/9612.html

- hasn't disappeared.

The interoperability problem hasn't disappeared either. There are still 
browsers in use - some mobile browsers, Lynx - that can't handle frames.


More recently, security-conscious users are being advised to disable 
"iframe" support as one measure against clickjacking:


http://hackademix.net/2008/09/27/clickjacking-and-noscript

http://hackademix.net/2008/09/29/clickjacking-and-other-browsers-ie-safari-chrome-opera/

http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/

Likewise the problems with frames for search engines described at the 
article Nielsen cites:


http://www.ehsco.com/opinion/19980209.html

appear to still exist today:

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35769

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=34445

http://searchenginewatch.com/2167901

http://help.yahoo.com/l/us/yahoo/search/webcrawler/slurp-08.html?terms=frames 
(although contrast 
http://help.yahoo.com/l/us/yahoo/search/webcrawler/slurp-09.html?terms=frames 
)



I have a client that seems determined to use them despite my best advice.


Use them how for what?

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Title attribute

[Benjamin Hawkes-Lewis]

On 12/1/09 00:00, Jens-Uwe Korff wrote:

I found that, contrary to what I believed previously, this is not
required for assistive technologies, ie. screenreaders. They usually
pick up the anchor text well.


http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/

is a very useful discussion of the TITLE attribute from an accessibility 
perspective.


I think the destination of a link is best made clear by the link text.

TITLE attributes are useful to provide tooltip text for icons however.

--
Benjamin Hawkes-Lewis


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

Re: [WSG] credibility of accessibility validator and evaluator

[Benjamin Hawkes-Lewis]

On 31/12/08 10:43, tee wrote:

I was testing the FAE the first time, and is questioning its report
credibility because it fails my document title 50%. Not that I don't
like to be wrong :)

According to the report:

Document Title Best Practices

* The page should contain exactly one title element.
* Pass: 1 title element was found.
* The text content of each h1 element should match all or part of the
title content.
* Fail: 0% (0 out of 1)

I cannot find any information about h1 content should match part or all
of the title content on WCAG 2.0 guideline. There isn't guideline
reference link to WCAG 2.0 official site, and I couldn't find such info
on WCAG official document.


FAE isn't a WCAG 2.0 compliance tool.

It's a tool testing for compliance with a set of best practices 
(CITES/DRES Best Practices) that aim to create accessible websites that 
comply with WCAG and Section 508 compliance.


http://fae.cita.uiuc.edu/about.php?page=overview

It therefore sbouldn't surprise you if:

1. Some tests aim at accessibility without being directly attributable 
to WCAG or Section 508.


2. Other tests depend on interpretation of WCAG or Section 508.

Note, furthermore, that the version of WCAG in question is 1.0 not 2.0:

http://cita.disability.uiuc.edu/html-best-practices/

The set of rules about titles refers back to WCAG 1.0 3.5 ("Use header 
elements to convey document structure and use them according to 
specification.") and WCAG 1.0 13.8 ("Place distinguishing information at 
the beginning of headings, paragraphs, lists, etc"):


http://cita.disability.uiuc.edu/html-best-practices/reqs.php

(Note because W3C has changed what http://www.w3.org/TR/WCAG/ points to, 
all their reference URLs are broken.)


So here TITLE is being used to distinguish the page with its page title 
and the site with its site title, and H1 is being used to structure the 
page under that page title.


If you have good reason to believe this would harm your users, don't do it!

For my part, I think this particular piece of advice is generally 
sensible from a usability perspective.



Though from the SEO point of view, this 'advice' makes sense.


Although it's not terrible from an SEO point of view, it's not 
necessarily optimal either.



This also makes me wonder how reliable those accessibility validators
are because I get different results from Cynthia Says and Total
Validators-these are the two I frequently use.


Those are likely using completely different rulesets again, so you have 
every reason to expect them to be different. They are as reliable as 
their rulesets.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] NCFH Site Check and CSS Issues

[Benjamin Hawkes-Lewis]

On 27/12/08 17:36, Chris Kennon wrote:


(3) The use of a background-image for the logo with the text
positioned off-screen means that if the user enforces their own colors
for increased legibility, the header _and its text_ will likely be
invisible.


What image replacement techniques do you suggest to compensate for this
issue?


Since all the widely CSS image replacement hacks I've seen are broken in 
this regard, I suggest using IMG with ALT as the least bad option until 
CSS3 content:url() image replacement is implemented in browsers 
additional to the (uncommonly used) Opera and Safari.


http://www.w3.org/TR/css3-content/

http://www.css3.info/image-replacement-in-css3/

--
Benjamin Hawkes-Lewis


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

Re: [WSG] NCFH Site Check and CSS Issues

[Benjamin Hawkes-Lewis]

On 22/12/08 20:55, Chris Kennon wrote:

Here a screen capture of the desired site layout and navigation styles:
<http://working.bushidodeep.com/dwd/ncfh/02/desired.png>

The drop downs appear above a flash element. And some reports of the
background color not
appearing Firefox have been reported. Would the list review the site,
offering CSS suggestions as needed?

<http://working.bushidodeep.com/dwd/ncfh/02/ncfh_template.html>


Like Henrik, I'm curious as to why a Flash object is being used, not a 
background image.


I suspect the drop downs aren't appearing above the Flash properly 
because its wmode is set to transparent not opaque.


http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_15523

A few other issues:

(1) What's your plan for keyboard accessibility of the navigation (or 
the items the navigation leads to)? At the moment, as I tab through the 
page, for large swathes of the tab order there is almost no visible focus.


http://www.w3.org/TR/WCAG20/#navigation-mechanisms-focus-visible

http://www.w3.org/TR/WCAG20/#keyboard-operation

Make sure there's a visible focus ring.

(2) In your CSS, ul#mainNav a sets a height in pixels for an anchor. 
This is highly unrealistic in a medium where you don't have good control 
over the font size. It causes the navigation items to overlap with font 
size increased merely two steps in Firefox.


(3) The use of a background-image for the logo with the text positioned 
off-screen means that if the user enforces their own colors for 
increased legibility, the header _and its text_ will likely be invisible.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] PopDown Menu NCFH

[Benjamin Hawkes-Lewis]

Chris Kennon wrote:
It's been a while, but given the season, not only could I use the wisdom 
of the list, but the subject matter of the project begs a collaborative 
effort. The National Center on Family Homeless redesign requires 
drop-down menus, of which I'm not a fan, but are required. Would those 
experienced with Pure CSS Drop-Downs assist my effort?


Why does the design require "Pure CSS" drop downs? Is there a plan for 
keyboard accessibility here?


Note the famous "Pure CSS" dropdowns tend to require JS anyway in IE6 to 
fake :hover support.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Dropmenu accessibility and layout problem IE6

[Benjamin Hawkes-Lewis]

Al Sparber wrote:

Having a hierarchical menu operate via the keyboard is, in my opinion, 
not the most accessible approach. This simple example page might provide 
some insight into how to apprach the accessibility of a dropdown or 
flyout menu:


http://www.projectseven.com/products/menusystems/pmm2/ug-examples/accessible/ 


Multiple hubpages reached are an excellent fallback for the non-JS 
state, and I'd agree that using multiple hubs is a reasonable 
keyboard-accessible alternative for dropdowns, particular as opposed to 
having lots of options in the tab order. However:


   * Opening submenus by activating a button-type control (e.g. 
pressing enter) avoids the need for excess tabbing. (Assuming your 
submenu links aren't tabbable when submenus are closed.)
   * I'm a bit uncomfortable with indicating to the keyboard user that 
a menu will dropdown with an arrow (as in your example), but sending 
them to another page instead. A possible enhancement might be making the 
arrow appear on mouse hover only?


On the whole, I favour multiple hubpages over dropdown menus as a 
navigation pattern for typical content-driven websites as opposed to web 
applications - they keep options simple and visible.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] the Name attribute

[Benjamin Hawkes-Lewis]

Joe Ortenzi wrote:

standards compliance should not be confused with WCAG conformance.

HTML is a standard WCAG is a guidance that people use as if it were a 
"standard", which could easily be a standard but is effectively not one. 
However, complying with WCAG confers added benefits which standards 
compliance creators strive for.


"Standard" is a pretty fuzzy word. Might be worth clarifying what 
definition of "standard" you are applying here.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] HTML/XHTML/XML - Question about the future of.

[Benjamin Hawkes-Lewis]

Kepler Gelotte wrote:
There is also another reason to use XHTML instead of HTML and it does 
not involve browsers. When representing your code (xHTML) as XML, it can 
also be viewed as data. A perfect example of this is screen scrapers 
which read your web pages to pull specific content out of them.


Any practical instance of which, in practice, has to deal not only with 
tag soup HTML but also malformed XML, which rather undermines this point.


--
Benjamin Hawkes-Lewis


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

Re: [WSG] HTML/XHTML/XML - Question about the future of.

[Benjamin Hawkes-Lewis]

David Hucklesby wrote:


The validator still needs a DTD though.


If you mean the W3C validator, then no, it just got experimental HTML5 
support.


--
Benjamin Hawkes-Lewis


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

Replacing a paragraph with JS [was: Re: [WSG] JavaScript clarification please]

[Benjamin Hawkes-Lewis]

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Progressive enhancement example</title>
</head>
<body>
<!-- This raw markup should provide core content and functionality. -->
<p id="text">Text without JavaScript.</p>

<!-- Rest of the raw document goes here. -->


</pre><tt><!-- All script put at end of document to ensure everything has been 
</tt><tt>parsed into the DOM and to maximize performance:
</tt><pre style="margin: 0em;">

* <a  rel="nofollow" href="http://peter.michaux.ca/article/553">http://peter.michaux.ca/article/553</a>

* <a  rel="nofollow" href="http://developer.yahoo.com/performance/rules.html#js_bottom">http://developer.yahoo.com/performance/rules.html#js_bottom</a>

-->

<script type="text/javascript">
<!--
// Wrap everything in an anonymous function to prevent pollution of the
// global context:
(function() {

// Keep string definitions, which we might want to localize or modify,
// separate from the presentational logic:
//
// <a  rel="nofollow" href="http://en.wikipedia.org/wiki/Separation_of_concerns">http://en.wikipedia.org/wiki/Separation_of_concerns</a>
//
var strings = {
'newText':'Text with JavaScript.'
};

// Check interfaces exist before trying to use them.
// Yes, the level of checking here is a little bit paranoid.
if (typeof this.window !== 'undefined' &&
typeof this.window.document !== 'undefined' &&
typeof this.window.document.getElementById !== 'undefined' ) {

// Get a reference to the P HTMLElement instance:
var p = this.window.document.getElementById('text');

// Internet Explorer does not support the standard textContent
// feature of the HTMLElement interface:
//
// <a  rel="nofollow" href="http://developer.mozilla.org/En/DOM/Element.textContent">http://developer.mozilla.org/En/DOM/Element.textContent</a>
//
// But it does implement a similar non-standard property, innerText:
//
// <a  rel="nofollow" href="http://msdn.microsoft.com/en-us/library/ms533899">http://msdn.microsoft.com/en-us/library/ms533899</a>(VS.85).aspx
//
// We can use typeof to detect which property is defined, if any:
if (typeof p.textContent !== 'undefined') {
p.textContent = strings.newText;
}
else if (typeof p.innerText !== 'undefined') {
p.innerText = strings.newText;
}

}

})();
//-->




Hope that helps.
--
Benjamin Hawkes-Lewis



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

Re: [WSG] JavaScript clarification please

[Benjamin Hawkes-Lewis]

Christian Snodgrass wrote:
I second that. They actually have a LOT more bad information than they 
do good information, and what little good information they have is often 
quite out of date (so, it was good information, but not anymore).


And when they _do_ add new information, they get that wrong too:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/016157.html

--
Benjamin Hawkes-Lewis


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

Re: [WSG] re: Semantic use of rel and rev in anchors

[Benjamin Hawkes-Lewis]

Susan Grossman wrote:


Since there are no "standard" values for rel


http://www.w3.org/TR/REC-html40/types.html#h-6.12 are the standard link 
types for REL and REV. They are open to use with other values, as 
specified by a scheme specified by a PROFILE link on HEAD (not that 
PROFILE has seen much adoption).


--
Benjamin Hawkes-Lewis


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

Re: [WSG] Flash replace Javascript in Future?

[Benjamin Hawkes-Lewis]

Webb, KerryA wrote:

Johan Douma wrote:


Flash is on 99.9% of the computers.


Which is the sort of claim made often by Adobe.

But, if we're talking about a recent version of Flash on 99.9% of
computers, that's a different matter.


I think that's somewhat unfair. Adobe go out of their way to provide a 
breakdown of the headline figure:


http://www.adobe.com/products/player_census/flashplayer/

http://www.adobe.com/products/player_census/flashplayer/version_penetration.html

(Also it's 99% not 99.9% - by Adobe's own figures 1 in 100 people don't 
have Flash, which is a not insignificant number if you're talking about, 
say, boosting sales from a website.)


--
Benjamin Hawkes-Lewis


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

Re: [WSG] labels as input wrappers + in place of legend

[Benjamin Hawkes-Lewis]

Stuart Foulstone wrote:

Actually, the label tag wrapped around form input is the "old traditional"
method.

The "for" attribute method was introduced later to allow designers greater
flexibility in positioning/styling forms whilst maintaining accessibility.


Really? As far as I can tell looking at the historical record, Internet 
Explorer 4.0 and HTML 4.0 introduced the LABEL element, including the 
FOR attribute, IE didn't support implicit association until version 7.0, 
and the old tutorials tended to teach it the FOR attribute, so I'm not 
sure what tradition you're referring to.


http://www.w3.org/TR/1998/REC-html40-19980424/appendix/changes.html#h-A.1.1.1

http://www.w3.org/TR/1998/REC-html40-19980424/interact/forms.html#h-17.9.1

http://www.sxlist.com/TECHREF/language/html/ib/Forms/label.htm

http://www.insidedhtml.com/tips/elements/ts17/page1.asp

http://www.cs.tut.fi/~jkorpela/forms/kbd.html

--
Benjamin Hawkes-Lewis

--
Benjamin Hawkes-Lewis



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

Re: [WSG] Flash replace Javascript in Future?

[Benjamin Hawkes-Lewis]

Charles Ling wrote:
I would like to get some opinion from you all, that would Flash 10 or ++ 
will replace JavaScript in the future?
According to this blog : 
http://ajaxian.com/archives/flash-10-and-the-bad-news-for-javascript-interaction.


I'm not entirely sure Christian's right that Flash 10 Security breaks 
all JS-triggering of Flash functionality rather than just preventing it 
triggering the File dialog. (Given how important this is for 
accessibility, I rather hope not!)


I found that alot of media website started to replace Javascript to play 
their audio/video and of course Flash required to be install as third

party plugin and had to be updated (which is annoying).


Alternative possibility: over the next decade (the lifetime of a typical 
IE version), this use-case for Flash will disappear, except as fallback 
for native HTML video and audio elements:


http://www.whatwg.org/specs/web-apps/current-work/#video

http://www.whatwg.org/specs/web-apps/current-work/#audio

--
Benjamin Hawkes-Lewis


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

Re: [WSG] labels as input wrappers + in place of legend

[Benjamin Hawkes-Lewis]

Johan Douma wrote:
I've always used label arount input fields text: type="text" /> without the for="" attribute.
I've never had problems with it, and I don't think I've ever seen any 
recommendation against it.


There's a discussion about some problems with that pattern at:

http://www.w3.org/TR/WCAG20-TECHS/H44.html

and

http://green-beast.com/blog/?p=254

I'd suggest just using:

Label text: id="field-id" name="field-key" type="text">


(substituting whatever you feel most appropriate for DIV)

--
Benjamin Hawkes-Lewis


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

Re: [WSG] Colour accessibility/ usability

[Benjamin White]

On 5/6/08, Linda Simpson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I would just like to thank all those who have shared their
> experiences.  There has been some very interesting feedback that has
> been mentioned and we are hoping to conduct a few tests and see how
> users feel with the colour scheme.  I've used the colour contrast
> analyser before, and it does help a lot (although it does say and red
> and white are acceptable - but that's where automated tools can
> sometimes cause false positives).
>

One more thing to consider: a fairly significant portion of the
world's population cannot easily distinguish red from black in a run
of text, meaning that links ought not to be only reddened but marked
in some other manner.



(Tip of the hat to Dean Allen )


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

Re: [WSG] Image links

[Benjamin White]

Y'all are missing a very important point: images will never, ever have
an underline if you set text-decoration: underline.

Actually, I take that back. There is only one instance in which an
image might have a true underline. In the very unlikely event that
someone produces a bit of code that looks like this:

Some text 

You will end up with an underline running from "Some" to the end of
the image. This is, of course, assuming you haven't monkeyed with the
basic link styles already.

Now, some browsers will put a border on an image link. Firefox does.
Safari doesn't. I'll bet a few more do or don't. By default it'll have
a width of 2px (in Firefox anyway). So the only thing you have to
worry about in terms of default styles on image links is the border.

Unless you've added a border to anchors. Maybe you wanted a different
color than the text. Maybe you wanted a nifty dotted or dashed border.
Now you have a border applied to the link itself rather than the image
and there's very little you can do to get rid of it without adding
extra markup.

The number of folks who have commented that img a doesn't make a bit
of sense are absolutely correct. The only correct way to touch this
image by css is a img, but that only targets the image itself, which
means all you can do is muck about the the border on the image—the
border that may or may not show up in your browser in the first place.

So, I suspect Dean has a style that looks something like a {
border-bottom: 1px solid #000; } and he doesn't want that on his
images.

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

Re: [WSG] Image links

[Benjamin White]

On 5/1/08, Dean Matthews <[EMAIL PROTECTED]> wrote:
> When you set up an anchor rule that has an underline on hover meant for
> text, is there a simple way to prevent the underline on image links in the
> same ID or do you have to set up a separate class with anchor rules?

By "underline" do you mean the underline text-decoration or a bottom
border? If it's the former, it isn't really an issue. Browsers
won't—as far as I know—add an underline or border to image links even
if you've declared it to be there on hover. The trick is you want to
change the styles on the image inside the anchor instead of the anchor
itself. Like so:

a img {
border: 0;
}

Or what have you.

If you're adding a border-bottom to links and you don't want it to
show up on images you have a wholly different problem. In this case
the border is being applied to the link that just so happens to have
an image inside of it. It won't put an underline, because that
underline is a text decoration and there ain't no text in the link.
There's no CSS selector to target something that has a child.

The way I see it you have a few options:

1.) Apply a class to every anchor with an image.
2.) Make sure all of your images are inside another element with a
class or id and then target the links inside of it.
3.) Use JavaScript to crawl through the document looking for links
that meet an if loop.
4.) Scrap the whole idea of a bottom border on links and use the underline.

I tend to choose option 4.

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

RE: [WSG] hand coding versus code generators

[Benjamin]

I started off in Dreamweaver 3 but quickly moved into handcoding found it
far better and easier to manipulate pages than with a GUI editor.

I cant go back to Dreamweaver, its slow its clunky and just doesn't cut it
like homesite 5+ does.


Benjamin

Life through a Polaroid
www.lifethroughapolaroid.com


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

RE: [WSG] What Editors do you guys use?

[Benjamin]

Homesite 5.5



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

[WSG] [wsg] position: absolute on the mac not displaying images

[Benjamin]

I have 2 images used for a bar graph where one over laps the other.
however on ie5.1 mac its not displaying the images when the css tells
the images to position absolutely.

anyone got any ideas?

thanks


Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] IE. Stopping a table from stretching past the containing div

[Benjamin]

thanks Phillipe

I solved the problem as you suggested 

I put a div around it called it tableContain

#tableContain{width: 100%}

works like a charm

> 
> On May 25, 2004, at 9:14 am, Benjamin wrote:
> 
> > got a problem with tables stretching past my globalWrap div in ie5.0,
> > 5.5, & 6.0 when they are set to 100%
> 
> IE win is unable to correctly calculate % width tables IF the direct 
> parent container doesn't have a dimension (width or height) specified.
> Wrap a div around your table, and style that div with: {height:1%} 
> (seems the most foolproof method, width:100% can give problems when 
> float is involved in the surroundings.). Hide all that from more decent 
> browsers.
> 
> Philippe
> ---/---
> Philippe Wittenbergh
> now live : <http://emps.l-c-n.com/>
> code | design | web projects : <http://www.l-c-n.com/>
> IE5 Mac bugs and oddities : <http://www.l-c-n.com/IE5tests/>
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] IE. Stopping a table from stretching past the containing div

[Benjamin]

the containing div has a width of 100%
but ie doesnt want to adhere to this 

> 
> On May 25, 2004, at 9:14 am, Benjamin wrote:
> 
> > got a problem with tables stretching past my globalWrap div in ie5.0,
> > 5.5, & 6.0 when they are set to 100%
> 
> IE win is unable to correctly calculate % width tables IF the direct 
> parent container doesn't have a dimension (width or height) specified.
> Wrap a div around your table, and style that div with: {height:1%} 
> (seems the most foolproof method, width:100% can give problems when 
> float is involved in the surroundings.). Hide all that from more decent 
> browsers.
> 
> Philippe
> ---/---
> Philippe Wittenbergh
> now live : <http://emps.l-c-n.com/>
> code | design | web projects : <http://www.l-c-n.com/>
> IE5 Mac bugs and oddities : <http://www.l-c-n.com/IE5tests/>
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

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

[WSG] IE. Stopping a table from stretching past the containing div

[Benjamin]

Hey all,

got a problem with tables stretching past my globalWrap div in ie5.0,
5.5, & 6.0 when they are set to 100%

works fine in firefox pc&mac, ie5.1+5.2 mac safari, ns6.2+ on pc and mac

anyone know how to fix this?

thanks

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] Clear Styles?

[Benjamin]

You could give the div a id of say #preview
*{ } and use that and it should attribute the styles you  define in
preview to everything in the div

 









From: Chris Stratford [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 22, 2004 11:34
AM
To: Web Standards Group
Subject: [WSG] Clear Styles?



 


I dont know, but is there a way to hide all styles from a 

what I have is - an admin page, where the owner can enter text into a

And click PREVIEW
and it will load it into a DIV below the TEXTAREA.

I dont want any of the styles to "cascade" down into this area...

Is there anyway to stop that from happening?

I think i explined it very "crappily" and i hope you understand what
I am after...






*
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] [WSG} Height Issue with two column layout

[Benjamin]

easy

put a globalWrap around your sideNav & mainContent divs

create a 1px high background image of your sideNav blue but make sure
its the width of your sidenav then in the css put

#globalWrap{background: url(images/bg_sideNav.gif) repeat-y left}

problem solved


Ben

> Hi Guys ..
> 
> I have the following page http://204.157.1.128/~wadigi/temp2.html with a 
> two column layout however i cant seem to make the sidebar div run 
> 100%  any help would be great !!!
> 
> Regards
> Simon
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> ***** 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] please help

[Benjamin]

have you tried using a clearing div

#cDiv{
   clear: left;
}



put this below your mast div

> 
> Hi Russ,
> At your recommendation i made my layout simple.
> It now works in ie4 and up. Thank you very much.
> However the image in the div "mast" dosnt show up in netscape,  can
you tell 
> me why?
> I've encluded most of the style sheet in this email.
> Nearly there.
> -Kevin
> 
> 
> 
> 
> 
> 
> 
> BODY {
> marging: 0 0;
>   background: #f4f2ea url(rightback.jpg)  repeat-x top left;
>   font-family: verdana, geneva, arial;
>   text-decoration:none;
>   font-size:90%;
>   height: 433px;
>   text-align:left;
> 
> p {
> width: 300px;
> background-color: #e8e8e8;
> text-align: left;
> font-family: verdana, geneva, arial;
> font-size:90%;
> color: #00;
> line-height: 1.3em;}
> 
> 
> #mast {
> position: absolute;
> margin: 0;
> left: 5%;
> top: 0px;
> width: 630px;
> height: 400;
> background: url(id.jpg) no-repeat top left;
> background-color: #cfd8e0;
> }
> 
> #left {
> position: absolute;
> top: 0px;
> left: 0px;
> width: 6%;
> height: 500;
> background: url(leftback.jpg) repeat-x top left;
> }
> 
> _
> Check out the coupons and bargains on MSN Offers!
http://youroffers.msn.com
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] Removing bullets

[Benjamin]

#menu ul{
   list-style: none none;
}

> Hi guys ,,
> 
> I have contructed this navigation bar --> 
> http://simondodson.com/nav2.html and im having trouble removing the 
> bullet points from the list ...
> 
> any help would be great !!!.
> 
> Cheers
> Simon Dodson
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] XML Includes?

[Benjamin]

wouldnt you need to use the xml doctype if your using xml ?
or the xml prologue as its called.?



> Heyas,
> 
> Still finding my feet with XHTML / CSS. I noticed that in Mozilla (well 
> through Eric Meyers new book) you can introduce your own tags (ie XML) 
> and basically in many ways can attach CSS to them (much like you would 
> with a simple old DIV)
> 
> In Internet Explorer this isn't the case? it ignores the tags / css?
> 
> eg:
> 
> 
> mycontent
> mycontent
> 
> 
> 
> window {
> display:block;
> left: 200px;
> top: 200px;
> width: 200px;
> height: 200px;
> border: 1px solid red;
> background-color: yellow;
> }
> 
> 
> Simple example, works great in Mozilla FireFox (heh go Mozilla) but 
> fails in IE? I'm using the doctype:
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> 
> with:
> http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US">
> 
> Anyone care to comment?
> 
> -- 
> 
> Regards,
> Scott Barnes
> -
> http://www.mossyblog.com
> http://www.bestrates.com.au
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] XML Includes?

[Benjamin]

wouldnt you need to use the xml doctype if your using xml ?
or the xml prologue as its called.?



> Heyas,
> 
> Still finding my feet with XHTML / CSS. I noticed that in Mozilla (well 
> through Eric Meyers new book) you can introduce your own tags (ie XML) 
> and basically in many ways can attach CSS to them (much like you would 
> with a simple old DIV)
> 
> In Internet Explorer this isn't the case? it ignores the tags / css?
> 
> eg:
> 
> 
> mycontent
> mycontent
> 
> 
> 
> window {
> display:block;
> left: 200px;
> top: 200px;
> width: 200px;
> height: 200px;
> border: 1px solid red;
> background-color: yellow;
> }
> 
> 
> Simple example, works great in Mozilla FireFox (heh go Mozilla) but 
> fails in IE? I'm using the doctype:
>  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
> 
> with:
> http://www.w3.org/1999/xhtml"; lang="en-US" xml:lang="en-US">
> 
> Anyone care to comment?
> 
> -- 
> 
> Regards,
> Scott Barnes
> -
> http://www.mossyblog.com
> http://www.bestrates.com.au
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] IE no padding?

[Benjamin]

p

{
voice-family:"\"}\""; voice-family:inherit;
margin: 0px;

}

voiceHack{}


copy that instead of what you have in there

older IE's dont read padding to well

or alternatively you could just remove your margin tag out of your p class

> 
> 
> 
>   
>   
> 
> 
> Hey WSG...
> 
> This STUPID bug with IE...
> why dont I see any padding for the content here:
> 
> http://www.vipclubs.net";>www.vipclubs.net
> 
> i have padding on the content...
> 
> 10px!
> 
> not showing at all...
> 
> any hacks/fixes?
> 
> 
> 
> 
> IE is really starting to *#$! me hard!
> If IE were a man, I would shoot him twice in the leg...
> -- 
> Chris Stratford
> mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
> Http://www.neester.com";>Http://www.neester.com
> 
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] Browser testing across Windows OS's

[Benjamin]

heya Miles,

at work I have 2 computers infront of me.

I have a pc which I do all of my interface development on.

I also have ie5, 5.5 and 6 installed and running side by side, with
ns6.2 open. the browser that I develop in is firefox. 99% of the time if
it works in firefox it works right across the board. Keep in mind though
to do this you have to know each browsers little quirks when you render
the page.

the other computer I have is a g4 with safari, ns7, ie5.1, ie5.2, and
firefox for osx.

like I said before develop in firefox and you will pretty much get it
looking as it should be across the range of browsers.

I dont develop for konqeror (sp) or opera unless the clients
specifically ask for it. having said that safari is based on konqeror (sp)

jsut to test whether running all ie's side by side on the pc were
working as they should be I had 98 and 2000 boxen set up and there were
no differences I could see.

happy browser testing

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com

> hmm, nobody wants to help or give away their secret strategies?  or
nobody does browser testing?   Or do I smell?
> 
> Mt.
> 
> > -Original Message-
> > From: Miles Tillinger 
> > Sent: Friday, April 16, 2004 4:42 PM
> > To: Web Standards Group (E-mail)
> > Subject: [WSG] Browser testing across Windows OS's
> > 
> > 
> > Hi all,
> > 
> > I'm working on improving the site testing procedures here at 
> > work.  I'm trying to gauge the need to test browsers on the 
> > different Windows (and other) OS's.   I'm using the 
> > standalone IE's under Windows XP and I'm wondering if the 
> > IE5.5 standalone is behaving exactly the same as an 
> > integrated IE5.5 installation on Windows 2000, ME or 98(SE)?  
> > E.g. Are there any HTML, Javascript or CSS bugs that are 
> > present in IE5.5 Win2k, but not IE5.5 WinXP?  Same question 
> > for Netscape, Mozilla and other browsers.  Are they mostly 
> > identical across the various OS's they support?
> > 
> > Evolt.org's testing chart only includes Windows, not the 
> > individual versions 
> > (http://evolt.org/article/Browser_testing_list/20/548/index.ht
> ml looks rather old).  Nor does it talk about different versions of
MacOS.  Do WSG members consider this sufficient testing strategy?  I
understand this is probably going to be very different from one
organisation to another but there has to be a baseline at least!
> 
> I'm keen to hear some opinions and get some good resources on this to
hopefully get an idea of how far I need to take our testing strategy.
> 
> Thanks in advance,
> 
> Miles.
> *
> 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
> *
> 
> 
> 

*
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] theage.com.au: new design

[Benjamin]

the age looks really good

its a lot easier to read than smh.com.au

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com

> 
> 
> 
>   
>   
> 
> 
> Hey Peter,
> 
> I dont know if its your intention, but some pages i loaded wern't
> centered...
> Like articles etc...
> 
> A comment on your stats the resolution -   class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">1400x1050 
>
  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">I am
> running this resolution, I didnt realise that many people actually had
> it...
> 
> Its a laptop resolution - as far as i know its only laptops...
> 
> nice work!
> 
> damn it must be a lot of work - working for a news website!
> so many users, so many computers, so many different OS/Browsers and
> other little issues...
> 
> Chris Stratford
> mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
> Http://www.neester.com";>Http://www.neester.com
> 
> 
> Peter Ottery wrote:
> 
>   
>   
>   hiya,
>   we
> relaunched theage.com.au today with improved markup and a
css layout.
>
href="http://theage.com.au/";>http://theage.com.au/
>    
>   a
> couple of points of interest:
>   
> a
> big part of the redesign was improving the markup - ie:
obviously using
> <h> tags and <ul> tags etc. still have a ways to go and
> it'll be a learning process for the many editors etc that maintain the
> site (which is why you may come across some irregularities in parts of
> the site).   class="312014522-19042004">the pages pass thru s many sets of
> hands to make it to the live site (so be gentle :) eg: - information
> architects -> design (me) -> CMS/tech guys ->
editors
> the
> layout is centred and fixed width - mainly for editorial
> reasons/requests for tighter control over positioning and relationships
> between elements on the page (eg: pictures relating to headlines). the
> default css is for a layout that fits at 800 wide, then a script
> detects if you are browsing at 1024 wide or higher and loads a 1024
> css layout (which just overrides some of the width values etc). this
> was to satisfy the need for tight control over the layout but to also
> try to optimise the layout for the ever growing 1024+ audience (stats
> below).
>   
>   some
> interesting stats:
>   
>   
> in
> the last month theage.com.au has had   class="312014522-19042004">1,718,644
> unique visitors
> browser
> stats for the last month
> 
>   IE6
> - 73%

> class="312014522-19042004">IE 5.5 -   class="312014522-19042004">9% 
> class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">IE 5.5 -   class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">9%

> class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">IE 5.0X -
  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">7%

> class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">Mozilla -
  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">1%

> class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">Firebird -
>   class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">1%

> class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">Safari
-   class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004">  class="312014522-19042004&quo

RE: [WSG] Making Dreamweaver's Rollover JS accessible

[Benjamin]

Heya Jaime,

define multi rollovers?

Benjamin

> 
> 
> Hi Benjamin
> 
> What is ecma?
> 
> Can what you proposed be used for multi-rollovers? 
> 
> I could use Meyer's
http://www.meyerweb.com/eric/css/edge/popups/demo2.html
> but not sure if it is stable enough for projects.
> 
> 
>  
> With Regards
> Jaime Wong
> ~~
> SODesires Design Team
> http://www.sodesires.com
> ~~
>  
> ---Original Message---
>  
> From: [EMAIL PROTECTED]
> Date: 04/18/04 22:07:19
> To: [EMAIL PROTECTED]
> Subject: RE: [WSG] Making Dreamweaver's Rollover JS accessible
>  
> The only way I can think of doing it off the top of my head is to use some
> ecma and css
>  
> onfocus="this.className="onState"
>  
> onblur="this.className="offState"
>  
>  
> ..onState{
> background: url(yourimageslocation/btn_onState.gif) no-repeat top left
> }
>  
> ..offState{
> background: url(yourimageslocation/btn_offState.gif) no-repeat top left
> }
>  
> and change the background image
>  
> -Original Message-
> From: Jaime Wong [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 18, 2004 8:59 PM
> To: WSG - CSS List
> Subject: [WSG] Making Dreamweaver's Rollover JS accessible
>  
>  
> Dreamweaver' common set of JS for rollover images are using
'onmouseover' i
> e. MM_swapImage JS.
>  
> I wanted to make it more accessible by using 'onfocus=' but I do not know
> how to work around it so that the JS will work.
>  
> Does anyone know where I could get some resources on this?
>  
>  
> With Regards
> Jaime Wong
> ~~
> SODesires Design Team
> http://www.sodesires.com
> ~~
>  
>  
> *
> 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
> *
> .
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] Making Dreamweaver's Rollover JS accessible

[Benjamin]

The only way I can think of doing it off the top of my head is to use some
ecma and css

onfocus="this.className="onState"

onblur="this.className="offState"


.onState{
background: url(yourimageslocation/btn_onState.gif) no-repeat top left
}

.offState{
background: url(yourimageslocation/btn_offState.gif) no-repeat top left
}

and change the background image

-Original Message-
From: Jaime Wong [mailto:[EMAIL PROTECTED] 
Sent: Sunday, April 18, 2004 8:59 PM
To: WSG - CSS List
Subject: [WSG] Making Dreamweaver's Rollover JS accessible

 
Dreamweaver' common set of JS for rollover images are using 'onmouseover' i
e. MM_swapImage JS.

I wanted to make it more accessible by using 'onfocus=' but I do not know
how to work around it so that the JS will work.

Does anyone know where I could get some resources on this? 


With Regards
Jaime Wong
~~
SODesires Design Team
http://www.sodesires.com
~~
 

*
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] Yarr, I think IE hates me :(

[Benjamin]

dont worry IE hates everyone 

you just have to show it whos boss 

have a look at this with your background issue

http://www.alistapart.com/articles/fauxcolumns/

you might need to have a wrapping div and put a background within that

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com


> I am having major issues with this layout. I've been working on it for a
> long time and it's just not cooperating in IE. The basic layout was lifted
> from MaxDesign's 2-column liquid layout
> (http://css.maxdesign.com.au/floatutorial/).
> 
> http://readordie.org/test/
> 
> It works like a dream in Firebird, but in IE, the menu on the left is
> causing a big gap in the content area. The more you add to the menu, the
> bigger the gap. I don't know what's causing it. In addition, in IE there
> is some kind of error on line 18, character 9, which is  class="upgrade">.
> 
> Also, for pages where the content is short, such as
> http://readordie.org/test/index.php?page=updates , how do I fix it so that
> the content's background color and left pink border extends down to the
> footer (where the copyright is)? I used to use min-height and set a really
> large number, such as 1200px, but I'm writing articles for my fansite that
> might be exceeding 1200px.
> 
> If anyone can help, I would appreciate it! :D
> 
> - Sarah
> 
> -- 
> Read or Die
> http://www.readordie.org/
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 


*
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] This sounds really silly BUT

[Benjamin]

try doing it like

Some text

if you dont want the text in the anchor tag to become a link
are you doing something in coldfusion that pumps out this anchor tag?

check your links make sure they are both on the same page 
make sure they arent missing a " or a >

make sure you your using the correct doc type

also depends how your doing the link
the only way that I could see that it would move to the root of the
folder would be if you told it to do 


Benjamin
Life through a polaroid

www.lifethroughapolaroid.com

> I am inserting what I think is a plane old link like this
> 
> Item 1
> 
> Some Text
> 
> I am doing this with Coldfusion on the server but that would be
irrelative I
> would have thought? when you click the link it moves the page to the
root of
> the folder rather than the URL I am currently on?
> 
> Its driving me mad! to seems so small and silly, i've done these thousands
> of times before but this time its not having it!
> 
> Any one care to speculate why?
> 
> GC
> 
> *
> 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] CENTERING SITE & WRAPPER PROBLEMS.

[Benjamin]

put 

margin-left: auto;
margin-right: auto; 

in your global wrapping div

or on the table class your using

alternatively you could set your body tag to a width of 760px and do the
same

> This is a multi-part message in MIME format.
> 
> 
> Hi all...
> I have a couple of problems here that i dont seem to be able to nut
out, any help would be greatly appreciated if there is anyone around on
the day before the easter break.
> 
> Firstly the site centers just fine in ie but is aligned left in
firefox...why is this so?
> 
> Secondly and more confusing, I have the site contained in a wrapper
but in firefox the wrapper doesnt wrap, it doesnt seem to contain any of
the elements that I have put in there. (if you look in firefox the
wrapper is the little white bit at the top that is supposed to fill the
whole site) Looks fine in ie again. 
> 
> If i display it as  table-cell; it seems to work but thats not widely
supported is it?
> 
> 
> 
> site: http://www.mockorange.com.au/mocksites/test/jugernaut/index.html
> css:
http://www.mockorange.com.au/mocksites/test/jugernaut/css/juganaut.css
> 
> 
> Jackie Reid
> Mock Orange Web Site Development
> 1st Floor
> 92 Victoria Street
> MACKAY Q 4740
> Ph: 07 4953 4035
> 
> [EMAIL PROTECTED]
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] Footer on the very bottom of the viewing port

[Benjamin]

http://www.alistapart.com/articles/footers/

that should have what you need

> I want to have a footer stuck to the bottom of the browser window, but if
> the window reduces in size, the footer goes over the top of other page
> content. What I'd like to do is have the footer stick to the
bottom
> of the browser, except if it collides with other page content, which
> will push it down below the bottom of the viewing port and have a vertical
> scroll bar appear.Is this possible with CSS?  I know it's
done
> with tables, because that's how this site is now, but I want to
get rid
> of these tables.CheersMike KearAFP Webworks, Windsor,
> NSW, Australia.
> 
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> ***** 
> 
> 
> 

Benjamin
Life through a polaroid

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

Re: [WSG] Re: List Left Margin

[Benjamin]

I understand nothing of your sentance

> Comrades
> 
> You lucky Ozzies!
> 
> The only I get like THAT are from sheep!
> 
> Malarkey
> www.malarkey.co.uk
> www.karova.com
> 
> ***
> 
>  >> Geeze Russ, aren't you married?
> 
> http://www.browsercam.com/projects/56771/930830.jpg
> 
> --
> Cameron Adams
> 
> W: www.themaninblue.com
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> * 
> 
> 
> 

Benjamin
Life through a polaroid

www.lifethroughapolaroid.com
*
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] hiding clear:both ?

[Benjamin]

If your in need of a clearing div what you might want to try is this

  // non breaking space used for older browsers

#cDiv{
clear:  left;
height: 1px;
overflow:   hidden /* used for ie */
}


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of russ weakley
Sent: Friday, April 02, 2004 11:39 PM
To: Web Standards Group
Subject: Re: [WSG] hiding clear:both ?

It is hard to tell without seeing what you are trying to achieve. From a
purists perspective, you should try and apply the clear to the item below,
rather than create a meaningless div.

One way around your problem MAY be to add a rule like:
{
clear: both;
font-size: 1px;
}

This will remove carriage returns in IE6. But, again, this is hard to tell
without seeing where it is used.
Russ



> I hate to ask a dumb question, but I can't find any information about
> this altough I'm pretty sure I've read about this someplace.
> 
> What I'm trying to do is use
> 
>  
> 
> .cl {
> clear:both;
> }
> 
> But the sticky part is that I don't want it to add the extra line
> space.  I'm not sure of the best way to do this.  I believe I need to
> have something inside of the div tags (?) and I've tried messing with
> visibility:hidden but that threw some more unexpected glitches at me
> (well, I was getting two separate lines instead of both on the same
> line).
> 
> Anybody have a good method for doing this?
> 
> Thanks...v
> 
> *
> The discussion list for http://webstandardsgroup.org/
> See http://webstandardsgroup.org/mail/guidelines.cfm
> for some hints on posting to the list & getting help
> *

Thanks
Russ

---
Russ Weakley
Max Design
Phone: (02) 9410 2521
Mobile: 0403 433 980
Email: [EMAIL PROTECTED]
http://www.maxdesign.com.au
---


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