From the editor's draft:

"
The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside
element, and which could be considered separate from that content. Such
sections are often represented as sidebars in printed typography.

The element can be used for typographical effects like pull quotes or
sidebars, for advertising, for groups of nav elements, and for other
content that is considered separate from the main content of the page.
"

Dear God, please don't suggest it be used for noise like sidebars,
advertising, or non related groups of nav elements. Asides are NOT often
represented AS sidebars in printed typography, they are often
represented IN sidebars of printed typography. This distinction is
fundamentally different.

I've never read a serious article where suddenly an aside is made where
it says:

BUY! BUY! BUY! BUY OUR JUNK TODAY!!

An aside is tangential to the content (as in the working draft of the
spec), this means it is related in some way, usually enriching the
information/experience rather than watering it down with nonsense.

I beg you to reconsider your wording for this element's description.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Op 2/10/10 9:08 PM, Robert Cummings schreef:
> From the editor's draft:
>
> "
> The aside element represents a section of a page that consists of
> content that is tangentially related to the content around the aside
> element, and which could be considered separate from that content. Such
> sections are often represented as sidebars in printed typography.
>
> The element can be used for typographical effects like pull quotes or
> sidebars, for advertising, for groups of nav elements, and for other
> content that is considered separate from the main content of the page.
> "
>
> Dear God, please don't suggest it be used for noise like sidebars,
> advertising, or non related groups of nav elements. Asides are NOT often
> represented AS sidebars in printed typography, they are often
> represented IN sidebars of printed typography. This distinction is
> fundamentally different.
>
> I've never read a serious article where suddenly an aside is made where
> it says:
>
> BUY! BUY! BUY! BUY OUR JUNK TODAY!!
>
> An aside is tangential to the content (as in the working draft of the
> spec), this means it is related in some way, usually enriching the
> information/experience rather than watering it down with nonsense.
>
> I beg you to reconsider your wording for this element's description.

as an aside, I think I'll wait until there is some general consensus on the
actual constructive usage of this sort of tag until I use it - personally I
really think this is too vague.

the concepts of what is structural, what is semantic and what is style are too
mixed up and vague for me to worry, just yet, about the details of these new-fangled
HTML5 tags (not mention browser support).

[at] Rob - your browswer compability 'hack' example in another recent thread is a
perfect example or the problems we face with trying to delineate between styling and
semantics and as such I think I lot of what HTML5 adds is arbitrary and rather
vague (the CANVAS and video stuff not withstanding)

personally I don't give a hoot - browsers (and more importantly the users, and the
various versions they run - and will be running for quite some time) mean that,
as fas as I'm concerned, HTML5 and everything it may entail is still a pipe dream.

As long as people run IE6 or IE7 (actually any POS browser that doesn't properly
attempt to implement current standards) such things as semantically marked up ASIDES
(as vague as the concept might) are rather irrelevant to the day to day business of
building web sites/applications that accessible/relevant/usable/etc to the general
public.

rgds,
Jochem

PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his assessment - I do enjoy
his posts, he's a sharp cookie with plenty to offer and I always enjoy reading his
argumentation and opinion!


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

*haha* I've removed w3.org from the recipients list... so onwards to the
content below...


Jochem Maas wrote:
> Op 2/10/10 9:08 PM, Robert Cummings schreef:
>> From the editor's draft:
>>
>> "
>> The aside element represents a section of a page that consists of
>> content that is tangentially related to the content around the aside
>> element, and which could be considered separate from that content. Such
>> sections are often represented as sidebars in printed typography.
>>
>> The element can be used for typographical effects like pull quotes or
>> sidebars, for advertising, for groups of nav elements, and for other
>> content that is considered separate from the main content of the page.
>> "
>>
>> Dear God, please don't suggest it be used for noise like sidebars,
>> advertising, or non related groups of nav elements. Asides are NOT often
>> represented AS sidebars in printed typography, they are often
>> represented IN sidebars of printed typography. This distinction is
>> fundamentally different.
>>
>> I've never read a serious article where suddenly an aside is made where
>> it says:
>>
>> BUY! BUY! BUY! BUY OUR JUNK TODAY!!
>>
>> An aside is tangential to the content (as in the working draft of the
>> spec), this means it is related in some way, usually enriching the
>> information/experience rather than watering it down with nonsense.
>>
>> I beg you to reconsider your wording for this element's description.
>
> as an aside, I think I'll wait until there is some general consensus on the
> actual constructive usage of this sort of tag until I use it - personally I
> really think this is too vague.
>
> the concepts of what is structural, what is semantic and what is style are too
> mixed up and vague for me to worry, just yet, about the details of these new-fangled
> HTML5 tags (not mention browser support).
>
> [at] Rob - your browswer compability 'hack' example in another recent thread is a
> perfect example or the problems we face with trying to delineate between styling and
> semantics and as such I think I lot of what HTML5 adds is arbitrary and rather
> vague (the CANVAS and video stuff not withstanding)
>
> personally I don't give a hoot - browsers (and more importantly the users, and the
> various versions they run - and will be running for quite some time) mean that,
> as fas as I'm concerned, HTML5 and everything it may entail is still a pipe dream.
>
> As long as people run IE6 or IE7 (actually any POS browser that doesn't properly
> attempt to implement current standards) such things as semantically marked up ASIDES
> (as vague as the concept might) are rather irrelevant to the day to day business of
> building web sites/applications that accessible/relevant/usable/etc to the general
> public.

I can only somewhat agree with your assessment above. It is true that
while many people still use broken browsers like IE6 and IE7; however,
this should not completely dissuade us from improving the experience for
those users that *do* choose standards compliant browsers. If we ignore
those users because we don't see the point in wasting time on the IE*
crowd, then we essentially weaken the argument in favour of embracing
standards. While IE* Joe, doesn't give a damn about whether his browser
supports <aside> or not, studious Jane really enjoys the enriched
experience her browser provides because not only does it understand
asides, but it provides a convenient extra facility that extracts them
into a browsable list with excerpts taken from the surrounding text for
context (inverting the relationship :). Then there's Jenny who's blind,
she's listening to the content on the page and hears a little ding go
off that indicates there's further information available that she can
review-- she can choose to pull it up and listen to it, after which the
reader returns to where she left off the original content. Alternatively
she may choose not to interrupt the main flow of information, but again,
similar to Jane's experience she can listen to each one afterwards in a
summarized fashion.

This is how serious organizations, and almost certainly Government, will
markup their information. Regardless of whether everyone has a browser
that supports the information. If the semantic markup improves usability
and enriches the information, then it will be used to meet that purpose.

> PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his assessment - I do enjoy
> his posts, he's a sharp cookie with plenty to offer and I always enjoy reading his
> argumentation and opinion!

Thanks... You've got me blushing :D

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--=-ycX4jRUmAri4TnKqCMWg
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-02-11 at 01:44 -0500, Robert Cummings wrote:

> *haha* I've removed w3.org from the recipients list... so onwards to the
> content below...
>
>
> Jochem Maas wrote:
> > Op 2/10/10 9:08 PM, Robert Cummings schreef:
> >> From the editor's draft:
> >>
> >> "
> >> The aside element represents a section of a page that consists of
> >> content that is tangentially related to the content around the aside
> >> element, and which could be considered separate from that content. Such
> >> sections are often represented as sidebars in printed typography.
> >>
> >> The element can be used for typographical effects like pull quotes or
> >> sidebars, for advertising, for groups of nav elements, and for other
> >> content that is considered separate from the main content of the page.
> >> "
> >>
> >> Dear God, please don't suggest it be used for noise like sidebars,
> >> advertising, or non related groups of nav elements. Asides are NOT often
> >> represented AS sidebars in printed typography, they are often
> >> represented IN sidebars of printed typography. This distinction is
> >> fundamentally different.
> >>
> >> I've never read a serious article where suddenly an aside is made where
> >> it says:
> >>
> >> BUY! BUY! BUY! BUY OUR JUNK TODAY!!
> >>
> >> An aside is tangential to the content (as in the working draft of the
> >> spec), this means it is related in some way, usually enriching the
> >> information/experience rather than watering it down with nonsense.
> >>
> >> I beg you to reconsider your wording for this element's description.
> >
> > as an aside, I think I'll wait until there is some general consensus on the
> > actual constructive usage of this sort of tag until I use it - personally I
> > really think this is too vague.
> >
> > the concepts of what is structural, what is semantic and what is style are too
> > mixed up and vague for me to worry, just yet, about the details of these new-fangled
> > HTML5 tags (not mention browser support).
> >
> > [at] Rob - your browswer compability 'hack' example in another recent thread is a
> > perfect example or the problems we face with trying to delineate between styling and
> > semantics and as such I think I lot of what HTML5 adds is arbitrary and rather
> > vague (the CANVAS and video stuff not withstanding)
> >
> > personally I don't give a hoot - browsers (and more importantly the users, and the
> > various versions they run - and will be running for quite some time) mean that,
> > as fas as I'm concerned, HTML5 and everything it may entail is still a pipe dream.
> >
> > As long as people run IE6 or IE7 (actually any POS browser that doesn't properly
> > attempt to implement current standards) such things as semantically marked up ASIDES
> > (as vague as the concept might) are rather irrelevant to the day to day business of
> > building web sites/applications that accessible/relevant/usable/etc to the general
> > public.
>
> I can only somewhat agree with your assessment above. It is true that
> while many people still use broken browsers like IE6 and IE7; however,
> this should not completely dissuade us from improving the experience for
> those users that *do* choose standards compliant browsers. If we ignore
> those users because we don't see the point in wasting time on the IE*
> crowd, then we essentially weaken the argument in favour of embracing
> standards. While IE* Joe, doesn't give a damn about whether his browser
> supports <aside> or not, studious Jane really enjoys the enriched
> experience her browser provides because not only does it understand
> asides, but it provides a convenient extra facility that extracts them
> into a browsable list with excerpts taken from the surrounding text for
> context (inverting the relationship :). Then there's Jenny who's blind,
> she's listening to the content on the page and hears a little ding go
> off that indicates there's further information available that she can
> review-- she can choose to pull it up and listen to it, after which the
> reader returns to where she left off the original content. Alternatively
> she may choose not to interrupt the main flow of information, but again,
> similar to Jane's experience she can listen to each one afterwards in a
> summarized fashion.
>
> This is how serious organizations, and almost certainly Government, will
> markup their information. Regardless of whether everyone has a browser
> that supports the information. If the semantic markup improves usability
> and enriches the information, then it will be used to meet that purpose.
>
> > PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his assessment - I do enjoy
> > his posts, he's a sharp cookie with plenty to offer and I always enjoy reading his
> > argumentation and opinion!
>
> Thanks... You've got me blushing :D
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>


I'd say that from what I've heard, Governments aren't that good at
getting accessible sites up, so the chances of them using HTML5
semantically, well, the immediate future doesn't look too rosy!

Also, I thought I'd throw in my tuppence as to the use of <aside>. I'd
tend to try and relate it to a footnote in a book, or a boxout in a
magazine article. It's not integral to the content it's related to or
near, but acts as an aid to it should the reader wish.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-ycX4jRUmAri4TnKqCMWg--

If <aside> is not proper to use for this purpose, what would be?

<sidebar> suggests a particular type of layout.
<section> suggests content.
<nav> is appropriate for some items in a side bar, but not all, and is
often a child of how <aside> is being used.
<div> give no semantics.

I would like to see a <toc> tag for nav that serves as a table of
contents of sorts (what I often have at the top of a side bar) but I
suspect <nav> is considered sufficient.

Maybe <sidebar> would be best, and the reference to column type layout
can just be understood that isn't necessarily on the side?

Reading up on it, I saw some suggest <figure> for what some of you want
<aside> used for, but a <figure> is often important content and has its
own meaning so that's not exactly appropriate.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Michael A. Peters wrote:
> If <aside> is not proper to use for this purpose, what would be?

How about <margin> ??

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--=-IKk+h/e7P7zJQTx/PENQ
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-02-11 at 05:59 -0800, Michael A. Peters wrote:

> Michael A. Peters wrote:
> > If <aside> is not proper to use for this purpose, what would be?
>
> How about <margin> ??
>


To me margin says an area of space around the content. That's not to say
that content can't be put in a margin, but I just don't think it
accurately describes the content. For me, the margin is the entire area
around the content, so these areas of content we're describing could
exist repeatedly as child elements of the margin.

How about <boxout> instead? It describes to me what I think is the gist
of the this topic.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-IKk+h/e7P7zJQTx/PENQ--

Ashley Sheridan wrote:
> On Thu, 2010-02-11 at 01:44 -0500, Robert Cummings wrote:
>> *haha* I've removed w3.org from the recipients list... so onwards to the
>> content below...
>>
>>
>> Jochem Maas wrote:
>> > Op 2/10/10 9:08 PM, Robert Cummings schreef:
>> >> From the editor's draft:
>> >>
>> >> "
>> >> The aside element represents a section of a page that consists of
>> >> content that is tangentially related to the content around the aside
>> >> element, and which could be considered separate from that content. Such
>> >> sections are often represented as sidebars in printed typography.
>> >>
>> >> The element can be used for typographical effects like pull quotes or
>> >> sidebars, for advertising, for groups of nav elements, and for other
>> >> content that is considered separate from the main content of the page.
>> >> "
>> >>
>> >> Dear God, please don't suggest it be used for noise like sidebars,
>> >> advertising, or non related groups of nav elements. Asides are NOT often
>> >> represented AS sidebars in printed typography, they are often
>> >> represented IN sidebars of printed typography. This distinction is
>> >> fundamentally different.
>> >>
>> >> I've never read a serious article where suddenly an aside is made where
>> >> it says:
>> >>
>> >> BUY! BUY! BUY! BUY OUR JUNK TODAY!!
>> >>
>> >> An aside is tangential to the content (as in the working draft of the
>> >> spec), this means it is related in some way, usually enriching the
>> >> information/experience rather than watering it down with nonsense.
>> >>
>> >> I beg you to reconsider your wording for this element's description.
>> >
>> > as an aside, I think I'll wait until there is some general consensus on the
>> > actual constructive usage of this sort of tag until I use it - personally I
>> > really think this is too vague.
>> >
>> > the concepts of what is structural, what is semantic and what is style are too
>> > mixed up and vague for me to worry, just yet, about the details of these new-fangled
>> > HTML5 tags (not mention browser support).
>> >
>> > [at] Rob - your browswer compability 'hack' example in another recent thread is a
>> > perfect example or the problems we face with trying to delineate between styling and
>> > semantics and as such I think I lot of what HTML5 adds is arbitrary and rather
>> > vague (the CANVAS and video stuff not withstanding)
>> >
>> > personally I don't give a hoot - browsers (and more importantly the users, and the
>> > various versions they run - and will be running for quite some time) mean that,
>> > as fas as I'm concerned, HTML5 and everything it may entail is still a pipe dream.
>> >
>> > As long as people run IE6 or IE7 (actually any POS browser that doesn't properly
>> > attempt to implement current standards) such things as semantically marked up ASIDES
>> > (as vague as the concept might) are rather irrelevant to the day to day business of
>> > building web sites/applications that accessible/relevant/usable/etc to the general
>> > public.
>>
>> I can only somewhat agree with your assessment above. It is true that
>> while many people still use broken browsers like IE6 and IE7; however,
>> this should not completely dissuade us from improving the experience for
>> those users that *do* choose standards compliant browsers. If we ignore
>> those users because we don't see the point in wasting time on the IE*
>> crowd, then we essentially weaken the argument in favour of embracing
>> standards. While IE* Joe, doesn't give a damn about whether his browser
>> supports <aside> or not, studious Jane really enjoys the enriched
>> experience her browser provides because not only does it understand
>> asides, but it provides a convenient extra facility that extracts them
>> into a browsable list with excerpts taken from the surrounding text for
>> context (inverting the relationship :). Then there's Jenny who's blind,
>> she's listening to the content on the page and hears a little ding go
>> off that indicates there's further information available that she can
>> review-- she can choose to pull it up and listen to it, after which the
>> reader returns to where she left off the original content. Alternatively
>> she may choose not to interrupt the main flow of information, but again,
>> similar to Jane's experience she can listen to each one afterwards in a
>> summarized fashion.
>>
>> This is how serious organizations, and almost certainly Government, will
>> markup their information. Regardless of whether everyone has a browser
>> that supports the information. If the semantic markup improves usability
>> and enriches the information, then it will be used to meet that purpose.
>>
>> > PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his assessment - I do enjoy
>> > his posts, he's a sharp cookie with plenty to offer and I always enjoy reading his
>> > argumentation and opinion!
>>
>> Thanks... You've got me blushing :D
>>
>> Cheers,
>> Rob.
>> --
>> http://www.interjinn.com
>> Application and Templating Framework for PHP
>>
>
> I'd say that from what I've heard, Governments aren't that good at
> getting accessible sites up, so the chances of them using HTML5
> semantically, well, the immediate future doesn't look too rosy!
>
> Also, I thought I'd throw in my tuppence as to the use of <aside>. I'd
> tend to try and relate it to a footnote in a book, or a boxout in a
> magazine article. It's not integral to the content it's related to or
> near, but acts as an aid to it should the reader wish.

I don't know about where you are, but Canadian government has very
specific guidelines on how content should be marked up... and semantic
use of tags is a clear part of that:

"The institution respects the universal accessibility
guidelines developed by the World Wide Web Consortium's Web
Accessibility Initiative by ensuring compliance of its Web
sites with the Priority 1 and Priority 2 checkpoints of the
Web Content Accessibility Guidelines 1.0 (WCAG), with the
following exception:

WCAG checkpoint 3.4 is superseded by requirement 2 of the
Common Look and Feel Standards for the Internet, Part 3:
Standard on Common Web Page Formats."

http://

Reviewing some of the WCAG guidelines...

3.3 Use style sheets to control layout and presentation.
[Priority 2]

3.5 Use header elements to convey document structure and
use them according to specification. [Priority 2]

3.6 Mark up lists and list items properly. [Priority 2]

3.7 Mark up quotations. Do not use quotation markup for
formatting effects such as indentation. [Priority 2]

5.1 For data tables, identify row and column headers.
[Priority 1]

5.2 For data tables that have two or more logical levels
of row or column headers, use markup to associate data
cells and header cells. [Priority 1]

These are just the checkpoints, further reading into the checkpoints
indicates that proper use of various tags such as <em>, <strong>,
<abbr>, <acronym>, etc should be used.

This is meant to be followed by all Canadian Government websites and
current hiring/contracting practices indicate experience with CLF2
guidelines as being a requirement.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Michael A. Peters wrote:
> If <aside> is not proper to use for this purpose, what would be?
>
> <sidebar> suggests a particular type of layout.
> <section> suggests content.
> <nav> is appropriate for some items in a side bar, but not all, and is
> often a child of how <aside> is being used.
> <div> give no semantics.
>
> I would like to see a <toc> tag for nav that serves as a table of
> contents of sorts (what I often have at the top of a side bar) but I
> suspect <nav> is considered sufficient.
>
> Maybe <sidebar> would be best, and the reference to column type layout
> can just be understood that isn't necessarily on the side?
>
> Reading up on it, I saw some suggest <figure> for what some of you want
> <aside> used for, but a <figure> is often important content and has its
> own meaning so that's not exactly appropriate.

I would lean towards <div> if there is no appropriate semantic tag to
markup the information. But in the case of ads, there really should be a
n <ad> tag :)

The problem though with semantic tags like <ad> is that it wouldn't be
used in practice by most commercial sites, because then the browser
would know exactly what to rip out (or at least plugins like adblock) *lol*.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Robert Cummings wrote:
> I don't know about where you are, but Canadian government has very
> specific guidelines on how content should be marked up... and semantic
> use of tags is a clear part of that:
>
> "The institution respects the universal accessibility
> guidelines developed by the World Wide Web Consortium's Web
> Accessibility Initiative by ensuring compliance of its Web
> sites with the Priority 1 and Priority 2 checkpoints of the
> Web Content Accessibility Guidelines 1.0 (WCAG), with the
> following exception:
>
> WCAG checkpoint 3.4 is superseded by requirement 2 of the
> Common Look and Feel Standards for the Internet, Part 3:
> Standard on Common Web Page Formats."
>
> http://

Oops, that was supposed to remind me to come back and paste the CLF2 URL:

http://www.tbs-sct.gc.ca/clf2-nsi2/index-eng.asp

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--=-Yp+hpS3PHE2ZBWsi6AFH
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-02-11 at 09:39 -0500, Robert Cummings wrote:

> Ashley Sheridan wrote:
> > On Thu, 2010-02-11 at 01:44 -0500, Robert Cummings wrote:
> >> *haha* I've removed w3.org from the recipients list... so onwards to the
> >> content below...
> >>
> >>
> >> Jochem Maas wrote:
> >> > Op 2/10/10 9:08 PM, Robert Cummings schreef:
> >> >> From the editor's draft:
> >> >>
> >> >> "
> >> >> The aside element represents a section of a page that consists of
> >> >> content that is tangentially related to the content around the aside
> >> >> element, and which could be considered separate from that content. Such
> >> >> sections are often represented as sidebars in printed typography.
> >> >>
> >> >> The element can be used for typographical effects like pull quotes or
> >> >> sidebars, for advertising, for groups of nav elements, and for other
> >> >> content that is considered separate from the main content of the page.
> >> >> "
> >> >>
> >> >> Dear God, please don't suggest it be used for noise like sidebars,
> >> >> advertising, or non related groups of nav elements. Asides are NOT often
> >> >> represented AS sidebars in printed typography, they are often
> >> >> represented IN sidebars of printed typography. This distinction is
> >> >> fundamentally different.
> >> >>
> >> >> I've never read a serious article where suddenly an aside is made where
> >> >> it says:
> >> >>
> >> >> BUY! BUY! BUY! BUY OUR JUNK TODAY!!
> >> >>
> >> >> An aside is tangential to the content (as in the working draft of the
> >> >> spec), this means it is related in some way, usually enriching the
> >> >> information/experience rather than watering it down with nonsense.
> >> >>
> >> >> I beg you to reconsider your wording for this element's description.
> >> >
> >> > as an aside, I think I'll wait until there is some general consensus on the
> >> > actual constructive usage of this sort of tag until I use it - personally I
> >> > really think this is too vague.
> >> >
> >> > the concepts of what is structural, what is semantic and what is style are too
> >> > mixed up and vague for me to worry, just yet, about the details of these new-fangled
> >> > HTML5 tags (not mention browser support).
> >> >
> >> > [at] Rob - your browswer compability 'hack' example in another recent thread is a
> >> > perfect example or the problems we face with trying to delineate between styling and
> >> > semantics and as such I think I lot of what HTML5 adds is arbitrary and rather
> >> > vague (the CANVAS and video stuff not withstanding)
> >> >
> >> > personally I don't give a hoot - browsers (and more importantly the users, and the
> >> > various versions they run - and will be running for quite some time) mean that,
> >> > as fas as I'm concerned, HTML5 and everything it may entail is still a pipe dream.
> >> >
> >> > As long as people run IE6 or IE7 (actually any POS browser that doesn't properly
> >> > attempt to implement current standards) such things as semantically marked up ASIDES
> >> > (as vague as the concept might) are rather irrelevant to the day to day business of
> >> > building web sites/applications that accessible/relevant/usable/etc to the general
> >> > public.
> >>
> >> I can only somewhat agree with your assessment above. It is true that
> >> while many people still use broken browsers like IE6 and IE7; however,
> >> this should not completely dissuade us from improving the experience for
> >> those users that *do* choose standards compliant browsers. If we ignore
> >> those users because we don't see the point in wasting time on the IE*
> >> crowd, then we essentially weaken the argument in favour of embracing
> >> standards. While IE* Joe, doesn't give a damn about whether his browser
> >> supports <aside> or not, studious Jane really enjoys the enriched
> >> experience her browser provides because not only does it understand
> >> asides, but it provides a convenient extra facility that extracts them
> >> into a browsable list with excerpts taken from the surrounding text for
> >> context (inverting the relationship :). Then there's Jenny who's blind,
> >> she's listening to the content on the page and hears a little ding go
> >> off that indicates there's further information available that she can
> >> review-- she can choose to pull it up and listen to it, after which the
> >> reader returns to where she left off the original content. Alternatively
> >> she may choose not to interrupt the main flow of information, but again,
> >> similar to Jane's experience she can listen to each one afterwards in a
> >> summarized fashion.
> >>
> >> This is how serious organizations, and almost certainly Government, will
> >> markup their information. Regardless of whether everyone has a browser
> >> that supports the information. If the semantic markup improves usability
> >> and enriches the information, then it will be used to meet that purpose.
> >>
> >> > PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his assessment - I do enjoy
> >> > his posts, he's a sharp cookie with plenty to offer and I always enjoy reading his
> >> > argumentation and opinion!
> >>
> >> Thanks... You've got me blushing :D
> >>
> >> Cheers,
> >> Rob.
> >> --
> >> http://www.interjinn.com
> >> Application and Templating Framework for PHP
> >>
> >
> > I'd say that from what I've heard, Governments aren't that good at
> > getting accessible sites up, so the chances of them using HTML5
> > semantically, well, the immediate future doesn't look too rosy!
> >
> > Also, I thought I'd throw in my tuppence as to the use of <aside>. I'd
> > tend to try and relate it to a footnote in a book, or a boxout in a
> > magazine article. It's not integral to the content it's related to or
> > near, but acts as an aid to it should the reader wish.
>
> I don't know about where you are, but Canadian government has very
> specific guidelines on how content should be marked up... and semantic
> use of tags is a clear part of that:
>
> "The institution respects the universal accessibility
> guidelines developed by the World Wide Web Consortium's Web
> Accessibility Initiative by ensuring compliance of its Web
> sites with the Priority 1 and Priority 2 checkpoints of the
> Web Content Accessibility Guidelines 1.0 (WCAG), with the
> following exception:
>
> WCAG checkpoint 3.4 is superseded by requirement 2 of the
> Common Look and Feel Standards for the Internet, Part 3:
> Standard on Common Web Page Formats."
>
> http://
>
> Reviewing some of the WCAG guidelines...
>
> 3.3 Use style sheets to control layout and presentation.
> [Priority 2]
>
> 3.5 Use header elements to convey document structure and
> use them according to specification. [Priority 2]
>
> 3.6 Mark up lists and list items properly. [Priority 2]
>
> 3.7 Mark up quotations. Do not use quotation markup for
> formatting effects such as indentation. [Priority 2]
>
> 5.1 For data tables, identify row and column headers.
> [Priority 1]
>
> 5.2 For data tables that have two or more logical levels
> of row or column headers, use markup to associate data
> cells and header cells. [Priority 1]
>
> These are just the checkpoints, further reading into the checkpoints
> indicates that proper use of various tags such as <em>, <strong>,
> <abbr>, <acronym>, etc should be used.
>
> This is meant to be followed by all Canadian Government websites and
> current hiring/contracting practices indicate experience with CLF2
> guidelines as being a requirement.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>


The good old UK, where the government is always a decade behind in the
technology stakes. There are legal requirements for accessibility, of
which semantics is a part, but often government sites seem to be some of
the worst to access from anything other than the most particular of
setups, ergo: Internet Explorer, Javascript turned on, colour monitor
(which itself assumes you're not blind), keyboard & mouse to navigate
(which assumes no motor difficulties).

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-Yp+hpS3PHE2ZBWsi6AFH--

Robert Cummings wrote:
> Michael A. Peters wrote:
>> If <aside> is not proper to use for this purpose, what would be?
>>
>> <sidebar> suggests a particular type of layout.
>> <section> suggests content.
>> <nav> is appropriate for some items in a side bar, but not all, and is
>> often a child of how <aside> is being used.
>> <div> give no semantics.
>>
>> I would like to see a <toc> tag for nav that serves as a table of
>> contents of sorts (what I often have at the top of a side bar) but I
>> suspect <nav> is considered sufficient.
>>
>> Maybe <sidebar> would be best, and the reference to column type layout
>> can just be understood that isn't necessarily on the side?
>>
>> Reading up on it, I saw some suggest <figure> for what some of you
>> want <aside> used for, but a <figure> is often important content and
>> has its own meaning so that's not exactly appropriate.
>
> I would lean towards <div> if there is no appropriate semantic tag to
> markup the information. But in the case of ads, there really should be a
> n <ad> tag :)

I don't know.
I understand making it cake for ad blockers is attractive, but I run a
web site that benefits the local community and is paid for out of my
pocket and while some donations have come in, nowhere near what it
costs. There are a few select ads (no flash or animated) and even they
don't make up the difference, but I wouldn't use something like <ad>
because I personally have taken a huge financial cut this year (20%
income reduction) yet I'm kind enough to out of pocket provide this
service, including things like a SSL certificate so that users who want
to log on can do so without fear of password sniffing etc. and I will
never charge for use of my site, so while I don't specifically look for
people running ad blockers, when they do, it kind of feels like they are
giving me the finger.

I do not mind script/flash blockers (and will never use flash ads
because of how many behave poorly and do things like expand to cover
content or flash at high rates giving headaches and possibly even
causing seizures) but I know people use ad blockers, so I host the ad
images myself which seems to neuter them, but I would never use
something like <ad> until someone paid me to, and it would have to cover
costs (which are not covered even right now even with ads).

I've been accused (once) of trying to profit from the site.
I'd post how I replied to the jerk, but I assume some children read this
list.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--=-tcK4PW1SnqfE+sOxwH3G
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2010-02-11 at 07:02 -0800, Michael A. Peters wrote:

> Robert Cummings wrote:
> > Michael A. Peters wrote:
> >> If <aside> is not proper to use for this purpose, what would be?
> >>
> >> <sidebar> suggests a particular type of layout.
> >> <section> suggests content.
> >> <nav> is appropriate for some items in a side bar, but not all, and is
> >> often a child of how <aside> is being used.
> >> <div> give no semantics.
> >>
> >> I would like to see a <toc> tag for nav that serves as a table of
> >> contents of sorts (what I often have at the top of a side bar) but I
> >> suspect <nav> is considered sufficient.
> >>
> >> Maybe <sidebar> would be best, and the reference to column type layout
> >> can just be understood that isn't necessarily on the side?
> >>
> >> Reading up on it, I saw some suggest <figure> for what some of you
> >> want <aside> used for, but a <figure> is often important content and
> >> has its own meaning so that's not exactly appropriate.
> >
> > I would lean towards <div> if there is no appropriate semantic tag to
> > markup the information. But in the case of ads, there really should be a
> > n <ad> tag :)
>
> I don't know.
> I understand making it cake for ad blockers is attractive, but I run a
> web site that benefits the local community and is paid for out of my
> pocket and while some donations have come in, nowhere near what it
> costs. There are a few select ads (no flash or animated) and even they
> don't make up the difference, but I wouldn't use something like <ad>
> because I personally have taken a huge financial cut this year (20%
> income reduction) yet I'm kind enough to out of pocket provide this
> service, including things like a SSL certificate so that users who want
> to log on can do so without fear of password sniffing etc. and I will
> never charge for use of my site, so while I don't specifically look for
> people running ad blockers, when they do, it kind of feels like they are
> giving me the finger.
>
> I do not mind script/flash blockers (and will never use flash ads
> because of how many behave poorly and do things like expand to cover
> content or flash at high rates giving headaches and possibly even
> causing seizures) but I know people use ad blockers, so I host the ad
> images myself which seems to neuter them, but I would never use
> something like <ad> until someone paid me to, and it would have to cover
> costs (which are not covered even right now even with ads).
>
> I've been accused (once) of trying to profit from the site.
> I'd post how I replied to the jerk, but I assume some children read this
> list.
>


I think ad's have and always will be part of the web. What gets up most
peoples noses, and is something you said you don't do, is flashy ads
that try to take over the screen, or ads that pretend to be some sort of
warning on your computer. I'm wise enough not to be taken by the latter
ones, but the ones that try to take over my screen (always in Flash too)
are annoying for 2 reasons: 1) older versions of the Flash player on
Linux couldn't handle transparent windowed mode in Flash, so I was left
with a big white block over the content, and 2) I just don't like ad's
that change size and move over the whole page forcing you to click on
them to get at the content that you wanted underneath.

Unobtrusive ads are fine. I can look at them or ignore them if I wish,
which is likely to get a better response than shoving them in my face.
It's for this very reason that I don't read most of the free London
newspapers, because I can't stand the people who try to shove them at me
every time I try to get a train home from work.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--=-tcK4PW1SnqfE+sOxwH3G--

Michael A. Peters wrote:
> Robert Cummings wrote:
>> Michael A. Peters wrote:
>>> If <aside> is not proper to use for this purpose, what would be?
>>>
>>> <sidebar> suggests a particular type of layout.
>>> <section> suggests content.
>>> <nav> is appropriate for some items in a side bar, but not all, and is
>>> often a child of how <aside> is being used.
>>> <div> give no semantics.
>>>
>>> I would like to see a <toc> tag for nav that serves as a table of
>>> contents of sorts (what I often have at the top of a side bar) but I
>>> suspect <nav> is considered sufficient.
>>>
>>> Maybe <sidebar> would be best, and the reference to column type layout
>>> can just be understood that isn't necessarily on the side?
>>>
>>> Reading up on it, I saw some suggest <figure> for what some of you
>>> want <aside> used for, but a <figure> is often important content and
>>> has its own meaning so that's not exactly appropriate.
>> I would lean towards <div> if there is no appropriate semantic tag to
>> markup the information. But in the case of ads, there really should be a
>> n <ad> tag :)
>
> I don't know.
> I understand making it cake for ad blockers is attractive, but I run a
> web site that benefits the local community and is paid for out of my
> pocket and while some donations have come in, nowhere near what it
> costs. There are a few select ads (no flash or animated) and even they
> don't make up the difference, but I wouldn't use something like <ad>
> because I personally have taken a huge financial cut this year (20%
> income reduction) yet I'm kind enough to out of pocket provide this
> service, including things like a SSL certificate so that users who want
> to log on can do so without fear of password sniffing etc. and I will
> never charge for use of my site, so while I don't specifically look for
> people running ad blockers, when they do, it kind of feels like they are
> giving me the finger.
>
> I do not mind script/flash blockers (and will never use flash ads
> because of how many behave poorly and do things like expand to cover
> content or flash at high rates giving headaches and possibly even
> causing seizures) but I know people use ad blockers, so I host the ad
> images myself which seems to neuter them, but I would never use
> something like <ad> until someone paid me to, and it would have to cover
> costs (which are not covered even right now even with ads).

My intent wasn't to make it easy for ad blockers, but to indicate that
for correctness that would be the appropriate semantic tag. As I later
mentioned, commercial sites wouldn't use just because it would make it
easy for ad blockers to strip :|

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

At 5:08 AM +0000 2/11/10, Jochem Maas wrote:
>rgds,
>Jochem
>
> PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his
>assessment - I do enjoy
>his posts, he's a sharp cookie with plenty to offer and I always
>enjoy reading his
>argumentation and opinion!

With the danger of Rob becoming insufferable, I enjoy and also learn
from Rob's opinion, advice, and practice. He is undoubtedly sharp and
probably too intelligent for this list. But until he realizes that,
we'll continue to gain from his contribution.

Cheers,

tedd

PS: I agree with most of what he practices except for bracket spacing. :-)

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

tedd wrote:
> At 5:08 AM +0000 2/11/10, Jochem Maas wrote:
>> rgds,
>> Jochem
>>
>> PS. from a semantics POV, Robert Cummings is, IMHO, spot on in his
>> assessment - I do enjoy
>> his posts, he's a sharp cookie with plenty to offer and I always
>> enjoy reading his
>> argumentation and opinion!
>
> With the danger of Rob becoming insufferable, I enjoy and also learn
> from Rob's opinion, advice, and practice. He is undoubtedly sharp and
> probably too intelligent for this list. But until he realizes that,
> we'll continue to gain from his contribution.

Bleh, I dunno about all that... even if I were too smart for the list, I
love the list for the feeling of community... it takes more than just me
for that feeling. I thank all the people on the list who make it a
pleasure to read and learn, and who don't take discussion/argumentation
personally. I learn many things from the members on this list too and
I'm never afraid to admit when I'm wrong. Mere discussion that exposes
the many facets of an issue is a great way to advance one's thinking
regardless of whether it confirms your original viewpoint or not. Thanks
again to all on this list.

> PS: I agree with most of what he practices except for bracket spacing. :-)

Everyone's a critic :D

Cheers,
Rob.

*lol* Almost got caught posting to W3.org again ;)

--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php