On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard wrote:
> On Mon, Mar 26, 2012 at 7:33 PM, Jonas Sicking wrote:
>>
>> Requiring callers to find the null character first, and then use that
>> will require one additional pass over the encoded binary data though.
>
>
> That's extremely fast (memchr),
On Mon, Mar 26, 2012 at 6:11 PM, Kenneth Russell wrote:
> On Mon, Mar 26, 2012 at 5:33 PM, Jonas Sicking wrote:
>> On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell wrote:
* We lost the ability to decode from a arraybuffer and see how many
bytes were consumed before a null-terminator was hi
On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard wrote:
> I guess. It doesn't seem that important, since it's just a few lines of
> code. If this is done, I'd suggest that this helper API *not* have any
> special support for streaming (not to disallow it, but not to have any
> special handling fo
On Mon, Mar 26, 2012 at 7:33 PM, Jonas Sicking wrote:
> Requiring callers to find the null character first, and then use that
> will require one additional pass over the encoded binary data though.
>
That's extremely fast (memchr), and it's probably the fastest thing to do
anyway, compared to em
On Mon, Mar 26, 2012 at 9:11 PM, Kenneth Russell wrote:
> The rationale for specifying the string encoding and decoding
> functionality outside the typed array specification is to keep the
> typed array spec small and easily implementable. The indexed property
> getters and setters on the typed a
On Mon, Mar 26, 2012 at 5:33 PM, Jonas Sicking wrote:
> On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell wrote:
>>> * We lost the ability to decode from a arraybuffer and see how many
>>> bytes were consumed before a null-terminator was hit. One not terribly
>>> elegant solution would be to add a Tex
On Mon, Mar 26, 2012 at 4:40 PM, Joshua Bell wrote:
>> * We lost the ability to decode from a arraybuffer and see how many
>> bytes were consumed before a null-terminator was hit. One not terribly
>> elegant solution would be to add a TextDecoder.decodeWithLength method
>> which return a DOMString
On Mon, Mar 26, 2012 at 8:30 PM, Tab Atkins Jr. wrote:
>
> It's possible they'd gotten confused by the fact that the first
> heading in a section, no matter what rank it is, is more-or-less
> equivalent to a as far as the outlining algorithm is concerned.
Actually his stated reason was that the
On Mon, Mar 26, 2012 at 5:20 PM, Hugh Guiney wrote:
> On Mon, Mar 26, 2012 at 8:08 PM, Tab Atkins Jr. wrote:
>>
>> What text are you looking at that implies the outline depths of the
>> headings in the first snippet are all 1?
>
> I could not find anything, but the person who wrote that JavaScrip
On Mon, Mar 26, 2012 at 8:08 PM, Tab Atkins Jr. wrote:
>
> What text are you looking at that implies the outline depths of the
> headings in the first snippet are all 1?
I could not find anything, but the person who wrote that JavaScript
implementation seemed pretty convinced that this was the ca
== Proposal ==
For nested browsing contexts, expose the origin of the parent browsing
context via location.parentOrigin. (For non-nested browsing context,
the property would null.)
== Use Case ==
Some widgets want to behave differently depending on the context in
which they are embedded. For e
On Mon, Mar 26, 2012 at 5:02 PM, Hugh Guiney wrote:
> I am confused by the current definition of outline depth (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outline-depth),
> which, if I understand it correctly, states that the depth resets with each
> sub-outline.
I am confused by the current definition of outline depth (
http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outline-depth),
which, if I understand it correctly, states that the depth resets with each
sub-outline.
So, in the following:
Document Title
Section Titl
On Mon, Mar 26, 2012 at 6:27 PM, Jonas Sicking wrote:
> * It appears that we lost the ability to measure how long a resulting
> buffer was going to be and then decode into the buffer. I don't know
> if this is an issue.
>
The theory is that it probably isn't a real performance issue to decode
in
On Mon, Mar 26, 2012 at 4:12 PM, Glenn Maynard wrote:
> On Mon, Mar 26, 2012 at 4:49 PM, Joshua Bell wrote:
>
>> * A |stream| option, per the above
>>
>
> Does this make sense when you're using stream: false to flush the stream?
> It's still a streaming operation. I guess it's "close enough".
>
On Mon, Mar 26, 2012 at 2:49 PM, Joshua Bell wrote:
> On Mon, Mar 26, 2012 at 2:42 PM, Anne van Kesteren wrote:
>
>> On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell
>> wrote:
>>
>>> Bikeshed: The |continues| term doesn't completely thrill me; it's clear
>>> in context, but not necessarily what s
Hi Ian,
You wrote:
> It would be unfortunate to have to reserve the use of a name as
> generic as "translate" for a particular library.
Indeed. That said, the name "translate" already means something in the
platform—it's used by CSS transforms and by the 2D Context API.
Wink's usage of the term
On Mon, Mar 26, 2012 at 4:49 PM, Joshua Bell wrote:
> * A |stream| option, per the above
>
Does this make sense when you're using stream: false to flush the stream?
It's still a streaming operation. I guess it's "close enough".
* A |nullTerminator| option eliminates the need for a stringLength
On 3/26/12 3:19 PM, Ian Hickson wrote:
Changing it to a string doesn't affect that, though, does it?
Well, changing to a nullable string does affect it because doing
something like this:
myFrame.sandbox = myFrame.sandbox;
is a no-op, as by all sane rights it should be More importantl
On Mon, Mar 26, 2012 at 3:17 PM, Ian Hickson wrote:
> On Mon, 26 Mar 2012, Adam Barth wrote:
>>
>> WebKit recently implemented
>> http://www.whatwg.org/specs/web-apps/current-work/#attr-translate, but
>> that caused us to break orange.fr on mobile:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=822
On Mon, 26 Mar 2012, Boris Zbarsky wrote:
> On 3/26/12 3:13 PM, Mounir Lamouri wrote:
> > I do not like [PutForwards=value] but I still believe
> > DOMSettableTokenList is useful.
>
> I think the issue in this case is that the DOMSettableTokenList
> representation of the sandbox attribute, as spe
On Mon, 26 Mar 2012, Adam Barth wrote:
>
> WebKit recently implemented
> http://www.whatwg.org/specs/web-apps/current-work/#attr-translate, but
> that caused us to break orange.fr on mobile:
>
> https://bugs.webkit.org/show_bug.cgi?id=82246
>
> The problem is that
> http://www.winktoolkit.org/doc
On 3/26/12 3:13 PM, Mounir Lamouri wrote:
I do not like [PutForwards=value] but I still believe
DOMSettableTokenList is useful.
I think the issue in this case is that the DOMSettableTokenList
representation of the sandbox attribute, as specced, cannot distinguish
between "not sandboxed at all
On Mon, 26 Mar 2012, Ian Melven wrote:
>
> While working on implementing HTML5's iframe sandbox, I realized that in
> script, one can't tell the difference between these two cases :
> and .
>
> In both cases, iframe.sandbox will be '' (the empty string). This is
> true in Webkit and IE10's imp
On 03/26/2012 02:37 PM, Ian Melven wrote:
> While working on implementing HTML5's iframe sandbox, I realized that in
> script, one can't
> tell the difference between these two cases : and ''>.
>
> In both cases, iframe.sandbox will be '' (the empty string). This is
> true in Webkit and IE10's
WebKit recently implemented
http://www.whatwg.org/specs/web-apps/current-work/#attr-translate, but
that caused us to break orange.fr on mobile:
https://bugs.webkit.org/show_bug.cgi?id=82246
The problem is that
http://www.winktoolkit.org/documentation/symbols/HTMLElement.html#translate
has a the f
On Mon, Mar 26, 2012 at 2:42 PM, Anne van Kesteren wrote:
> On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell
> wrote:
>
>> Bikeshed: The |continues| term doesn't completely thrill me; it's clear
>> in context, but not necessarily what someone might go searching for.
>> {eof:true} would be lovely
Hi,
While working on implementing HTML5's iframe sandbox, I realized that in
script, one can't
tell the difference between these two cases : and .
In both cases, iframe.sandbox will be '' (the empty string). This is
true in Webkit and IE10's implementations, as far as my testing can tell (and
On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell
wrote:
Bikeshed: The |continues| term doesn't completely thrill me; it's clear
in context, but not necessarily what someone might go searching for.
{eof:true} would be lovely except we want the default to be yes-EOF but a
falsy JS value. |noEOF|
On Sat, Mar 24, 2012 at 6:52 AM, Glenn Maynard wrote:
> On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren
> wrote:
>
> > Another way would be to have a second optional argument that indicates
> > whether more bytes are coming (defaults to false), but I'm not sure of
> the
> > chances that would
30 matches
Mail list logo
