Re: comments back from Compound Documents

>In January UAWG through the PF group submitted comments to Compound
>Documents group
>[http://lists.w3.org/Archives/Public/public-cdf/2006Jan/0068]
>
>the CD group has responded
>[http://lists.w3.org/Archives/Public/public-cdf/2006May/0000]
>below is a specific issue from the May message above...
><snip>
>3. Scalable Child Elements
>http://www.w3.org/TR/2005/WD-WICD-20051219/#scalable-child-formats <uawg> We
>agree with the requirements for functions user agents must support. On
>reading this section, we hoped to find something about the user being able
>to scale the destination box. For example: a user has default font size set
>to 18 points. An svg element with fixed size (100x100) is referenced in a
>document. The default font size causes the information to expand behind the
>bounding edge of the svg element. The user must now focus on the svg and
>scroll within the svg. </uawg>
>
><CDFWG> The CDF WG suggests this issue be taken up with the HTML group that
>owns the <obj> element. <CDFWG>
>
>No change was made based on this comment.
></snip>
>
><jim>On the call I used a scenario of flash content inside the object, and
>the flash content being required to provide its own scaling and scrolling
>functions because the <obj> cannot 'know' what it contains, so the <obj>
>(browser) providing the scaling functionality would serve no useful purpose.
>
>Rereading the Scalable Child elements information in the recommendation, I
>am not sure I have a clear understanding of how these compound elements are
>to interact. Will need to think of a scenario to illustrate my thoughts.
>
>Anyone else have any comments?

1. What did they say?

I think that they said you can zoom the SVG by whatever the SVG player
gives you, and show a cropped region in the frame HTML gives you, but you can't
enlarge the frame from SVG.  [not that  you can't access the Flash or SVG
view controls.  But they probably didn't say that must be able to access
them, either.]

I think we want to enlarge the frame from the browser, not from the SVG
plugin.

I think we can live with their response that the frame belongs to HTML not
SVG and hence we are talking to the HTML player, not the SVG player,
to adjust the frame.

But I think we have an ongoing issue that might best go in from CDF about
unbundling, selecting items that could be played through an alternate
player and disposing them thence.  Interactive functionality analogous
to the configuration controls to assign default players to MIME types.

And this most critically affects CDR -- where you aren't just expanding
XML in XML.

2. Example  from current practice?

Talk to Chaals about Opera.

IIRC he had some problem with the [abeit definition-confused] stuff 
about "static
images."  Opera may offer functions such as zoom the selected image, and that
may pop out a larger viewframe for the image than in the prior layout.

In other words, if there is frame resizing already implemented as a 
browser service,
then it's harder to say that the frame size stated in the HTML host 
document absolutely
has to be what is on the screen.  These are presentation parameters that should
be available for adjustment to mitigate PWD problems.

Al

>
>
>Jim Allan, Webmaster & Statewide Technical Support Specialist
>Texas School for the Blind and Visually Impaired
>1100 W. 45th St., Austin, Texas 78756
>voice 512.206.9315    fax: 512.206.9264  http://www.tsbvi.edu/
>---> Share to Win!! <---

Received on Friday, 19 May 2006 16:02:41 UTC