On Tue, 26 Jan 2010, Michael A. Puls II wrote:
Please see the note in the object element section. It has more
detailed info. The embed and applet elements have the old, less-detailed
note.
Yeah. It turns out that trying to make the paragraph that's in the
object section fit the embed and
Am 04.02.2010 01:00, schrieb Tim Hutt:
On 3 February 2010 23:16, Boris Zbarskybzbar...@mit.edu wrote:
On 2/3/10 6:12 PM, Tim Hutt wrote:
Ah yes that works nicely
Hmm maybe I spoke too soon. The interaction of the CSS size and the
canvas.width/height is confounding! It seems
I tried to solve the aliasing problem in Firefox and found out, that it
really isn't possible to get it right, if you set the width and height
in CSS:
If you leave the css-width/height as it is when resizing the canvas, it
will get blurred in Firefox. If you change it to 'auto' it won't resize
On Mon, 25 Jan 2010, Michal Zalewski wrote:
This has been proposed before. The concern is that many authors would
be likely to make mistakes in their selection of random tokens that
would lead to significant flaws in the deployment of the feature.
srcdoc= is less prone to errors.
Hi
Couple of questions about the details element, raised by Shelley Powers
in comments to an article I wrote on html5 doctor
http://html5doctor.com/summary-figcaption-element/
1) I read that details doesn't require any authorial scritping to work,
and that a details element should expand/
On Thu, 04 Feb 2010 12:26:10 +0100, Bruce Lawson bru...@opera.com wrote:
Couple of questions about the details element, raised by Shelley Powers
in comments to an article I wrote on html5 doctor
http://html5doctor.com/summary-figcaption-element/
1) I read that details doesn't require any
On Fri, 29 Jan 2010, Olli Pettay wrote:
On 1/29/10 3:32 AM, Ian Hickson wrote:
I've tried to spec this. There is a high risk of compatibility issues,
so I would very much welcome feedback from implementors who try to
implement this.
The main goal of the change here is to make it
On Thu, 24 Dec 2009, Kyle Scholz wrote:
A common application of WebStorage will be clientside caching. Since
there are limits on store size, developers will be implementing eviction
schemes, but this is currently difficult because the interface doesn't
expose store size or get/set times
On Thu, 4 Feb 2010, Bruce Lawson wrote:
1) I read that details doesn't require any authorial scritping to
work, and that a details element should expand/ contract for user agents
that have JS disabled. Is that correct?
Yes, assuming the browser supports it.
2) What should UAs do when
On Thu, 29 Oct 2009, Futomi Hatano wrote:
I found an odd example in the meter element section of the spec.
http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element
metermax: 100; current: 75/meter
According to steps for finding one or two
On Feb 4, 2010, at 9:21 PM, Ian Hickson wrote:
2) What should UAs do when printing? It seems to me that, when printing,
a details element should be open, regardless of the state of the
boolean open attribute. (because it's a markup attribute, there is
presumably now way for a print
On Thu, 04 Feb 2010 03:47:22 -0500, Ian Hickson i...@hixie.ch wrote:
On Tue, 26 Jan 2010, Michael A. Puls II wrote:
Please see the note in the object element section. It has more
detailed info. The embed and applet elements have the old, less-detailed
note.
Yeah. It turns out that trying to
On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote:
On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell lam...@continuation.org
wrote:
I think the most reasonable approach would be to say that the
getBoundingClientRect().width or height is rounded to the nearest pixel.
Boxes are displayed
On Thu, Feb 4, 2010 at 5:12 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 25 Jan 2010, Tab Atkins Jr. wrote:
Adam Barth rightfully points out that this only stops certain classes
of data exfiltration attacks, and so probably isn't worthwhile as a
solution to that matter. However, I think this
On Thu, Feb 4, 2010 at 6:51 AM, Philippe Wittenbergh e...@l-c-n.com wrote:
On Feb 4, 2010, at 9:21 PM, Ian Hickson wrote:
2) What should UAs do when printing? It seems to me that, when printing,
a details element should be open, regardless of the state of the
boolean open attribute. (because
Not escaping is so easily and quickly discovered that I really don't
think that's a problem.
The same argument could be made for not escaping , but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.
That would be great. I think Adam proposed we
On Fri, Feb 5, 2010 at 3:25 AM, Brian Campbell lam...@continuation.orgwrote:
On Feb 4, 2010, at 1:55 AM, Robert O'Callahan wrote:
On Thu, Feb 4, 2010 at 6:50 PM, Brian Campbell lam...@continuation.org
wrote:
I think the most reasonable approach would be to say that the
Hi all,
About half a year ago I came up with an idea to add a unique window id
as request header to each browser request. I published this initially on
my website
http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html
About a week ago, I have stumbled upon the WebApps Working
On 4 February 2010 20:49, Sebastian Hennebrueder use...@laliluna.de wrote:
What is the idea about?
I think Web Storage does what you want and is already implemented
(apparently even in IE). The description from the spec:
This specification introduces two related mechanisms, similar to HTTP
On Feb 3, 2010, at 15:03 , Kit Grose wrote:
I feel that the user shouldn't have the ability to enter into some sort of
pseudo-fullscreen. If the content needs to be displayed full-screen,
I don't believe that there is any such 'need' and that the user should own that
decision. I, for
Tim Hutt schrieb:
On 4 February 2010 20:49, Sebastian Hennebrueder use...@laliluna.de wrote:
What is the idea about?
I think Web Storage does what you want and is already implemented
(apparently even in IE). The description from the spec:
This specification introduces two related mechanisms,
Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but
case-insensitively (at least for Text, I didn't test URL). Chrome is
case-insensitive for everything.
Tough call. I guess we'll go with just converting everything to lowercase,
so that it's case-insensitive.
BTW I
On Thu, Feb 4, 2010 at 12:44 PM, Michal Zalewski lcam...@coredump.cx wrote:
The same argument could be made for not escaping , but I don't think
it's valid in practice - particularly for (hypothetically) constrained
input fields.
The use-cases for srcdoc are only where you expect HTML input.
On 05/02/2010, at 8:08 AM, David Singer wrote:
On Feb 3, 2010, at 15:03 , Kit Grose wrote:
I feel that the user shouldn't have the ability to enter into some sort of
pseudo-fullscreen. If the content needs to be displayed full-screen,
I don't believe that there is any such 'need' and that
On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 4 Feb 2010, Daniel Cheng wrote:
Webkit and Firefox are case-sensitive. IE only does TEXT and URL,
but case-insensitively (at least for Text, I didn't test URL). Chrome
is case-insensitive for everything.
On Thu, 4 Feb 2010, Daniel Cheng wrote:
On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 4 Feb 2010, Daniel Cheng wrote:
Webkit and Firefox are case-sensitive. IE only does TEXT and
URL, but case-insensitively (at least for Text, I didn't test
URL).
Hi,
According to [1], the video's width height attributes are DOMString, but
according to [2] width height must have values that are valid
non-negative integers.
Shouldn't they be long then?
Digging deeper, I found that video, iframe, embed and object all have
DOMString width height
Since I am currently in the process of fixing bugs in this area for Chrome,
there are 2 things I'm wondering about:
.) whether Text and URL should be part of the return value of types
(probably not, according to Ian's comment). However, since text/uri-list
may in fact not contain a valid URL, the
28 matches
Mail list logo
