It would be very sweet if you could actually enforce an element's
aspect ratio using CSS, so you wouldn't have to rely on hacks in the
line of http://lab.veille.jp/aspectratio/ anymore.
This is especially useful when designing elastic interfaces that display videos.
Example: Right column at http:/
On Tue, May 4, 2010 at 8:21 PM, Boris Zbarsky wrote:
> On 5/4/10 10:56 PM, Dirk Pranke wrote:
>>
>> What I would like to offer is a way to control some amount of the
>> sign-in/sign-out
>> experience while improving the security, by at least giving an in-page
>> way to trigger sign-in / sign-out (
On Tue, 4 May 2010, Perry Smith wrote:
>
> I see in the html5 spec an 'onshow' event but no text describing when
> the 'show' event is triggered.
It's part of the context menu mechanism:
http://www.whatwg.org/specs/web-apps/current-work/complete.html#context-menus
> It would be wonderful if an
On 5/4/10 10:56 PM, Dirk Pranke wrote:
What I would like to offer is a way to control some amount of the
sign-in/sign-out
experience while improving the security, by at least giving an in-page
way to trigger sign-in / sign-out (the actual mechanism of collecting
the credentials and performing th
On Tue, May 4, 2010 at 7:40 PM, Robert O'Callahan wrote:
> On Wed, May 5, 2010 at 1:27 PM, Dirk Pranke wrote:
>>
>> The principal difference or change is that as far as I know, Mozilla's
>> account manager offers only an out-of-page experience for managing
>> your logged-in status.
>
> I don't th
On Wed, May 5, 2010 at 1:27 PM, Dirk Pranke wrote:
> The principal difference or change is that as far as I know, Mozilla's
> account manager offers only an out-of-page experience for managing
> your logged-in status.
I don't think this is true. Sites can report user login status even if the
us
I see in the html5 spec an 'onshow' event but no text describing when the
'show' event is triggered.
I've poked at FF 3.5 and Opera and can not get it to fire. But I may be
completely confused on when it should fire.
It would be wonderful if an element had an event that would fire when that
p
On Tue, May 4, 2010 at 2:02 PM, Jonas Sicking wrote:
> On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke wrote:
>> On Tue, May 4, 2010 at 12:08 AM, Eitan Adler
>> wrote:
>>> Use cases:
>>> 1) A screen reader that sees a form with a type=username and a
>>> password field. The screen reader could just
On Tue, 4 May 2010, Julian Reschke wrote:
> On 26.04.2010 22:17, Roger Hågensen wrote:
> > ...
> > Oh, and could someone on the HTML5 list poke some of the guys over there
> > and
> > see if a ping attribute for the body tag in a similar vein could be
> > considered?
> > ...
>
> If by "HTML5 list"
On Wed, May 5, 2010 at 2:31 AM, Julian Reschke wrote:
> Short question: is it intentional that the partial GETs do not use an
> If-Match: request header?
>
No. I suppose we should, but honestly it's never come up.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
On Tue, May 4, 2010 at 1:53 PM, Dirk Pranke wrote:
> On Tue, May 4, 2010 at 12:08 AM, Eitan Adler wrote:
>> Use cases:
>> 1) A screen reader that sees a form with a type=username and a
>> password field. The screen reader could just ask "Log in to this site?
>> [y/n]?". No further context would b
On Tue, May 4, 2010 at 12:08 AM, Eitan Adler wrote:
> Use cases:
> 1) A screen reader that sees a form with a type=username and a
> password field. The screen reader could just ask "Log in to this site?
> [y/n]?". No further context would be needed.
> 2) UAs can more easily discover login forms an
> I don't think type=username is good solution, but I agree that autofill needs
> help. Sites often use e-mail address as login. There would be conflict
> between type=email and type=username.
I could imagine one two solutions here. 1) Change type="username" to
role="username" which makes more s
The was added by Ian Hickson in response to some of the work in the
W3C DAP working group. The original intent was to make sure the user are
actively grant permission to a particular device camera or microphone instead
of just click okay since some malicious site can just capture and post it on
On 04.05.2010 16:16, Julian Reschke wrote:
Rob,
related question: do you do the partial GET only for getting access to
metadata, or are you also using it for seeking in the video? (As opposed
to downloading it once into the media cache, and then use that content
throughout?)
Best regards, Julia
On 17.04.2010 09:36, Robert O'Callahan wrote:
This is an implementation issue rather than a spec issue. It's basically
just because of the way the Firefox network cache works. When we play an
Ogg video we generally don't download the data in a single continuous
HTTP GET; if the server supports by
On 26.04.2010 22:17, Roger Hågensen wrote:
...
Oh, and could someone on the HTML5 list poke some of the guys over there
and
see if a ping attribute for the body tag in a similar vein could be
considered?
...
If by "HTML5 list" you happen to mean the mailing list of the W3C HTML
WG...: the WG d
On 4 May 2010, at 09:07, timeless wrote:
> On Tue, May 4, 2010 at 10:08 AM, Eitan Adler wrote:
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails.
>
> Why would a site which doesn't cooperate with today's
establish a WebSocket connection:
[[
15. If the client has any cookies that would be relevant to a resource
accessed over HTTP, if secure is false, or HTTPS, if it is true, on host
host, port port, with resource name as the path (and possibly query
parameters), then add to fields any HTTP he
On 4/05/2010, at 9:07 AM, timeless wrote:
> On Tue, May 4, 2010 at 10:08 AM, Eitan Adler wrote:
>> 3) Currently autofill for usernames looks for something like
>> id="username" or name="username". However on certain websites this
>> fails.
>
> Why would a site which doesn't cooperate with today
On Tue, May 4, 2010 at 10:08 AM, Eitan Adler wrote:
> 3) Currently autofill for usernames looks for something like
> id="username" or name="username". However on certain websites this
> fails.
Why would a site which doesn't cooperate with today's autofill
features choose to cooperate with your pr
On Mon, 03 May 2010 23:59:19 +0200, Mark Frohnmayer
wrote:
Hey all,
In continuation of the effort to make browsers a home for real-time
peer to peer applications and games without a plugin, I've done a bit
of digging on the spec. Currently the spec contains section 4.11.6.2
(Peer-to-peer co
Use cases:
1) A screen reader that sees a form with a type=username and a
password field. The screen reader could just ask "Log in to this site?
[y/n]?". No further context would be needed.
2) UAs can more easily discover login forms and offer things such as
Firefox's Account Manager [1] or a "reme
23 matches
Mail list logo
