Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you want to provide an alternative for time-based media (in WCAG 2's phrase), then you want a method that can scale to contain semantic information, such as indicating language changes (lang) or changes of speaker (dialog). Here's how WCAG 2 defines alternative for time-based media: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing. http://www.w3.org/TR/WCAG20/#alt-time-based-mediadef Here's just three ways you could do this without changing HTML5, assuming the incorporation of WAI-ARIA: 1. figurelegendBall acceleraton.detailsA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./details/legendvideo.../video/figure 2. video title=Ball acceleration aria-describedby=alternative.../videop id=alternativeA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./p 3. video title=Interview with Barack Obama aria-describedby=transcript-link.../videoa href=transcript.html id=transcript-linkTranscript of Interview with Barack Obama/a See also: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (proposal for using aria-describedby in place of longdesc): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 WCAG 2 Technique G159: Providing an alternative for time-based media for video-only content: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G159 WCAG 2 Technique G58: Placing a link to the alternative for time-based media immediately next to the non-text content http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G58.html Do these features meet your requirements? If not, why not? -- Benjamin Hawkes-Lewis
Re: [whatwg] Codecs for audio and video
Hi Sam, On Sun, Aug 09, 2009 at 03:23:15PM +0100, Sam Dutton wrote: As an aside to Chris McCormick's comments, I wonder if it might also be useful/possible/appropriate (or not) to provide access to media data in the way that the ActionScript computeSpectrum function does: http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/media/SoundMixer.html#computeSpectrum%28%29 Sample visualization using Canvas with computeSpectrum: http://www2.nihilogic.dk/labs/canvas_music_visualization/ If the set of signal vector operators came with an FFT operator, which they definately should, then this would be taken care of in a way which would look pretty similar to that API. Best, Chris. --- http://mccormick.cx
[whatwg] Expose event.dataTransfer.files accessor to allow file drag and drop
PROPOSAL When the user drags-and-drops files onto a web page, we should expose those files to the page via a files accessor on the dataTransfer property of the event object. This feature is consistent with HTML 5's security model for drag and drop. I wasn't clear on this part -- how is the proposal consistent with the HTML5 drag drop security model? ~noel
Re: [whatwg] Alt attribute for video and audio
On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: On 10/08/2009 04:05, Remco wrote: A title is a short description, and could be the movie title in the case of a video element. WCAG 2 1.1.1 requires that: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. title and aria-labelledby seem sufficient for this purpose. So do figure and legend: http://dev.w3.org/html5/spec/Overview.html#the-figure-element An alt is a textual alternative for the content. [snip] For video, audio, object, iframe, this is a little sparse. [snip] But Elephants Dream may not be a good example for a video where an alt text would be useful. It's simply too complicated to replace with alternative text. But if you have a short video that explains something on Wikipedia, it would be tremendously helpful if the alt text would convey the same meaning. A video of a ball falling to show what gravity is, could have the alt text: A ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second.. If you want to provide an alternative for time-based media (in WCAG 2's phrase), then you want a method that can scale to contain semantic information, such as indicating language changes (lang) or changes of speaker (dialog). Here's how WCAG 2 defines alternative for time-based media: document including correctly sequenced text descriptions of time-based visual and auditory information and providing a means for achieving the outcomes of any time-based interaction Note: A screenplay used to create the synchronized media content would meet this definition only if it was corrected to accurately represent the final synchronized media after editing. http://www.w3.org/TR/WCAG20/#alt-time-based-mediadef Here's just three ways you could do this without changing HTML5, assuming the incorporation of WAI-ARIA: 1. figurelegendBall acceleraton.detailsA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./details/legendvideo.../video/figure 2. video title=Ball acceleration aria-describedby=alternative.../videop id=alternativeA ball accelerates as it moves down. Next to the ball's trajectory, a speedometer increases with 9.8 m/s per second./p 3. video title=Interview with Barack Obama aria-describedby=transcript-link.../videoa href=transcript.html id=transcript-linkTranscript of Interview with Barack Obama/a See also: WAI CG Consensus Resolutions on Text alternatives in HTML 5 (proposal for using aria-describedby in place of longdesc): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 WCAG 2 Technique G159: Providing an alternative for time-based media for video-only content: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G159 WCAG 2 Technique G58: Placing a link to the alternative for time-based media immediately next to the non-text content http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G58.html Do these features meet your requirements? If not, why not? -- Benjamin Hawkes-Lewis A longdesc is not the same as an alt, in that a longdesc is a long description of the content, while an alt is alternative actual content. This distinction may in practice be unnecessary though. And I see that the WAI has redefined alt to mean a short description. Does this mean that the alt attribute and longdesc attribute for images can be combined and deprecated in favor of aria-describedby or a figure/legend combo? It would make the HTML spec more consistent. So instead of this: img title=Tank Man alt=A man stands in front of a column of three tanks. longdesc=page-about-tank-man-photo.html src=tankman.jpg We would get this: img title=Tank Man aria-describedby=tank-desc src=tankman.jpg p id=tank-descA man stands in front of a column of three tanks. a href=page-about-tank-man-photo.htmlMore information/a./p Or this: figure legendTank Man/legend img src=tankman.jpg detailslegendAlternative content/legendA man stands in front of a column of three tanks. a href=page-about-tank-man-photo.htmlMore information/a/details /figure And for an iframe: iframe title=Cool Widget aria-describedby=widget-desc src=http://cool-widget.example.com/user/remco; p id=widget-descAll visiting IP addresses and their browsing history as tracked by Example Inc. are displayed in a list. a href=bigbrother.htmlMore information/a./p Or: figure legendCool Widget/legend iframe src=http://cool-widget.example.com/user/remco; detailslegendDescription/legendAll visiting IP addresses and their browsing history as tracked by Example Inc. are displayed in a list. a href=bigbrother.htmlMore information/a./details /figure One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for
Re: [whatwg] Test results for xmlns:foo attribute preservation across all browsers
Charles McCathieNevile wrote on 8/6/2009 2:24 PM: On Thu, 06 Aug 2009 15:12:07 -0400, Manu Sporny mspo...@digitalbazaar.com wrote: The test ensures that attributes originating in the markup of an HTML4 document are preserved by the HTML parser and are preserved in the DOM. [...] http://html5.digitalbazaar.com/tests/xmlns-attribute-test.html We have verified that xmlns:-style attributes are preserved in the following browsers: Also works in the latest Opera 10 Beta 2 plus Unite snapshot. Opera 10 - Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00 (yeah, the UA string is like that because important websites with browser sniffing check version numbers, but only the first digit. I.e. they can't count to ten yet). The issue now is that websites that can't count to ten will not realize it because their site continues to function properly. And for sites that can count to ten, well, you've broken them too. My own sniffer reports version 9.80 for the above UA string whereas if it was still in the normal Opera format, it would correctly report version 10.00. - Bil
Re: [whatwg] Alt attribute for video and audio
On 10/08/2009 15:42, Remco wrote: On Mon, Aug 10, 2009 at 8:53 AM, Benjamin Hawkes-Lewisbhawkesle...@googlemail.com wrote: Do these features meet your requirements? If not, why not? A longdesc is not the same as an alt, in that a longdesc is a long description of the content, while an alt is alternative actual content. Maybe. Does any W3C recommendation use those precise words to distinguish them? This distinction may in practice be unnecessary though. And I see that the WAI has redefined alt to mean a short description. HTML 4.01 implementations must treat alt as defined in the HTML 4.01 specification. HTML5 implementations would have to treat alt as defined in the HTML5 specification. WAI have not redefined the semantics of W3C markup languages, though they are defining ARIA markup that (it is proposed) will override the native semantics of those other languages in ARIA implementations. In terms of your question about whether video element should allow an alt attribute, I was looking at: * How the editorial draft of HTML5 defines alt. * The WCAG 2.0 Recommendation's conformance requirements for text alternatives for media. I regard discussing how HTML 4.01 defines alt and how WCAG 1.0 or WAI Notes suggest using alt in the context of HTML 4.01/XHTML 1.x as a distraction when trying to answer your question. It seems to me that: 1. Publishers do not need alt on video to meet WCAG 2.0's conformance requirements. 2. Adding alt to video would not meet any other use cases. 3. /If/ I'm wrong and we do need another mechanism to provide a text alternative to meet WCAG 2.0's conformance requirement, it would be better to supply a mechanism that allows markup (e.g. of changes of language and of changes of speaker). Do you agree with these claims? Does this mean that the alt attribute and longdesc attribute for images can be combined and deprecated in favor of aria-describedby or a figure/legend combo? Controversially, longdesc is not conforming markup in the HTML5 editor's draft because of a track record of poor implementations in the web corpus and popular user agents: http://blog.whatwg.org/the-longdesc-lottery This is an open issue for the HTML WG: http://www.w3.org/html/wg/tracker/issues/30 The WAI-CG Task Force on Alternative Text has recommended that longdesc only be obsoleted /if/ aria-describedby is incorporated in HTML5 and aria-describedby allows pointing to long text alternatives that are off of the page (by pointing to a link on the page): http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 I'm suggesting that one could use various /existing/ HTML5 features to provide distinct short descriptions (i.e. titles) and long descriptions (i.e. transcripts) for video and audio elements. alt is problematic for providing text alternatives, since as an attribute it cannot contain markup (e.g. to indicate changes of language). But it is useful for alt to continue to be conforming on elements that currently have an alt attribute since: 1. Many text alternatives do not need markup 2. alt more widely supported by user agents than alternatives like aria-label or aria-labelledby. 3. alt is unambiguously available for all user agents rather than relegated to being provided only to system accessibility APIs. alt on video, on the other hand, is supported by no popular user agents, whereas heading elements, legend, title, aria-label, and aria-labelledby already are supported by some user agents. It would make the HTML spec more consistent. Perhaps. But interoperability may be more important. One advantage of this is that the alternative content is now by default always visible (or can be made visible in the case of details). That makes it much more useful for normal use cases (no network problems or disabled audience), which means it would be provided a lot more. This is a lot better than the current situation with alt. This touches on some frequently debated points: 1. Are people more likely to provide text alternatives when they are visible? 2. Are such text alternatives likely to be /actual/ text alternatives or will they be more like captions that assume people can see the image? The question now is: why would we need both figure and aria-describedby? figure is an HTML5-specific technology for use by all user agents that indicates a figure. aria-describedby is an HTML-and-XML-general technology that points to a description to be exposed to system accessibility APIs. So they are rather different. -- Benjamin Hawkes-Lewis
Re: [whatwg] DOMTokenList: mutation clarification
On Mon, Aug 10, 2009 at 1:09 AM, Ian Hicksoni...@hixie.ch wrote: I've reworded it to imply only one mutation event fires. Thanks. 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? I think that the spec now implies that you set the attribute to the empty string. Do you agree? I don't think it changes the interpretation of this border case and I still think the spec implies that no attribute is added. Maybe the ambiguity is about the definition of mutation in the when the object mutates this empty string sentence. If we have an element with no class attribute and call .remove(foo), we start the remove() algorithm with the empty string and it doesn't modify that string. So I would say that there wasn't a mutation and that no attribute should be added. One way to clarify that no attribute should be added might be (the change is between the parentheses): When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string (that is, the algorithm changes the underlying string to a non-empty string), the user agent must add the corresponding content attribute, with its value set to the value it would have been set to after mutating the empty string. I also assume an otherwise, do nothing at the end of that sentence. Do you think somebody could interpret this as an otherwise add an attribute set to the empty string? Sylvain
Re: [whatwg] Installed Apps
TO SUMMARIZE: -There are many other existing ways to notify -I'd suggest browsers have a Notification process with which open tabs register. -Registered open tabs could tell the browser to pop up a notification, perhaps with title text, body text, and image -Clicking the notification would set focus to the browser and to the notifying tab. To solve the lifetime issue: -Torn-off tabs run in separate processes -Processes may be re-skinned to appear as applications, but are really tabs. -Minimized/docked Processes taken off the taskbar/dock and into a notification area or Application Manager -If the rest of the browser is closed, the main process will stay on until the application tabs are closed -Browser's 'Application Manager' in notification area or taskbar/dock (and as a button in the main browser) holds all open application tabs Have I forgotten anything? Even without the application tabs, the notification process would be great to implement. I think it's appeared on this thread before, but I'm currently working on an API to provide desktop notifications. A patch has been proposed to WebKit at https://bugs.webkit.org/show_bug.cgi?id=25463. I had originally proposed it to this list back in March under the context of persistent workers, which had the same motivation that you describe: background process while the application tab is closed. Now I think it makes more sense to make this API available generically (pages included, as the above WebKit patch does) subject to permissions, so that it will be available to applications regardless of where they end up running. Desktop notifications are pretty useful even when the tab is active but minimized, so it doesn't necessarily need to be wrapped up in a persistent installation process, as long as permission can be established. -John
Re: [whatwg] Reading spec without boxes
On Thu, Aug 6, 2009 at 2:09 PM, Ian Hicksoni...@hixie.ch wrote: Do either of you have a minimum font size preference set? Yes, I have a 16 point minimum font size set; and removing that moved the boxes out of the way. It also made the text in the boxes so small as to be noticeably more difficult to read. The spec text is still comfortably legible though. (Many other sites aren't so legible of course.) -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] Reading spec without boxes
Elliotte Rusty Harold wrote on 8/10/2009 1:26 PM: On Thu, Aug 6, 2009 at 2:09 PM, Ian Hicksoni...@hixie.ch wrote: Do either of you have a minimum font size preference set? Yes, I have a 16 point minimum font size set; and removing that moved the boxes out of the way. It also made the text in the boxes so small as to be noticeably more difficult to read. The spec text is still comfortably legible though. (Many other sites aren't so legible of course.) As an alternative, in FF and IE (and probably other UAs), you can use ctrl-plus and ctrl-minus to grow and shrink the page content. - Bil
Re: [whatwg] Alt attribute for video and audio
At 11:22 +1000 10/08/09, Silvia Pfeiffer wrote: I'd be curious to hear what those problems and provisions are for video and audio. I'm just referring to the rather extensive disciussion of 'alt' for images, and the concern some have with attributes that 'most' people don't see. I do agree that we need to think about both timed-media alternatives and accessibility provisions (captions, audio description of video, etc.) and untimed-media accessibility provisions (alternative text, titles, summaries, links to transcripts etc.). I'm just not sure what the best tools are, etc. Even though I'm a strong supporter of solving the subtitles/captions/i18n/sign language/audio annotation a11y issues of video and audio, I still believe that alt may have a use similar to what it is used for with images. I agree there is a need, I'm just not sure how best to satisfy it. Discussion is good, but let's start with the problems and opportunities, then look at existing structures (such as ARIA) or parallels (such as alt), and see how well we can do. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Installed Apps
From: John Gregg Sent: Monday, August 10, 2009 12:54 PM I think it's appeared on this thread before, but I'm currently working on an API to provide desktop notifications. A patch has been proposed to WebKit at https://bugs.webkit.org/show_bug.cgi?id=25463. I had originally proposed it to this list back in March under the context of persistent workers, which had the same motivation that you describe: background process while the application tab is closed. Now I think it makes more sense to make this API available generically (pages included, as the above WebKit patch does) subject to permissions, so that it will be available to applications regardless of where they end up running. Desktop notifications are pretty useful even when the tab is active but minimized, so it doesn't necessarily need to be wrapped up in a persistent installation process, as long as permission can be established. -John Are notifications really a renderer problem, as opposed to a browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit') Also, I don't know of any notifications (Outlook, Messenger, AVG, TweetDeck, etc.) that require permissions, so I'd argue that requiring permissions for notification would be arguably confusing. It doesn't interrupt flow like alert() does. Just in case I need to be set straight, here, I've got a couple questions: If vendors implemented this, they would have to work on their browsers, right? Is it easier for them to work on the rendering engine or on the application, or is there no difference? Do they prefer to add functionality to their rendering engine or to their application, or do they not care? (For these, I'm working from the assumption that it doesn't noticeably affect the UI, such as a new button or bar would.) And last: do they try not to touch the browsers, or do they prefer to delegate upgrades based on where they would be most suitable? I think answering those questions would help me the most, because at this point I don't know why they'd alter the renderer or JS engine to handle popup JavaScript instead of altering the browser to support what seems like a simple UI addition of pop-ups, but I do feel as though they wouldn't like to change the browser process. (As a final point, it's been mentioned that such a feature would become very popular, so many sites would implement it. It begs the question of which option is best for handling the volume of notifications and potentially abused notifications.)
Re: [whatwg] Alt attribute for video and audio
I have no opinion on the need being adequately covered by other attributes, but… On Sun, Aug 9, 2009 at 11:05 PM, Remcoremc...@gmail.com wrote: For an image this usually works well. An image usually doesn't convey a lot of meaning. It can be replaced by a simple sentence like A young dog plays with a red ball on the grass.. For video, audio, object, iframe, this is a little sparse. Shortening [snip] For some videos a simple textual description is inadequate, just like it is a poor proxy for some still images. Yet for some other videos, it is completely accurate. I have no problem imagining a short video clip which fits your A young dog plays with a red ball on the grass just as accurately as a still image could fit that description. An argument that an attribute is inadequate to cover *all* cases shouldn't be used as a reason to exclude something which is useful in many case.
Re: [whatwg] Reading spec without boxes
Am Montag, den 10.08.2009, 13:38 -0500 schrieb Bil Corry: As an alternative, in FF and IE (and probably other UAs), you can use ctrl-plus and ctrl-minus to grow and shrink the page content. Or, the stylesheet could just properly depend on the fontsize, eg. by using EM units. -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] Reading spec without boxes
On Thu, 6 Aug 2009, Smylers wrote: I experienced this recently with a minimum font size set (in Firefox). I tracked it down to something like this (sorry, that was on another computer, so this is from memory): * The main content's left margin, in which the boxes have to fit, is specified relative to the main content's text size. * The boxes' font size is specified as a proportion of the main content's font size. * The boxes' width is specified relative to the boxes' font size. And because of the previous two points this is relative to the main content's left margin, so is always less than that margin regardless of the main font size. * But with a minimum font size set in the UI, the actual box font size can end up larger than that computed above. The boxes' width are then correspondingly bigger, and may now be wider than the main content's left margin. I prototyped a fix for this, which went something like: Instead of setting the smaller font on the boxes, set it on all their children (.box * -- or whatever the class name is). This still makes the text smaller. But that leaves the width of the box being specified relative to the main content font -- the same as the margin it needs to fit in. As such it's trivial to pick a size that always fits. I hadn't yet submitted this because I first planned to try it in more browsers. In particular I'm concerned that the child selector isn't support in some IE versions. I applied the above suggestions. On Thu, 6 Aug 2009, Justin Lebar wrote: Unbeknownst to me, I had a minimum font size of 12pt set. FWIW, I don't remember setting this, so it may have been a default. On Mon, 10 Aug 2009, Elliotte Rusty Harold wrote: Yes, I have a 16 point minimum font size set; and removing that moved the boxes out of the way. It also made the text in the boxes so small as to be noticeably more difficult to read. The spec text is still comfortably legible though. (Many other sites aren't so legible of course.) Hopefully the boxes no longer overlap the text. On Mon, 10 Aug 2009, Nils Dagsson Moskopp wrote: Or, the stylesheet could just properly depend on the fontsize, eg. by using EM units. It actually did (and still does), the problem was that it was going below the minimum font-size threshold. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] 2.2.2 editorial
For example, while strongly discouraged to do so, an implementation Foo Browser could add a new DOM attribute fooTypeTime to a control's DOM interface that returned the time it took the user to select the current value of a control (say). while strongly discouraged to do so -- while strongly discouraged from doing so delete (say). It's informal and redundant with For example. -- Elliotte Rusty Harold elh...@ibiblio.org
[whatwg] 2.3 editorial: operators, operations, or ?
This specification defines several comparison operators for strings. Really, operators? Is this the right word here? Maybe it should be several comparison operations on strings or several possible comparisons for strings. -- Elliotte Rusty Harold elh...@ibiblio.org
[whatwg] 2.4.4.3 editorial
As with the previous algorithms, when this one is invoked, the steps must be followed in the order given, aborting at the first step that returns something. I suggest deleting when this one is invoked. It doesn't really add anything. -- Elliotte Rusty Harold elh...@ibiblio.org
[whatwg] Editorial 2.2.2
Extensions must be defined so that the use of extensions does not contradict nor cause the non-conformance of functionality defined in the specification. should be either Extensions must be defined so that the use of extensions neither contradicts nor causes the non-conformance of functionality defined in the specification. or Extensions must be defined so that the use of extensions does not contradict or cause the non-conformance of functionality defined in the specification. I prefer the second. -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] Installed Apps
From: John Gregg Sent: Monday, August 10, 2009 2:34 PM Michael Kozakewich wrote: Are notifications really a renderer problem, as opposed to a browser-UI problem? (e.g. 'Safari' or 'Chromium', rather than 'Webkit') Also, I don't know of any notifications (Outlook, Messenger, AVG, TweetDeck, etc.) that require permissions, so I'd argue that requiring permissions for notification would be arguably confusing. It doesn't interrupt flow like alert() does. It's not a renderer 'problem'; the code that would go in WebKit is just to define the API and some basic logic about events flowing back and forth. More work is certainly necessary beyond that (code which I am also writing for Chromium). The idea is that there be a standard notification API which apps can write to and expect the intuitive thing to happen according to the user agent platform: on Mac these may go to Growl, on Linux to libnotify, on Windows to toasts on the screen, on Mobile to something specific for the device, etc. I think there's a big difference in expectations for an installed native app like those in your list versus a web page. The user grants broad permission when they install an app like that, but when they visit a web page the expectation is very different. The fact that it's not modal like an alert could even make it more necessary to secure: do you want an evil site to spam your desktop with an unbounded # of toasts? Again, I'm talking about a notifications API which is independent of the installed web app idea also being discussed in this thread. It certainly might make sense that if there is a way to install a web app in some form with a permissions step, notifications could piggyback on that to avoid confusing prompts. Just in case I need to be set straight, here, I've got a couple questions: If vendors implemented this, they would have to work on their browsers, right? Is it easier for them to work on the rendering engine or on the application, or is there no difference? Do they prefer to add functionality to their rendering engine or to their application, or do they not care? (For these, I'm working from the assumption that it doesn't noticeably affect the UI, such as a new button or bar would.) And last: do they try not to touch the browsers, or do they prefer to delegate upgrades based on where they would be most suitable? I'm not sure I follow the question, but I think it depends on the architecture of the particular browser. Based on what I've proposed, a browser maker would need to build all the pieces necessary to go from script executing notification.show() to getting something on the screen. I think answering those questions would help me the most, because at this point I don't know why they'd alter the renderer or JS engine to handle popup JavaScript instead of altering the browser to support what seems like a simple UI addition of pop-ups, but I do feel as though they wouldn't like to change the browser process. (As a final point, it's been mentioned that such a feature would become very popular, so many sites would implement it. It begs the question of which option is best for handling the volume of notifications and potentially abused notifications.) Handling the volume falls on the browser or on the presenter of notifications that the browser may might choose to delegate to (like Growl). I would think queuing based on available space is a reasonable start. Handling potential abuse is exactly why a permissions model is part of the proposal. -John For some reason, I seemed to forget that the call would be made through JavaScript in either case. I only briefly touched on the idea of 3rd-party apps like feed-readers, because I'm really not enamored with the idea. My main thought was that the browser itself would have a notifications process that would be subscribed to, and then the tabs could post messages to it. The browser would police that. (It could automatically register the tab as the first post method was sent, and unregister when that tab was closed). I don't believe such a process would have inherent security concerns, if the process was thought out (all it needs is presentation/layout). In this way, you wouldn't need to install the app to use notifications. I just wonder about policing (give a little notification, like when pop-ups are blocked, with option allowing notifications for the whole site? +Whitelisting?) I admit I worded the browser/renderer questions horribly. I meant the difference of using JavaScript to pop up an HTML message, with a bit of help from the browser; as compared to posting to the browser with JavaScript and having the browser pop up a message with its own (themeable) UI, like what one might expect from an extension. Both need everything to work together, but they have different focuses. I'd imagine (from other WHATWG discussion) the HTML version would have
Re: [whatwg] Language tags
On Thu, 13 Apr 2006, Henri Sivonen wrote: Web Apps 1.0 references RFC 3066. However, IANA seems to behave as if a successor for the RFC had already been approved. The successor draft is http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt Is it safe to expect Web Apps 1.0 to change its normative reference on language tags to the successor of RFC 3066? (XML 1.0 has or its successor language regarding RFC 3066, so that won't be a problem.) It will reference BCP47. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More comments and questions on Web Apps 1.0
On Fri, 1 Jun 2007, Bjoern Hoehrmann wrote: * Ian Hickson wrote: 2.14.1.1. The spec should probably mention http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt or its successor around here. I have no idea which section that was, nor which RFC that is (the URI is now dead). Is there an updated link? That would be RFC 4329. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Suggestions and questions for Web Forms 2.0, 2004-12-26 working draft
On Wed, 18 Oct 2006, Christian Schmidt wrote: Ian Hickson skrev: On Sat, 1 Jan 2005, Matthew Thomas wrote: 55. http://devedge.netscape.com/library/manuals/2000/javascript/1.3/ reference/index.html has been unavailable throughout the period I was reviewing this spec. Perhaps http://web.archive.org/web/20040202050531/http://devedge.netscape.com/ library/manuals/2000/javascript/1.3/reference/ would be a better reference. devedge goes up and down. I'm following that situation and will update the link as appropriate at some future point. According to http://uptime.netcraft.com/up/graph?site=devedge.netscape.com, the site hasn't been online for several months. The documents are available from http://devedge-temp.mozilla.org instead. This became a non-issue. In HTML5 I now point to: http://tools.ietf.org/html/draft-hoehrmann-javascript-scheme Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RFC 2732 reference unneeded
On Sat, 11 Aug 2007, Geoffrey Sneddon wrote: #terminology: For readability, the term URI is used to refer to both ASCII URIs and Unicode IRIs, as those terms are defined by RFC 3986 and RFC 3987 respectively, and as modified by RFC 2732. RFC 2732 is irrelevant, as URIs as of RFC 3986 and IRIs as of RFC 3987 define how to deal with IPv6 addresses. RFC 2732 is noted as obsoleted by RFC 3986. Fixed, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codecs for audio and video
In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/
Re: [whatwg] Language codes: RFC 3066 versus RFC 4646
On Fri, 3 Apr 2009, Alex Bishop wrote: In several places in HTML5 (specifically, sections 3.3.3.3, 4.2.5.3 and 5.11.1), the specification states that certain attribute values must be valid RFC 3066 language codes. However, RFC 3066 was replaced by RFC 4646 (and RFC 4647) in September 2006. Is there a reason that HTML5 refers to the older standard or is this just an oversight? On Fri, 3 Apr 2009, Masataka Yakura wrote: I think the current plan is to point to BCP 47, since RFC 4646 is soon to be replaced by its successor [1]. [1] http://lists.w3.org/Archives/Public/public-html/2008Jan/0298.html On Fri, 3 Apr 2009, Michael(tm) Smith wrote: And the general plan is to at some point(s) (e.g., before taking the W3C version to Last call) do a thorough review and update of all the references/citations to whatever the current versions are that they should point to at that time. It's maybe not all that useful to try to keep them up to date piecemeal along the way. I'm now going through the references. I've updated the RFC3066 references to point to BCP47. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Parsing RFC3339 constructs
On Mon, 27 Apr 2009, Asbjørn Ulsberg wrote: On Mon, 27 Apr 2009 12:59:11 +0200, Julian Reschke julian.resc...@gmx.de wrote: - the literal letters T and Z must be uppercase Any technical reason why they have to? Any reason why they don't? It simplifies processing a tiny amount. It would help people understand what the difference to RFC 3339 is. Indeed, and this is exactly what we did in RFC 4287, as I've pointed out previously. And I can't say that date parsing has proven to be an issue there at all, even with the little work we did on narrowing down and tightening the syntax. Section 3.3. of RFC 4287 says: A Date construct is an element whose content MUST conform to the date-time production in [RFC3339]. In addition, an uppercase T character MUST be used to separate date and time, and an uppercase Z character MUST be present in the absence of a numeric time zone offset. Perhaps HTML5 needs more detailing than this for parsing, but not referencing RFC 3339 just for the sake of not referencing RFC 3339 doesn't make much sense imho. For authoring (and parsing, infact), RFC 3339 plus a couple of additional guidelines have proven to be enough for implementors of RFC 4287, so assume HTML5 could be better off doing the same, no? HTML5 now references ISO8601 directly in a non-normative note explaining why ISO8601 isn't referenced normatively. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codecs for audio and video
Perhaps Google will finally be able to break this horrible deadlock by doing just that. :) On Mon, Aug 10, 2009 at 6:44 PM, Sam Kuper sam.ku...@uclmail.net wrote: In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/
Re: [whatwg] Codecs for audio and video
Am Dienstag, den 11.08.2009, 00:44 +0100 schrieb Sam Kuper: In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/ At this point, this seems to be pure speculation. Maybe Google representatives can chime in on this issue ? -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
[whatwg] A tag for measurements / quantity?
Hi Everyone, I've been off the list for quite some time, so bear with me if I missed something searching the archives. I've been looking at the meter element, which specifically states that There is no explicit way to specify units in the meter element, but the units may be specified in the title attribute in free-form text. Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. An backwards compatible inline element to specify a quantity would be rather trivial: quantity unit=cm12 cm/quantity quantity unit=kg2 kg/quantity With this implementation a number inside the quantity element would be interpreted as the numerical value of the unit. Other characters would be ignored. That way old browsers would simply ignore the unknown tag, whereas a browser aware of this tag could provide DOM hooks for things like implementing a browser extension to convert between metric and imperial units. Food for thought. Opinions, anyone? .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
