Christoph Päper wrote:
Ian Hickson (2009-02-13):
There are three of these attributes so far:
autocomplete = on/off
contenteditable = true/false
draggable = true/false
It would be nice, actually, from an author perspective at least, if
all of these worked for all applicable attributes:
Ian Hickson wrote:
...
Note that the Web addresses draft isn't specific to HTML5. It is intended
to apply to any user agent that interacts with Web content, not just Web
browsers and HTML. (That's why we took it out of HTML5.)
...
Be careful; depending on what you call Web content. For
On Mon, 23 Mar 2009 09:45:39 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Ian Hickson wrote:
...
Note that the Web addresses draft isn't specific to HTML5. It is
intended to apply to any user agent that interacts with Web content,
not just Web browsers and HTML. (That's why we took
Anne van Kesteren wrote:
Be careful; depending on what you call Web content. For instance, I
would consider the Atom feed content (RFC4287) as Web content, but
Atom really uses IRIs, and doesn't need workarounds for broken IRIs in
content (as far as I can tell).
Are you sure browser
On Mon, 23 Mar 2009 11:25:19 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Anne van Kesteren wrote:
Be careful; depending on what you call Web content. For instance, I
would consider the Atom feed content (RFC4287) as Web content, but
Atom really uses IRIs, and doesn't need workarounds
Anne van Kesteren wrote:
I wasn't talking of browser implementations of feeds, but feed
readers in general.
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate URL
parsing functions?
Yes, absolutely.
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Anne van Kesteren wrote:
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate
URL parsing functions?
Yes, absolutely.
Why?
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 11:31:01 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
Anne van Kesteren wrote:
Well yes, and a subset of those is browser based. Besides that, most
feed readers handle HTML. Do you think they should have two separate
URL parsing functions?
On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Because it's preferable to the alternative, which is, leaking out the
non-conformant URI/IRI handling into other places.
Apparently that is already happening in part anyway due to LEIRIs. Modulo
the URL
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 11:46:15 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
Because it's preferable to the alternative, which is, leaking out the
non-conformant URI/IRI handling into other places.
Apparently that is already happening in part anyway due to LEIRIs.
On Mon, 23 Mar 2009 11:58:59 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
Whitespace is a big issue - auto-highlighting will fail all over the
place.
Auto-higlighting and linking code already fails all over the place due to
e.g. punctation issues. A solution for whitespace
Anne van Kesteren wrote:
The issue is that it's *not* the same thing.
Well, no, not exactly. But they perform essentially the same task,
modulo a few characters. And since one is a superset of the other (as
long as URL encoding is UTF-8) I don't see a point in having both.
Well, then let's
Anne van Kesteren wrote:
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke
julian.resc...@gmx.de wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle
On Mon, 23 Mar 2009 12:50:46 +0100, Julian Reschke julian.resc...@gmx.de
wrote:
...and other characters that are not allowed in URIs and IRIs, such as
{ and } (which therefore can be used as delimiters).
And keeping them invalid but requiring user agents to handle those
characters as part
i understand that SVG is meant for advanced timing etc.
but it would be very useful to have a simple mechanism in html/
javascript for playing sounds together. conceptually, sounds would be
placed on a timeline at a certain time. the sounds on the timeline can
then be played back together
On Mon, 23 Mar 2009, Julian Reschke wrote:
You are essentially proposing to change existing specifications (such as
Atom). I just do not see the point.
The point is to ensure there is only one way to handle strings that are
purported to be IRIs but that are invalid. Right now, there are at
Ian Hickson wrote:
On Mon, 23 Mar 2009, Julian Reschke wrote:
You are essentially proposing to change existing specifications (such as
Atom). I just do not see the point.
The point is to ensure there is only one way to handle strings that are
purported to be IRIs but that are invalid. Right
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser implemenation is concerned, a call to this function
would be the same as the script
[cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the
editor of the draft at this point]
On Mon, 23 Mar 2009, Julian Reschke wrote:
For example, curl will not refuse to fetch the URL
http://example.com/% despite that URL being invalid.
Should it refuse to?
The
On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow jor...@google.com wrote:
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser
Ian Hickson wrote:
[cc'ed DanC since I don't think Dan is on the WHATWG list, and he's the
editor of the draft at this point]
On Mon, 23 Mar 2009, Julian Reschke wrote:
For example, curl will not refuse to fetch the URL
http://example.com/% despite that URL being invalid.
Should it refuse
On Tue, Mar 24, 2009 at 7:41 AM, Jeremy Orlow jor...@google.com wrote:
One thing that hasn't been considered yet is some sort of optional hint to
say I'm done in terms of accessing localStorage. Maybe call it
localStorage.checkpoint() or localStroage.commit()?
As far as the browser
On Mon, 23 Mar 2009, Julian Reschke wrote:
However, what seems to be more likely is that one tool refuses to fetch
the file (because the URI parser didn't like it), while in the other
case, the tool puts the invalid URL on to the wire
IMHO this is basically the definition of a standards
I really like the idea of some generic yield, though I wonder if there's
some reason it hasn't been added earlier. People have been using the
setTimeout(..., 0) trick for a while to get around slow script warnings (and
general unresponsiveness)...so surely something like this must have come up
On Tue, 24 Mar 2009, Robert O'Callahan wrote:
I think a better construct might be some sort of yield which
explicitly returns to a (nested) browser event loop and basically acts
as a script completion point. Even browsers that only use a single
thread can run the event loop there so that
On Tue, Mar 24, 2009 at 10:40 AM, Jeremy Orlow jor...@google.com wrote:
I really like the idea of some generic yield, though I wonder if there's
some reason it hasn't been added earlier. People have been using the
setTimeout(..., 0) trick for a while to get around slow script warnings (and
On Mar 23, 2009, at 2:25 PM, Ian Hickson wrote:
On Mon, 23 Mar 2009, Julian Reschke wrote:
However, what seems to be more likely is that one tool refuses to
fetch
the file (because the URI parser didn't like it), while in the other
case, the tool puts the invalid URL on to the wire
IMHO
On Mon, Mar 23, 2009 at 2:45 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 24 Mar 2009, Robert O'Callahan wrote:
I think a better construct might be some sort of yield which
explicitly returns to a (nested) browser event loop and basically acts
as a script completion point. Even browsers that
On Mon, 23 Mar 2009, Jonas Sicking wrote:
And that's not even touching on the stack space limitations that you're
quite likely to run in to when you have an API specifically for nesting.
I think any sane implementation of this would have to be non-recursive.
That's part of why I think it'd
On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 23 Mar 2009, Jonas Sicking wrote:
And that's not even touching on the stack space limitations that you're
quite likely to run in to when you have an API specifically for nesting.
I think any sane implementation of this
*Given that things have simmered down, it seems like it's time for a re-cap
of the options. I believe this includes all the options currently on the
table (in broad strokes anyhow). If I missed anything or grossly
mischaracterized any idea, feel free to correct me.*
0: Do nothing. As far as I
Dear WHATWG,
Recently section 4.10.4.3 of the HTML5 specification was changed to
recommend that C:\fakepath\ be prepended to the DOM value of file upload
input elements. For example, when uploading /home/alex/upload.txt,
JavaScript will see C:\fakepath\upload.txt. This is now implemented in IE8
On Mon, 23 Mar 2009, Alex Henrie wrote:
Recently section 4.10.4.3 of the HTML5 specification was changed to
recommend that C:\fakepath\ be prepended to the DOM value of file
upload input elements. For example, when uploading
/home/alex/upload.txt, JavaScript will see
On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote:
I agree. Unfortunately, sometimes we are unable to make choices that end
up with a nice language. :-(
Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4?
-Alex
Ian Hickson wrote:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
expect the path (and they expect a Windows path, no less).
I don't believe I've seen many bugs along these lines for Firefox...
On Tue, Mar 24, 2009 at 1:09 AM, Ian Hickson i...@hixie.ch wrote:
The original plan was to just have the filename. Unfortunately, it turns
out that if you do that, there are certain sites that break, because they
Chance of this happening is only for intranet site.
So if browser vendors want to
Ian Hickson wrote on 3/24/2009 12:09 AM:
On Mon, 23 Mar 2009, Alex Henrie wrote:
First, this change is dishonest. It tells JavaScript that the file is
stored somewhere that it is not. And why say anything, true or not,
about where the file is stored at all? All JavaScript needs to know is
37 matches
Mail list logo
