- From: Ian Jacobs <ij@w3.org>
- Date: Sat, 21 Apr 2001 12:02:56 -0400
- To: Al Gilman <asgilman@iamdigex.net>
- CC: w3c-wai-ua@w3.org
Al Gilman wrote: > > At 07:29 PM 2001-04-18 -0400, Ian Jacobs wrote: > >Hello, > > > >During my recent visits to Microsoft and RealNetworks, a couple > >of issues arose while reviewing the 9 April 2001 draft [1]. > >Please see my comments below. > > > > AG:: I can't tell from the styling of this communication > what is yours and what is the commenter's. Sorry, these are notes that I took for myself (based on the discussion). These are not formal review comments from MS or RN. Thanks for your comments, Al. My comments below preceded by IJ:. > >[1] > <http://www.w3.org/TR/2001/WD-UAAG10-20010409/>http://www.w3.org/TR/2001/WD- > UAAG10-20010409/ [snip] > >---------------------------------------------------------- > >Issue 4: Conformance for some formats only must be clarified > >[Proposal] > >---------------------------------------------------------- > > > >It is my understanding that our document allows conformance for a > >subset of all formats implemented by the user agent. For > >instance, the claimant might choose to claim conformance for HTML > >and PNG, but not for JPEG, even if it implements JPEG. Imagine a > >media player that implements 20 formats. A developer may not wish > >to claim conformance for all 20, and shouldn't be required to. > > > >Checkpoint 2.1 reads: > > > > "For all format specifications that the user agent implements, > > make content available through the rendering processes > > described by those specifications." > > > >I think that "for all" needs to be restricted to "for all that > >are part of the conformance claim". I think the same change needs > >to be made for checkpoint 2.2 ("For all text formats..."), > >8.1 ("of all implemented specifications"), and 8.2. > > > >I'm not sure how to rewrite them (as I don't want to mention > >conformance in the checkpoints if I can avoid it). Something like > >this might be reasonable: > > > ><NEW 2.1> > >For the format specifications implemented to satisfy the > >requirements of this document, make content available through > >the rendering processes described by those specifications." > ></NEW 2.1> > > > >------------------ > > > ><OLD 2.2> > >For all text formats that the user agent implements, provide > >a view of the text source. > ></OLD 2.2> > > > ><NEW 2.2> > >For text formats implemented to satisfy the requirements > >of this document, provide a view of the text source. > ></NEW 2.2> > > > > AG:: I would like to have an example of hardship imposed by the simpler rule > before considering this level of hair. That is for 2.1 and 2.2, I don't see > the problem. 8.1 is another matter. IJ: I don't think it's a question of hardship, just of conformance consistency. I have been talking to vendors and saying "the conformance model allows you to conform for certain formats only, so if you implement 3 video formats, but only meet the requirements for two of them, you can still conform for those two." Therefore, statements such as "for all formats that you implement" seem inconsistent with the desired flexibility in the conformance model. > >------------------ > > > ><OLD 8.1> > >Implement the accessibility features of all implemented > >specifications (etc.). > ></OLD 8.1> > > > ><NEW 8.1> > >Implement the accessibility features of all specifications > >implemented to satisfy the requirements of this document (etc.) > ></NEW 8.1> > > > >------------------ > > > ><OLD 8.2> > >8.2 Use and conform to ... > ></OLD 8.2> > > > ><NEW 8.2> > >8.2 To satisfy the requirements of this document, > > use and conform to ... > ></NEW 8.2> > > > > AG:: This is a genuine problem. The browser configuration item does not > decide > whether it implements Flash or not. It just checks locally for a compatible > handler for the medium. IJ: I'm not sure I understand. It's true that the browser doesn't decide, but the claimant does (by including the Flash plug-in in the claim). > >---------------------------------------------------------- > >Issue 5: Checkpoint 3.3 (blinking/animation) and streams > >[No proposal] > >---------------------------------------------------------- > > > >What is the relationship between streaming and animated text? > >Animated text may be part of a text stream (so the text content > >is not all available at time "t"). How should the animated text > >be rendered as motionless text (per 3.3) in that case? > > > >I don't think that the user agent should have to wait for the > >entire text stream to render part of it as motionless text. > > > >I can imagine the "subtitles" technique, where a phrase of text > >is rendered for a few seconds, then another phrase, etc. (I > >don't think that this should be considered an animation, since > >this is not a "visual movement effect" as mentioned in the > >glossary.) Furthermore, in this case, I don't think there's > >interaction between checkpoint 3.3 (animated text) and 2.6 > >(respect synchronization cues). > > > > AG:: Who is saying what, here? I can't follow the boundaries of 'animation' > in any of the above. > > Yes, there is interaction between 3.3 and 2.6 where timed text captions are > synchronized with a video, for example. Stopping the text from changing will > (depending on the SMIL synchronization details as discussed above) sometimes > require that the video be stopped. IJ: I would distinguish animated text (by which I mean scrolling along the bottom of the screen) from changing text (e.g., as subtitles in a movie are replaced by new subtitles after a few seconds, and in synchrony with the video track). There is an issue here: define "blinking". Do changing subtitles count as blinking text? (I hope not.) At what rate does blinking start? > There may be a requirement buried in here for a pop-on presentation method to > be an option for any timed-text stream, but we haven't studied it in enought > detail to define a hard and fast requirement. > > >---------------------------------------------------------- > >Issue 6: Checkpoint 4.6: Captions positioning > >[Proposal] > >---------------------------------------------------------- > > > >What happens when the author has laid out captions with some > >particular constraints (e.g., take up fifty percent of the > >parent's available horizontal width and be centered within that > >width)? Should the user be able to override that? What happens to > >the rest of the layout? > > > >Checkpoint 4.6 reads: "For graphical viewports, allow the user to > >position text transcripts, collated text transcripts, and > >captions in the viewport." However, I can imagine techniques > >(that might even address the previous question) where a solution > >would be to render the captions in a separate viewport (i.e., not > >in the same viewport, which is suggested by the end of 4.6). Did > >we mean to exclude the technique of rendering in a separate (and > >positionable) viewport? > > > >Proposed: > > > ><NEW 4.6> > > "For graphical viewports, allow the user to position text > > transcripts, collated text transcripts, and captions in the > > same or another viewport." > ></NEW 4.6> > > > >For example, the user might be able to select captions and > >"extract them" from the presentation into a second viewport, > >leaving the layout otherwise intact. > > > > AG:: I do not concur with this proposal. In the earlier discussion, we > pointed > out that this positioning capability was so a low vision user could control > what portion of the video is adjacent to the captions and hence visible within > the cropped effective viewport along with the captions when the user is > using a > high power of magnification. Moving the captions into a separate window > prevents the user from having the juxtaposition capability they need. IJ: I'm not sure I agree. I was aware of this case when I made the proposal. It seems like an implementation detail to me whether the captions track is moved to a global x,y that happens to be in the same viewport, or whether it is put in a new viewport that is then moved to the same global x,y. One difference might be that the new viewport has chrome to it, and that chrome might get in the way of the video content behind it. But suppose it doesn't have a lot of chrome? Then it seems to me to provide the same functionality, but the ability to move the viewport is provided by the windowing system, not the user agent directly. > Another viewport is sometimes desirable, but does not satisfy this > requirement. > > What happens to the rest of the layout? It is unaffected, as if grouped into > wallpaper, for the purposes of positioning the caption display. IJ: Yes. - Ian -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 831 457-2842 Cell: +1 917 450-8783
Received on Saturday, 21 April 2001 12:03:05 UTC