Re: transparent content model

Hi Jason,

On Aug 4, 2007, at 12:30 AM, Jason White wrote:

>
> On Fri, Aug 03, 2007 at 11:56:38PM -0500, Robert Burns wrote:
>
>> Yes, I've read the draft. It's another one of those sections  
>> that's in
>> serious need of clarification. Is your reading of that section  
>> such that
>> "block-level or inline-level elements but not both" is the content  
>> model
>> you're proposing for ALT? Or is that a different content model?
>
> My proposal is that if <alt> is at block level, then it must contain
> block-level elements.
>
> If it is at inline level, then it must contain inline-level elements.
>
> This is consistent with how I read the definition, in the draft, of a
> transparent content model: removal of the element (<alt> in this  
> instance)
> leaves a structurally correct document tree.
>

Thanks for that explanation. That's the best explanation I've see for  
what a transparent content model is (or in this case a transparent  
element type). I assume this means that, in a strictly inline -level  
context, the ALT element must have a strictly inline-level content  
(with structure inline context, it could be otherwise?). I usually  
think of this dependency occurring in the  opposite direction: where  
the existence of line-breaking elements within an element would  
necessarily turn that element into a line-breaking element itself (or  
otherwise appear like an IMG or IFRAME or inline TABLE might appear  
(sort of an inline element, but with a block/structural content  
model; in CSS3 speak an inline display role with a block display  
model). In any even,t I think the current draft needs some work  
regarding content models and element types.

However, I was thinking of an ALT element as more of a hidden element  
in visual media browsers. Something that would be there in the  
document tree, waiting to be swapped in for the primary content. In  
that sense the content model surrounding the ALT element would be  
irrelevant (however I think in this case it would be best for this  
element to just occur where block-level elements are expected).

More and more, though I think its the FALLBACK element that should be  
the one we're concerned about. This should be the element that is  
hidden or whose display is none (in CSS) in screen/print (visual)  
media. We could also have an attribute on FALLBACK to let authors  
designate whether they should be hidden or not. By not hiding the  
FALLLBACK element it would provide a way to display alternates along- 
side primary content (if that's what the author was after) . Then the  
ALT element would always occur in a FALLBACK element. The FALLBACK  
element would simply provide a container for marking up alternate  
equivalents.

Also:
On Aug 4, 2007, at 12:22 AM, Robert Burns wrote:
> The FALLBACK element's content model is thus one or more ALT  
> elements. It would need an @id set to be able to reference it with  
> the @longdesc attribute. The FALLBACK element could be used within  
> OBJECT, VIDEO, AUDIO, and CANVAS to flatten the alternatives, as  
> James called it.

I meant to write Jason. Sorry for getting your name wrong.

Take care,
Rob