On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 11 Aug 2007, Michael A. Puls II wrote:
I like hashchange even if it's not perfectly descriptive.
However, fragmentidentifierchange although long, isn't much longer
than DOMAttributeModified
and is shorter than say,
Anne van Kesteren wrote:
On Wed, 04 Apr 2007 Christian Schmidt wrote:
There appears to be at least some demand for such a feature, and so
far there has been no negative responses. What is the next step?
Providing some compelling usecases.
This has been provided a while back. Should I
On Wed, 15 Aug 2007, Christian Schmidt wrote:
This has been provided a while back. Should I interpret the lack of
response as lack of interest in a feature like this?
No; your feedback has been noted and I'll be getting to it in due course
(though new features to Web Forms are pretty much
On Sat, 4 Nov 2006, Lachlan Hunt wrote:
Ian Hickson wrote:
On Fri, 3 Nov 2006, Anne van Kesteren wrote:
* It should probably mention 'img.src = foo' (that loading directly
starts). I thought that 'img.setAttribute(src, foo)' even did different
things in browsers (when the element is
On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote:
On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 11 Aug 2007, Michael A. Puls II wrote:
I like hashchange even if it's not perfectly descriptive.
However, fragmentidentifierchange although long, isn't much longer
than
Hi,
There is a possible issue serialising HTML fragments section [1].
The algorithm seems fine for use with things like innerHTML, but there
are other issues that should be considered when serialising to a file,
database, network stream or something.
Such serialisers should consider the
Hi
I want to sugges some new attributes related to security of the form for
Web Forms 2, XForms and HTML 5.
http://www.w3.org/TR/web-forms-2/
Example:
input type=password hash=sha256 name=mypass /
so the browser transmits only the corresponding hash of the
given value.
Also, as we need
Any serializer that needs an exotic character set should also have a way of
retrieving the character set. This character set need not be specified
within the fragment stored because it would probably be the same for many
fragments. The serializer should rather store it elsewhere without
Křištof Želechovski wrote:
Any serializer that needs an exotic character set should also have a way of
retrieving the character set. This character set need not be specified
within the fragment stored because it would probably be the same for many
fragments. The serializer should rather store
At 10:48 + 15/08/07, Ian Hickson wrote:
* I would also suggest to put If the src attribute is omitted,
there is no alternative image representation. after the last
statement on the alt attribute.
Done. (I think. I edited a bunch of stuff before reading your comment
so it
Hi,
anchorchange
I like anchorchange, I think it's the most descriptive of all the
proposed names. Otherwise, hashchange is good enough for me.
Can the event be preventDefaulted?
-
Also, could the default action of the event be prevented?
I think
Hi,
p xml:base=foo.pngimg src= alt=//p
Ok but... what's an image? Do we exclude PDFs and SVG? (Safari and
Opera
respectively support those.)
snip
As Simon asked on IRC, who are we helping by limiting what's allowed?
Displaying PDF is great for company web-apps (mine uses it
You can store additional information in the resource fork and the fragment
in the data fork. The server must be configured to accept such fragments;
the server configuration should specify how these fragments should be used
and interpreted. It need not involve modifying the fragment. The
On Wed, 15 Aug 2007 16:08:51 +0100, Julien TOUCHE
[EMAIL PROTECTED] wrote:
input type=password hash=sha256 name=mypass /
so the browser transmits only the corresponding hash of the
given value.
Unfortunately this will not secure browsing session, because once user is
14 matches
Mail list logo
