[Wsuug] New Web Page

[Joshua McDonald]

This kind of debate is what drives me, and many developers away from being
involved in standards groups.

Class vs ID is a non-issue and not worth a debate.  The choice to use either
one effects only the developer.  Classes make sense in some cases, IDs make
sense in others.  I have one #mainNav and one #leftSidebar ... i know I will
never have 2 of those on a single page - those are IDs to ME.  But if you
make them classes, then thats works just as well.  I think that what feels
comfortable to you has to do with where you started.  If you started with
HTML, you will probably be more in tune with the class use - if you learned
in an OOP environment, you will probably find ID/Class mixes making more
sense.

It's one of the reasons I respond infrequently to this mailing list.  The
output is all that matters.  The code is irrelevant to the task as long as
you reach the output.  This debate is about as effective as arguing "$i++"
vs "$i = $i + 1"

Sure people have written long-winded articles and probably even books about
it, but frankly, a lot of articles and books on web development are written
for the sake of writing an article or a book and generating site hits and/or
sales.

I mean no offense to anyone, honestly - but these kinds of debates are just
silly, afaik.



Joshua McDonald
Grow Interactive
www.thisisgrow.com
757-248-5274
757-248-5275 (f)


On Thu, Feb 18, 2010 at 1:20 AM, Kelley Walker <kcwalker at inkworkswell.com>wrote:

> ooooo. that's a new one. where can i read up on the semanticness conveyed
> by class v id? i was unaware that, by themselves, the class and id conveyed
> semantic meaning *as* class versus id.
>
> i always thought it was the naming that conveyed semantic meaning. thus,
> andy clarke argued for the use of "branding" to convey the meaning of what
> people often call the "header" or "masthead". Both header and masthead,
> Clarke argued, conveyed locational or positional information. heading or
> masthead might not make sense if you had a page where there was no header
> and instead a band down the side of the page or the middle contained the
> branding information.
>
> html5 decided to go with <header>.
>
> so, i've have been using a content-based workflow where i refuse to look at
> the design and only go by the _content_. i would have only taken the words
> and functiongs on the refresh mock, getting rid of everything else and
> marking it up on the basis of content only. that's the method advocated by
> clarke and by progressive enhancement enthusiasts.
>
>
>
> ken: here's is Nicole's layout:
> http://wiki.github.com/stubbornella/oocss/template
>
> notice it uses no IDs.
>
> it's a religion thing. :)
>
> i propose that the first extension of the refresh pages be called Religion.
>
>
>
> Kelley
>
> At 09:25 PM 2/17/2010, Zach Young wrote:
>
>> > Ken wrote:
>> > I totally agree with her and just think that taking her message as
>> meaning not to write IDs ever is the wrong one. For instance if there was a
>> #branding it does not mean you could not use a CSS object/class with it. I
>> just still think page structure should be ID driven, MHO.
>> >
>>
>> I tend to agree. There's also just a lot of good semanticness that can
>> be had with ids (for example the branding id.) Makes more sense
>> semantically for that to be an id than a class. Anyway, just my 2
>> cents.
>>
>> I know its out of fashion, but I'm not convinced that its bad to use a
>> fair amount of ids (regardless of whether you're styling them based on
>> id or not.) Personally I still use ids for my page structure (and
>> semantic meaning) and classes for everything else.
>>
>> Zach
>>
>> _______________________________________________
>> Wsuug mailing list
>> Wsuug at list.wsuug.org
>> http://www.thelinuxlink.net/mailman/listinfo/wsuug
>>
>
> _______________________________________________
> Wsuug mailing list
> Wsuug at list.wsuug.org
> http://www.thelinuxlink.net/mailman/listinfo/wsuug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.thelinuxlink.net/pipermail/wsuug/attachments/20100218/2fe3296d/attachment.html>