Skip to main content ↑ ↓
Topic: definition lists (Read 7073 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

definition lists

I know definition lists are nice, but... heck are a pita to deal with in javascript!
You always need two ids or rely on parent and then prev/next, I'm not a javascript expert, but I don't like that much either solutions.

What do you think about get rid of them at least in the admin panel in 1.1?
It would be cool if each pair setting/description was contained into a single container, something like:
Code: [Select]
<div class="setting" id="this_setting_box">
    <label for="this_setting" class="definition">This setting is</label>
    <span class="value"><input id="this_setting" name="this_setting" /></span>
</div>
Dunno if it make sense in terms of styling, semantics, accessibility, etc., ence the question/proposal :-[

Also, it would help in other ways: easier error/success handling (at the moment we don't have it, but I'd like to have something for 1.1, and with that it would be enough a single class on the container), it would allow to use the target selector to highlight settings when using the search, maybe something else.

Thoughts?
Bugs creator.
Features destroyer.
Template killer.

Re: definition lists

Reply #1 –

Mixed feelings regarding semantic html. That was IIRC the reason I converted the old tables from the core theme to definition lists in curve.
Thorsten "TE" Eurich
------------------------

Re: definition lists

Reply #2 –

It would be nice for the js, I don't necessarily mind the .parent .prev .next stuff, then again when you see it in the JS you tend to have to go to the markup to understand why its doing that so you can trace what element its trying to find  :P

Going to a div structure seems to me like we would be adding in a lot of divs, so I'm just wondering if there is another tag structure that may work for us?  The dl dt dd stuff is easy to understand, so maybe there is some other semantic markup that would group things nicer for JS. 

Re: definition lists

Reply #3 –

Yes, tables used for everything are a pain no matter what, I agree.

On the semantics I was reading a bit just now and TBH the arguments are not very persuasive (to me): the semantic of the form is given by the pair <label><input>, once a pair is defined give yet another pair <dt><dd> is a duplication and as such it may even be counter-productive:
http://html5doctor.com/the-dl-element/
http://webaim.org/discussion/mail_thread?thread=4960
http://webaim.org/techniques/formvalidation/

Not talking explicitly about <dl>s here, but forms and too much markup:
http://webaim.org/discussion/mail_thread?thread=4348

Not talking about forms here:
Quote> Am I just making matters
Quote worse by using a definition list,

Yes. You are not presenting any definitions, so definition list markup is
semantically incorrect. (Let's suppress the usual argument over the fact
that the <dl> element's description in HTML specifications is
self-contradictory and just state that partly due to that, the element has
little practical usefulness and is best forgotten, except perhaps for
glossaries and other constructs that are undeniably lists of
term/definition pairs.)

Quote<div id="faq1">
<h2>Is this the best way to handle a frequently asked question?</h2>
<p>Perhaps.</p>
</div>

AFAIK all current screen reader releases allow users to skip from
heading to heading.

[...]
Quote The definition list provides the closest semantically correct method
 of marking up an FAQ list, although if you really want to split hairs
 you may argue the point.

There's no case for splitting hairs. A question is not a term and an
answer is not a definition for a term. If you want to split hairs or
play with semantics, you may claim that the W3C means a description
list or annotated list or sequence of pairs, despite their use of
"definition" and "term".
Bugs creator.
Features destroyer.
Template killer.

Re: definition lists

Reply #4 –

Definition lists suck to style. I use a ul with label and input. Then again, I use bootstrap which handles this pretty well.

Code: [Select]
<li class="setting" id="this_setting_box">
    <label for="this_setting" class="definition">This setting is</label>
    <input id="this_setting" name="this_setting">
</li>

Re: definition lists

Reply #5 –

Side note (feel free to split): why doesn't the preview show the code highlighting?

Re: definition lists

Reply #6 –

Quote from: groundup – Side note (feel free to split): why doesn't the preview show the code highlighting?
probably because of my "bad implementation" :P

I'll check it ;)
Thorsten "TE" Eurich
------------------------