On Tue, Jul 24, 2012 at 2:41 AM, Ian Hickson wrote:
> Are there any common fields missing from the list above?
Government-issued ID numbers might be worth adding. In America,
social security numbers are sometimes used for this purpose, but are
treated as semi-secret, so you usually don't enter t
On Wed, Jul 25, 2012 at 10:18 PM, Robert O'Callahan wrote:
> On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier 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 i
On Tue, Jul 17, 2012 at 4:34 PM, Rik Cabanier 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 could even suppo
On Jul 25, 2012, at 12:36 PM, Anne van Kesteren wrote:
> On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak 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
On Jul 21, 2012, at 1:20 PM, Silvia Pfeiffer 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 code for it. The post
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 co
On Wed, Jul 25, 2012 at 11:51 PM, Cyril Concolato
wrote:
> Hi Silvia,
>
> Le 7/25/2012 3:42 PM, Silvia Pfeiffer a écrit :
>
>> On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonen wrote:
>>>
>>> On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
>>> wrote:
But you can use cue.text and parse
On Wed, Jul 25, 2012 at 11:45 PM, Cyril Concolato
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 needs to be specified ;) meaning
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 lon
On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak 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
Telephone
On Jul 23, 2012, at 4:41 PM, Ian Hickson 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:
>>
>>
>>
>> How about merging autocompletetype with autocomplete then?
>>
>>
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
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
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 generat
On 25 July 2012 18:12, Ian Hickson 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 mailing
Hi Steve,
You wrote:
> From my reading of the hitregion() [1] section of the spec it is
> unclear to me whether click events work on unbacked regions
>
> It is clear that mouse move events can be used, but will developers be
> able to detect and make use of click events on backed regions?
>
> My
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 alt="" exception.
> 2. Mint a global boolean attribute that, when present, indicates that
>the element and its descendants are outside of the page author's
>
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
sign
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,
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
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:
https
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 tasks
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
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 W
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
This Mozilla bug has more info:
https://bugzilla.mozilla.org/show_bug.cgi?id=674214
2012/7/25 Bronislav Klučka
> 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
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 draf
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 draf
Hi Silvia,
Le 7/25/2012 3:42 PM, Silvia Pfeiffer a écrit :
On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonen wrote:
On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
wrote:
But you can use cue.text and parse it as a SVG fragment.
That would be RSS all over again. :-(
To some extent. If we a
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
wrote:
Dear WhatWG,
During the ongoing SVG F2F meeting, the SVG WG discussed the use case of
displaying SVG graphics on top of a video, in a sync
On Wed, Jul 25, 2012 at 10:55 PM, Henri Sivonen wrote:
> On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
> wrote:
>> But you can use cue.text and parse it as a SVG fragment.
>
> That would be RSS all over again. :-(
To some extent. If we are very clear about what will be in the cues
and that i
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
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 cla
On Wed, Jul 25, 2012 at 11:24 AM, Silvia Pfeiffer
wrote:
> But you can use cue.text and parse it as a SVG fragment.
That would be RSS all over again. :-(
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
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 subscribed
On Tue, Jul 24, 2012 at 10:58 PM, Jukka K. Korpela 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 that conformance
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 app
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 overfl
On 20 July 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 appe
resending as plain text as the first time the links made it indecipherable,
On 25 July 2012 01:13, Steve Faulkner 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
> exception and abort th
On Wed, Jul 25, 2012 at 6:00 PM, Anne van Kesteren wrote:
> On Wed, Jul 25, 2012 at 4:24 AM, Silvia Pfeiffer
> 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.
On Wed, Jul 25, 2012 at 4:24 AM, Silvia Pfeiffer
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
a WebVTT tree which cann
42 matches
Mail list logo
