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

2010-11-10 Thread Benjamin Hawkes-Lewis
On Wed, Nov 10, 2010 at 3:07 AM, Micky Hulse mickyhulse.li...@gmail.com 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] lazyweb://schema.agnostic.URLs

2010-11-10 Thread Russ Weakley
 Not quite:
 
 http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/

Yikes! It all seemed so easy... suspiciously easy!  :)

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



[WSG] Out of Office AutoReply: [BULK] WSG Digest

2010-11-10 Thread Andy Dempster
I will be out of the office on Wednesday, November 10th.




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

2010-11-10 Thread Seona Bellamy
On 10 November 2010 19:22, Russ Weakley r...@maxdesign.com.au wrote:

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

 Yikes! It all seemed so easy... suspiciously easy!  :)


That last post from a Microsoft guy was interesting though. He says Until
recently there was a bug... Does that mean it's fixed? Or that it's going
to be fixed in IE9 and everything prior can go hang? Or that they've just
re-classified it so that it's not a bug anymore?

~Seona


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

[WSG] HTML5 - Marking up forms

2010-11-10 Thread Eric Taylor
Hi all - this is my first time sending to the list, but was looking for 
feedback on marking up forms in HTML5. Granted the spec is still a work in 
progress, but I was wondering if there was any current conversation about this 
multiple techniques of marking up forms via HTML5.

As stated, the purpose of this conversation is the marking up of forms. 
Currently, from what I have read, there are various ways of going about this. 
I'll name a couple that I have personally used, and I am interested in hearing 
feedback from you all about what you prefer and why.

From my experience, the best practice, currently, is using Description lists; 
however, my concern with this method is the lack of semantic grouping when 
using this set of elements.

Another method I have used is using an Unordered list to group each field 
inside of a list item. However, this doesn't seem like it makes as much sense, 
semantically, as the Description list.

What do you all think, and how do you go about marking up your forms in HTML5?

Thanks in advance,

Eric Taylor
 Elements Aside /
http://www.elementsaside.com

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

2010-11-10 Thread Patrick H. Lauke

On 10/11/2010 17:08, Eric Taylor wrote:

 From my experience, the best practice, currently, is using Description
lists; however, my concern with this method is the lack of semantic
grouping when using this set of elements.

Another method I have used is using an Unordered list to group each
field inside of a list item. However, this doesn't seem like it makes as
much sense, semantically, as the Description list.

What do you all think, and how do you go about marking up your forms in
HTML5?


HTML5 does not add any new semantics or constructs to mark up the 
structure of forms, it only adds new types, a few features (autofocus 
for instance) and validation functionality.


How you actually structure the lot is still as before (and there are 
still likely heated arguments over which way is good or 
not...personally, I just use paragraphs, as the extra structure of lists 
is just overkill in my opinion)


P
--
Patrick H. Lauke
__
re∑dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
__
twitter: @patrick_h_lauke | skype: patrick_h_lauke
__


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

2010-11-10 Thread Eric Taylor
Understandable; however, with the change in HTML5 from Definition Lists to 
Description lists, would it not be more semantically valuable to mark forms up 
using dt and dd, for labels and inputs, providing the document with a more 
solid structure? As stated, my concern with this is the lack of grouping per 
item, when using Description Lists.

I understand that paragraphs may be easier to handle when marking up forms and 
doing the CSS; however, is it a meaningful method of marking up forms that 
supports the forward progression of HTML5 and front-end development in general?

This is the main reason I'm torn between Description lists and 
Unordered/Ordered lists. What makes most sense from a semantics view, and where 
is the balance between semantics and ease-of-use?

Eric Taylor
 Elements Aside /
http://www.elementsaside.com

On Nov 10, 2010, at 11:41 AM, Patrick H. Lauke re...@splintered.co.uk wrote:

 On 10/11/2010 17:08, Eric Taylor wrote:
 From my experience, the best practice, currently, is using Description
 lists; however, my concern with this method is the lack of semantic
 grouping when using this set of elements.
 
 Another method I have used is using an Unordered list to group each
 field inside of a list item. However, this doesn't seem like it makes as
 much sense, semantically, as the Description list.
 
 What do you all think, and how do you go about marking up your forms in
 HTML5?
 
 HTML5 does not add any new semantics or constructs to mark up the structure 
 of forms, it only adds new types, a few features (autofocus for instance) and 
 validation functionality.
 
 How you actually structure the lot is still as before (and there are still 
 likely heated arguments over which way is good or not...personally, I just 
 use paragraphs, as the extra structure of lists is just overkill in my 
 opinion)
 
 P
 -- 
 Patrick H. Lauke
 __
 re∑dux (adj.): brought back; returned. used postpositively
 [latin : re-, re- + dux, leader; see duke.]
 
 www.splintered.co.uk | www.photographia.co.uk
 http://redux.deviantart.com | http://flickr.com/photos/redux/
 __
 twitter: @patrick_h_lauke | skype: patrick_h_lauke
 __
 
 
 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***
 


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



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

2010-11-10 Thread Micky Hulse
On Wed, Nov 10, 2010 at 12:22 AM, Russ Weakley r...@maxdesign.com.au wrote:
 Yikes! It all seemed so easy... suspiciously easy!  :)

Haha! Too true!

Back to the drawing board I guess. :D

Dang, I am still undecided about weather or not I should adopt this
technique! On one hand, the no-http site was very convicing as to why
one should stop using HTTP... On the other hand, if IE can't get it
right...

Anyway, thanks all for the interesting thread!


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

2010-11-10 Thread Steve Green
I'm with Patrick on this one. The form, fieldset and label elements 
provide all the semantic structure you need. Anything else is noise.

Steve Green
Test Partners Ltd

 

-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of Eric Taylor
Sent: 10 November 2010 17:30
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] HTML5 - Marking up forms

Understandable; however, with the change in HTML5 from Definition Lists to 
Description lists, would it not be more semantically valuable to mark forms up 
using dt and dd, for labels and inputs, providing the document with a more 
solid structure? As stated, my concern with this is the lack of grouping per 
item, when using Description Lists.

I understand that paragraphs may be easier to handle when marking up forms and 
doing the CSS; however, is it a meaningful method of marking up forms that 
supports the forward progression of HTML5 and front-end development in general?

This is the main reason I'm torn between Description lists and 
Unordered/Ordered lists. What makes most sense from a semantics view, and where 
is the balance between semantics and ease-of-use?

Eric Taylor
 Elements Aside /
http://www.elementsaside.com

On Nov 10, 2010, at 11:41 AM, Patrick H. Lauke re...@splintered.co.uk wrote:

 On 10/11/2010 17:08, Eric Taylor wrote:
 From my experience, the best practice, currently, is using 
 Description lists; however, my concern with this method is the lack 
 of semantic grouping when using this set of elements.
 
 Another method I have used is using an Unordered list to group each 
 field inside of a list item. However, this doesn't seem like it makes 
 as much sense, semantically, as the Description list.
 
 What do you all think, and how do you go about marking up your forms 
 in HTML5?
 
 HTML5 does not add any new semantics or constructs to mark up the structure 
 of forms, it only adds new types, a few features (autofocus for instance) and 
 validation functionality.
 
 How you actually structure the lot is still as before (and there are 
 still likely heated arguments over which way is good or 
 not...personally, I just use paragraphs, as the extra structure of 
 lists is just overkill in my opinion)
 
 P
 --
 Patrick H. Lauke
 __
 re\xAD\xF4dux (adj.): brought back; returned. used postpositively [latin : 
 re-, re- + dux, leader; see duke.]
 
 www.splintered.co.uk | www.photographia.co.uk 
 http://redux.deviantart.com | http://flickr.com/photos/redux/ 
 __
 twitter: @patrick_h_lauke | skype: patrick_h_lauke 
 __
 
 
 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***
 


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



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

2010-11-10 Thread Joseph Taylor

Eric,

There are a ton of ways to do this. At the moment I stick with one of 
two formulas:


fieldset
legendMy Legend/legend
div
label for=My FieldMy Label/label
input type=text name=My Field
/div
/fieldset

Or if its a bunch of checkboxes or something:

fieldset
legendMy Legend/legend
div
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
/div
/fieldset

Joseph R. B. Taylor
/Web Designer / Developer/
--
Sites by Joe, LLC
/Clean, Simple and Elegant Web Design/
Phone: (609) 335-3076
Web: http://sitesbyjoe.com
Email: j...@sitesbyjoe.com


On 11/10/10 12:30 PM, Eric Taylor wrote:

Understandable; however, with the change in HTML5 from Definition Lists to Description 
lists, would it not be more semantically valuable to mark forms up usingdt  
anddd, for labels and inputs, providing the document with a more solid structure? 
As stated, my concern with this is the lack of grouping per item, when using Description 
Lists.

I understand that paragraphs may be easier to handle when marking up forms and 
doing the CSS; however, is it a meaningful method of marking up forms that 
supports the forward progression of HTML5 and front-end development in general?

This is the main reason I'm torn between Description lists and 
Unordered/Ordered lists. What makes most sense from a semantics view, and where 
is the balance between semantics and ease-of-use?

Eric Taylor
  Elements Aside /
http://www.elementsaside.com

On Nov 10, 2010, at 11:41 AM, Patrick H. Laukere...@splintered.co.uk  wrote:


On 10/11/2010 17:08, Eric Taylor wrote:

 From my experience, the best practice, currently, is using Description
lists; however, my concern with this method is the lack of semantic
grouping when using this set of elements.

Another method I have used is using an Unordered list to group each
field inside of a list item. However, this doesn't seem like it makes as
much sense, semantically, as the Description list.

What do you all think, and how do you go about marking up your forms in
HTML5?

HTML5 does not add any new semantics or constructs to mark up the structure of 
forms, it only adds new types, a few features (autofocus for instance) and 
validation functionality.

How you actually structure the lot is still as before (and there are still 
likely heated arguments over which way is good or not...personally, I just use 
paragraphs, as the extra structure of lists is just overkill in my opinion)

P
--
Patrick H. Lauke
__
re∑dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
__
twitter: @patrick_h_lauke | skype: patrick_h_lauke
__


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



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




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

2010-11-10 Thread Kepler Gelotte
There are a ton of ways to do this. At the moment I stick with one of two
formulas:

fieldset
legendMy Legend/legend
div
label for=My FieldMy Label/label
input type=text name=My Field
/div
/fieldset





I believe the “for” attribute should reference the “id” attribute of the
input element. So the above example should be:



fieldset
legendMy Legend/legend
div
label for=My Field IdMy Label/label
input type=text name=My Field id=”My Field Id”
/div
/fieldset



In the case of checkboxes, multiple inputs can have the same name (that’s
how they are grouped together). Each input needs a unique id though, so each
label will reference a unique checkbox within the group.



Best regards,

Kepler Gelotte

Neighbor Webmaster, Inc.

156 Normandy Dr., Piscataway, NJ 08854

 http://www.neighborwebmaster.com www.neighborwebmaster.com

phone/fax: (732) 302-0904

  _

From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On
Behalf Of Joseph Taylor
Sent: Wednesday, November 10, 2010 12:50 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] HTML5 - Marking up forms



Eric,

There are a ton of ways to do this. At the moment I stick with one of two
formulas:

fieldset
legendMy Legend/legend
div
label for=My FieldMy Label/label
input type=text name=My Field
/div
/fieldset

Or if its a bunch of checkboxes or something:

fieldset
legendMy Legend/legend
div
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
label for=My Field
input type=checkbox name=My Field
Label for the checkbox
/label
/div
/fieldset


Joseph R. B. Taylor
Web Designer / Developer
--
Sites by Joe, LLC
Clean, Simple and Elegant Web Design
Phone: (609) 335-3076
Web: http://sitesbyjoe.com
Email: j...@sitesbyjoe.com


On 11/10/10 12:30 PM, Eric Taylor wrote:

Understandable; however, with the change in HTML5 from Definition Lists to
Description lists, would it not be more semantically valuable to mark forms
up using dt and dd, for labels and inputs, providing the document with a
more solid structure? As stated, my concern with this is the lack of
grouping per item, when using Description Lists.

I understand that paragraphs may be easier to handle when marking up forms
and doing the CSS; however, is it a meaningful method of marking up forms
that supports the forward progression of HTML5 and front-end development in
general?

This is the main reason I'm torn between Description lists and
Unordered/Ordered lists. What makes most sense from a semantics view, and
where is the balance between semantics and ease-of-use?

Eric Taylor
 Elements Aside /
http://www.elementsaside.com

On Nov 10, 2010, at 11:41 AM, Patrick H. Lauke
mailto:re...@splintered.co.uk re...@splintered.co.uk wrote:


On 10/11/2010 17:08, Eric Taylor wrote:

From my experience, the best practice, currently, is using Description
lists; however, my concern with this method is the lack of semantic
grouping when using this set of elements.

Another method I have used is using an Unordered list to group each
field inside of a list item. However, this doesn't seem like it makes as
much sense, semantically, as the Description list.

What do you all think, and how do you go about marking up your forms in
HTML5?


HTML5 does not add any new semantics or constructs to mark up the structure
of forms, it only adds new types, a few features (autofocus for instance)
and validation functionality.

How you actually structure the lot is still as before (and there are still
likely heated arguments over which way is good or not...personally, I just
use paragraphs, as the extra structure of lists is just overkill in my
opinion)

P
--
Patrick H. Lauke
__
re\xAD\xF4dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
__
twitter: @patrick_h_lauke | skype: patrick_h_lauke
__


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




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

RE: [WSG] HTML5 - Marking up forms

2010-11-10 Thread Thierry Koblentz
 Understandable; however, with the change in HTML5 from Definition Lists
 to Description lists, would it not be more semantically valuable to
 mark forms up using dt and dd, for labels and inputs, providing the
 document with a more solid structure? As stated, my concern with this
 is the lack of grouping per item, when using Description Lists.
 
 I understand that paragraphs may be easier to handle when marking up
 forms and doing the CSS; however, is it a meaningful method of marking
 up forms that supports the forward progression of HTML5 and front-end
 development in general?

I don't think lists should be used for this (there might be a case for a OL in 
case of dependant selects, but that would be a stretch). In the case of DL, I'd 
say that the relationship between DTs and DDs is no better than the one created 
by the labels and their for attribute.

fwiw, I use divs to wrap controls with their label, not because it makes things 
easier to style, but because of the way the form would look with no such 
wrapper and no styling. 

--
Regards,
Thierry
www.tjkdesign.com | www.ez-css.org | @thierrykoblentz




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

2010-11-10 Thread Patrick H. Lauke

On 10/11/2010 18:38, Micky Hulse wrote:

On Wed, Nov 10, 2010 at 12:22 AM, Russ Weakleyr...@maxdesign.com.au  wrote:

Yikes! It all seemed so easy... suspiciously easy!  :)


Haha! Too true!

Back to the drawing board I guess. :D


It really just depends on what you're trying to do though. The bug 
apparently only affects stylesheets, and the whole reason I'm assuming 
you'd want to use the protocol-less syntax is to have shared assets 
between http and https versions that are cached even when moving from 
insecure to secure. If you can live with the tiny overhead of just 
having the stylesheet recalled twice, it's not a huge deal imho (not 
optimal, but not a deal-breaker). If you're holding all the files you 
reference (like css) one the same server anyway, a simple 
/path/to/stylesheet.css path relative to the root of the current 
server will work fine and avoid the double download...so really, the 
only issue (when you'd want to use //foo.com/stylesheet.css) is when 
you want to reference a stylesheet from another domain using the same 
protocol as the one you're currently using...an edge-case, I'd argue?


P


Dang, I am still undecided about weather or not I should adopt this
technique! On one hand, the no-http site was very convicing as to why
one should stop using HTTP... On the other hand, if IE can't get it
right...

Anyway, thanks all for the interesting thread!


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




--
Patrick H. Lauke
__
re∑dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
__
twitter: @patrick_h_lauke | skype: patrick_h_lauke
__


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

2010-11-10 Thread Micky Hulse
On Wed, Nov 10, 2010 at 11:10 AM, Patrick H. Lauke
re...@splintered.co.uk wrote:
 It really just depends on what you're trying to do though. The bug
 apparently only affects stylesheets, and the whole reason I'm assuming you'd
 ...snip...
 another domain using the same protocol as the one you're currently
 using...an edge-case, I'd argue?

Excellent points Patrick! I would have to agree. :)

I personally have not dealt with HTTPS in a while, but I will
definitely consider using this technique in future.

Cheers!
M


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

2010-11-10 Thread Chris Price
On 10 November 2010 18:52, Thierry Koblentz thierry.koble...@gmail.comwrote:


 I don't think lists should be used for this (there might be a case for a OL
 in case of dependant selects, but that would be a stretch). In the case of
 DL, I'd say that the relationship between DTs and DDs is no better than the
 one created by the labels and their for attribute.

 fwiw, I use divs to wrap controls with their label, not because it makes
 things easier to style, but because of the way the form would look with no
 such wrapper and no styling.


I'm with you there Thierry

Fieldset is, by definition, a grouping within a form.
The legend describes the fieldset.
The label for and input id link to each other.
There is no subset of fieldset like dt is to dl or li is to ul so the only
logical element would be a div which is neutral.

I can only imagine I would have to grapple with semantics when I need to
break down a li or dd. If you lost the styling in a form built with a list
would it appear to make sense when each element had a bullet beside it?
Would another logical outcome not be that each fieldset would require a
separate list which may comprise 1 element?

--
Chris Price
Choctaw


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

2010-11-10 Thread Joseph Taylor

IE8 and earlier

Joseph R. B. Taylor
/Web Designer / Developer/
--
Sites by Joe, LLC
/Clean, Simple and Elegant Web Design/
Phone: (609) 335-3076
Web: http://sitesbyjoe.com
Email: j...@sitesbyjoe.com


On 11/10/10 3: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.


form action=# method=post
fieldset
legend class=visuallyhiddenForm legend text/legend

progress value=0.0 max=5.0
label for=text-example
span class=label
Label for text input
/span

span class=input
input type=text name=text-example id=text-example class=text /
/span
/label
/progress

progress value=1.0 max=5.0 class=radio-group
fieldset
legend class=visuallyhiddenForm legend text/legend

span class=label
Label for radio group
/span

div class=radiobutton-container
progress value=1.1 max=5.0
label for=radio-label-1
span class=input
input type=radio name=radio-group-name id=radio-label-1 /
/span

span class=label
Radio label
/span
/label
/progress

progress value=1.2 max=5.0
label for=radio-label-2
span class=input
input type=radio name=radio-group-name id=radio-label-2 /
/span

span class=label
Radio label
/span
/label
/progress

progress value=1.3 max=5.0
label for=radio-label-3
span class=input
input type=radio name=radio-group-name id=radio-label-3 /
/span

span class=label
Radio label
/span
/label
/progress
/div!-- / .radiobutton-container --
/fieldset
/progress!-- / .radio-group --

progress value=2.0 max=5.0 class=checkbox-group
fieldset
legend class=visuallyhiddenForm legend text/legend

span class=label
Label for checkbox group
/span

div class=checkbox-container
progress value=2.1 max=5.0
label for=checkbox-label-1
span class=input
input type=checkbox name=checkbox-label-1 id=checkbox-label-1 /
/span
span class=label
Checkbox label
/span
/label
/progress

progress value=2.2 max=5.0
label for=checkbox-label-2
span class=input
input type=checkbox name=checkbox-label-2 id=checkbox-label-2 /
/span
span class=label
Checkbox label
/span
/label
/progress

progress value=2.3 max=5.0
label for=checkbox-label-3
span class=input
input type=checkbox name=checkbox-label-3 id=checkbox-label-3 /
/span

span class=label
Checkbox label
/span
/label
/progress
/div!-- / .checkbox-container --
/fieldset
/progress!-- / .checkbox-group --

progress value=3.0 max=5.0
label for=select-box-label
span class=label
Option label text
/span

span class=input
select name=select-box-label id=select-box-label
option selected=selected data-skip=1Option text/option
optionOption text/option
optionOption text/option
optionOption text/option
optionOption text/option
/select
/span
/label
/progress

progress value=4.0 max=5.0
label for=select-box-label
span class=label
Option label text
/span

span class=input
select name=fancySelect class=combibox
option value=0 selected=selected data-skip=1Choose Your 
Product/option
option value=1 
data-icon=/graphics/structure/forms/products/iphone.png 
data-html-text=iPhone 4lt;igt;in stocklt;/igt;iPhone 4/option
option value=2 
data-icon=/graphics/structure/forms/products/ipod.png 
data-html-text=iPod lt;igt;in stocklt;/igt;iPod/option
option value=3 
data-icon=/graphics/structure/forms/products/air.png 
data-html-text=MacBook Airlt;igt;out of stocklt;/igt;MacBook 
Air/option
option value=4 
data-icon=/graphics/structure/forms/products/imac.png 
data-html-text=iMac Stationlt;igt;in stocklt;/igt;iMac 
Station/option

/select
/span
/label
/progress

progress value=5.0 max=5.0
label for=textarea-example
span class=label
Label for textarea
/span

span class=input
textarea name=textarea-example id=textarea-example class=text 
rows=10 cols=51/textarea

/span
/label
/progress

input type=submit value=Submit form class=button /
/fieldset
/form


Kevin Rapley
Yoo-zuh-buhl | User Experience Consultant
0115 714 2337 | 0772 345 7862
yoo-zuh-buhl.co.uk http://yoo-zuh-buhl.co.uk

Yoo-zuh-buhl, The Terrace, Cultural Quarter, Grantham Road, Lincoln, 
LN2 1BD


On 10/11/2010 19:37, Chris Price wrote:
On 10 November 2010 18:52, Thierry Koblentz 
thierry.koble...@gmail.com mailto:thierry.koble...@gmail.com wrote:



I don't think lists should be used for this (there might be a case
for a OL in case of dependant selects, but that would be a
stretch). In the case of DL, I'd say that the relationship between
DTs and DDs is no better than the one created by the labels and
their for attribute.

fwiw, I use divs to wrap controls with their label, not because it
makes things easier to style, but because of the way the form
would look with no such wrapper and no styling.


I'm with you there Thierry

Fieldset is, by definition, a grouping within a form.
The legend describes the fieldset.
The label for and input id link to each other.
There is no subset of fieldset like dt is to dl or li is to ul so the 
only logical element would be a div which is neutral.


I can only imagine I would have 

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

2010-11-10 Thread Andrew Harris
On Thu, Nov 11, 2010 at 6:10 AM, Patrick H. Lauke
re...@splintered.co.uk wrote:
 It really just depends on what you're trying to do though.

Precisely, and the IE hit certainly pales into insignificance compared
to the benefits for us.
We run a lot of sites, an awful lot of pages, and an awful lot of
visitors. Any resources - even the Uni logo in the corner - that can
be shared effectively are going to make a substantial difference. Our
current style sheets have absolute URLs to these shared graphics,
which caused 'mixed content' problems in secure environments.

 shared assets between http and https versions that are cached
 even when moving from insecure to secure.

I actually expect to see a cached version of each, not a single, shared object.
We'll be doing a bit more testing, but at this stage, it looks like a
thumbs up for our situation.

Thanks again to all who contributed.

-- 
Andrew Harris
and...@woowoowoo.com
http://www.woowoowoo.com

~~~ * ~~~


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



Re: [WSG] mixing media queries?

2010-11-10 Thread tee
Thank you very much!!

This one works (combination of portriat/landscape fails also).
@media only screen and (max-width: 480px),
only screen and (min-device-width : 768px) and (max-device-width : 1024px)

Maybe it's obvious to others however it was not  for me and  I can now see 
where my confusion came from after reading a number times (before my original 
post) the spec of media quires in w3.org/TR/css3-mediaqueries.

1. I do see the  If one or more of the media queries in the comma-separated 
list are true, the whole list is true,
and otherwise false.

2. In the css3-mediaqueries examples, the comma is used to separate different 
media, e.g., screen, projection, speech.

3. #2 could be a blind spot when you want to target only screen and thus 
assume 'and' is the only and logical choice.

The example in this site brings clarity.
http://protofluid.com/?c=mediaQueries 

tee
On Nov 9, 2010, at 10:00 PM, Micky Hulse wrote:

 On Tue, Nov 9, 2010 at 8:59 PM, tee weblis...@gmail.com wrote:
 ...snip...
 My various tests show that it's not possible to have more than 2 rules put 
 together.
 
 Hi!
 
 Sounds like a fun project that you are tackling!
 
 I am not sure I can help much, but if you have time to browse the net,
 maybe the info on via these links will be of some help:
 
 1.
 W3C Media Queries
 http://www.w3.org/TR/css3-mediaqueries/
 
 2.
 Mobile-friendly: The mobile web optimization guide
 http://dev.opera.com/articles/view/the-mobile-web-optimization-guide/
 
 3.
 ProtoFluid: Rapid Prototyping of Adaptive CSS and Responsive Design.
 http://protofluid.com/
 
 4.
 Smashing Magazine: How To Use CSS3 Media Queries To Create a Mobile
 Version of Your Website
 http://www.smashingmagazine.com/2010/07/19/how-to-use-css3-media-queries-to-create-a-mobile-version-of-your-website/
 
 From the W3C site:
 
 [[
 
 Several media queries can be combined in a media query list. A
 comma-separated list of media queries. If one or more of the media
 queries in the comma-separated list are true, the whole list is true,
 and otherwise false. In the media queries syntax, the comma expresses
 a logical OR, while the ‘and’ keyword expresses a logical AND.
 
 ]]
 
 Based on what I am reading above, if I am understanding it correctly
 (I am 3 glasses of wine deep atm) maybe your logic is a little off in
 terms of one of the bits of logic being false, so that makes the whole
 statement false? You might play around with Protofluid app and work
 with the comma vs. the AND (or combo of both.)
 
 I hope that helps!
 
 Cheers,
 Micky
 
 -- 
 Micky Hulse
 Web Content Editor
 The Register-Guard
 3500 Chad Drive
 Eugene, OR 97408
 Phone: (541) 338-2621
 Fax: (541) 683-7631
 Web: http://www.registerguard.com
 
 
 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***
 



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



[WSG] XHTML or HTML?

2010-11-10 Thread cat soul
Any thoughts on which we ought to be using, and what information  
ought to be up at top of an HTML page, along with !DOCTYPE, etc?


Thank you,

cs


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



RE: [WSG] XHTML or HTML?

2010-11-10 Thread Thierry Koblentz
 Any thoughts on which we ought to be using, and what information
 ought to be up at top of an HTML page, along with !DOCTYPE, etc?

I'd go with !DOCTYPE html with nothing above that

--
Regards,
Thierry
www.tjkdesign.com | www.ez-css.org | @thierrykoblentz






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



Re: [WSG] XHTML or HTML?

2010-11-10 Thread David Dorward
 
On 10 Nov 2010, at 22:34, cat soul wrote:

 Any thoughts on which we ought to be using

HTML, since it works in IE  9 without having to pretend it is HTML.

4.01, since it is a stable recommendation with mature QA tools (unless you have 
a need for features added in HTML5 and are willing to life on the bleeding edge)

Strict, unless you need something only offered by Transitional (in which case 
think twice as not being in Strict is a clue that you probably shouldn't use 
something).


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

Title is mandatory. 

Meta charset if you think people are more likely to view a locally saved copy 
of the document than a copy that has gone through a transcoding proxy.

Links to any stylesheets.

Scripts that need to run before the page has finished loading.

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



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




RE: [WSG] XHTML or HTML?

2010-11-10 Thread Ted Drake
Thierry's right. It's time to start making those baby steps into HTML5.
But you'll also need to add your charset and lang definition

!doctype html
html lang=en 
head
meta charset=UTF-8
...






ted
-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of Thierry Koblentz
Sent: Wednesday, November 10, 2010 2:54 PM
To: wsg@webstandardsgroup.org
Subject: RE: [WSG] XHTML or HTML?

 Any thoughts on which we ought to be using, and what information
 ought to be up at top of an HTML page, along with !DOCTYPE, etc?

I'd go with !DOCTYPE html with nothing above that

--
Regards,
Thierry
www.tjkdesign.com | www.ez-css.org | @thierrykoblentz






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



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



Re: [WSG] XHTML or HTML?

2010-11-10 Thread Mathew Robertson
Here is a reasonably good example:

http://www.texaswebdevelopers.com/blog/template_permalink.asp?id=136

http://www.texaswebdevelopers.com/blog/template_permalink.asp?id=136In
particular, the 'dir' and 'lang' attributes - most people just assume that
english is the only language...

regards,
Mathew Robertson

On 11 November 2010 09:53, Thierry Koblentz thierry.koble...@gmail.comwrote:

  Any thoughts on which we ought to be using, and what information
  ought to be up at top of an HTML page, along with !DOCTYPE, etc?

 I'd go with !DOCTYPE html with nothing above that

 --
 Regards,
 Thierry
 www.tjkdesign.com | www.ez-css.org | @thierrykoblentz






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




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

Re: [WSG] XHTML or HTML?

2010-11-10 Thread Chris F.A. Johnson

On Wed, 10 Nov 2010, cat soul wrote:

Any thoughts on which we ought to be using, and what information ought to be 
up at top of an HTML page, along with !DOCTYPE, etc?


   The first line should be a doctype. I recommend either 4.01 strict
   or HTML5.

  !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
http://www.w3.org/TR/html4/strict.dtd;
or
  !DOCTYPE html

   In the HEAD you need a TITLE element.

   You probably also want a charset declaration, e.g.:

 meta http-equiv=Content-Type content=text/html; charset=utf-8

   a link to a stylesheet:

 link href=body.css rel=stylesheet type=text/css

   a description META tag:

 meta name=description
  content=Chris F.A. Johnson's home page: Web design, Chess, Unix shell, Cryptic 
Crosswords, Books

   Then the BODY.

   And always check your page with http://validator.w3.org/.

--
   Chris F.A. Johnson, http://cfajohnson.com
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)


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



Re: [WSG] XHTML or HTML?

2010-11-10 Thread Benjamin Hawkes-Lewis
On Wed, Nov 10, 2010 at 10:34 PM, cat soul cats...@thinkplan.org 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 !DOCTYPE, 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] XHTML or HTML?

2010-11-10 Thread cat soul


On Nov 10, 2010, at 3:14 PM, Ted Drake wrote:

Thierry's right. It's time to start making those baby steps into  
HTML5.

But you'll also need to add your charset and lang definition

!doctype html
html lang=en
head
meta charset=UTF-8



Great! Most everyone else is saying HTML5 is 10 years off and not to  
code for it, not to worry about it until then.


cs


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



RE: [WSG] XHTML or HTML?

2010-11-10 Thread Ted Drake
Benjamin always has a way of cutting through the fog and giving succent advice.
Ted


-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of Benjamin Hawkes-Lewis
Sent: Wednesday, November 10, 2010 3:26 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] XHTML or HTML?

On Wed, Nov 10, 2010 at 10:34 PM, cat soul cats...@thinkplan.org 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 !DOCTYPE, 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
***


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

Re: [WSG] XHTML or HTML?

2010-11-10 Thread David Storey
 
On 11 Nov 2010, at 00:17, Mathew Robertson wrote:

 Here is a reasonably good example:
 
 http://www.texaswebdevelopers.com/blog/template_permalink.asp?id=136
 
 In particular, the 'dir' and 'lang' attributes - most people just assume 
 that english is the only language…

dir isn’t needed unless you are using rtl or something more exotic. The default 
is ltr. 

Also be aware if you are using a HTML5 structural elements like section and so 
on, while they work in modern browsers by adding “display: block;” and IE by 
the HTML5 Shim (createElement), they will not work on the BlackBerry browser 
(Pre-BB6, but that is most BBs on the market). BlackBerry is highly underrated, 
but by some measures it is the second most popular mobile browser after Opera: 
http://gs.statcounter.com/#mobile_browser-ww-daily-20091001-20101109

 
 regards,
 Mathew Robertson
 
 On 11 November 2010 09:53, Thierry Koblentz thierry.koble...@gmail.com 
 wrote:
  Any thoughts on which we ought to be using, and what information
  ought to be up at top of an HTML page, along with !DOCTYPE, etc?
 
 I'd go with !DOCTYPE html with nothing above that
 
 --
 Regards,
 Thierry
 www.tjkdesign.com | www.ez-css.org | @thierrykoblentz
 
 
 
 
 
 
 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***
 
 
 
 ***
 List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
 Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
 Help: memberh...@webstandardsgroup.org
 ***

-- 
David Storey

Chief Web Opener / Product Manager, Opera Dragonfly
W3C WG:  Mobile Web Best Practices / SVG Interest Group 

Opera Software ASA, Oslo, Norway
Mobile: +47 94 22 02 32 / E-Mail/XMPP: dsto...@opera.com / Twitter: dstorey



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


[WSG] all media queries in one style sheet Vs individually served

2010-11-10 Thread tee
I fully understand the need to reducing extra HTTP requests, however as the 
main style sheet gets fatter and fatter with different media queries stuff in 
it I am starting to doubt the benefit of reducing HTTP requests in this manner.

Say, in the main style sheet I serve 

@media print

@media only screen and (max-width: 480px)

@media only screen and (orientation: portrait) and (device-width: 768px) 

By deleting the above 3 media types I can cut down some 30% fat.

2 questions:

1.  Will the desktop browser stops loading the above 3 media unless 
requested?

2.  If I link each media type individually, does the desktop browser 
actually load the above 3 style sheets? 

My thought is not but I haven't a clue. 

Similarly, will it not  better for targeted device not loading two of the media 
types? If a targeted device loads only the correct style sheets, it will be 2 
HTTP requests (one for main style and one for targeted media type) but the file 
size of each style sheet is significant reduce, and this seems to be beneficial 
especially for bandwidth concerned mobile devices. Yes?


Thanks!

tee




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

2010-11-10 Thread Benjamin Hawkes-Lewis
On Wed, Nov 10, 2010 at 8:45 PM, Kevin Rapley ke...@digikev.co.uk 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
***