On Fri, 06 Aug 2010 00:17:54 +0200, Simon Fraser s...@me.com 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
Justin Lebar:
Christoph Päper christoph.pae...@crissov.de wrote:
Why do you want to put this on the HTML level (exclusively), not the HTTP
level?
If you reference an image from a CSS file and include that CSS file in an
HTML file which uses resource packages, the image can be loaded
On Thu, 05 Aug 2010 17:22:17 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
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
On 8/6/10 4:04 AM, Philip Jägenstedt wrote:
See, this concept of a script is a funny one, given that scripts are
reentrant, and that multiple different scripts can all be running at
the same time, possibly with event loops nested in between on the
conceptual callstack
Well, what we really look
Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan
to allow fullscreen without the use of a user-trigggered event such as a
button-click like Flash does. Not only would I like to launch my app in
fullscreen to play a game, I may want to allow my advertisers to launch
On Aug 5, 2010, at 9:24 PM, Robert O'Callahan wrote:
It's probably worth having such an event, but there will be times when
neither fullscreendenied or fullscreenchanged are fired. I hope authors don't
write apps that break in such cases.
We definitely need some sort of event to indicate
Snipping liberally...
On Thu, 05 Aug 2010 17:01:47 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
CONSIDERING EXISTING FORMATS
Note that the subtitling community has traditionally been using the
Subrip
(srt) or SubViewer (sub) formats as a simple format and SubStation alpha
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper
christoph.pae...@crissov.de wrote:
Justin Lebar:
Christoph Päper christoph.pae...@crissov.de wrote:
Why do you want to put this on the HTML level (exclusively), not the HTTP
level?
If you reference an image from a CSS file and include that
On Fri, Aug 6, 2010 at 12:46 AM, Christoph Päper
christoph.pae...@crissov.de wrote:
Justin Lebar:
Christoph Päper christoph.pae...@crissov.de wrote:
Why do you want to put this on the HTML level (exclusively), not the HTTP
level?
If you reference an image from a CSS file and include that
On Tue, 8 Jun 2010, Mounir Lamouri wrote:
An example where this behavior seems buggy:
- input.type and button.type: every browser makes it return text if
@type isn't set to a known value. If we follow the specifications, .type
should return the current value of @type.
Fixed.
Examples
On Tue, 8 Jun 2010, Eitan Adler wrote:
A lot of websites let you upload either from a file on your hard drive
or from a link on the web. Most of the time this is done by having two
different inputs: One for a file and the other for a URL.
If there were some type of input like upload'
On Tue, 8 Jun 2010, Charles Pritchard wrote:
As part of a web form, a user signs their digital signature to confirm
acceptance of terms.
While filling out an online profile, a user submits a simple doodle as
their avatar.
To quickly log into an online system, a user scribbles a
On Thu, Aug 5, 2010 at 7:43 PM, Bjartur Thorlacius svartma...@gmail.com wrote:
On 8/5/10, Tab Atkins Jr. jackalm...@gmail.com wrote:
I'll note, though, that that isn't a very useful pattern for users in
the first place. Most users won't have any idea what to do with a
video file, especially
On Fri, Aug 6, 2010 at 12:10 PM, Ian Hickson i...@hixie.ch wrote:
I think it might make sense to expose file upload progress on a form
to a same-origin server. It would be interesting to see how the equivalent
feature in XMLHttpRequest is received before we add this, though.
I've made a note
On Wed, Aug 4, 2010 at 7:03 PM, Jeremy Keith jer...@adactio.com wrote:
This is no longer true. The semantics of b and i have been changed in
HTML5, specifically to separate the presentation from the meaning.
Specifically, any reference to screen- or page-specific styling like bold
and
On Fri, 2010-08-06 at 12:43 -0700, Tab Atkins Jr. wrote:
On Thu, Aug 5, 2010 at 7:43 PM, Bjartur Thorlacius svartma...@gmail.com
wrote:
On 8/5/10, Tab Atkins Jr. jackalm...@gmail.com wrote:
I'll note, though, that that isn't a very useful pattern for users in
the first place. Most users
On 8/5/10 9:14 PM, Kevin Ar18 wrote:
First off, where would be an appropriate area to continue this conversation?
Here is probably fine, unless you want one of www-st...@w3.org or
www-...@w3.org.
I'm guessing the discussion is becoming less relevant to the HTML5 spec...
But this isn't an
On Thu, Aug 5, 2010 at 5:24 AM, Thomas Koetter
thomas.koet...@id-script.de wrote:
That's not correct.
Then give a counterexample.
Actually, I shouldn't have used the term definition list as such a list
type does not exist in HTML5. The meaning of the dl element has been changed
to that of
On Thu, Aug 5, 2010 at 1:48 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote:
That's totally incorrect in HTML5 as Thomas has pointed out.
As I pointed out, it's only theoretically incorrect. b still means
something that's conventionally boldface, and i still means
something that's conventionally
On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields royalrod...@gmail.com wrote:
Why not just list br along with the other obsolete elements instead of
trying to rebrand it semantically?
What markup do you propose for addresses and poems, and in what
practical sense would this markup be superior to
On Fri, Aug 6, 2010 at 1:12 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
On Fri, 2010-08-06 at 12:43 -0700, Tab Atkins Jr. wrote:
Do browsers supply a file extension for un-extensioned files based on
the mimetype? I didn't think they did. A file without an extension
confuses most
On Fri, Aug 6, 2010 at 3:01 PM, Ian Hickson i...@hixie.ch wrote:
I'm happy to make more of them limited, especially new attributes or ones
that were already that way, but I'd rather not change the default as that
can have unexpected effects (e.g. some of the attributes are definitely
not so
On Fri, Aug 6, 2010 at 4:29 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
On Thu, Aug 5, 2010 at 2:53 PM, Bryce Fields royalrod...@gmail.com wrote:
Why not just list br along with the other obsolete elements instead of
trying to rebrand it semantically?
What markup do you propose for
On Tue, Aug 3, 2010 at 8:31 PM, Justin Lebar justin.le...@gmail.com wrote:
We at Mozilla are hoping to ship HTML resource packages in Firefox 4,
and we wanted to get the WhatWG's feedback on the feature.
For the impatient, the spec is here:
http://people.mozilla.org/~jlebar/respkg/
I
On Fri, Aug 6, 2010 at 3:10 PM, Ian Hickson i...@hixie.ch wrote:
I think it might make sense to expose file upload progress on a form
to a same-origin server. It would be interesting to see how the equivalent
feature in XMLHttpRequest is received before we add this, though.
I've made a note
On Sat, Aug 7, 2010 at 1:39 AM, Mike Wilcox m...@mikewilcox.net wrote:
Kudos to Mozilla (and Robert?). This is awesome. It does appear that you
plan to allow fullscreen without the use of a user-trigggered event such as
a button-click like Flash does.
The proposed spec allows that, but I
On Sat, Aug 7, 2010 at 1:57 AM, Mike Wilcox m...@mikewilcox.net wrote:
Regarding fullscreen elements: I appreciate the initiative, but I wonder if
it's necessary to allow fullscreen at the element level?
It's not necessary, but it's a very useful convenience. It also allows the
UA to perform
So if resource packages don't share caches, you need to either give up
on caching, [or] put a given file only in one resource package on your
whole site. The latter is not practical if pages use small, fairly
random subsets of your assets and it's not feasible to package them
all on every
On 08/06/2010 09:01 PM, Ian Hickson wrote:
- input.autocomplete: at the moment, it is returning the content but it
could return the resulting autocompletion state which is maybe a bit
more than just being limited to only known values but still in the same
spirit.
I haven't changed this;
Hi Ian,
I think there's a typo in the description of the TimedTrack mode at
http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#timed-track-mode.
It says:
Hidden
Indicates that the timed track is active, but that the user agent is not
actively displaying the cues. If no
First off, where would be an appropriate area to continue this conversation?
Here is probably fine, unless you want one of www-st...@w3.org or
www-...@w3.org.
I'm guessing the discussion is becoming less relevant to the HTML5 spec...
But this isn't an HTML5 spec list... It's a whatwg
31 matches
Mail list logo
