Re: [WSG] Chrome and Safari

2008-10-16 Thread Ben Buchanan
Seeing as though Google's new Chrome browser uses the same rendering engine
 as Apple's Safari, would it be acceptable to test browser layout issues in
 Chrome and assume the same CSS solutions apply in Safari? Does anyone know
 of any distinct differences in CSS rendering between the 2 browsers?

I don't know of any issues now, but as a long term solution I would assume
that the two browsers will get out of synch at some stage in terms of the
specific version of teh rendering engine. Also as other people have noted
the whole browser is more than just the rendering engine; so it's prudent to
test them separately.

cheers,

Ben


-- 
--- http://weblog.200ok.com.au/
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson


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

Re: [WSG] Browser loading images issue

2008-10-16 Thread kate

Working fine first load Kristine in the UK
Winxp:
SP2
1680x1050
IE6
Kate
Forum: http://princess.invisionzone.com/index.php
Borneo: http://simplyborneo.com/borneosnaturaltreasures/


- Original Message - 
From: Kristine Cummins [EMAIL PROTECTED]

To: wsg@webstandardsgroup.org
Sent: Wednesday, October 15, 2008 7:55 PM
Subject: [WSG] Browser loading images issue



Hi all,

I'm still having this issue as the client is contacting about images 
simply

not showing up but on refresh, they do. Frustrating as I don't know how to
solve this issue.

The page is http://www.cpwrehab.com/employee_listing.html
Stylesheet is: http://www.cpwrehab.com/styles.css


Thanks,
Kristine


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kristine Cummins
Sent: Friday, October 10, 2008 11:28 AM
To: wsg@webstandardsgroup.org
Subject: [WSG] Browser loading images issue

I noticed that sometimes some images will not load upon visiting a page
while others on the page will, but when I hit the browser's refresh 
button,
the image will load. This was happening in IE, but no other browser. 
Anyone

have any ideas how to fix this issue?

Thanks,
Kristine



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





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



Re: [WSG] Chrome and Safari

2008-10-16 Thread Johan Douma
Not only JS, there are differences in CSS as well.

Shadows appear, but kinda buggy, not as it should. text-shadow and
box-shadow.
The rounded borders are not antialiased (as in aliased or pixelated) in
Chrome whereas FF3 and Safari handle it correctly.
And font-face doesn't work at all, whereas it does in safari.

I know these properties are not part of css2.1, so it's acceptable, but good
to know. That was a few weeks ago as well. Maybe it's been fixed... I
haven't checked today.

I've heard about problems with png as well, but I haven;t seen any problems
on that side of things.

There are probably other things that are different in Chrome than in Safari.


Cheers,

Johan Douma


2008/10/16 Ben Buchanan [EMAIL PROTECTED]




 Seeing as though Google's new Chrome browser uses the same rendering engine
 as Apple's Safari, would it be acceptable to test browser layout issues in
 Chrome and assume the same CSS solutions apply in Safari? Does anyone know
 of any distinct differences in CSS rendering between the 2 browsers?

 I don't know of any issues now, but as a long term solution I would assume
 that the two browsers will get out of synch at some stage in terms of the
 specific version of teh rendering engine. Also as other people have noted
 the whole browser is more than just the rendering engine; so it's prudent to
 test them separately.

 cheers,

 Ben


 --
 --- http://weblog.200ok.com.au/
 --- The future has arrived; it's just not
 --- evenly distributed. - William Gibson

 ***

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



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

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

2008-10-16 Thread ox4dboy


I am looking for feedback on two questions, based on the simple form snippet 
below. 

fieldset 
legendbPersonal Details/b/legend 
label for=nameName:/label 
input id=name type=text name=name size=30 br 
label for=idID Number:/label 
input id=id type=text name=id number size=10 
/fieldset 

Question 1: 
Is it acceptable, or advisable, to use a header tag h6 in place of the 
legend in order to get cross-browsers consistency when dealing with complex 
form styling? How much impact might this have on accessibility, if any? 

Question 2: 
I don't see many folks using the label as a wrapper to contain the input. Any 
reason not to do this? It allows for the br / to be removed via display: 
block; on the label tag as well as allowing users (of most browsers) to click 
on a much larger label to select the accompanying input. 

fieldset 
h6Personal Details/h6 
label for=nameName: 
input id=name type=text name=name size=30 
/label 
label for=idID Number: 
input id=id type=text name=id number size=10 
/label 
/fieldset 


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

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

2008-10-16 Thread David Dorward
Jason Grant wrote:
 Ok you got both of these quite wrong for following reasons: 

 In the first instance you shouldn't use b or br / at all. 
 In the second instance you should not wrap input into label as the
 label should quite clearly be used for denoting a label of an input
 field and not the input field itself.
Not so:

When [the for attribute is] absent, the label being defined is
associated with the element's contents.


LABEL

   First Name
   INPUT type=text name=firstname
/LABEL


  -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1


-- 
David Dorward
http://dorward.me.uk/



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



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

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




Johan Douma
[EMAIL PROTECTED]


2008/10/16 David Dorward [EMAIL PROTECTED]

 Jason Grant wrote:
  Ok you got both of these quite wrong for following reasons:
 
  In the first instance you shouldn't use b or br / at all.
  In the second instance you should not wrap input into label as the
  label should quite clearly be used for denoting a label of an input
  field and not the input field itself.
 Not so:

 When [the for attribute is] absent, the label being defined is
 associated with the element's contents.

 
 LABEL

   First Name
   INPUT type=text name=firstname
 /LABEL
 

  -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1


 --
 David Dorward
 http://dorward.me.uk/



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




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

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

2008-10-16 Thread Jason Grant
This is the first time for me to see someone proposing use of labelinput
//label structure.I agree that ol is not strictly necessary and that a
form is not necessarily a list, but one could argue that you are dealing
with a list of form input elements.
Read more why I do this here:
http://www.alistapart.com/articles/prettyaccessibleforms
Using a list also gives better control over the look as I never do:
float:left; clear: left; since that proves to cause cross browser issues
more often than not.
Cheers,
Jason

On Thu, Oct 16, 2008 at 1:23 PM, Johan Douma [EMAIL PROTECTED] wrote:

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




 Johan Douma
 [EMAIL PROTECTED]


 2008/10/16 David Dorward [EMAIL PROTECTED]

 Jason Grant wrote:

  Ok you got both of these quite wrong for following reasons:
 
  In the first instance you shouldn't use b or br / at all.
  In the second instance you should not wrap input into label as the
  label should quite clearly be used for denoting a label of an input
  field and not the input field itself.
 Not so:

 When [the for attribute is] absent, the label being defined is
 associated with the element's contents.

 
 LABEL

   First Name
   INPUT type=text name=firstname
 /LABEL
 

  -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1


 --
 David Dorward
 http://dorward.me.uk/



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



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




-- 
Jason Grant BSc, MSc
CEO, Flexewebs Ltd.
www.flexewebs.com
[EMAIL PROTECTED]
+44 (0)7748 591 770
Company no.: 5587469

www.twitter.com/flexewebs
www.linkedin.com/in/flexewebs


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

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

2008-10-16 Thread Tatham Oddie
Johan – what you are describing is the correct usage in that scenario.

 

 

Thanks,

 

Tatham Oddie

 callto:+61414275989 call:+61414275989,  callto:+61280113982 
call:+61280113982,  skype:tathamoddie?call skype:tathamoddie,  msnim:[EMAIL 
PROTECTED] msn:[EMAIL PROTECTED],  http://tatham.oddie.com.au/ 
tatham.oddie.com.au

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Douma
Sent: Thursday, 16 October 2008 11:23 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] labels as input wrappers + h6 in place of legend

 

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




Johan Douma
[EMAIL PROTECTED]



2008/10/16 David Dorward [EMAIL PROTECTED]

Jason Grant wrote:
 Ok you got both of these quite wrong for following reasons:

 In the first instance you shouldn't use b or br / at all.
 In the second instance you should not wrap input into label as the
 label should quite clearly be used for denoting a label of an input
 field and not the input field itself.

Not so:

When [the for attribute is] absent, the label being defined is
associated with the element's contents.


LABEL

  First Name
  INPUT type=text name=firstname
/LABEL


 -- http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1


--
David Dorward
http://dorward.me.uk/




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

 


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



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


[WSG] Flash replace Javascript in Future?

2008-10-16 Thread Charles Ling
Hi Guys/Gals,

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 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). Did you guys/gals
use alot of flash in your past projects that you were working with?

Cheers,
Charles.


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

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

2008-10-16 Thread Benjamin Hawkes-Lewis

Johan Douma wrote:
I've always used label arount input fields labeltext: input 
type=text //label 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:

div class=fieldlabel for=field-idLabel text:/label input 
id=field-id name=field-key type=text/div


(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] Flash replace Javascript in Future?

2008-10-16 Thread Christian Montoya
On Thu, Oct 16, 2008 at 9:27 AM, Charles Ling [EMAIL PROTECTED] wrote:
 Hi Guys/Gals,

 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 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). Did you guys/gals
 use alot of flash in your past projects that you were working with?

I think you misunderstood the article big-time. It's saying that Flash
10 is planned to not support DHTML scripting access, which means you
won't be able to control a flash video via Javascript. That just means
that a lot of interfaces where Flash is *not* currently sufficient
(such as Yahoo Video) or where Flash is used as a workaround to assist
Javascript/HTML (such as batch uploading in Wordpress) will no longer
be possible, at which point people will need to find a way to make
these things work with Javascript alone, or convince Adobe to change
their minds about this.

As for whether or not Javascript is ever going away, try using web
apps like Gmail or Facebook without Javascript and see what you lose.
The reason why Javascript has gained so much traction in the past few
years is because you can do a heck of a lot with it before you have to
load up a third-party plugin.


-- 
--
Christian Montoya
christianmontoya.net


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

2008-10-16 Thread 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] Flash replace Javascript in Future?

2008-10-16 Thread Breton Slivka
Read the story on that page carefully. What has happened is that flash
10 has increased restrictions over what features within the flash
plugin can be invoked via javascript. This only applies to one
specific feature (file uploads), and effects virtually no other flash
features. It does not effect javascript's abilities in general, only
the abilities of javascript to use flash in certain ways. This point
will largely become moot once video/audio/3d/canvas becomes widespread
and built into browsers, and flash as a result becomes less relevant-
Particularly on low powered platforms like the iPhone, and Android
which do not have flash- or the wii which only has an older and
underpowered version of flash.

So in my opinion, to the contrary- This news story is reporting on
decreased ability of the flash plugin to play well with javascript- It
will not make flash replace javascript- Except as a workaround in the
specific case of file uploads.


On Fri, Oct 17, 2008 at 12:27 AM, Charles Ling [EMAIL PROTECTED] wrote:
 Hi Guys/Gals,

 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 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). Did you guys/gals
 use alot of flash in your past projects that you were working with?

 Cheers,
 Charles.

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


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



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

2008-10-16 Thread Svip
2008/10/16 David Dorward [EMAIL PROTECTED]

 Jason Grant wrote:
  Ok you got both of these quite wrong for following reasons:
 
  In the first instance you shouldn't use b or br / at all.
  In the second instance you should not wrap input into label as the
  label should quite clearly be used for denoting a label of an input
  field and not the input field itself.
 Not so:

 When [the for attribute is] absent, the label being defined is
 associated with the element's contents.


Which it isn't in the original example provided, the *for* attribute is
provided.

In addition, there is no need to use the li elements around the input
elements, as you can use the display: option in CSS to make them appear like
a list, which is probably what you want, and not going through the hassle of
adding the list HTML elements.  Since it is technically not a list.

My suggestion would be something to the content of:

fieldset
  *legend //h6 /
  *label for=name
  input type=text id=name /
  *etc...
*/fieldset

CSS:

label, input {
  float: left;
  clear: left;
}

Or, alternatively;

label, input {
  display: list-element;
}

Or just mess around with it.  Dude...

Also, no one has yet to answer the original question.  And my suggestion is
no, because legend can easily be configured via CSS to look and appear
exactly as h6.  So there.

/Svip


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

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

2008-10-16 Thread Jason Grant
Ok you got both of these quite wrong for following reasons:
In the first instance you shouldn't use b or br / at all.
In the second instance you should not wrap input into label as the
label should quite clearly be used for denoting a label of an input field
and not the input field itself.
Using a heading instead of a legend is OK, but use legend if the design
allows it for even better accessibility.

What you ought to do is something like this.

fieldset
h3Personal details/h3
ol
li
label for=surnameSurname/label
input type=text name=surname id=surname /
/li
li
label for=emailEmail/label
input type=text name=email id=email /
/li
/ol
/fieldset

Each /li is a container for labelinput pairs. No need for br/. Each
element is nicely 'styleable' via CSS. The ol gives a user insight into
how many elements exist inside the given fieldset so for non-sighted user
they will know to expect a more complex form if there are 15 items in the
given list. You can give each li a class attribute to give it a more
specific hook for styling or behaviour purposes.

Hope this helps.

Jason

On Thu, Oct 16, 2008 at 12:35 PM, [EMAIL PROTECTED] wrote:

 I am looking  for feedback on two questions, based on the simple form
 snippet below.

 fieldset
legendbPersonal Details/b/legend
label for=nameName:/label
input id=name type=text name=name size=30 br
label for=idID Number:/label
input id=id type=text name=id number size=10
 /fieldset

 Question 1:
 Is it acceptable, or advisable, to use a header tag h6 in place of the
 legend in order to get cross-browsers consistency when dealing with
 complex form styling?  How much impact might this have on accessibility, if
 any?

 Question 2:
 I don't see many folks using the label as a wrapper to contain the
 input.  Any reason not to do this?  It allows for the br / to be removed
 via display: block; on the label tag as well as allowing users (of most
 browsers) to click on a much larger label to select the accompanying input.

  fieldset
h6Personal Details/h6
label for=nameName:
input id=name type=text name=name size=30
/label
label for=idID Number:
input id=id type=text name=id number size=10
/label
 /fieldset

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




-- 
Jason Grant BSc, MSc
CEO, Flexewebs Ltd.
www.flexewebs.com
[EMAIL PROTECTED]
+44 (0)7748 591 770
Company no.: 5587469

www.twitter.com/flexewebs
www.linkedin.com/in/flexewebs


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

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

2008-10-16 Thread Mike at Green-Beast.com

Hi Ben,


I've always used label arount input fields [...]
I don't think I've ever seen any recommendation against it.


Here's one for you:
http://green-beast.com/blog/?p=254

I haven't been paying attention to this, and someone's probably already said 
it (if so, sorry), but it's also worth noting that only form elements will 
be read in a screen reader's forms mode. Being as such, it's better to style 
the legend to look like an h6 rather than substituting it for one.


Respectfully,
Mike Cherim




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



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

2008-10-16 Thread David Dorward
Johan Douma wrote:
 I've always used label arount input fields labeltext: input
 type=text //label without the for= attribute.
 I've never had problems with it, and I don't think I've ever seen any
 recommendation against it.
Support is weaker then for the for attribute, so I would avoid it.

It is just worth pointing out that it isn't wrong to put the input
inside the label.

-- 
David Dorward
http://dorward.me.uk/



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



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

2008-10-16 Thread Rachel Radford
I understand where you’re coming from because for some designs the legend isn’t 
easy to style consistently cross-browser, and so sometimes I have used a 
heading instead.  However if possible, using the legend is much better.

 

I also used to wrap form inputs in labels for the same reason as you say – 
styling the form becomes easy – however Mike’s article is very insightful and 
since then I’ve changed what I did and wrap as he suggests.  

 

So I just realised I’m basically echoing Mike’s comments, as that’s what I have 
also discerned as my best practice after quite a bit of form css experience and 
research.

 

J

Rach

 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: 16 October 2008 12:35
To: wsg@webstandardsgroup.org
Subject: [WSG] labels as input wrappers + h6 in place of legend

 

I am looking  for feedback on two questions, based on the simple form snippet 
below.

fieldset
   legendbPersonal Details/b/legend
   label for=nameName:/label
   input id=name type=text name=name size=30 br
   label for=idID Number:/label
   input id=id type=text name=id number size=10
/fieldset

Question 1:
Is it acceptable, or advisable, to use a header tag h6 in place of the 
legend in order to get cross-browsers consistency when dealing with complex 
form styling?  How much impact might this have on accessibility, if any?

Question 2:
I don't see many folks using the label as a wrapper to contain the input.  
Any reason not to do this?  It allows for the br / to be removed via display: 
block; on the label tag as well as allowing users (of most browsers) to click 
on a much larger label to select the accompanying input.

 fieldset
   h6Personal Details/h6
   label for=nameName:
   input id=name type=text name=name size=30
   /label
   label for=idID Number:
   input id=id type=text name=id number size=10
   /label
/fieldset


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


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

Re: [WSG] Chrome and Safari

2008-10-16 Thread David Hucklesby
On Thu, 16 Oct 2008 10:49:59 +1000, [EMAIL PROTECTED] wrote:
 Hi,

 Seeing as though Google's new Chrome browser uses the same rendering engine 
 as Apple's
 Safari, would it be acceptable to test browser layout issues in Chrome and 
 assume the
 same CSS solutions apply in Safari?

 Does anyone know of any distinct differences in CSS rendering between the 2 
 browsers?

The two are mostly in sync, but I wouldn't depend on it.

I would test in both, if I were you.

Cordially,
David
--



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



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

2008-10-16 Thread ox4dboy
Thank you everyone for your replies. So it seems the trusty old traditional 
filedset 
llegendContact Information/legend 
label for=nameName/labelbr / 
input id=name type=text 
/fieldset 
is the way to go to keep all browsers and screen readers happy. I think I can 
likely lose the br / and replace that with a display: block; on the label or 
input. This is the first of a series of questions I will have. I have the 
opportunity to rewrite some extremely complex forms for a very large CMS and I 
want to make them the best they can be. 

Thanks! 

- Original Message - 
From: Mike at Green-Beast.com [EMAIL PROTECTED] 
To: wsg@webstandardsgroup.org 
Sent: Thursday, October 16, 2008 11:07:33 AM GMT -05:00 US/Canada Eastern 
Subject: Re: [WSG] labels as input wrappers + h6 in place of legend 

Hi Ben, 

 I've always used label arount input fields [...] 
 I don't think I've ever seen any recommendation against it. 

Here's one for you: 
http://green-beast.com/blog/?p=254 

I haven't been paying attention to this, and someone's probably already said 
it (if so, sorry), but it's also worth noting that only form elements will 
be read in a screen reader's forms mode. Being as such, it's better to style 
the legend to look like an h6 rather than substituting it for one. 

Respectfully, 
Mike Cherim 




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



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

Re: [WSG] Flash replace Javascript in Future?

2008-10-16 Thread Johan Douma
I don't see flash becoming a dominant technology in the future. It's
definitly not going to replace javascript.
It wouldn't actually surprise me if it is going to die off really slowly...
Only to be used in really specific cases.

Flash gets used a lot today because the flash video codec is good and
because it's the easiest way to integrate some video into the browser
without needed any plugins that might not be on everybody's computer. Flash
is on 99.9% of the computers.

Now that might change as well in the next 3 or 4 years as the video and
audio tag are going to be more and more available to easily integrate video
and audio files into a page.
We would still need plugins anyway, but browser could at least integrate
open sources plugins, like ogg... etc...
I only use flash for multiple file uploads, and some small animations in the
page itself.

Ow and damn flash 10 has broken my file uploader, I'll have to work on that.





Cheers,
Johan Douma


2008/10/16 Breton Slivka [EMAIL PROTECTED]

 Read the story on that page carefully. What has happened is that flash
 10 has increased restrictions over what features within the flash
 plugin can be invoked via javascript. This only applies to one
 specific feature (file uploads), and effects virtually no other flash
 features. It does not effect javascript's abilities in general, only
 the abilities of javascript to use flash in certain ways. This point
 will largely become moot once video/audio/3d/canvas becomes widespread
 and built into browsers, and flash as a result becomes less relevant-
 Particularly on low powered platforms like the iPhone, and Android
 which do not have flash- or the wii which only has an older and
 underpowered version of flash.

 So in my opinion, to the contrary- This news story is reporting on
 decreased ability of the flash plugin to play well with javascript- It
 will not make flash replace javascript- Except as a workaround in the
 specific case of file uploads.


 On Fri, Oct 17, 2008 at 12:27 AM, Charles Ling [EMAIL PROTECTED]
 wrote:
  Hi Guys/Gals,
 
  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 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). Did you guys/gals
  use alot of flash in your past projects that you were working with?
 
  Cheers,
  Charles.
 
  ***
  List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
  Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
  Help: [EMAIL PROTECTED]
  ***


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




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