Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

On Fri, 06 Aug 2010 00:17:54 +0200, Simon Fraser wrote: or have some constants for behavior: const unsigned short ALLOW_KEYBOARD_INPUT = 1; void requestFullScreen(unsigned short behavior) This would be extensible, and would allow us to permit other behaviors later. Can't we use a stri

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] "Content-Disposition" property for tags

> On Wed, Aug 4, 2010 at 2:26 PM, Bjartur Thorlacius w= > rote: > > A) Per resource metadata: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Some resource is inherently insuitable for imm= > ediate > > =C2=A0 =C2=A0 =C2=A0 =C2=A0presentation. Metadata regarding this can be p= > rovided by e.g. the > > =C2=A0 =C2=

Re: [whatwg] and links with @rel=embed

On 8/5/10, Tab Atkins Jr. wrote: > On Wed, Aug 4, 2010 at 7:25 PM, Bjartur Thorlacius > wrote: >>> On Tue, 18 May 2010, bjartur wrote: >>> > >>> > First of all I think we should use >>> > instead of . >>> >>> What problem would this solve? >>> >> It would tell UAs that don't implement HTML 5 tha

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

On Fri, Aug 6, 2010 at 1:37 PM, Simon Fraser wrote: > On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote: > > On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser wrote: > > > > * void cancelFullScreen() >> >> I think "exit" would be better than "cancel". >> > > The only problem with "exit" is that y

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

On Aug 5, 2010, at 5:56 PM, Robert O'Callahan wrote: > On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser wrote: > This is feedback on the Mozilla FullScreen API proposal here: > > > > The user agent may transition a Document into or out

Re: [whatwg] Non-blocking SVG Canvas?

First off, where would be an appropriate area to continue this conversation? I'm guessing the discussion is becoming less relevant to the HTML5 spec... and I don't want to bother others on this list. (Sorry to everyone for any issues this causes.) Would this be better continued on the SVG mai

Re: [whatwg] WebSockets feedback

On Thu, 22 Jul 2010, Simon Pieters wrote: > > Because I expected the closing frame to be the exact sequence 0xFF 0x00 > and nothing else. It makes the protocol simpler to understand and > explain. This is a moot point now. > The problem I was discussing is the following scenario: > > 1. Clien

Re: [whatwg] WebSocket: garbage collection

On Thu, 20 May 2010, Simon Pieters wrote: > > [...] (I didn't realize that you could get message and error events in > CLOSING state.) Good point. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\

Re: [whatwg] WebSockets: why boolean return value for send()?

On Thu, 15 Apr 2010, Simon Pieters wrote: > > WebSocket send(): > > [[ > The send(data) method transmits data using the connection. ... If the > connection is established, and the string has no unpaired surrogates, and the > WebSocket closing handshake has not yet started, then the user agent must

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

On Fri, Aug 6, 2010 at 10:17 AM, Simon Fraser wrote: > This is feedback on the Mozilla FullScreen API proposal here: > > > > The user agent may transition a Document into or out of the > > fullscreen state at any time, whether or not

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/5/10, Garrett Smith wrote: > On 8/5/10, Oliver Hunt wrote: >> >> On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote: >> >>> On 8/4/10, Oliver Hunt wrote: On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote: > On 8/4/10, Garrett Smith wrote: > > [...] [...] > > I'm not

[whatwg] Feedback on the Mozilla FullScreen API proposal

This is feedback on the Mozilla FullScreen API proposal here: > The user agent may transition a Document into or out of the > fullscreen state at any time, whether or not script has requested > it. User agents are encouraged to provide

Re: [whatwg] Non-blocking SVG Canvas?

On 8/5/10 4:40 PM, Kevin Ar18 wrote: I guess that would solve future issues... but it involves a new spec right? Well, any sort of clarification here does, yes. My concern is that we get this specific HTML5-SVG interaction right now It needs a new spec no matter what, no matter where it liv

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On 8/5/10, Oliver Hunt wrote: > > On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote: > >> On 8/4/10, Oliver Hunt wrote: >>> >>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote: >>> On 8/4/10, Garrett Smith wrote: [...] > "submitButton" in form.elements > > Existing imple

Re: [whatwg] "Content-Disposition" property for tags

On Mon, Aug 2, 2010 at 7:37 PM, Boris Zbarsky wrote: > On 8/2/10 1:15 PM, Aryeh Gregor wrote: >> >> If you don't agree that this use-case is worth adding the feature for, >> do you think that: >> 3) Something else? > > For the use case your describe, it might just make more sense for browsers > to

Re: [whatwg] Non-blocking SVG Canvas?

> > Do you think there is a need for some clarification on this issue in the > > HTML5 specs? > > I think there's work on a clarification going on already in the CSS > working group. See the thread starting with > http://lists.w3.org/Archives/Public/www-style/2008Jul/0428.html I guess that w

Re: [whatwg] Non-blocking SVG Canvas?

On 8/5/10 4:16 PM, Kevin Ar18 wrote: Do you think there is a need for some clarification on this issue in the HTML5 specs? I think there's work on a clarification going on already in the CSS working group. See the thread starting with http://lists.w3.org/A

Re: [whatwg] Non-blocking SVG Canvas?

> This might depend on the browser, since nothing actually defines the > interaction of SVG and HTML in this area very well. Per SVG spec, > pointer-events is not supposed to apply to , for example. > > However in the case of Gecko specifically, the "none" value is supported > for all elements, no

Re: [whatwg] Non-blocking SVG Canvas?

> > Is it possible to create an SVG shape (say a hollow circle) that allows you > > to click through the invisible areas of the svg canvas to html objects > > underneath? > > Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty > > -Boris Another followup. First, I should tha

Re: [whatwg] Non-blocking SVG Canvas?

On 8/5/10 3:36 PM, Kevin Ar18 wrote: On 8/5/10 3:14 PM, Kevin Ar18 wrote: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEve

Re: [whatwg] Non-blocking SVG Canvas?

> On 8/5/10 3:14 PM, Kevin Ar18 wrote: > > Is it possible to create an SVG shape (say a hollow circle) that allows you > > to click through the invisible areas of the svg canvas to html objects > > underneath? > > Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty Quick quest

Re: [whatwg] Non-blocking SVG Canvas?

On 8/5/10 3:14 PM, Kevin Ar18 wrote: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? Yes. See http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty -Boris

[whatwg] Non-blocking SVG Canvas?

First off, let me start with a question to see if maybe I missed something somewhere: Is it possible to create an SVG shape (say a hollow circle) that allows you to click through the invisible areas of the svg canvas to html objects underneath? As far as I know, there is no way to do th

Re: [whatwg] [br] element should not be a line break

On Thu, Aug 5, 2010 at 1:24 PM, Christoph Päper wrote: > Jeremy Keith: > > > > The element is currently defined as "a paragraph-level thematic > break." I think could be defined as "a text-level thematic break." > > That makes perfect sense. The only problem I see is existing content which > re

Re: [whatwg] Race condition in media load algorithm

On 8/5/10 2:24 PM, Eric Carlson wrote: On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote: In practice, what Gecko would likely do here is to treat "stable state" as "the event loop is spinning", just like we would for the other case. This means that while a modal dialog is up, or a sync XHR i

Re: [whatwg] Race condition in media load algorithm

On Aug 5, 2010, at 8:22 AM, Boris Zbarsky wrote: > In practice, what Gecko would likely do here is to treat "stable state" as > "the event loop is spinning", just like we would for the other case. This > means that while a modal dialog is up, or a sync XHR is running or whatnot is > a stable

Re: [whatwg] [br] element should not be a line break

On Wed, Aug 4, 2010 at 2:31 PM, Aryeh Gregor > wrote: > On Wed, Aug 4, 2010 at 8:56 AM, Thomas Koetter > wrote: > > What strikes me though is that according to the spec "The br element > represents a line break". A *line* break is presentational in nature. The > break is structural, but restrict

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote: > On 8/4/10, Oliver Hunt wrote: >> >> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote: >> >>> On 8/4/10, Garrett Smith wrote: >>> >>> [...] "submitButton" in form.elements Existing implementations vary on when they use catchall

Re: [whatwg] [br] element should not be a line break

Jeremy Keith: > > The element is currently defined as "a paragraph-level thematic break." > I think could be defined as "a text-level thematic break." That makes perfect sense. The only problem I see is existing content which relies on consecutive ‘br’s producing multiple line breaks, i.e. of

Re: [whatwg] [br] element should not be a line break

On Thu, Aug 5, 2010 at 2:24 AM, Thomas Koetter wrote: > Aryeh wrote: >>That's invalid markup.  The first child of a (if any) must be a >>.  I don't know what the semantics of are supposed to be with >>no . > > According to the spec it is perfectly acceptable to leave out all dt elements: > "If a

Re: [whatwg] and links with @rel=embed

On Wed, Aug 4, 2010 at 7:25 PM, Bjartur Thorlacius wrote: >> On Tue, 18 May 2010, bjartur wrote: >> > >> > First of all I think we should use >> > instead of . >> >> What problem would this solve? >> > It would tell UAs that don't implement HTML 5 that the value of @href is > an URI. Then it can

Re: [whatwg] [br] element should not be a line break

I do see an advantage to permitting the arbitrary styling of the BR element. Often a series of links shown inline are separated by a pipe (|) character. In the past I've produced this effect using border-right and other such malarky on the anchors or inline LIs with the same, but I think semanti

Re: [whatwg] Race condition in media load algorithm

On 8/5/10 5:14 AM, Philip Jägenstedt wrote: It's not, in fact, trivial in implementation. You're making assumptions about how implementations work that don't seem warranted (e.g. the concept of "reference to that very script" is not well-defined in some implementations). In particular, what you'r

[whatwg] Discussing WebSRT and alternatives/improvements

Hi Ian, all, I'd like to pick up again on the discussion about what file format should be supported as baseline in HTML5 for providing time-synchronized text for media resources. This is particularly important now that we have the WebSRT proposal http://www.whatwg.org/specs/web-apps/current-work/w

Re: [whatwg] Form validation against invisible controls

On Wed, 04 Aug 2010 23:32:46 +0200, Ian Hickson wrote: On Fri, 4 Jun 2010, TAMURA, Kent wrote: > > > > An element is a "candidate for constraint validation" if > > 1. it is a validatable type, > >e.g. true if , false if > > 2. has no "disabled" attribute, > > 3. has no "readonly" attribu

Re: [whatwg] [br] element should not be a line break

Andy wrote: >Far greater semantic richness is obtained by using the ADR microformat Absolutely! Good point. As I was talking about HTML5 elements, I didn't take that into consideration. But then I suggest a combination of the two is even better. P. Sherman

Re: [whatwg] [br] element should not be a line break

I wrote: >> Given the inherent structure of an address, a definition list with >> name/value pairs would also be more semantically fitting than a paragraph of >> text with line breaks. Aryeh wrote; >That would either be incorrect use of , or would not display as >desired, or would require hiding

Re: [whatwg] Race condition in media load algorithm

On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky wrote: On 8/4/10 6:56 AM, Philip Jägenstedt wrote: On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky wrote: On 8/4/10 4:29 AM, Philip Jägenstedt wrote: That could be, but is this behavior actually useful for anything? It's certainly simpl

Re: [whatwg] Proposal for Web Storage expiration

As far as I can see, the next steps are (roughly in order): 1) Figure out whether it should be an origin wide setting or not. In order to prove that it needs to be a per LocalStorage bucket setting, its on you to come up with use cases where an origin wide setting is not enough. By use cases, we