Thanks for the changes, some comments below.
On Tue, 31 Aug 2010 01:58:52 +0200, Ian Hickson wrote:
On Sat, 7 Aug 2010, Anne van Kesteren wrote:
2) Is there any reason we cannot also use this "no browsing context"
clause to define document.cookie rather than having a special type of
Document o
On Sun, 8 Aug 2010, Tantek �~Gelik wrote:
>
> the 6 new datetime types are quite useful for a variety of
> use-cases but could use 2 more that fit in with the current set.
>
> In addition to current new absolute types of "date", "week", "month", it
> makes sense to add type="year" as well for c
On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote:
> On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth wrote:
>> On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote:
>>> Should @seamless imply @sandbox too, then?
>>
>> I think there lots of use cases for seamless that don't require
>> sandbox.
On Sat, 7 Aug 2010, Tantek �~Gelik wrote:
>
> the new element is very useful for absolute dates and times, but
> omits several useful granularity levels, in particular for dates.
>
> The following additional date granularities would be useful, and are
> fairly straightforward to incorporate int
On Sat, 7 Aug 2010, Anne van Kesteren wrote:
>
> 1) document.location returns null when there is no browsing context for
> the Document. document.defaultView needs this too. (It returns null in
> the implementations I tested.)
Done.
> 2) Is there any reason we cannot also use this "no browsin
On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth wrote:
> On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote:
>> Should @seamless imply @sandbox too, then?
>
> I think there lots of use cases for seamless that don't require
> sandbox. For example, suppose a site wants to show a login form on
>
On Mon, Aug 30, 2010 at 1:57 PM, Maciej Stachowiak wrote:
>
> On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote:
>
>> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>>>
>>> I think it's better to let these remain orthogonal features. In general I
>>> think it is a net negative to usab
>
> >>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
> This would mean that there is no way for an author to use @srcdoc
> *without* sandboxing. This appears to be a minority use-case in the
> first place (as far as I can tell, it's pretty much just useful for
> testing
On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote:
>
> On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote:
>
>> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>>>
>>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
>>>
While talking with the implementor of @srcdoc in W
On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote:
> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>>
>> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
>>
>>> While talking with the implementor of @srcdoc in Webkit, it came up
>>> that, though @srcdoc is *designed* for use w
On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote:
> On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>>
>> I think it's better to let these remain orthogonal features. In general I
>> think it is a net negative to usability when Feature A implicitly turns on
>> Feature B. Implicit r
On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>
> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
>
>> While talking with the implementor of @srcdoc in Webkit, it came up
>> that, though @srcdoc is *designed* for use with @sandbox, the author
>> still has to explicitly add @sandbo
On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote:
>
> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
>
>> While talking with the implementor of @srcdoc in Webkit, it came up
>> that, though @srcdoc is *designed* for use with @sandbox, the author
>> still has to explicitly add @sandbo
On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
> While talking with the implementor of @srcdoc in Webkit, it came up
> that, though @srcdoc is *designed* for use with @sandbox, the author
> still has to explicitly add @sandbox to the or else they
> don't get the sandbox security model.
>
>
On Mon, Aug 30, 2010 at 4:19 AM, Simon Pieters wrote:
> This change clashes with data-*.
How? Are you missing the fact that *two* consecutive hyphens are needed?
While talking with the implementor of @srcdoc in Webkit, it came up
that, though @srcdoc is *designed* for use with @sandbox, the author
still has to explicitly add @sandbox to the or else they
don't get the sandbox security model.
Can we make this automatic? Specifically, when is specified (wi
On Mon, 30 Aug 2010 14:35:03 +0200, L. David Baron
wrote:
But the problem with adding a new general selectors feature is that
authors will discover it and try to use it for things that aren't ok
being ASCII-only.
Yeah, maybe. But we could define it as some kind of token feature. As far
as I
On Monday 2010-08-30 14:28 +0200, Anne van Kesteren wrote:
> On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron
> wrote:
> >On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote:
> >>We need a feature for case-insensitive matching in Selectors already
> >>for XHTML (if we really care about
On Sun, 29 Aug 2010 15:01:27 +0200, L. David Baron
wrote:
On Wednesday 2010-08-25 10:28 +0200, Anne van Kesteren wrote:
We need a feature for case-insensitive matching in Selectors already
for XHTML (if we really care about this, not sure we do).
Allowing case-insensitive matching beyond mat
On Tue, 17 Aug 2010 00:14:17 +0200, wrote:
Author: ianh
Date: 2010-08-16 15:14:15 -0700 (Mon, 16 Aug 2010)
New Revision: 5307
Modified:
complete.html
index
source
Log:
[giow] (0) use vendor--feature instead of _vendor-feature since Apple
engineers think underscores are ugly.
Fixing
20 matches
Mail list logo
