Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
James pointed out to me that the proposal explains the difference to noreferrer, which is essential that it *does* send a referrer, but has the rel=noreferrer behavior of nulling out window.opener. I'm still not clear on the use case for nulling the opener but still sending the Referer header. It seems like it is better for mail clients to clear referrer. What kinds of web apps need to open new windows and null window.opener, but still send Referer? The reason I'm asking is that it seems regrettable to have two link types with such similar but subtly different behavior. Cheers, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak wrote: > > Someone earlier in the thread mentioned that this feature sounds an awful lot > like rel=noreferrer, which has been in WebKit for several years: > http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ > > It is also mentioned in the official link relation registry: > http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions > > Do you have a use case for your new proposal that is not handled by href="..." rel=noreferrer target=_blank>? Does it have a materially different > effect? (I can't tell.) > > Regards, > Maciej > > > On Aug 27, 2012, at 5:29 PM, Charlie Reis wrote: > >> On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson wrote: >>> >>> On Wed, 6 Jun 2012, Charlie Reis wrote: 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 >>> >>> It's not entirely clear to me what the desired behaviour is here. Which of >>> the following are considered features that we need to provide? Which are >>> secondary goals, which are non-goals, which are anti-goals? >> >> >> I think our discussion found this feature would be most useful if the new >> page was unable to find its opener, so I'd group things as follows. >> >> Primary goals: >> + have the new page use a different event loop if possible (new process) >> + have the window of the new page not be able to reach the opener via >> a named window.open() or target="" >> >> As a result, I think these are also necessary features: >> + have the new page be in a different unit of related browsing contexts >> + have the new page be in a new browsing context >> + have "window.opener" not be set >> + have the window.name of the new page be set to "" >> >> Secondary goals: >> + have the sessionStorage not be cloned for the new page's browsing >> context >> >> Non-goals: >> + have the new page be in the same browsing context >> >> Anti-goals: >> + have the referer header be cleared on the load of the new page >> >> >>> Does this need to be done from window.open()? >> >> Yes. For example, Gmail uses window.open() for the links in emails, but >> would like the links to open in an unrelated context. >> >>> From ? >> >> Yes. For example, links to switch between apps within a domain would be >> useful to have open in an unrelated context (e.g., the black bar at the top >> of Google pages). >> >>> From ? >> >> I don't know of any immediate use cases for this, but it might be nice for >> consistency. >> >>> Is this a symmetric feature? >> >> Sorry, I'm not sure what you mean by symmetric here. The page opened in >> the unrelated context may also be able to open pages in another unrelated >> context. >> >>> At a more fundamental level: what are the use cases here? Is it just >>> e-mail clients that want to open links? >> >> Links in email clients is one use case. For user agents that can open such >> links in a different event loop, another use case is to allow multiple >> independent apps under the same domain to run in parallel, even when >> opening one app from another. (For example, Chrome could open links to >> different Google apps like Search, Maps, Mail, etc, in different processes.) >> >> Even in user agents where all pages share the same event loop, this can be >> useful to help enforce modularity in large applications (e.g., stopping a >> developer in one part of a large site from introducing a scripting >> dependency on another part of the site). That's admittedly a secondary >> benefit, and not the primary goal. >> >>> What are the attack scenarios? Is >>> it just links in e-mails getting at the e-mail app somehow? >> >> The attack scenarios are about protecting any web app from unwanted script >> calls or navigation attempts from untrusted pages in windows that it opens. >> You could imagine anything from a mail client to a news reade
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
I overlooked that it's also in the spec itself, not just the registry: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer Regards, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak wrote: > > Someone earlier in the thread mentioned that this feature sounds an awful lot > like rel=noreferrer, which has been in WebKit for several years: > http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ > > It is also mentioned in the official link relation registry: > http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions > > Do you have a use case for your new proposal that is not handled by href="..." rel=noreferrer target=_blank>? Does it have a materially different > effect? (I can't tell.) > > Regards, > Maciej > > > On Aug 27, 2012, at 5:29 PM, Charlie Reis wrote: > >> On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson wrote: >>> >>> On Wed, 6 Jun 2012, Charlie Reis wrote: 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 >>> >>> It's not entirely clear to me what the desired behaviour is here. Which of >>> the following are considered features that we need to provide? Which are >>> secondary goals, which are non-goals, which are anti-goals? >> >> >> I think our discussion found this feature would be most useful if the new >> page was unable to find its opener, so I'd group things as follows. >> >> Primary goals: >> + have the new page use a different event loop if possible (new process) >> + have the window of the new page not be able to reach the opener via >> a named window.open() or target="" >> >> As a result, I think these are also necessary features: >> + have the new page be in a different unit of related browsing contexts >> + have the new page be in a new browsing context >> + have "window.opener" not be set >> + have the window.name of the new page be set to "" >> >> Secondary goals: >> + have the sessionStorage not be cloned for the new page's browsing >> context >> >> Non-goals: >> + have the new page be in the same browsing context >> >> Anti-goals: >> + have the referer header be cleared on the load of the new page >> >> >>> Does this need to be done from window.open()? >> >> Yes. For example, Gmail uses window.open() for the links in emails, but >> would like the links to open in an unrelated context. >> >>> From ? >> >> Yes. For example, links to switch between apps within a domain would be >> useful to have open in an unrelated context (e.g., the black bar at the top >> of Google pages). >> >>> From ? >> >> I don't know of any immediate use cases for this, but it might be nice for >> consistency. >> >>> Is this a symmetric feature? >> >> Sorry, I'm not sure what you mean by symmetric here. The page opened in >> the unrelated context may also be able to open pages in another unrelated >> context. >> >>> At a more fundamental level: what are the use cases here? Is it just >>> e-mail clients that want to open links? >> >> Links in email clients is one use case. For user agents that can open such >> links in a different event loop, another use case is to allow multiple >> independent apps under the same domain to run in parallel, even when >> opening one app from another. (For example, Chrome could open links to >> different Google apps like Search, Maps, Mail, etc, in different processes.) >> >> Even in user agents where all pages share the same event loop, this can be >> useful to help enforce modularity in large applications (e.g., stopping a >> developer in one part of a large site from introducing a scripting >> dependency on another part of the site). That's admittedly a secondary >> benefit, and not the primary goal. >> >>> What are the attack scenarios? Is >>> it just links in e-mails getting at the e-mail app somehow? >> >> The attack scenarios are about protecting any web app from unwanted script >> calls or navigation attempts from untrusted pages in windows that it opens. >> You could imagine anything from a mail client to a news reader to a social >> network using it for links to external content. >> >> Beyond defending against those attacks, the feature is also about allowing >> unrelated pages to run on parallel event loops, so they aren't blocked on >> each other. >> >> >>> Without more details like the above it's hard to evaluate the proposals. >>> >>> -- >>> Ian Hickson U+1047E)\._.,--,'``.fL >>> http
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years: http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ It is also mentioned in the official link relation registry: http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions Do you have a use case for your new proposal that is not handled by ? Does it have a materially different effect? (I can't tell.) Regards, Maciej On Aug 27, 2012, at 5:29 PM, Charlie Reis wrote: > On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson wrote: >> >> On Wed, 6 Jun 2012, Charlie Reis wrote: >>> >>> 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 >> >> It's not entirely clear to me what the desired behaviour is here. Which of >> the following are considered features that we need to provide? Which are >> secondary goals, which are non-goals, which are anti-goals? > > > I think our discussion found this feature would be most useful if the new > page was unable to find its opener, so I'd group things as follows. > > Primary goals: > + have the new page use a different event loop if possible (new process) > + have the window of the new page not be able to reach the opener via > a named window.open() or target="" > > As a result, I think these are also necessary features: > + have the new page be in a different unit of related browsing contexts > + have the new page be in a new browsing context > + have "window.opener" not be set > + have the window.name of the new page be set to "" > > Secondary goals: > + have the sessionStorage not be cloned for the new page's browsing > context > > Non-goals: > + have the new page be in the same browsing context > > Anti-goals: > + have the referer header be cleared on the load of the new page > > >> Does this need to be done from window.open()? > > Yes. For example, Gmail uses window.open() for the links in emails, but > would like the links to open in an unrelated context. > >> From ? > > Yes. For example, links to switch between apps within a domain would be > useful to have open in an unrelated context (e.g., the black bar at the top > of Google pages). > >> From ? > > I don't know of any immediate use cases for this, but it might be nice for > consistency. > >> Is this a symmetric feature? > > Sorry, I'm not sure what you mean by symmetric here. The page opened in > the unrelated context may also be able to open pages in another unrelated > context. > >> At a more fundamental level: what are the use cases here? Is it just >> e-mail clients that want to open links? > > Links in email clients is one use case. For user agents that can open such > links in a different event loop, another use case is to allow multiple > independent apps under the same domain to run in parallel, even when > opening one app from another. (For example, Chrome could open links to > different Google apps like Search, Maps, Mail, etc, in different processes.) > > Even in user agents where all pages share the same event loop, this can be > useful to help enforce modularity in large applications (e.g., stopping a > developer in one part of a large site from introducing a scripting > dependency on another part of the site). That's admittedly a secondary > benefit, and not the primary goal. > >> What are the attack scenarios? Is >> it just links in e-mails getting at the e-mail app somehow? > > The attack scenarios are about protecting any web app from unwanted script > calls or navigation attempts from untrusted pages in windows that it opens. > You could imagine anything from a mail client to a news reader to a social > network using it for links to external content. > > Beyond defending against those attacks, the feature is also about allowing > unrelated pages to run on parallel event loops, so they aren't blocked on > each other. > > >> Without more details like the above it's hard to evaluate the proposals. >> >> -- >> Ian Hickson U+1047E)\._.,--,'``.fL >> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > > I hope that clarifies things! It wasn't initially clear whether preventing > any access from the new page to the opener window (e.g., by finding the > named window) was necessary, but it does seem like the feature would be > most useful if that were the case
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 28 Aug 2012, Boris Zbarsky wrote: > On 8/28/12 12:46 AM, Ian Hickson wrote: > > I've updated the spec to not block on style sheets for nested parser's > > scripts. > > I'm not sure I follow. What is not going to block on what with this change? > > As far as I can tell, "0 1 2" in your testcase at > http://damowmow.com/playground/demos/document-write-and-scripts/002.html is > consistent with the following order of execution: > > 1) x=0 > 2) x1=0,x=1 (nothing else has run yet because we're waiting on > blank.js) > 3) setTimeout fires, sets x2 = 1 > 3) second external script runs, sets x = 2. There's only one external script. The script after the style sheet is internal. If it blocks, you get "0 1 2" (when x2 gets set to x in the timeout, it's still x=1, because the next script, which sets x=2, hasn't run). In Gecko, however, that internal script doesn't block, and so the timeout runs after x has been set to 2. Hence "0 2 2". The reason for having the external script in 002.html is that it causes document.write() to return right there (except in IE9, but that's another story, not sure what that's about), so you can tell the difference between how the internal
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On 8/28/12 12:46 AM, Ian Hickson wrote: I've updated the spec to not block on style sheets for nested parser's scripts. I'm not sure I follow. What is not going to block on what with this change? As far as I can tell, "0 1 2" in your testcase at http://damowmow.com/playground/demos/document-write-and-scripts/002.html is consistent with the following order of execution: 1) x=0 2) x1=0,x=1 (nothing else has run yet because we're waiting on blank.js) 3) setTimeout fires, sets x2 = 1 3) second external script runs, sets x = 2. So it looks like the second external script in your testcase there is in fact blocking on the stylesheet... or something. And I'm not sure how reconcile that with the behavior at http://damowmow.com/playground/demos/document-write-and-scripts/001.html What am I missing? -Boris
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Wed, 6 Jun 2012, Boris Zbarsky wrote:
> >
> > 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("" +
> "
Re: [whatwg] Various HTML element feedback
On Wed, 6 Jun 2012, Henri Sivonen wrote: > On Wed, Jun 6, 2012 at 2:53 AM, Ian Hickson 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 , , and together with 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 ? There's some in-between steps, e.g.: http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0155.html > >> So why not simply define recommended and describe , , > >> , and 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. I think this harm is dramatically reduced relative to the HTML4 days by the extensive use of examples and detailed descriptions in the spec now. If people are still having long debates, please don't hesitate to point me to them so I can clarify them in the spec. That's what a living standard is good for, after all. > > 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. I don't think that's healthy. > > Note that as it is specified, can be used instead of with > > basically no loss of semantics. (This is because the spec defines > > "paragraph" in a way that doesn't depend on .) > > 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"? No, this is just to make it clear that you don't need to use , and to short-circuit arguments about whether a is in a paragraph, etc. -- 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
On Mon, Aug 27, 2012 at 4:46 PM, Ian Hickson wrote: > > On Wed, 6 Jun 2012, Charlie Reis wrote: > > > > 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 > > It's not entirely clear to me what the desired behaviour is here. Which of > the following are considered features that we need to provide? Which are > secondary goals, which are non-goals, which are anti-goals? I think our discussion found this feature would be most useful if the new page was unable to find its opener, so I'd group things as follows. Primary goals: + have the new page use a different event loop if possible (new process) + have the window of the new page not be able to reach the opener via a named window.open() or target="" As a result, I think these are also necessary features: + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have "window.opener" not be set + have the window.name of the new page be set to "" Secondary goals: + have the sessionStorage not be cloned for the new page's browsing context Non-goals: + have the new page be in the same browsing context Anti-goals: + have the referer header be cleared on the load of the new page > Does this need to be done from window.open()? Yes. For example, Gmail uses window.open() for the links in emails, but would like the links to open in an unrelated context. > From ? Yes. For example, links to switch between apps within a domain would be useful to have open in an unrelated context (e.g., the black bar at the top of Google pages). > From ? I don't know of any immediate use cases for this, but it might be nice for consistency. > Is this a symmetric feature? Sorry, I'm not sure what you mean by symmetric here. The page opened in the unrelated context may also be able to open pages in another unrelated context. > At a more fundamental level: what are the use cases here? Is it just > e-mail clients that want to open links? Links in email clients is one use case. For user agents that can open such links in a different event loop, another use case is to allow multiple independent apps under the same domain to run in parallel, even when opening one app from another. (For example, Chrome could open links to different Google apps like Search, Maps, Mail, etc, in different processes.) Even in user agents where all pages share the same event loop, this can be useful to help enforce modularity in large applications (e.g., stopping a developer in one part of a large site from introducing a scripting dependency on another part of the site). That's admittedly a secondary benefit, and not the primary goal. > What are the attack scenarios? Is > it just links in e-mails getting at the e-mail app somehow? The attack scenarios are about protecting any web app from unwanted script calls or navigation attempts from untrusted pages in windows that it opens. You could imagine anything from a mail client to a news reader to a social network using it for links to external content. Beyond defending against those attacks, the feature is also about allowing unrelated pages to run on parallel event loops, so they aren't blocked on each other. > Without more details like the above it's hard to evaluate the proposals. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' I hope that clarifies things! It wasn't initially clear whether preventing any access from the new page to the opener window (e.g., by finding the named window) was necessary, but it does seem like the feature would be most useful if that were the case. Charlie
Re: [whatwg] Various HTML element feedback
On Wed, 6 Jun 2012, Jukka K. Korpela wrote: > 2012-06-06 2:53, Ian Hickson wrote: > > > > > > I have rather been optimistic about future developments for markup > > > elements that have been defined exactly enough to warrant meaningful > > > semantics-based processing. For example, most of the uses mentioned > > > in current text imply that element contents should be kept > > > intact in automatic language translation. > > > > That continues to be the case, so I don't know why you conclude that > > using it is now pointless. > > It is worse than pointless, if the definition of covers "a term > used as a placeholder in prose". Such expressions should definitely not > be kept intact in automatic language translation. They shouldn't be kept intact, but they still need special semantic processing to not break the page's meaning during translation (e.g. ensuring that the same variable name is always translated the same way). > > > So why not simply define recommended and describe ,, > > > , and as deprecated but supported alternatives? > > > > What benefit does empty deprecation have? > > Declaring some features as "obsolete" is effectively deprecation; I just > used the term "deprecate" as per HTML 4.01 because I find it more > descriptive. Anyway, defining those elements as deprecated/obsolete > would be no less and no more "empty" than the current statements about > obsolete status. Validators/checkers would issue messages (hopefully > just warnings) about them, and tutorials would probably describe them as > secondary if at all. I don't see any benefit to obsoleting these elements. They are useful for various purposes. Even the HTML spec uses them (all of the above, in fact) to obtain special behaviour (e.g. the cross-referencing system uses ). In general having a variety of elements provides authors with good hooks for styling, too. > Reducing alternatives, from five to one in this case, makes the > recommendations simpler and helps authors because they need not spend > time in making choices between the elements. Such choices can be tough, > if you try to play by the declared "semantics", especially if it is > vague (to a normal reader of a spec). > > My point is: either make elements like , , , , > defined so that the differences can be utilized in automatic processing, > or just bundle them together, to . I certainly agree that we shouldn't go to a DocBook level of element variety, but reducing the avilable elements to a mere handful doesn't make any sense either. We have to strike a balance, taking into account what elements have historically been available (and thus which authors are familiar with), what use cases might argue for new ones, which elements have been most used or not used, etc. > > It's not like we can ever remove these elements altogether. > > Oh, in 20 or 30 years, I think browsers could support to some of them. I'm not sure what you meant to write, but I don't see why 1992-2012 would be harder than 2012-2032 in terms of dropping these elements. > > What harm do they cause? > > Unnecessary complication to the language, artificial "semantics" that do > not actually define meanings, and confusion among those authors who try > to take semantics and specifications seriously. Oh, and pointless > variation in markup and added complexity of styling. I disagree that these are really serious problems, or that their magnitude outweights the benefits here. > > 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 this summarizes well the idea behind some of the most contrived > "semantic" definitions. It was a brave attempt, but it failed. No normal > author will ever get your idea of the new meaning for and , for > example. I guess we shall see. :-) > And since, for example, the markup needs to be supported for a > long time, how come *it* has not got a new, semantic definition? I didn't start from and look for a use case. People presented use cases, and when looking for a solution, fit the bill. Same with , etc. We did at one point have in the spec, but the use case that supported its inclusion was later solved in a different way (I forget what it was) and we ended up removing it again. If a use case is presented for which is a good fit, we can use it again. > > > This would make authoring simpler without any real cost. There’s > > > little reason to tell authors to use “semantic markup” if we > > > don’t think it has real effect on anything. > > > > It does have an effect. It has many effects. It makes maintenance > > easier, it makes it easier to transition from project to project, it > > makes it easier to work on other people's markup, it makes it > > significantly easier to dramatically change a site's appearance, it > > makes it easier to create apply custom tools to extract information
Re: [whatwg] MediaController feedback
On Tue, 5 Jun 2012, Jer Noble wrote: > >> > >> The overall purpose of the modifications is to achieve the following: > >> when controller.play() is called, all slaved media elements > >> unconditionally will begin playing. > > > > I don't think this is a good idea. If the user has paused one of the > > slaves, and then pauses and resumes the whole thing, the paused media > > element shouldn't resume. It should remain paused. (I meant author, not user, here.) > With JavaScript, it's certainly possible for a page author to play() or > pause() a slaved media element directly, but that author could just as > easily remove the media element from the media group / media controller. > > > [...] > > > > That only works if there's JavaScript doing the removing. The idea > > here is that this should all work even without any JS, just with UA > > UI. > > With just the UA UI, the behavior would be exactly the same [...] If you remove the element from the media controller, the media controller's timeline changes. It'll be quite common for there to be videos that are not currently playing, e.g. sign-language tracks. If we change anything here, I think it would be the currently required UI behaviour which requires all the videos to start playing when the user overrides the JS-provided controls and just uses the UA controls. -- 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
On Wed, 6 Jun 2012, Charlie Reis wrote: > > 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 It's not entirely clear to me what the desired behaviour is here. Which of the following are considered features that we need to provide? Which are secondary goals, which are non-goals, which are anti-goals? + have "window.opener" not be set + have the window.name of the new page be set to "" + have the window of the new page not be able to reach the opener via a named window.open() or target="" + have the referer header be cleared on the load of the new page + have the sessionStorage not be cloned for the new page's browsing context + have the new page use a different event loop if possible (new process) + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have the new page be in the same browsing context Does this need to be done from window.open()? From ? From ? Is this a symmetric feature? At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? Without more details like the above it's hard to evaluate the proposals. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=barcode?
On 27 August 2012 20:25, Tab Atkins Jr. wrote: > On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson wrote: >>> >>> True, so this is perhaps closer to an IME hint, as has been suggested >>> for a couple of other input types. >> >> Do you mean something like inputmode=barcode? Can you elaborate on how >> that would work? It's an intriguing idea, but I'm not sure I follow quite >> how to specify it. > > Yes, something like that. In terms of the table in the spec: > > Keyword: barcode > State: Barcode > Fallback State: Default > Description: Text input in the user's locale, with keys to activate > the system's built-in barcode reader to retrieve a value instead. > When you say "barcode" I'm presuming you're referring to barcode in all it's forms e.g. barcode, QR code, datamatrix etc? Some of these can contain up to 4,000 characters but many imagers have problems reading them. BTW there's an interesting introduction to barcodes from Data Logic here: https://easeofaccess.scanning.datalogic.com/public/marketlit/Send.aspx?file=EB-THEARTOFTHECODE-EN Cheers Andy
Re: [whatwg] input type=barcode?
On Mon, Aug 27, 2012 at 10:56 AM, Ian Hickson wrote: > On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: >> On Wed, Aug 3, 2011 at 8:50 AM, Randy wrote: >> > On top of that, the vast majority of these readers just translate it >> > back to text. It's just another input "device", as barcodes are fixed >> > (and sometimes standardized) fonts. >> >> True, so this is perhaps closer to an IME hint, as has been suggested >> for a couple of other input types. > > Do you mean something like inputmode=barcode? Can you elaborate on how > that would work? It's an intriguing idea, but I'm not sure I follow quite > how to specify it. Yes, something like that. In terms of the table in the spec: Keyword: barcode State: Barcode Fallback State: Default Description: Text input in the user's locale, with keys to activate the system's built-in barcode reader to retrieve a value instead. ~TJ
Re: [whatwg] input type=barcode?
On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: > On Wed, Aug 3, 2011 at 8:50 AM, Randy wrote: > > On top of that, the vast majority of these readers just translate it > > back to text. It's just another input "device", as barcodes are fixed > > (and sometimes standardized) fonts. > > True, so this is perhaps closer to an IME hint, as has been suggested > for a couple of other input types. Do you mean something like inputmode=barcode? Can you elaborate on how that would work? It's an intriguing idea, but I'm not sure I follow quite how to specify it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] New canvas additions
Hi, I've just read over the new(ish) canvas additions - paths, hit regions etc and they sound great - but are they "final". ie Can they be expected to be seen in browsers any time soon? I guess IE10 is wishful thinking, but IE11? By which time other browsers may have implemented them. Thanks. -- Richard
Re: [whatwg] Features for responsive Web design
On Tue, 21 Aug 2012 22:36:15 +0200, Steve Dennis wrote: While it's unlikely that screen resolution will go above 2x in the near future, should we be taking into account the zooming of specific elements that might result in the need for larger artwork? (take icons, that can scale all the way up to 512px or above) Or outdoor screens that are 4m x 8m, carrying the same content meant for a TV display and a message to your mobile. Use cases: + emergency information provision, where the sign is acting as a server providing information to all devices that can connect). + providing advertising, local information that can be rendered on large outdoor screens, tv-size screens, and for customers. cheers Chaals On 13/08/2012, at 5:39 PM, Henri Sivonen wrote: Another thing worth considering is if ever anyone is really going to go over 2x, given that at normal viewing distances 2x is roughly enough to saturate the resolution of the human eye (hence the "retina" branding). Even for printing photos, 192 pixels per inch should result in very good quality, and for line art, authors should use SVG instead of bitmaps anyway. -- Chaals - standards declaimer
