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] lazyweb://schema.agnostic.URLs

[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

[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

[Seona Bellamy]

On 10 November 2010 19:22, Russ Weakley  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

[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

[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

[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  and , 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"  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

[Micky Hulse]

On Wed, Nov 10, 2010 at 12:22 AM, Russ Weakley  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

[Steve Green]

I'm with Patrick on this one. The ,  and  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  and , 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"  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

[Joseph Taylor]

Eric,

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



My Legend

My Label




Or if its a bunch of checkboxes or something:


My Legend



Label for the checkbox



Label for the checkbox



Label for the checkbox




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  
and, 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"  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

[Kepler Gelotte]

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


My Legend

My Label








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




My Legend

My Label






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

  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:


My Legend

My Label




Or if its a bunch of checkboxes or something:


My Legend



Label for the checkbox



Label for the checkbox



Label for the checkbox





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  and , 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"
  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
***


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubs

RE: [WSG] HTML5 - Marking up forms

[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  and , 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

[Patrick H. Lauke]

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

On Wed, Nov 10, 2010 at 12:22 AM, Russ Weakley  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

[Micky Hulse]

On Wed, Nov 10, 2010 at 11:10 AM, Patrick H. Lauke
 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
> ..
> 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

[Chris Price]

On 10 November 2010 18:52, Thierry Koblentz 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 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

[Kevin Rapley]

I would be interested to gather your thoughts around this solution, 
using progress tags to mark progress through the form.




Form legend text




Label for text input










Form legend text


Label for radio group










Radio label











Radio label











Radio label









Form legend text


Label for checkbox group









Checkbox label










Checkbox label











Checkbox label










Option label text




Option text
Option text
Option text
Option text
Option text








Option label text




Choose Your 
Product
data-icon="/graphics/structure/forms/products/iphone.png" 
data-html-text="iPhone 4in stock">iPhone 4
data-icon="/graphics/structure/forms/products/ipod.png" 
data-html-text="iPod in stock">iPod
data-html-text="MacBook Airout of stock">MacBook 
Air
data-icon="/graphics/structure/forms/products/imac.png" 
data-html-text="iMac Stationin stock">iMac 
Station









Label for textarea



rows="10" cols="51">










Kevin Rapley
Yoo-zuh-buhl | User Experience Consultant
0115 714 2337 | 0772 345 7862
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 
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 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
*** 



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

[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 legend text




Label for text input










Form legend text


Label for radio group










Radio label











Radio label











Radio label









Form legend text


Label for checkbox group









Checkbox label










Checkbox label











Checkbox label










Option label text




Option text
Option text
Option text
Option text
Option text








Option label text




Choose Your 
Product
data-icon="/graphics/structure/forms/products/iphone.png" 
data-html-text="iPhone 4in stock">iPhone 4
data-icon="/graphics/structure/forms/products/ipod.png" 
data-html-text="iPod in stock">iPod
data-icon="/graphics/structure/forms/products/air.png" 
data-html-text="MacBook Airout of stock">MacBook 
Air
data-icon="/graphics/structure/forms/products/imac.png" 
data-html-text="iMac Stationin stock">iMac 
Station









Label for textarea



rows="10" cols="51">










Kevin Rapley
Yoo-zuh-buhl | User Experience Consultant
0115 714 2337 | 0772 345 7862
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 
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 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
*** 



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

[Andrew Harris]

On Thu, Nov 11, 2010 at 6:10 AM, Patrick H. Lauke
 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?

[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  wrote:
>> ..
>> 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"
> 
> 
> 2.
> "Mobile-friendly: The mobile web optimization guide"
> 
> 
> 3.
> "ProtoFluid: Rapid Prototyping of Adaptive CSS and Responsive Design."
> 
> 
> 4.
> "Smashing Magazine: 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: 
> 
> 
> ***
> 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?

[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 , 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?

[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 , etc?

I'd go with  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?

[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 
> , 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?

[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


 


...






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 , etc?

I'd go with  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?

[Mathew Robertson]

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

regards,
Mathew Robertson

On 11 November 2010 09:53, Thierry Koblentz 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 , etc?
>
> I'd go with  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?

[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 , etc?


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

  http://www.w3.org/TR/html4/strict.dtd";>
or
  

   In the HEAD you need a TITLE element.

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

 

   a link to a stylesheet:

 

   a description META tag:

 

   Then the BODY.

   And always check your page with .

--
   Chris F.A. Johnson, 
   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?

[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] XHTML or HTML?

[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








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?

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


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

Re: [WSG] XHTML or HTML?

[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  
> 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 , etc?
> 
> I'd go with  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

[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

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