- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Sun, 24 Jan 2010 16:44:39 -0600
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, James Craig <jcraig@apple.com>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
- Message-ID: <OF4171A8D1.CC48A1D7-ON862576B5.007BB5E3-862576B5.007CF012@us.ibm.com>
Hi Maciej, I understand. I have two concerns with this approach: 1. id names are not reserved. Potentially, and although remote, an author could randomly have chosen those id's. We want to have reserved CSS Properties that may applied to any web page. 2. Authors may wish to choose a src file to be rendered. Companies are providing public APIs out there to provide reusable content such as a Google Map and with a small parameter change the driving directions. We should allow authors to provide entire remote fragments as alternatives to canvas to pul into a web page. Here are three versions of the driving directions: http://maps.google.com/maps?f=d&output=html&hl=en&q=3832+royal+troon+drive +Round+Rock%2C+78664+to+11501+burnet+road+austin +78758&dirmode=walking&ie=UTF8&dirflg=w http://maps.google.com/maps?f=d&output=map&hl=en&q=3832+royal+troon+drive +Round+Rock%2C+78664+to+11501+burnet+road+austin +78758&dirmode=walking&ie=UTF8&dirflg=w http://maps.google.com/maps?f=d&output=kml&hl=en&q=3832+royal+troon+drive +Round+Rock%2C+78664+to+11501+burnet+road+austin +78758&dirmode=walking&ie=UTF8&dirflg=w Rich: Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Maciej Stachowiak <mjs@apple.com> To 01/22/2010 06:10 Richard PM Schwerdtfeger/Austin/IBM@IBMUS cc James Craig <jcraig@apple.com>, Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, HTML WG <public-html@w3.org> Subject Re: Canvas Accessibility Next steps On Jan 22, 2010, at 2:36 PM, Richard Schwerdtfeger wrote:>, Let's discuss on Monday's call Canvas accessibility call. The CSS media query for HTML 5 is bound to there being things like an audio and video media element. The media query is used to select the appropriate content. This is why we need to have a visual ( or screen media type) as an alternative. I would be happy to have the media types as DOM attributes but the current HTML 5 spec. defines media types as elements in the DOM instead. I am trying to stay consistent. HTML 5 defines a <video> and <audio> tag to define media types vs. <div media="audio">/ Actually, for purposes of showing or hiding different chunks of content, you can just use CSS media queries through straight CSS. Let's say you have this markup: <canvas id="my-app-ui"> <div id="visual"> ... </div> <div id="high-contrast"> .... </div> <div id="audio"> ... </div> </canvas> You can just use this style: <style> #my-app-ui > #visual { display: block; } #my-app-ui > #high-contrast { display: none; } #my-app-ui > #audio { display: none; } @media (aural) { #my-app-ui > #visual { display: none; } #my-app-ui > #high-contrast { display: none; } #my-app-ui > #audio { display: block; } } @media (high-contrast) { /* suggested future CSS media type */ #my-app-ui > #visual { display: none; } #my-app-ui > #high-contrast { display: block; } #my-app-ui > #audio { display: none; } } </style> This technique is fully general and can apply to selection from multiple content sets in just about any context. The only reason <video> and <audio> need a special feature for their <source> elements is because in that case, the choice is not a matter of whether an element is rendered, but rather of choosing a media item to be presented by a parent element. But <canvas> can do the same thing without the need for special features. Regards, Maciej
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic32495.gif
- image/gif attachment: ecblank.gif
Received on Sunday, 24 January 2010 22:45:20 UTC