On Wed, Jul 25, 2012 at 4:24 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
You can even use
getCueAsHTML() to simply hand the SVG to HTML for rendering.
FWIW, that is not going to work. You need to parse the SVG using
innerHTML or some such. getCueAsHTML() only gives a representation of
resending as plain text as the first time the links made it indecipherable,
On 25 July 2012 01:13, Steve Faulkner faulkner.st...@gmail.com wrote:
Upon reading the hit region section [1] of the spec again I noticed this:
If any of the following conditions are met, throw a NotSupportedError
On 20 July 2012 14:38, Steve Faulkner faulkner.st...@gmail.com wrote:
Hi Hixie,
I believe you have made some spurious claims, one of them being;
The WHATWG effort is focused on developing the
canonical description of HTML and related technologies
The claim that HTML the living standard is
Hello,
I've been looking for some standard approach to fixed header (no weird
positioning, wrappers divs, JS woodoo, etc. - I've written those and
there are couple hundreds more on the web) and I found this bug in webkit
https://bugs.webkit.org/show_bug.cgi?id=3239
discussing, whether
On 20.7.2012 14:38, Steve Faulkner wrote:
Hi Hixie,
I believe you have made some spurious claims, one of them being;
The WHATWG effort is focused on developing the
canonical description of HTML and related technologies
The claim that HTML the living standard is canonical
On Tue, Jul 24, 2012 at 10:58 PM, Jukka K. Korpela jkorp...@cs.tut.fi wrote:
This is an improvement, but I think Edward O'Connor's points still apply.
Indeed. The spec edit is a rather disappointing response.
I think it would be better to keep the alt attribute always required but
recommend
Le 7/24/2012 5:04 PM, Ian Hickson a écrit :
[only replied on the whatwg list; please if possible avoid cross-posting
as it tends to fracture threads when people only on one list and not the
other reply]
[I'll forward the mails to the SVG mailing list separately to make sure
people not
Le 25/07/2012 13:45, Bronislav Klučka a écrit :
On 20.7.2012 14:38, Steve Faulkner wrote:
Hi Hixie,
I believe you have made some spurious claims, one of them being;
The WHATWG effort is focused on developing the
canonical description of HTML and related technologies
The
Canonical means neither correct nor accurate, those words have no
meaning in this case, you cannot apply them on set of rules (you
first have to have set of rules, to claim, whether something is
accurate or correct within the boundaries of those rules), canonical
means, that those set of
Hi Silvia,
Le 7/25/2012 4:24 AM, Silvia Pfeiffer a écrit :
Expanding a bit on what Anne said...
On Tue, Jul 24, 2012 at 11:18 PM, Cyril Concolato
cyril.concol...@telecom-paristech.fr wrote:
Dear WhatWG,
During the ongoing SVG F2F meeting, the SVG WG discussed the use case of
displaying SVG
Hi Silvia,
Le 7/25/2012 3:42 PM, Silvia Pfeiffer a écrit :
On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonenhsivo...@iki.fi wrote:
On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
But you can use cue.text and parse it as a SVG fragment.
That would be RSS all
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to follow
the same path, the same implementation of tasks, but not all major
vendors are part of WHATWG (as far as I know), and if some choose to
follow W3C and some different WHATWG
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to follow
the same path, the same implementation of tasks, but not all major
vendors are part of WHATWG (as far as I know), and if some choose to
follow W3C and some different WHATWG
This Mozilla bug has more info:
https://bugzilla.mozilla.org/show_bug.cgi?id=674214
2012/7/25 Bronislav Klučka bronislav.klu...@bauglir.com
Hello,
I've been looking for some standard approach to fixed header (no weird
positioning, wrappers divs, JS woodoo, etc. - I've written those and there
On 25.7.2012 16:04, David Bruant wrote:
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to follow
the same path, the same implementation of tasks, but not all major
vendors are part of WHATWG (as far as I know), and if some choose to
Le 25/07/2012 16:36, Bronislav Klučka a écrit :
On 25.7.2012 16:04, David Bruant wrote:
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to
follow the same path, the same implementation of tasks, but not all
major vendors are part of
hi Bronislav
you wrote:
I was just looking at WHATWG wiki and there is nice sentence: In
general the WHATWG will ensure that the normative content of the
specifications (the requirements on authors and implementors) remains
the same so long as the W3C group doesn't demonstrate any serious lapses
On 25.7.2012 16:52, David Bruant wrote:
Le 25/07/2012 16:36, Bronislav Klučka a écrit :
On 25.7.2012 16:04, David Bruant wrote:
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to
follow the same path, the same implementation of
So the answer is it probably should apply, because of CSS3, but since
noone is implementing it it should not apply because it will be removed?
Is there anyone, who can make the judgement call?
B.
On 25.7.2012 16:34, Alfonso Martínez de Lizarrondo wrote:
This Mozilla bug has more info:
On 25.7.2012 16:55, Steve Faulkner wrote:
hi Bronislav
you wrote:
I was just looking at WHATWG wiki and there is nice sentence: In
general the WHATWG will ensure that the normative content of the
specifications (the requirements on authors and implementors) remains
the same so long as the W3C
Le 25 juil. 2012 à 10:04, David Bruant a écrit :
W3C forgot that.
Who did? I mean, the actual people.
Nobody forgot. The discussions are not about WHATWG vs W3C. This is nonsense.
There W3C is not a monolithic bloc either. Most of the browser engineers
working on whatwg lists, IRC channels,
To reiterate the statement I made in the original post on this thread:
If you have any questions, I encourage you to e-mail me privately or ask
on the IRC channel (#whatwg on Freenode); process-related discussion is
discouraged on this mailing list so that we can maintain a high technical
Edward O'Connor on Tue, 24 Jul 2012 10:37:20 -0700
We could address this problem by making changes along these lines:
1. Drop the meta name=generator alt= exception.
2. Mint a global boolean attribute that, when present, indicates that
the element and its descendants are outside of the
On 25 July 2012 18:12, Ian Hickson i...@hixie.ch wrote:
To reiterate the statement I made in the original post on this thread:
If you have any questions, I encourage you to e-mail me privately or ask
on the IRC channel (#whatwg on Freenode); process-related discussion is
discouraged on this
2012-07-25 15:05, Henri Sivonen wrote:
I think it would be better to keep the alt attribute always required but
recommend that conformance checkers have an option of switching off errors
related to this
The big question is whether that would be enough to solve the problem
of generators
On 7/25/12 7:14 AM, Bronislav Klučka wrote:
Should simple
tbody {height: 200px; overflow: scroll; }
work, and this feature is missing in browsers implementations?
Per CSS2.1 it should not work.
There's an out-of-date (older than CSS2.1) draft of CSS3 that says it
should, but doesn't actually
On Wed, 25 Jul 2012, Melvin Carvalho wrote:
Just so that it's possible to understand how to name the two new
branches correctly, can you confirm that the W3C branch is now called
HTML5 and the WHATWG branch is named 'HTML Living Standard'.
Is this the long term project name, or just a
On Jul 23, 2012, at 4:41 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 26 Jan 2012, Kornel LesiÅ~Dski wrote:
But even if single-mixed-login-field autocomplete was desired, then
perhaps a mixed type would work too:
input type=username email
How about merging autocompletetype with
On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak m...@apple.com wrote:
For some of these fields, autocomplete= as a hint to autocompletion seems
sufficient. However, I think some may logically be a distinct input type as
well.
This is also true for the inputmode attribute. In particular its
2012-07-25 20:40, Ian Hickson wrote:
On Wed, 25 Jul 2012, Melvin Carvalho wrote:
Just so that it's possible to understand how to name the two new
branches correctly, can you confirm that the W3C branch is now called
HTML5 and the WHATWG branch is named 'HTML Living Standard'.
Is this the long
On Wed, Jul 25, 2012 at 11:45 PM, Cyril Concolato
cyril.concol...@telecom-paristech.fr wrote:
Right now it is fully defined how data in a TextTrack (of the defined
kinds) is displayed on top of the video. As this is as yet unclear for
SVG resources,
I wouldn't say it's unclear, I'd say it
On Wed, Jul 25, 2012 at 11:51 PM, Cyril Concolato
cyril.concol...@telecom-paristech.fr wrote:
Hi Silvia,
Le 7/25/2012 3:42 PM, Silvia Pfeiffer a écrit :
On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonenhsivo...@iki.fi wrote:
On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
Having carefully studied the Mozilla Web Activities proposal, the Web
Intents draft, the register*Handler APIs, and to a lesser extent the
dispatch mechanisms in existing operating systems (desktop and mobile) and
the piles of advocacy on teh subject on the Web, I've tried to come up
with a
On Jul 21, 2012, at 1:20 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote:
I'm not opposed to the idea, but I'm failing to see the benefit.
The advantage clearly is that if you have a canvas that is copying
data out of the video, it includes the poster without having to write
custom
On Jul 25, 2012, at 12:36 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak m...@apple.com wrote:
For some of these fields, autocomplete= as a hint to autocompletion seems
sufficient. However, I think some may logically be a distinct input type
On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier caban...@gmail.com wrote:
I agree that it would be great to have filter effects in Canvas. It should
be fairly efficient if you have a GPU backend since the effects can all be
done with shaders so it should take up too much memory.
This workflow
On Wed, Jul 25, 2012 at 10:18 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier caban...@gmail.com wrote:
I agree that it would be great to have filter effects in Canvas. It should
be fairly efficient if you have a GPU backend since the effects can
37 matches
Mail list logo
