Re: [whatwg] Fullscreen events dispatched to elements
What do you do when element A goes fullscreen and then element B in the same document goes fullscreen on top of it? Do you fire a single fullscreenchange event at B? Or do you fire a fullscreenchange event at A and then at B? Or something else? Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] sources in video by quality as well as codec
I believe right now there are two proposals under discussion that are trying to address the adaptive streaming issues: https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html and http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html I believe both are still somewhat at the experimental level and need harmonization, but they are both being worked on at the W3C. HTH. Cheers, Silvia. On Wed, Jun 6, 2012 at 8:23 AM, Charles Pritchard ch...@jumis.com wrote: On Jun 5, 2012, at 2:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 21 Feb 2012, Rodger Combs wrote: I propose that source add a quality, bitrate, or filesize attribute to allow the UA to decide between multiple streams by choosing the maximum quality file that it can download within a reasonable amount of time (e.g. it will download faster than it will play) or based on a user preference (e.g. prefer SD quality, or always use HD when provided). It should also be possible to retrieve a list of the sources the UA can play in JS, and switch between them by user action (either a JS call for a custom UI or a dropdown in the builtin UI), loading the new file and switching to it with minimal skipping. This way, a site like YouTube, which presents several files in various bitrates and codecs, can allow the user to choose to use a higher quality without having to force an src attribute on the video, and a mobile UA that roams from 3G to WiFi or moves close to a base station can increase the quality of its stream. I think it fits in well with the purpose of the source element. This is certainly open for modification, but I think it's a good concept in essence. If this is for a site like YouTube, I think an adaptive network channel would be a more effective solution (i.e. one where the download adapts in real time to changing network conditions, with the endpoints negotiating with each other regarding what to transmit). I'd like to see strawman proposals for resource description markup. Presently, magnet+BitTorrent is the only mature and implemented tech in this field that I've found with wide support. And it's not even meant for adaptive streaming. I know that markup for subtitles happened in this group. I'd like to see an effort for markup for resources, with the same experimental atmosphere. The hope being that we can copy and paste some kind of text markup which describes various endpoints and metadata sufficient for streaming strategies for media. -Charles
Re: [whatwg] Various HTML element feedback
On Wed, Jun 6, 2012 at 2:53 AM, Ian Hickson i...@hixie.ch wrote: That might be realistic, especially there is no significant semantic clarification in sight in general. This raises the question why we could not just return to the original design with some physical markup like i, b, and u together with span that was added later. I think you'll find the original design of HTML isn't what you think it is (or at least, it's certainly not as presentational as you imply above), but that's neither here nor there. Is there a record of design between http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html and http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt ? So why not simply define i recommended and describe var, cite, em, and dfn as deprecated but supported alternatives? What benefit does empty deprecation have? It's not like we can ever remove these elements altogether. What harm do they cause? The harm is the wasted time spent worrying about and debating which semantic alternative for italics to use. If we have to keep them, we are better served by embracing them and giving them renewed purpose and vigour, rather than being ashamed of them. I think we have to keep them, because trying to declare them invalid would cause people to do a lot of pointless work, too, but I think we could still be ashamed of them. Note that as it is specified, div can be used instead of p with basically no loss of semantics. (This is because the spec defines paragraph in a way that doesn't depend on p.) Is there any known example of a piece of software that needs to care about the concept of paragraph and uses the rules given in the spec for determining what constituted paragraphs? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Wed, May 23, 2012 at 6:21 PM, Florian Rivoal flori...@opera.com wrote: On the other hand, I think that including 600w 400h in there is misguided. I agree. 1) simplyfy srcset to only accept the *x qualifier Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? I believe the only way out is through an image format that: ... - is designed so that the browser can stop downloading half way through the file, if it determines it got sufficiently high resolution given the environment More to the point, the important characteristic is being able to stop downloading *quarter* way through the file and get results that are as good as if the full-size file had been down sampled with both dimensions halved and that size had been sent as the full file. (I am not aware of a bitmap format suitable for photographs that has this characteristic. I am aware that JPEG 2000 does not have this characteristic. I believe interlaced PNGs have that characteristic, but they aren't suitable for photographs, due to the lossless compression.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 06.06.2012 14:36 schrieb Henri Sivonen: On Wed, May 23, 2012 at 6:21 PM, Florian Rivoalflori...@opera.com wrote: 1) simplyfy srcset to only accept the *x qualifier Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? Explicitly specifying the * in *x allows more flexibility in the future for cases such as: - If sometime most displays will have 2x or higher resolutions, authors might want to set 1x versions aside. - If 3x or whatever displays should occur, the spec should be suitable for them, too. - Some UAs might decide to progressively load sources in order to emulate what we know from interlaced GIFs. Authors could for this purpose add 0.5x and even 0.25x versions.
Re: [whatwg] sources in video by quality as well as codec
On Jun 5, 2012, at 2:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 21 Feb 2012, Rodger Combs wrote: I propose that source add a quality, bitrate, or filesize attribute to allow the UA to decide between multiple streams by choosing the maximum quality file that it can download within a reasonable amount of time (e.g. it will download faster than it will play) or based on a user preference (e.g. prefer SD quality, or always use HD when provided). It should also be possible to retrieve a list of the sources the UA can play in JS, and switch between them by user action (either a JS call for a custom UI or a dropdown in the builtin UI), loading the new file and switching to it with minimal skipping. This way, a site like YouTube, which presents several files in various bitrates and codecs, can allow the user to choose to use a higher quality without having to force an src attribute on the video, and a mobile UA that roams from 3G to WiFi or moves close to a base station can increase the quality of its stream. I think it fits in well with the purpose of the source element. This is certainly open for modification, but I think it's a good concept in essence. If this is for a site like YouTube, I think an adaptive network channel would be a more effective solution (i.e. one where the download adapts in real time to changing network conditions, with the endpoints negotiating with each other regarding what to transmit). I'd like to see strawman proposals for resource description markup. Presently, magnet+BitTorrent is the only mature and implemented tech in this field that I've found with wide support. And it's not even meant for adaptive streaming. I know that markup for subtitles happened in this group. I'd like to see an effort for markup for resources, with the same experimental atmosphere. The hope being that we can copy and paste some kind of text markup which describes various endpoints and metadata sufficient for streaming strategies for media. -Charles
[whatwg] Proposal for Links to Unrelated Browsing Contexts
Hi all-- I've posted a new proposal to the WhatWG wiki to give web sites a way to open a link in an unrelated browsing context. These links would open in a new window with no script connections back to the original site, which is useful for web apps like Gmail that open user-contributed links. Also, this could allow multi-process browsers like Google Chrome to open the new page in a separate process. Any feedback on the proposal is appreciated! http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts Thanks, Charlie Reis
Re: [whatwg] Cut and paste (and related) events' futures
On Thu, 26 Jan 2012, Chris O'Brien wrote: This is my first post to the mailing list, so please forgive me if the following is inappropriate for the list and let me know where I should direct this instead (h...@whatwg.org? http://h...@whatwg.org/?). In all the last-released versions of the major browsers (except Opera), there's support for cut-and-paste events like onpaste on input type=text... and textarea elements. Is there any plan to put these events into the standard? Isn't that a basic tenent of WHATWG--if the real-world vendor implementations are in consensus yet don't reflect the standard, change (or add to) the standard to reflect the de facto market standard, so long as any modifications are backwards compatible? On Thu, 26 Jan 2012, Mike Taylor wrote: You're probably looking for this: http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for clipboard data API in the archives might bring up some interesting discussion as well. Yeah, I haven't added this to the HTML spec because of the existence of Hallvord's work cited above. I haven't reviewed it closely. I think it might make sense to embed it into the larger HTML spec, but that's basically up to Hallvord. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] beforepopstate event?
On Fri, 27 Jan 2012, Thomas Broyer wrote: A common use case for beforeunload is to prompt the user before leaving when it has unsaved changes. For instance, you edited a mail draft, updated the phone number of a contact, or filled any kind of form, but you didn't save your changes; when you navigate away, beforeunload can be used to prompt you whether you really want to go (and lose your changes). Within a single-page app, where you use location.hash=xxx and hashchange, or pushState() and popstate, to handle the navigation, there doesn't seem to be any way to prompt the user and possibly *cancel* the navigation. Something like: 1. you're looking at your mail inbox, and click on new mail 2. you type in some text 3. you click on the previous page button of your browser, or trigger an equivalent action using a keyboard shortcut (possibly mistakenly) As the app developer, I'd like to be able to prompt the user whether he really want to go (and lose his changes), and if he actually wants to continue editing his mail draft (and/or save it before navigating again), then *cancel* the history traversal; in a similar way as if I developed a multi-page app (or if he'd close the window/tab or navigate away from the app): I could then do that using the beforeunload event, either cancelling it or setting its returnValue to some non-empty string value. Ah, yeah. This isn't supported. I would recommend just making the app not discard the state, so it becomes a non-issue. They hit back, and the message is saved to drafts and can be obtained again by going forward. You can put up a message saying that the draft will be discarded in five minutes or some such, if the ideal model is for the data to be lost. The reason onbeforeunload makes sense is that there's no way to do anything once the page is unloaded. But that doesn't apply here, where the same code is still running. Unless I missed something, all I can do is to handle the hashchange or popstate event and use Window.confirm() or similar, and only update the page from the location.hash or history.state if he confirms; but then navigation has already taken place, I cannot cancel the navigation but only ignore it. Well, you can always just do history.forward() or whatever, to go back to the previous state. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Fri, 27 Jan 2012, Boris Zbarsky wrote: On 1/27/12 1:30 AM, Ian Hickson wrote: On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarskybzbar...@mit.edu wrote: What Firefox does do is block execution ofscript tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that ascript coming after alink will never see the link in an unloaded state... unless there's a network error for thelink or whatever. One exception: If an inline script comes from document.write(), it doesn't block on pending sheets. It runs right away. If it blocked on pending sheets, the point at which document.write() returns would depend on network performance, which I think would be worse than having document.written inline scripts that poke at styles fail depending on network performance. Note that this is not conforming. The spec does not currently define any such behaviour. Which part is not conforming? The exception for alternate sheets, the inline script inside document.write thing, or something else? Unless I'm mistaken, nothing in the HTML spec does anything differently based on whether a script comes from document.write() or not. The information about whether a character in the tokeniser came from the network, document.write() during a network parse, or document.write() on a completely script-written document, is not stored along with the character in the tokeniser's input stream. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Offline-Capable Meta Tag and API Indicates Application's Ability to Function Without Network Connection
On Fri, 27 Jan 2012, Brian Blakely wrote: On Fri, Jan 27, 2012 at 4:50 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 27 Jan 2012, Brian Blakely wrote: What kind of app are you considering that needs 700MB at once? I'm considering videogames that the user would like to play offline (plane flight, subway, etc), as well as massive software packages like Adobe CS. A good application designer would allow the user to choose portions of the app that they would like to cache long-term, but suppose the user needs the entire thing? In that case, 700MB could likely lowballing by quite a bit. I think appcache handles this particular case reasonably well (modulo it's other known limitations, anyway). The caching progress can be easily reported to the user (either by the UA or the page), so the user can know that they should leave the tab open while it does the update, and yet the page is usable in the meantime. I completely agree Ian, app cache would be the means by which a developer sends their assets to the user's local storage device. This proposal deals chiefly with standardizing the messaging around that. The developer sets up the application to be ready for offline use (via App Cache, localStorage, IndexedDB, cookies, etc), and informs the UA when the user can go off the wire. The UA then informs the user in a predictable way that will become familiar to them as they continue to use that particular client. Background downloading and other mechanics introduced in this thread enable a native-like app download process that is, again, always the same on the same UA, instead of varying from application to application. I think we should wait for sites to start showing their own UI for this kind of thing -- ok, I'm now fully cached -- before we add a mechanism for the script to ask the UA to show UI for this. Without the experience gained from authors doing it themselves, we don't really have enough information about how to design the feature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Several questions: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to an existing window? Would that window become isolated? What would happen to the 'back' button / history.back()?
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
I'm hoping to bypass all of those by overriding any specification of target in the link. That is, if rel=unrelated is specified, that forces target to be _blank. Charlie On Wed, Jun 6, 2012 at 4:53 PM, Michal Zalewski lcam...@coredump.cx wrote: Several questions: 1) How would this mechanism work with named windows (which may be targeted by means other than accessing opener.*)? In certain implementations (e.g., Chrome), the separation in this namespace comes free, but that's not given for other browsers. There are ways in which the attacker could, for example, load GMail in a window that already has window.name set. 2) What would be the behavior of a rel=unrelated link with target= pointing to an existing iframe on the page? Could it work in any useful way? 3) What about the same with target= pointing to an existing window? Would that window become isolated? What would happen to the 'back' button / history.back()?
Re: [whatwg] tabindexscope
On Mon, 30 Jan 2012, Tab Atkins Jr. wrote: On Mon, Jan 30, 2012 at 1:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 8 Nov 2011, Ojan Vafai wrote: We keep running into the use case where the physical position matters for the tab order. The problem with just setting tabIndex (or CSS3 tab-index) is that it takes the thing out of the natural order. This problem comes up in a lot of places (e.g. absolute positioning). It's recently come up for CSS flexboxes, e.g. if you set flex-order or a reverse flow, then the tabindex still being in document order is often not what the author wants (https://bugs.webkit.org/show_bug.cgi?id=62664). button tabindex=0A/button div tabindex=2 tabindexscope button tabindex=2C/button button tabindex=1B/button /div button tabindex=1D/button The order for the tabbing would be A-D-B-C. The spec says that the order when you omit tabindex (or set it to 0) should follow platform conventions. If the platform convention is to make the tab order follow the visual position, then that's what the browser should do. Surely that would be better than having authors manage local regions for tabindex, especially since the positioning depends on the CSS level, not the HTML level, and thus trying to manage the tabindex in the HTML would be a layering violation anyway. If you are attempting to match the tab order to the position of an element, you are correct. In this situation, the tab order of the group itself should be controlled by the 'nav-index' property alongside the positioning code. However, *within* a group of controls, the relative order can want to be scoped without reference to CSS. This can happen because the group is being positioned with CSS (and thus the appropriate tab-index is unpredictable), because the group may be generated into multiple pages with different tab-index'd items elsewhere in the page, or just because the dev would like to write their tab-indexes without having to renumber everything every time they move the HTML around in the page. Scoping a tab-index is thus a property that can appropriately belong to the HTML level, just as much as tab-index itself does. Can you give some examples of real-world pages where the tabindex attribute has been used (with difficulty due to the lack of scoping), where nav-index is not the right solution, and where the UA following platform conventions for tab order doesn't or wouldn't end up in a good UI, that show that this feature would be useful? I'm having trouble picturing it, and the frequent references above to positioning and other CSS layout features is confusing me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 6/6/12 7:47 PM, Ian Hickson wrote: On Fri, 27 Jan 2012, Boris Zbarsky wrote: On 1/27/12 1:30 AM, Ian Hickson wrote: On Wed, 5 Oct 2011, Henri Sivonen wrote: On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarskybzbar...@mit.edu wrote: What Firefox does do is block execution ofscript tags (but not timeouts, callbacks, etc!) if there are pending non-altenate parser-inserted stylesheet loads. This is necessary to make sure that scripts getting layout properties see the effect of those stylesheets. A side-effect is that ascript coming after alink will never see the link in an unloaded state... unless there's a network error for thelink or whatever. One exception: If an inline script comes from document.write(), it doesn't block on pending sheets. It runs right away. If it blocked on pending sheets, the point at which document.write() returns would depend on network performance, which I think would be worse than having document.written inline scripts that poke at styles fail depending on network performance. Note that this is not conforming. The spec does not currently define any such behaviour. Which part is not conforming? The exception for alternate sheets, the inline script inside document.write thing, or something else? Unless I'm mistaken, nothing in the HTML spec does anything differently based on whether a script comes from document.write() or not. The information about whether a character in the tokeniser came from the network, document.write() during a network parse, or document.write() on a completely script-written document, is not stored along with the character in the tokeniser's input stream. Oh, I see. The problem with that is situations like this script: var x = 0; document.write(link rel=stylesheet href=something + scriptx = 1;/ + script); alert(x); This interoperably alerts 1 in Trident, Gecko, Presto, and WebKit. That means that either the write() call can't return until the sheet is done loading or the script from write() needs to be able to run before the sheet is done loading. A bit of further experimentation indicates that in all of the above browsers its the latter: the script that sets x=1 runs before the link is loaded. If the spec says something different, the spec probably needs to change to match implementations here... -Boris
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 6:56 PM, Charlie Reis cr...@chromium.org wrote: I'm hoping to bypass all of those by overriding any specification of target in the link. That is, if rel=unrelated is specified, that forces target to be _blank. Please don't encourage yet more sites to open new tabs when I didn't ask for it. -- Glenn Maynard
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 06/06/2012 21:36, Henri Sivonen wrote: More to the point, the important characteristic is being able to stop downloading *quarter* way through the file and get results that are as good as if the full-size file had been down sampled with both dimensions halved and that size had been sent as the full file. (I am not aware of a bitmap format suitable for photographs that has this characteristic. I am aware that JPEG 2000 does not have this characteristic. I believe interlaced PNGs have that characteristic, but they aren't suitable for photographs, due to the lossless compression.) IIRC Kodak's PhotoCD image format had this characteristic. The first part is a low res. image, the second is the differences between the low res. image zoomed to the high res. size and the actual high res. image. Regards -Mark
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote: Please don't encourage yet more sites to open new tabs when I didn't ask for it. It's merely a new browsing context IIUC, not necessarily a new window (frame, tab, tile or whatever it's called this year). Someone that understands the codebase of a modern browser could even make the back button work, although he would have to restrict write access to the history stack or tree as well, for security reasons. He's saying he wants it to force target=_blank, though. -- Glenn Maynard
Re: [whatwg] video element not ready for prime time
On 06/06/2012, at 7:44 AM, Ian Hickson wrote: On Fri, 13 Jan 2012, Kit Grose wrote: I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. I don't think it's time to give up yet, but maybe I'm overly optimistic... Is there any reason why it wouldn't be prudent to render the content of the video element as HTML if the video cannot be played, given that fallback content in the video element is already supported for legacy browsers in the spec: Content may be provided inside the video element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browsers informing them of how to access the video contents. How are legacy UAs without video support appreciably different from a UA with restrictive or limited video support? Surely the author's intent in either case is delivering the content in a different way or delivering appropriate alternate content. Even if we eventually get a common codec (which I—perhaps overly pessimistically—feel is unlikely), authors are already using the video element without supplying whatever that eventual codec will be, and users are suffering without reasonable fallbacks. As it stands, it's almost better (and certainly easier) for authors to default to Flash video and use the existing, declarative fallback behaviour of the object element to use a video element instead. That can't be in the best interest of the open web. —Kit Grose
Re: [whatwg] video element not ready for prime time
On Fri, Jan 13, 2012 at 6:46 AM, Francis Boumphrey boumphre...@gmail.com wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. Recent versions of Firefox display a message for the user if the mime type of the video is not supported instead of a blank screen. -- http://www.bluishcoder.co.nz
