Re: Accessibility/SEO and IDs?

I should correct my earlier e-mail about ID attributes and SEO.  It
turns out that the HTML standards may soon include header and footer
(etc) elements based on the amout of sites using DIVs with those IDs. 
It was a search engine company that provided that information to the
standards folks, which is where I confused the issue.  My apologies.

In regards to Anthony's statement, "since it's an id, it should only
be on the page once....if your page load time is effected by the id
attribute, you've got bigger problems," I don't think that is
completely accurate.  True, a given ID should only appear once in a
document, but your document can have as many IDs as it does elements. 
So shortening their names can certainly shorten the total size of
outputted content.  This is a valid thought on the part of site owners
with cheaper hosting whose sites could receive bursts of traffic. 
Serving 100 extra bytes several thousand times can add up.  If it adds
up enough, it can cost you down time or extra money.  Just a thought.

Jim

On 3/22/06, Anthony Ettinger <[email protected]> wrote:
> On 3/22/06, Chris <[email protected]> wrote:
> > If you work in a team, there's the benefit of whoever does the CSS, or
> > ties in backend code, etc, has a better chance of discerning one chunk
> > of HTML from another and its purpose.
> >
> >  From a user's perspective, remember that every ID can be targeted as an
> > anchor, i.e.: blah.html#list_of_shopping - that can be useful if for
> > example, you want to link someone to a specific section of a long page
> > they want to read. Personally, I'll occasionally View Selected Source in
> > Firefox to get IDs like that and add them into a link I send to people
> > on occasion. That's an extremely geeky use of the capability, but the
> > point is, there are uses... probably some far less geeky than my own. So
> > you may as well make them user-friendly.
> >
> > Lastly, you're going to run into overlap with short IDs... but if small
> > HTML is of the utmost importance for some reason, the shorter IDs may be
> > a better fit.
> >
> > -Chris
> >
> > Seb Frost wrote:
> > > Is there any reason (other than to make your own work/maintenance easier) to
> > > use semantic IDs on your webpages?
> > >
> > > In other words, does <div id="header"> benefit anyone other than the coder
> > > over <div id="h">?
> > >
> > > I'm all for cutting down on any bytes that don't need to be sent to the
> > > browser, and if working by myself I'd quickly get used to shorthands like
> > > this, and they wouldn't proove to be a maintenance headache at all, for me.
> > >
> > > But is there a benefit to longer IDs?  Will search engines pick up on <ul
> > > id="list_of_shopping"> or is <ul id="l"> just as good?
> > >
> > > cheers
> > >
> > > Seb
> > >
> > >
> > >
> > > Unsubscribe
> > > [email protected]
> > >
> > > List info
> > > http://www.quirksmode.org/dom/list.html
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Unsubscribe
> > [email protected]
> >
> > List info
> > http://www.quirksmode.org/dom/list.html
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
> microformats are on the rise, but I would stop short of saying it
> makes a difference in Google serps.
>
> The main concern should be readability. id="header" makes much more
> sense than id="h".
>
> since it's an id, it should only be on the page once....if your page
> load time is effected by the id attribute, you've got bigger problems
> :-)
>
>
>
> --
> Anthony Ettinger
> Signature: http://chovy.dyndns.org/hcard.html
>
>
> Unsubscribe
> [email protected]
>
> List info
> http://www.quirksmode.org/dom/list.html
> Yahoo! Groups Links
>
>
>
>
>
>
>


Unsubscribe
[email protected]

List info
http://www.quirksmode.org/dom/list.html 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/wdf-dom/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/