Re: ISSUE-95 hidden - Chairs Solicit Proposals

>>>>>>>>> meant to mark a DOM subtree pruned from all presentations on 
>>>>>>>>> all media.

I interpreted the use of the term "pruned" as being, well, like not 
there anymore, or after parsing, evermore. It got clipped off and 
never got to make a bud (node).
Hidden stuff is rejected up front, I was thinking.
So, a player in a @hidden element that was "pruned" would not be 
there, so no problem.
But I am still not understanding or missed a use case for this. .
Thank You and Best Regards,
Joe

----- Original Message ----- 
From: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
To: "Joe D Williams" <joedwil@earthlink.net>
Cc: "Jonas Sicking" <jonas@sicking.cc>; <public-html@w3.org>
Sent: Friday, January 29, 2010 5:34 PM
Subject: Re: ISSUE-95 hidden - Chairs Solicit Proposals


> Joe D Williams, Fri, 29 Jan 2010 15:36:37 -0800:
>
> Is <hidden> better than @declare/@hidden?
>
> [...]
>>>>>>>>> The hidden attribute is meant to mark a DOM subtree pruned
>>>>>>>>> from all presentations on all media.
>>
>> I am reaching some due to the <iframe with @sandbox and
>> <sandbox></sandbox>  [...] so why not an element?
>
> And then you proposed two alternatives to @hidden/@declare:
>
>> <head>
>> <mystuff [space separated strings representing name.id containers
>> that are to be hidden as quoted above] />
>> </head>
>  [...]
>> Or, in the body
>>
>> <hidden>
>> <htmlstuffthatshouldnotbeincluded... >
>> </hidden>
>
> A <hidden> element could not live up to the benefits of
> @hidden/@declare, as it would meddle with the DOM. (E.g. consider
> <hidden><caption></caption></hidden> - doesn't work.) Keeping a list 
> of
> the hidden elements in the <head> would not meddle with the DOM - 
> but
> such an extra indirection would complicate things severely.
>
> Another issue to consider w.r.t. @hidden/@declare is the earlier
> discussed the autoplay feature of <video>/<audio>: What happens to
> <video> if it is @hidden? E.g. does it still load? And so on.
> -- 
> leif halvard silli

Received on Saturday, 30 January 2010 03:25:05 UTC