On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan wrote:
So the ::backdrop could be styled to not cover the whole page?
Yes. It's there for convenience only, since people often want an
element that does exactly this. If we didn't provide it explicitly,
they
On 5/04/12 2:39 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan wrote:
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
Both of your examples would be done by using elements that are
children of the, and perhaps just positioned explicitly
somewhere.
That doesn't sound like a goo
On Thu, 5 Apr 2012, Sean Hogan wrote:
>
> So the ::backdrop could be styled to not cover the whole page?
> Could it default to a "top" layer, but optionally be given a z-index?
The ::backdrop specifically would just be immediately below its element in
the "top layer" stack, at least as proposed.
A follow up about this proposal:
Based on the feedbacks we got on this list we've implemented the following
API to do experiments in Chrome:
DataTransferItem.getAsEntry(in EntryCallback callback)
which takes a callback that returns FileEntry or DirectoryEntry if it's for
drop event and the item'
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan wrote:
> On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
>> Both of your examples would be done by using elements that are
>> children of the, and perhaps just positioned explicitly
>> somewhere.
>
> That doesn't sound like a good solution, but maybe I'm misund
In fact, in the vein of opt-in disclosure perhaps something like
discloselocation={none|origin|full} would be more convenient - in
which case, you get something like
window.parentLocations[n].{origin|href|hash|...}
I constantly fear that origin scoping for security mechanisms is too
coarse-grained
I can think of some fringe scenarios where disclosing parent origins
may be somewhat undesirable. One example may be a "double-bagged"
advertisement, where the intent is to not tell the advertiser about
the top-level page the ad is embedded on (visited site ->
pointing to the ad provider site ->
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan wrote:
> So the ::backdrop could be styled to not cover the whole page?
Yes. It's there for convenience only, since people often want an
element that does exactly this. If we didn't provide it explicitly,
they'd just awkwardly wrap their s in a backgro
On Wed, Apr 4, 2012 at 9:50 PM, Sean Hogan wrote:
> Will non-modal `` have a backdrop?
Dunno! We've just been thinking about modal dialogs, since they're
the hard ones.
~TJ
On Wed, Apr 4, 2012 at 11:20 AM, Adam Barth wrote:
> On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson wrote:
>> On Tue, 3 Apr 2012, Adam Barth wrote:
>>> On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson wrote:
>>> > On Tue, 3 Apr 2012, Adam Barth wrote:
>>> >> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson
On 4/04/12 9:14 AM, Ian Hickson wrote:
So based on our discussions on IRC and in person earlier today, I think
the following additions to the Fullscreen specification would provide the
necessary infrastructure to support:
- Add a new stacking layer to the CSS 2.1 Appendix E layering model,
af
On 5/04/12 3:31 AM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
If this works, then I'll use this for.
How does this work for nested browsing contexts? Currently using (not in HTML yet) you can fullscr
On Wed, Apr 4, 2012 at 6:52 PM, Ojan Vafai wrote:
> 1. We should add iframe[seamless] { display:block; }.
> http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
> expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
> uses, seamless iframes will not w
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless iframes will not want a border and will want to fill their
container. This way
On Wed, Apr 4, 2012 at 11:09 AM, Joshua Bell wrote:
> Any further input on Kenneth's suggestions?
>
I largely disagree with those suggestions, because I don't believe they
align with the natural, intuitive usage of the API.
Re: ArrayBufferView vs. DataView - I'm tempted to make the switch to ju
On Wed, Apr 4, 2012 at 11:20 AM, Adam Barth wrote:
> On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson wrote:
>> On Tue, 3 Apr 2012, Adam Barth wrote:
>>> On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson wrote:
>>> > On Tue, 3 Apr 2012, Adam Barth wrote:
>>> >> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson
On Wed, Apr 4, 2012 at 10:39 AM, Anne van Kesteren wrote:
> On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr.
> wrote:
>> The thinking so far is that we don't do anything special for dialogs.
>> They don't escape their , and the doesn't have any
>> special response to a dialog spawning within i
On Wed, 4 Apr 2012, Philip Jägenstedt wrote:
> > >
> > > In current Opera and Firefox the timeline is always normalized to
> > > start at 0, so the time that corresponds to 0 in the original
> > > timeline would be at a negative currentTime.
> >
> > I still don't really understand what you mean
On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson wrote:
> On Tue, 3 Apr 2012, Adam Barth wrote:
>> On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson wrote:
>> > On Tue, 3 Apr 2012, Adam Barth wrote:
>> >> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson wrote:
>> >> > On Tue, 3 Apr 2012, Adam Barth wrote:
>> >
On Tue, 3 Apr 2012, Adam Barth wrote:
> On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson wrote:
> > On Tue, 3 Apr 2012, Adam Barth wrote:
> >> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson wrote:
> >> > On Tue, 3 Apr 2012, Adam Barth wrote:
> >> >> Talking with some folks off-list, there are also use ca
On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr.
wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren
wrote:
How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embedded
via an . Would we then have to push th
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren wrote:
> On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
>>
>> If this works, then I'll use this for .
>
> How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embe
Any further input on Kenneth's suggestions?
Re: ArrayBufferView vs. DataView - I'm tempted to make the switch to just
DataView. As discussed below, data parsing/serialization operations will
tend to be associated with DataViews. As Glenn has mentioned elsewhere
recently, it is possible to accident
On Fri, 30 Mar 2012 14:00:38 +0200, Anne van Kesteren
wrote:
Ideally someone does detailed content analysis to figure out what the
best path forward is here, though I'm not entirely sure how.
I still don't know how, but thanks to Simon Pieters I gathered some URLs
from http://dotnetdotcom.
On Tue, Apr 3, 2012 at 10:08 PM, Anne van Kesteren wrote:
>> I didn't mean a prescan. I meant proceeding with the real parse and
>> switching decoders in midstream. This would have the complication of
>> also having to change the encoding the document object reports to
>> JavaScript in some cases
On Tue, 03 Apr 2012 19:13:12 +0200, Ian Hickson wrote:
On Tue, 3 Apr 2012, Philip Jägenstedt wrote:
> >
> > It could also do with a good example. The spec says:
> >
> > "If the media resource specifies an explicit start time and date,
> > then that time and date should be considered the zero p
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
If this works, then I'll use this for .
How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embedded
via an . Would we then have to push the element on the
st
On Wed, 04 Apr 2012 02:25:01 +0200, Robert O'Callahan
wrote:
On Tue, Apr 3, 2012 at 9:28 PM, Philip Jägenstedt
wrote:
AFAIK, no browser supports any format for that does not have
timestamps.
I have patches being reviewed that add support for using MediaStreams as
sources. These do n
28 matches
Mail list logo
