Re: ISSUE 30 @longdesc use cases

On Aug 23, 2010, at 4:52 PM, Jonas Sicking wrote:

> On Mon, Aug 23, 2010 at 4:14 PM, Ian Hickson <ian@hixie.ch> wrote:
>> On Mon, 23 Aug 2010, Jonas Sicking wrote:
>>>> 
>>>> Elements that are not hidden should not link to or refer to elements
>>>> that are hidden.
>>> 
>>> This, however I don't agree with. Why should this not be permitted? What
>>> problem is solved by forbidding this?
>> 
>> It solves the problem of someone accidentally linking to a section that is
>> hidden (which they obviously wouldn't do on purpose, since the hidden
>> section is by definition irrelevant, so linking to it would be pointless),
>> and then realising their mistake when the validator points it out.
>> 
>> In your suggestion, the text is not irrelevant. It's very relevant.
> 
> This is somewhat circular reasoning. You're saying that it's obviously
> a mistake to link to inside a @hidden subtree because it's disallowed.
> And it's disallowed because we want to help people find that mistake.
> 
> Why not explicitly define that elements can still refer to to parts of
> a document can refer to elements inside a @hidden subtree? I.e. define
> that @hidden just makes part of the document irrelevant to the normal
> flow of the page.
> 
> This is effectively how implementations work anyway, the elements are
> still in the DOM, and have all the usual effects there. The elements
> are just taken out of the flow, screen readers skipping the element
> when reading a page, and rendering UAs don't render the element.
> 
> Given that referring to elements inside a @hidden subtree using IDREFs
> will work in implementations (and as I understand it, are required by
> spec to work), it seems very likely that people will use this
> mechanism. So what problem is solved by forbidding it?

It's clear that you and Ian disagree, but I'm not sure new information is being provided by discussing it further on the list. Maybe time to file a bug?

Regards,
Maciej

Received on Monday, 23 August 2010 23:57:54 UTC