Re: ISSUE-83 ACTION-152 Change Proposal for the use of dt/dd in figure and details

On Sat, Nov 28, 2009 at 10:52 AM, Jeroen van der Gun
<noreplytopreventspam@blijbol.nl> wrote:
> To Maciej:
> - If you don't try to style the dt and dd childs of figure and details
> directly, there is no problem at all.
> - If you apply styles to the figure/details element, the only thing
> you need to do is create the figure/details element through
> JavaScript. Styles of the figure/details element itself will not leak.
>
> *Maybe* XSLT provides a way to move my 'hack' into JavaScript for the
> real div haters (by translating the dd's and dt's into a new element).
> However, I pretty much don't know anything about XSLT so I'll leave
> this idea to someone else.

Actually the real div haters are the folks who came up with article,
section, figure, etc.

Me, I've never had a problem with div elements.

>
> Personally I wouldn't use JavaScript element creation in HTML5
> documents at all. Adding div and span elements does the job well, it
> does not change any semantics of the document (so it's not bad if it
> stays there longer than needed), it is not browser-specific and I
> assume the page loads faster than having to wait for an external
> script to load.
>

But it is a hack, in that it exists in order to work around browser
differences, and will, most likely, linger on long after the need for
the hack is gone.

If we need to start wrapping new HTML elements in divs and spans, what
purpose the new elements?

> This is not a reason to drop the new elements since they do provide
> additional semantic information for user agents that do support them.
> The figure element clearly links the caption of an image to the image
> itself and indicates that the contents are not part of the main
> content. User agents may use this information to enhance accessibility
> (e.g. by allowing to skip over everything related to the image) and
> search indexing bots can better understand the page. Pick a random
> page from Wikipedia with images and you have a practical application
> of the element.
>

This might be true, but figure isn't always an image. It has been
redefined to be anything from an image to a block of code. By such
redefinition, figure has lost both meaning and relevance. Now it's
nothing more than a section that may or may not be included in the
content and that is referenced in the text of the content. This usage
does not extract well from the page.

>From an accessibility perspective, accessibility doesn't mean skipping
over figures. Accessibility has always been related to providing
alternative textual information for a visual element. You definitely
don't want to reference a figure in text, and then have the figure
skipped over.

As for a caption for the figure, since it's a visual element, one
could easily provide a caption and figure pairing just by using the
img element, following by a paragraph styled appropriately beginning
with something like: Figure 1. here is some text.

And again, we assume search bots will use the img element in order to
find images. This doesn't change, figure doesn't replace img. If
search bots were to somehow pair the caption with the figure, both are
context dependent: a caption is only meaningful within the context of
its usage. If anything, search bots should use the alt text as caption
in a non-contextual setting.

Of course, I'm arguing about figure itself here, and the change
proposal has to do with not using dt/dd within figure, not
specifically about getting rid of figure.

> Jeroen van der Gun
>

Shelley

> 2009/11/28 Tab Atkins Jr. <jackalmage@gmail.com>:
>> On Fri, Nov 27, 2009 at 10:13 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>> This does seem to mitigate the concern. I'm not sure whether it completely
>>> eliminates it. Is <figure> any trickier to use correctly than other new
>>> HTML5 elements, with this technique?
>>
>> Marginally trickier.  The js hack used for the other elements is
>> conceptually simpler, but this hack doesn't depend on js being
>> available, which is a plus.  I don't think the difference in
>> trickiness is significant.
>>
>> ~TJ
>>
>
>
>

Received on Saturday, 28 November 2009 17:34:56 UTC