Small authors are hardly an alternative to YouTube because they use YouTube
(or a similar service) to publish their content. Neither do YouTube publish
most of the stuff on their own; they only allow the authors to do it using
YT technology.
In short, if you do not have the know-how to serve your
Regarding DOMTokenList, why not:
contains(): true
add,remove,toggle(): no effect?
Are there situations that would require an exception to be thrown, or else
the page would go out in a blast?
Chris
For those of you that are concerned whether Microsoft will support web
video: Internet Explorer already does, albeit in the Microsoft WayT:
* dynsrc Property (IMG, INPUT, INPUT type=image, ...)
URL:http://msdn.microsoft.com/en-us/library/ms533742(VS.85).aspx
:-)
2009/7/6 Kristof Zelechovski giecr...@stegny.2a.pl:
Small authors are hardly an alternative to YouTube because they use YouTube
(or a similar service) to publish their content.
[snip]
In short, if you do not have the know-how to serve your video content, you
will just use YouTube and never
2009/7/6 Jim Jewett jimjjew...@gmail.com:
As of 2009, there is no single efficient codec which works on all
modern browsers. Content producers are encouraged to supply the video
in both Theora and H.264 formats, as per the following example
A spec that makes an encumbered format a SHOULD is
On Jul 6, 2009, at 12:52 AM, Lino Mastrodomenico wrote:
HTML5 solves this problem because now the player is embedded in the
browser, so I started using video src=whatever.ogv and hiding the
YouTube object blurb inside it as a fallback. This should work with
every browser (except maybe Safari
[to list as well, oops]
-- Forwarded message --
From: David Gerard dger...@gmail.com
Date: 2009/7/6
Subject: Re: [whatwg] Chipset support is a good argument
To: Ian Hickson i...@hixie.ch
2009/7/6 Ian Hickson i...@hixie.ch:
Given the volume of support Theora has gotten without
On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
You've expressed something similar in a couple of the other threads as
well, and I find it puzzling. It's true that if you spec things that
will never be implemented, it harms the integrity of the spec. But on
the other hand, if you allow any one
2009/7/6 Maciej Stachowiak m...@apple.com:
Here's an example of some markup that will work on a wide range of browsers,
if you provide Ogg and MP4 versions of your video:
http://camendesign.com/code/video_for_everybody. The MP4 version can be
played either through video in browsers that
On Mon, 6 Jul 2009, Jonas Sicking wrote:
On Sun, Jul 5, 2009 at 8:14 PM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
It's not the standard alone that makes it happen. The standard is for
the general market neither a necessary nor a sufficient requirement
On Sun, Jul 5, 2009 at 8:14 PM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 6 Jul 2009, Silvia Pfeiffer wrote:
It's not the standard alone that makes it happen. The standard is for
the general market neither a necessary nor a sufficient requirement for
uptake. However, for the individual vendor,
Hi,
WHATWG is a public community specifying web technologies, such as HTML5.
Xiph.org is a public community specifying free codecs, such as Ogg Theora.
It's great that many people in the web community are supporting Ogg;
but it seems that specifying Ogg in HTML5 is not practical for WHATWG.
On Mon, 6 Jul 2009 09:02:51 + (UTC), Ian Hickson i...@hixie.ch wrote:
On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
You've expressed something similar in a couple of the other threads as
well, and I find it puzzling. It's true that if you spec things that
will never be implemented, it
On Jul 6, 2009, at 3:00 AM, Lino Mastrodomenico wrote:
(BTW, canPlayType in Safari 4.0 seems buggy: it always
returns no, even with XiphQT installed).
That was fixed just after Safari 4.0 shipped, it should work in
WebKit nightly builds. See http://trac.webkit.org/changeset/43972.
eric
Hi everybody.
I've recently done some experiments using SVG filters (see
http://www.tapper-ware.net/stable/web.filter.voxels/index.xhtml ). SVG
Filters basically offer greater speed for users and easier optimization for
implementing parties than trying to implement standard image
The spec (at least from what I know) wants to create a unified experience,
we don't want users to have a different experience from browser to browser.
Nor do developers want to implement hacks for every browser. If no common
ground can be reached then maybe no common ground is better than common
When a page is loaded from an AppCache, even when online, external resources
such as images will not be loaded at all.
If foo.com has an image img src=http://bar.com/img.png; /, then according
to the steps in
Not loading cross-domain images in e-mail messages is a standard privacy
feature e.g. in Microsoft Outlook. (Indeed, that means that Microsoft
Outlook does not allow any external images, only attachments).
The workaround, to save as a HTML document and view in browser, should work.
If the images
Yup... the source of grief is...
6.9.7 Changes to the networking model5: Fail the resource load.
The intent behind this was making the testing of offline application
easier. Given the unintended consequence Aaron brought up, we should
probably revisit this.
Maybe only fail to load the
I just read about how other markup languages (e.g. MathML, SVG) will be
implicitly namespace'd when put into an appropriate tag here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020740.htm
l
Allowing XML namespaces to be inserted into HTML5 is a neat feature,
but
On Mon, Jul 6, 2009 at 9:17 PM, Anton Frattaroli wrote:
I just read about how other markup languages (e.g. MathML, SVG) will be
implicitly namespace’d when put into an appropriate tag here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020740.html
Allowing XML namespaces to
On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyteawh...@google.com wrote:
When a page is loaded from an AppCache, even when online, external resources
such as images will not be loaded at all.
If foo.com has an image img src=http://bar.com/img.png; /, then according
to the steps in
On Mon, Jul 6, 2009 at 2:47 PM, Thomas Broyert.bro...@gmail.com wrote:
On Mon, Jul 6, 2009 at 9:17 PM, Anton Frattaroli wrote:
Mixing markup languages also makes the DOCTYPE declaration pretty much null
and void. What’s the point of a DTD if you’re going to add in other DTDs?
There's no DTD
On 7/6/2009 9:08 AM, Kristof Zelechovski wrote:
Regarding DOMTokenList, why not:
contains(): true
add,remove,toggle(): no effect?
That could be an option. There is already a INVALID_CHARACTER_ERR
exception thrown if the token contains spaces. So I think it would be
consistent
On Tue, Jul 7, 2009 at 2:09 AM, hansschmuc...@gmail.com wrote:
SVG Filters are a relatively easy spec, where the most important parts can
be implemented in a matter of hours.
Speaking as an implementor of SVG filters, I don't believe you :-).
Am I the only one seeing any benefit for this or
Couple of comments...
1) Aaron's comment was not about caching them at all, it was about referring
to them from a cached application and having them load via the network as
usual. Step 5 gets in the way of that.
2) The spec already allows for cross-origin caching, they can be explicitly
listed
On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sicking jo...@sicking.cc wrote:
The workaround is for the gmail to download the images to gmails
servers and then serve them from a google domain.
This isn't just an email problem. It'll also affect RSS readers, document
editors, blogging tools, and
On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sickingjo...@sicking.cc wrote:
On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyteawh...@google.com wrote:
When a page is loaded from an AppCache, even when online, external resources
such as images will not be loaded at all.
If foo.com has an image img
On Tue, Jul 7, 2009 at 9:21 AM, hansschmuc...@gmail.com wrote:
On Tue, Jul 7, 2009 at 2:09 AM, hansschmuc...@gmail.com wrote:
SVG Filters are a relatively easy spec, where the most important parts
can be implemented in a matter of hours.
On Jul 6, 2009 10:54pm, Robert O'Callahan
On Mon, 6 Jul 2009, Kartikaya Gupta wrote:
Seriously? If I were to declare that I, as a browser vendor, will not
support anything in HTML5 that wasn't in HTML4, would you actually
remove all the new additions from the HTML5 spec?
Not immediately, but if you had notable market share and we
On Mon, 6 Jul 2009 hansschmuc...@gmail.com wrote:
Aside from drawWindow, we are currently unable to build a processing
chain that does include filters, other than applying a filter to the
result rendered by the canvas via foreignObject.
Doing filters in canvas is an interesting idea, but I
On Mon, 6 Jul 2009, Anton Frattaroli wrote:
Allowing XML namespaces to be inserted into HTML5 is a neat feature,
but challenges its definition as a subset of XML.
As others have noted, HTML5 in text/html isn't XML. If you want to use
HTML5 with XML you have to use XHTML5, which does require
The current behavior in Webkit is for URL fragments to be stored in the
URLs for master entries. I believe this to be a bug in Webkit, but cannot
determine from the spec if this is or not.
Example:
1. Navigate to: http://www.thecssninja.com/demo/offline_webapp/#foo
2. Go offline
3. Do a browser
On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahanrob...@ocallahan.org wrote:
On Tue, Jul 7, 2009 at 9:21 AM, hansschmuc...@gmail.com wrote:
On Tue, Jul 7, 2009 at 2:09 AM, hansschmuc...@gmail.com wrote:
SVG Filters are a relatively easy spec, where the most important parts
can be
Doing filters in canvas is an interesting idea, but I think that it is
probably too early to add it. We have dozens of feature requests for the
next version of canvas already.
For what it's worth, you can do filters manually using getImageData() and
putImageData().
But if we begin with a
On Tue, 7 Jul 2009, Hans Schmucker wrote:
Doing filters in canvas is an interesting idea, but I think that it
is probably too early to add it. We have dozens of feature requests
for the next version of canvas already.
For what it's worth, you can do filters manually using
Kartikaya Gupta wrote:
I'm not sure whether specs can create demand, and frankly, I find it somewhat
irrelevant to the point at hand. The fact is there is already demand for a
single encoding format that will be compatible with as many browsers as
possible. The only question is what that
I think in practice if people have declarative filter needs, they'll just
use SVG. But that said, filters are indeed something we should look at in
a future version. Right now, though, I'd rather we let the browser vendors
get interoperable on what exists already in the spec.
Often, you have
I should really add one point. The Canvas spec, above all, is
predictable. You pretty much know exactly what you'll get when you
perform certain actions. Relying directly on SVG filters makes things
harder to understand and predict. A flat, stripped-down API on the
other hand could provide the
On Tue, 7 Jul 2009, Hans Schmucker wrote:
About interoperability: At least for me Canvas support seems very stable
across browsers, which is why I'm comfortable asking for the next step,
as long as including it doesn't change compatibility with existing JS
code and wouldn't require
On Tue, Jul 7, 2009 at 10:52 AM, Hans Schmucker hansschmuc...@gmail.comwrote:
It may just be me, but I think that the success of Canvas, which is
way ahead of HTML5 in general, is largely due to the fact that it's
pretty much standalone. You don't have to read through hundreds of
pages of
On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker hansschmuc...@gmail.comwrote:
I should really add one point. The Canvas spec, above all, is
predictable. You pretty much know exactly what you'll get when you
perform certain actions.
Like arcTo?
Relying directly on SVG filters makes things
On Mon, Jul 6, 2009 at 7:30 PM, Joshua Cranmerpidgeo...@verizon.net wrote:
Perhaps what could break the deadlock would be Apple conceding to
implementing Theora, or Mozilla conceding to implementing H.264. In either
case, the decision to implement would most likely be a result of market
On Tue, Jul 7, 2009 at 1:47 AM, Robert O'Callahanrob...@ocallahan.org wrote:
On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker hansschmuc...@gmail.com
wrote:
I should really add one point. The Canvas spec, above all, is
predictable. You pretty much know exactly what you'll get when you
perform
On Thu, 2 Jul 2009, Olli Pettay wrote:
[22:59] smaug I'm trying to understand the Each browsing context,
including
nested browsing context, has a distinct session history.
[23:00] smaug but in practice if go(-1) is called in a iframe (and it
hasn't
been navigated from the
*sigh* I hate it when I start sounding whiny and I probably did in the
previous posts.
I'll try to sum it up again without the whining sound.
I simply think that when using SVG filters, we are much more likely to
add a lot of these border-cases where browsers behave subtly
different. We already
On Tue, 7 Jul 2009, Hans Schmucker wrote:
I simply think that when using SVG filters, we are much more likely to
add a lot of these border-cases where browsers behave subtly
different. We already have that problem with SVG in general and it's
really holding SVG back. If at all possible,
If we add filters to canvas, I would expect to be defined in a way that
doesn't leave edge cases undefined.
But for all practical purposes, that would be what we'd do if we just
said just use your usual SVG filter system,
On Tue, Jul 7, 2009 at 12:38 PM, Hans Schmucker hansschmuc...@gmail.comwrote:
I simply think that when using SVG filters, we are much more likely to
add a lot of these border-cases where browsers behave subtly
different. We already have that problem with SVG in general and it's
really holding
Ian Hickson wrote:
On Thu, 2 Jul 2009, Charles Pritchard wrote:
I'd like to see canvas support added to the video tag (it's as
natural as img).
video elements can be painted onto canvas elements already; did you
have something more in mind?
This is sufficient. video can be used
On Tue, 7 Jul 2009, Hans Schmucker wrote:
If we add filters to canvas, I would expect to be defined in a way
that doesn't leave edge cases undefined.
But for all practical purposes, that would be what we'd do if we just
said just use your usual SVG filter system,
That's possible, I
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At this
point I don't really want to add new features yet because otherwise
we'll never get the browser vendors caught up to implementing the same
spec. :-)
Consider a
Whatever those issues are that you're referring to, they need to be fixed in
SVG already. Creating a new set of well-defined behaviours in canvas can
only add more work. If the new well-defined behaviours fail to match the
behaviour SVG requires, then the situation will be even worse.
feImage
On Mon, Jul 6, 2009 at 2:40 PM, Aaron Boodman a...@google.com wrote:
On Mon, Jul 6, 2009 at 1:28 PM, Jonas Sickingjo...@sicking.cc wrote:
On Mon, Jul 6, 2009 at 11:46 AM, Aaron Whyteawh...@google.com wrote:
When a page is loaded from an AppCache, even when online, external
resources
such
Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At this
point I don't really want to add new features yet because otherwise
we'll never get the browser vendors caught up to implementing the same
spec. :-)
On Mon, 6 Jul 2009, Charles Pritchard wrote:
Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At
this point I don't really want to add new features yet because
otherwise we'll never get the browser
Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At
this point I don't really want to add new features yet because
otherwise we'll
On Jul 6, 2009, at 6:08 PM, Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At
this
point I don't really want to add new features yet because otherwise
we'll never get the browser vendors caught up to
Actually, I believe the spec does address the question in the following
passage (this is in the manifest parsing algorithm):
If mode is explicit
Resolve the first item in tokens, relative to base URL; ignore the rest.
If this fails, then jump back to the step labeled start of line.
If
Could you elaborate on what your use cases are? Is it just the ability to
manually decode audio tracks?
I actually have thought about this. Having an ability to post-process,
mix, or generate audio content manually is useful for certain classes of
games and applications.
There's
On Fri, 26 Jun 2009, James Robinson wrote:
0) postMessage() looks as if it is intended to mimic
MessagePort.postMessage(), but the arguments and error conditions are
different. While it would be conceptually nice to treat a web socket in
the same way as a message port, it's not possible
On Wed, 10 Jun 2009, Julian Reschke wrote:
Ian Hickson wrote:
So far based on my experience with the Workers, Storage, Web Sockets,
and Server-sent Events sections, I'm not convinced that the advantage
of getting more review is real. Those sections in particular got more
review while
On Mon, 6 Jul 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
On Thu, 2 Jul 2009, Olli Pettay wrote:
[22:59] smaug I'm trying to understand the Each browsing context,
including
nested browsing context, has a distinct session history.
[23:00] smaug but in practice if go(-1) is
Audible mouse feedback is an OS thing, not an HTML thing.
I would rather have programmatic access to the MIDI synthesizer rather than
be able to simulate it with a beep.
How do you detect that the client mixer is too slow?
Why can't you just get the premixed jingles from the server?
Isn't the
64 matches
Mail list logo
