[whatwg] alt and title attribute exception
Hi all, The spec currently allows img without alt if the title attribute is present This is problematic for a number of reasons: 1. One of the functions of alt as implemented is that the text is displayed when images are disabled or not available . I ran some tests a while back[1] and found that while webkit based browsers display title attribute content if images are disabled or not available, IE, Firefox and Opera do not. I did a quick recheck and focund the implementations have not changed in the 2.5 years since I ran those tests. 2. title attribute content is commonly displayed as a tooltip that appears when a user moves their mouse over an element (in this case an img) It is long running issue (14 years or so) that tooltips and thus title attribute content is not displayed for keyboard only users. Browsers vendors are fully aware of the issue, but as yet there have not yet been moves to fix the issue* It is suggested that due to the current and historical implementation of title attribute display in browser, discouraging authors from using the img title=text markup pattern would result in more usable and accessible content. We could address this problem by making changes along these lines: Remove the clause in the spec [2] that makes the markup pattern conforming: The title attribute is present and has a non-empty value If at some point in the future browsers implementations change to: 1. Displaying title attribute content when images are disabled or are not available. 2. Providing input device independent access to title attribute content on non focusable elements. It would then make sense to reapply the clause so that the spec and implementation realities align. * IE 10 has implemented the display of tooltips on focusable elements, but this does not resolve the issue for non focusable elements. Note: further details of the issues are available [3] [1] http://www.paciellogroup.com/blog/misc/HTML5/alt-tests/alt-examples.html [2] http://www.whatwg.org/specs/web-apps/current-work/multipage//embedded-content-1.html#guidance-for-conformance-checkers [3] http://www.w3.org/html/wg/wiki/ChangeProposals/notitlev2 -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Re: [whatwg] Comments about the track element
Hi Silvia, [trimming a bit the text to keep the email short] Le 7/27/2012 12:35 AM, Silvia Pfeiffer a écrit : There is the SVG viewbox and there is the video viewbox. It is not immediately clear how they relate to each other. What I meant was: how to position the SVG viewbox within the boundaries of the video viewbox. It could fully cover it, but it may not need to. For example in your example with the clock, it could be positioned by coordinates of the video, e.g. left: 70%, top:30% or something like it. Then the SVG can be much smaller and it is possible to overlay other elements, too. I understand. What I'm saying is: when SVG is used as track, make it simple, both viewboxes are the same. You could, however, put SVG in WebVTT e.g. to provide overlay graphics that are non-moving or are in a loop for a certain duration of the video. E.g. an animated character (like your Rhino) could be rendered in a loop on top of a video for the first 3 minutes of the video. Agreed, why not. I don't want to take this discussion off track, but it is news to me that TTML can express frame-based animations. I indeed wouldn't mingle WebVTT and TTML layering since they satisfy the same use cases. I've seen examples like that, used to carry DVB subtitles, urgh! How does the browser support constructing SVG progressively right now? If there is a SVG-internal solution, that should be used. In this case, @mediagroup synchronization would again make the most sense. Or you just do everything in SVG. Browsers construct SVG progressively right now as they do for HTML. The parser parses the data as it receives it. @mediagroup is indeed a solution but the track has other advantages. Controlling the time when the data is received for instance with inband stored track is one. No, not really. What I meant was to draw the blue handle on top of the video not through cues, but directly in the browser. Then, the WebVTT file only delivers the according position changes for that particular time and all you need to do in JavaScript is to change the handle position in the SVG. That makes the WebVTT slimmer and not contain any SVG at all. Right, but that again requires JS, and hence incurs some processing penalty. And also, this requires a dedicated authoring while using an SVG track, you could just use any existing tool. The basic Track interface would be almost the same as the VideoTrack or AudioTrack. The GraphicsDocumentTrack interface would be used for tracks which have an underlying document (TTML, SVG, SMIL?, HTML?...) with a visual representation and not necessarily based on cues. For these documents, you are not interested in cues or cue changes (and it might not make sense to define cues). For these, you're only interested in: - the dispatch of the track content to the parser being done automatically by the browser (no need to use a JS DOMParser); - the rendering of the underlying document being synchronized (natively) by the browser, i.e. the timeline of the underlying document should be locked with the timeline of the video (or audio). No need to monitor cue changes to render the right SVG. You could discriminate between a TextTrack and a GraphicsDocumentTrack by a mime type or the inBandMetadataTrackDispatchType (not sure...). When the track carries SVG, the trackDocument object could be an SVGDocument. This would allow for controlling the SVG as if it was embedded in the HTML but for the synchronization done by the browser. What do you think? Why does it have to be a track at all? Video and audio can be synchronized to each other without one needing to be a track of the other. To use @mediagroup, you might need to consider what an SVG graphic has to provide for the MediaController [1]. There is no need to consider cues and tracks - we seem to agree on that. :-) We seem to agree on many things but not all ;) We agree that there are use cases for SVG graphics synchronize and overlayed on top of a video and that @mediagroup is a solution. The track mechanism (without cue) has several advantages: - synchronization equivalent to the @mediagroup solution - reuse of SVG native behavior (progressive loading) equivalent to the @mediagroup solution - selectability of the track using the default UI controls, just like with subtitles, without needing specific controls. - rendering on top of the video (just like subtitles) without interfering with the UI controls. - unified handling of out-of-band and in-band SVG tracks. Note, that this would be perfectly applicable to HTML/CSS animations on top of a video. It is just enlarging the scope of tracks, currently restricted (except for video and audio) to cue-based formats and text only. Regards, Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Tue, 19 Jun 2012 11:56:04 +0200, Chaals McCathieNevile w...@chaals.com wrote: On Fri, 08 Jun 2012 05:05:11 +0200, Mark Callow callow_m...@hicorp.co.jp wrote: On 08/06/2012 06:09, Ian Hickson wrote: The dire warning doesn't work. I'm just saying that's the direction that operating system vendors have been going in; that disallowing it in the browser case is not a different direction, it's consistent with the industry's direction as a whole. The platform providers want control so they can extract money from application developers; Sure. Although in most cases they are not in a position to enforce this. You *can* choose another browser - or even make your own. If you don't, then you're failing to keep your side of the freedom bargain (the price of freedom is eternal vigilance) they do it under the guise of safety security so people will go along with it. Governments get control over people in the same way. The comment is sometimes true. It is also true that users get very upset *at the browser* when it permits things to happen that they hadn't expected. The same-origin security policy that is rampant on the Web is clearly unhelpful in many ways. And doesn't have any particular benefit for browser manufacturers, except that it protects users. In both cases it is an existential threat to freedom and civil liberties. I think that is overstating the case. A *lot*. Nobody forces you to follow the way this is specified. You can just implement something different, and nobody will stop you. That happens all the time, for different issues. It is simply untrue to say that nobody will *let* you make your own browser. We write the spec so you can more easily figure out how to make it compatible with the web - in other words, to *help* you do so. I wish this were the case, however it does appear that websites, are trying to control the platform. They do this via their terms of use and by twisting laws to suit them. There was a recent case in which Google took down a website that presented audio from youtube videos, stating terms of use violations and copyright laws. This service could well be viewed as a cloud web browser that was presenting the content in a format requested by the users. There are many other terms of use that attempt to place significant restrictions on use. If it can ever be claimed that HTML is a standard suited to delivery of digital content on the terms stated by websites then it will be a significant loss. Adding virtual browser app support would make it so easy to develop and share customized web browsers that it would be near impossible for websites to enforce restrictions. It would also empower users of devices with a fixed browser to still be able to have a web app that suits their needs. It is very easy for devices to lock out other native browsers, but if custom browsers apps become popular then such devices would be less attractive which would place pressure on them to open up. The browser app need not have any more privilege than any other webpage. It can manage its own navigation tabs and history. It could even be of utility if it was unable to save files. For example, a browser app could implement privacy strategies to minimize fingerprinting and tracking etc. The Firefox OS project is developing an implementation and I think this is a really exciting development that could empower web users. It would help web users use their browser in the manner they want rather than as dictated by websites. I will try to assist the development of this feature and to make an implementation available as a modification to Firefox if it does not get official support in Firefox. There are some real concerns relating to the trust users place in the browser apps. However these apps could be curated as for current add-ons. cheers Fred
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
Fred Andrews freda...@live.com schrieb am Fri, 27 Jul 2012 13:52:28 +: […] I wish this were the case, however it does appear that websites, are trying to control the platform. They do this via their terms of use and by twisting laws to suit them. There was a recent case in which Google took down a website that presented audio from youtube videos, stating terms of use violations and copyright laws. This service could well be viewed as a cloud web browser that was presenting the content in a format requested by the users. There are many other terms of use that attempt to place significant restrictions on use. If it can ever be claimed that HTML is a standard suited to delivery of digital content on the terms stated by websites then it will be a significant loss. That multimedia platform providers like Google can (and might even be obligated to) do this is foremost a sociopolitical, legal and ethical problem, not a technical one. While software can provide a short-term gain, a conflict like this cannot be solved by technical means alone. And as the multimedia codec story has shown, major players are not obligated to do as the spec says. As many will probably remember, three years ago, Apple did not implement support for the royalty free codecs Vorbis and Theora, citing submarine patent concerns. Google, Mozilla and Opera however did. Fast-forward to VP8 implementation, same story. Regarding making royalty-free formats part of the specification, Hixie stated: “Unfortunately, it seems that this would not force Apple to implement it.” and “if a browser refuses to implement something, then we can't require it.” The specification can therefore only be descriptive – not prescriptive. Based on this, I would argue that specifying user-friendly features is outside the scope of the WHATWG. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020620.html http://www.freesound.org/data/previews/73/73581_634166-lq.ogg (Btw, Hixie stated the following to be a possibility: „Google ships support for the codec for long enough without getting sued that Apple's concern regarding submarine patents is reduced.“. Any update on that?) Adding virtual browser app support would make it so easy to develop and share customized web browsers that it would be near impossible for websites to enforce restrictions. Userscripts exist. AdBlock Plus exists. In fact, the four most popular Firefox extensions all can be used to subvert the intention of content providers – with VideoDownloadHelper, I would even assert that this is its only purpose. We are living in a world in which the Browser is primarily a “User Agent” – not an author or corporate one, as you fear. https://addons.mozilla.org/en-US/firefox/extensions/?sort=users It would also empower users of devices with a fixed browser to still be able to have a web app that suits their needs. It is very easy for devices to lock out other native browsers, but if custom browsers apps become popular then such devices would be less attractive which would place pressure on them to open up. JavaScript can already be used to implement codecs and even run Linux on user-hostile, locked-down hardware like iDevices or Android gadgets. I assert it is only a question of how much time someone wants to invest, how soon there will be an X server or framebuffer followup. http://libwebpjs.hohenlimburg.org/vp8/webm-javascript-decoder-2/ http://bellard.org/jslinux/ Be aware, everything that makes user-hostile hardware more suit the needs of users while still maintaining a lockdown is only strenghtening the platform in question, making it appear not-so-bad in comparison to competition where you have a root password for devices you own. I will try to assist the development of this feature and to make an implementation available as a modification to Firefox if it does not get official support in Firefox. I am looking forward to your Firefox extension. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] CSS Filter Effects for Canvas 2D Context
On Thu, Jul 26, 2012 at 11:42 AM, David Geary david.mark.ge...@gmail.comwrote: On Mon, Jul 16, 2012 at 2:02 PM, Ashley Gullen ash...@scirra.com wrote: I'd like to bring up this subject again especially now that first implementations are starting to appear. IMO the big use case here is games - the CSS filters are great for interesting visual effects. However there doesn't seem to be a way to use them in canvas rendering, other than applying the effect to an entire canvas. Games typically want to apply effects to individual objects (meaning individual drawImage() calls), and there is no good way to do this. Stacking separate canvas elements is out of the question, because it makes Z ordering with effects impossible. Consider trying to overlay an image with no effect on top of an image with an effect. Also consider the fact canvas has compositing modes like lighter and destination-out, but CSS filters do not provide these. This makes it impossible to combine CSS filters and composite modes. An example is displaying an additive blended explosion (typical in games) on top of an image with a blur CSS filter, which seems to be impossible to achieve at all. Forcing developers to use CSS with Canvas to get high-level *graphics* functionality is just plain wrong. If anything, it's completely backwards. Why do we arbitrarily restrict high-level graphics functionality such as filters and composite modes to individual technologies like CSS and Canvas? I'm completely unaware of the advantages of such an approach. The term CSS filters is absurd. I think Ashley's point was to make CSS shaders-like functionality available in Canvas. Filters are an important high-level graphics capability that should be available to any HTML5 technology that chooses to incorporate them. I agree with Ashley, let's get them into Canvas. One way to define this is to specify that drawImage(), when passed another canvas as a parameter, must take in to account the canvas' 'filter' CSS property. So to draw an image with a blur you'd render using an intermediate canvas, e.g. tempcanvascontext.drawImage(myimage, 0, 0); tempcanvas.style.filter = blur(10px); gamecanvascontext.drawImage(tempcanvas, 0, 0); // draws with blur Another way would be just to add a 'filter' property to the 2D context, e.g.: gamecanvascontext.filter = blur(10px); gamecanvascontext.drawImage(myimage, 0, 0); This would also be extremely powerful if custom CSS shaders are also supported, allowing for user-written effects in the canvas 2D context. Effects should should apply to all drawing operations for consistency, including lines, paths, rectangles and patterns. I like the filter attribute on the context, provided that it's part of the state saved by save(): gamecanvascontext.drawImage(...); // image drawn normally gamecanvascontext.save(); gamecanvascontext.filter = '...'; gamecanvascontext.drawImage(...); // image drawn w/filter gamecanvascontext.restore(); gamecanvascontext.drawImage(...); // image drawn normally The default filter could be a no-op, which would be similar in behavior to the default clipping region (they would both do nothing). This looks very reasonable. On another note, wouldn't it be nice if you could add a grouping operator such as this: gamecanvascontext.filter = '...'; gamecanvascontext.beginGroup(); ... // lots of drawing operators gamecanvascontext.endGroup(); and have everything in that group at endGroup time? I have no idea if this is easy for implementers (would appreciate comments on that), but hopefully the CSS filter rendering can be recycled with drawImage(). Another argument is that you should just use WebGL and write shaders for advanced effects. It's a poor argument, IMO. We should leave 3D for WebGL, but make advanced effects available to all interested technologies. This is an option, but given that a filter effect can be applied to an entire canvas, it seems a waste not to enable it for individual draw calls, especially given the 2D context is considerably easier and quicker to code for. Agreed. David Ashley Gullen Scirra.com On 25 January 2012 16:26, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jan 25, 2012 at 6:41 AM, David Geary david.mark.ge...@gmail.com wrote: On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin cmar...@apple.com wrote: Adding filter functions to canvas would require you to re-render the items for every filter change and you'd have to animate it all yourself. Sure, but you must create a superfluous canvas for each set of images that you animate, and invoke an entirely different technology to apply the filter. You must make sure that those superfluous canvases have transparent backgrounds, no borders, and have the correct Z order so they appear over, and not under, the
