I would have put the <code> inside a <div> ... can it go inside a <dl>
without breaking the xhtml validatio tool?
and I would class the code, so as to not conflict with the normal
<code> tags that may wind up on the page.
You and I are on the same page!
On 10/30/06, Paul McLanahan <[EMAIL PROTECTED]> wrote:
> The main reason I'm trying to avoid non-spec attributes is for code
> longevity. We maintain around 1500 sites, many of which are getting old. So
> we've been bitten by past bad coding practices more than most. Our policy
> because of this is to do all new sites completely up to XHTML 1.0
> Transitional (our QA team even validates with CSE). So, while there isn't
> much danger in a non-standard attribute on a few <ul>s, it would really suck
> for us for the spec to change in a few years and for the new browsers to be
> using the attrib that we hijacked for a plugin for something we didn't
> intend. I know it's highly unlikely, but it's a concern when dealing in the
> volume we do. Massive retrofit efforts are to be avoided at all costs.
>
> That said, I don't think the risk on this one outweighs the potential
> rewards, so I might do it anyway. I'm agreeing with you guys though about
> the title attrib that since it is already expected to have some semantic
> meaning it would be worse to hijack it than to make one up.
>
> @jake
> I'm really liking the <code> tag idea. If I'm understanding you correctly,
> it would work something like associating a label to an input using the "for"
> attribute. I'd just be associating a code tag's contents with a specific DL
> either by location in the markup or maybe by some specific classes. That
> might prove to be the easiest and most semantically correct solution.
>
> I don't know about you guys, but this situation has come up a lot in JS I've
> written and want to write. So if we could standardize a "jQuery way" of
> accomplishing this then I think it would be helpful to all plugin authors.
> Much like the standardization of the options object overriding the defaults
> using $.extend in the plugin docs. Right now I'm liking Jake's suggestion.
> My thinking is that it would work something like this (not tested):
>
> // get options (assuming we're in an each loop and "this" is a DL node)
> if($(this).prev().is('code')){
> eval("thisOpts = {" + $(this).prev('code').text() + "}");
> $.extend(options,thisOpts);
> }
>
> Which would work on some markup like this:
>
> <code>accordion:false,showSpeed:'slow',hideAll:true</code>
> <dl class="accordion">
> <dt>click me</dt>
> <dd>to show me</dd>
> </dl>
>
> Then either hide all code tags in the CSS or give the code tag a class if
> you don't want to hide them all.
>
> Thoughts?
>
> On 10/30/06, Brandon Aaron <[EMAIL PROTECTED]> wrote:
> > On 10/30/06, Kurt Mackey <[EMAIL PROTECTED]> wrote:
> > > That's strange, unless one of your custom attributes happens to be
> > > "runat='server'".
> >
> > No we had issues with the form tag and custom attributes with a
> > namespace specifically. Nothing special just something like:
> > ch:validate="true" and .net would blow up. Of course it was only if
> > the form tag was runat server.
> >
> > --
> > Brandon Aaron
> >
> > _______________________________________________
> > jQuery mailing list
> > [email protected]
> > http://jquery.com/discuss/
> >
>
>
>
> _______________________________________________
> jQuery mailing list
> [email protected]
> http://jquery.com/discuss/
>
>
>
--
Ⓙⓐⓚⓔ - יעקב ʝǡǩȩ ᎫᎪᏦᎬ
_______________________________________________
jQuery mailing list
[email protected]
http://jquery.com/discuss/
