Re: [whatwg] behavior

[Michael A. Puls II]

On Mon, 14 Sep 2009 21:13:46 -0400, Boris Zbarsky  wrote:


Michael A. Puls II wrote:
I'm trying to remember. Did you also say that FF makes some use of  
display: none for fallback content


It does not, but it does make use of lack of CSS boxes...

and that if FF was fixed so display:none didn't affect plug-in  
instantiation, both plug-ins in the following would load at the same  
time?

 




If the plugin instantiation were done entirely via the DOM, then yes,  
unless something prevented that from happening.



Also, is it considered a bug just for , or  too?


I'd think both.


Thanks

--
Michael

Re: [whatwg] cloneNode and HTML elements

[Ian Hickson]

On Thu, 10 Sep 2009, Robert O'Callahan wrote:
>
> If you call cloneNode on a media element, the state of the resulting 
> media element seems unspecified. Should it be playing the same media 
> resource at the same current time as the original?
> 
> Similar questions arise when you clone form elements; is the state 
> that's not visible in the DOM cloned?

Cloning a DOM node is equivalent to serialising it and reparsing it. 
Nothing but the element's tag name, prefix, namespace, and attributes is 
cloned (plus the children, if the right argument is provided).

The only exception to this is the 

Re: [whatwg] U+FEFF (BOM) stripping in UTF-16BE and UTF-16LE

[Ian Hickson]

On Wed, 9 Sep 2009, Øistein E. Andersen wrote:
>
> § 9.2.2.2 "Preprocessing the input stream" requires that a leading 
> U+FEFF (byte order mark) be stripped irrespective of encoding, contra 
> Unicode, which says that a leading U+FEFF is part of the document when 
> the byte order is already established by other means.  This is probably 
> harmless and potentially useful to deal with bislabelled documents, but 
> it might be worth adding an explanatory note.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Surrogate pairs and character references

[Ian Hickson]

On Tue, 8 Sep 2009, Øistein E. Andersen wrote:
>
> According to the spec, character references may cause surrogate characters
> (0xD800 to 0xDFFF) to be inserted into the DOM.  Assuming that the DOM is an
> UTF-16 environment, �� and 𐀀 will both result in
> \xD800\xDC00 or U+1,.  This should probably be pointed out explicitly
> since extra processing has to be done to achieve the same result in a parser
> that is not built atop UTF-16.

Actually it's the other way around. Extra work has to be done in UTF-16 
environments to make sure that Unicode characters in the surrogate 
character range don't get processed as surrogate characters. (That is, 
regardless of the environment, �� and 𐀀 are not the 
same -- the first has two invalid characters U+D800 and U+DC00, the second 
has one character U+1.)

I'm not really sure how to make that clearer in the spec. I suppose we 
could just change the spec and say that surrogate characters (whether 
literal characters, e.g. in UTF-8, or from character references) all get 
converted to U+FFFD?.


> Furthermore, it is not entirely clear whether a mixed form like \xD800�
> encoded in UTF-16BE should give \xD800\xDC00 or \xFFFD\xDC00.

It should give U+FFFD U+DC00. It's not clear to me why that is not clear. :-)
Could you walk me through the spec interpreting it in such a way that you 
get any other result?


> Not all browsers convert unpaired surrogates in UTF-16 to U+FFFD, so the 
> mixed form may be interpreted as U+1,.

The spec says "Bytes or sequences of bytes in the original byte stream 
that could not be converted to Unicode characters must be converted to 
U+FFFD REPLACEMENT CHARACTER code points".

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Marius Gundersen]

Boris, thats because I realized I never actually tested how it worked, and
it would have been a useless function. But if it can sovle the anti-alias
problem, then I re-suggest it.

Robert, can you explain what you mean by your comment? I'm not too familiar
with postscript.

Marius Gundersen

On Mon, Sep 14, 2009 at 11:37 PM, Boris Zbarsky  wrote:

> Marius Gundersen wrote:
>
>> The composite paths that you indicated sounds cool, but sounds like
>> something I asked about previously, namely having an explicit method for
>> redrawing the canvas when the user is done.
>>
>
> I should note that you never responded to the comments Robert and I made in
> that thread
>
> -Boris
>
>

Re: [whatwg] Ambiguous ampersand

[Ian Hickson]

On Tue, 8 Sep 2009, Øistein E. Andersen wrote:
>
> According to § 9.1.4 Character references, "An ambiguous ampersand is a 
> U+0026 AMPERSAND (&) character that is followed by some text other than 
> a space character, a U+003C LESS-THAN SIGN character ('<'), or another 
> U+0026 AMPERSAND (&) character", text being "allowed inside elements, 
> attributes, and comments" (§ 9.1.3 Text). (Should that be "attribute 
> values"? Either is probably acceptable.)
> 
> This text does not seem to define the ampersand in  as 
> ambiguous, but it still causes a parse error. , 
>  and  are all conforming, so the 
> most consistent solution would probably be to remove the parse error by 
> setting the "additional allowed character" to '>' when encountering an 
> ampersand in the "Attribute value (unquoted)" state.

Fixed, thanks.


> Also, making the sequence "&<" conforming in (quoted) attribute values, 
> where the '<' occurs as text, seems inconsistent.

If we made &< non-conforming everywhere, then to detect this case would be 
ridiculously complicated in  elements:

test &< test & & &

Which are compliant and which are not?

Making &< conforming everywhere that the < is conforming text is more 
consistent than making &< only conforming in RCDATA text.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Editorial: Colloquial contractions

[Ian Hickson]

On Tue, 8 Sep 2009, Øistein E. Andersen wrote:
>
> The spec currently contains a few occurrences of colloquial contractions 
> like "can't", "won't" and "there's", which should be changed to 
> "cannot", "will not", "there is" etc. for consistency.

I haven't changed this, because it doesn't seem especially important, 
frankly. If there are specific cases where you think the current text 
reads poorly due to the use of contractions, please let me know.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Editorial: "Character reference data" tokeniser state name

[Ian Hickson]

On Tue, 8 Sep 2009, Øistein E. Andersen wrote:
>
> The "Character reference data" tokeniser state should probably be 
> renamed to "Character reference in data".  Adding "in" would arguably 
> make the name more accurately descriptive and furthermore consistent 
> with the "Character reference in attribute" state.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] nested hashchange events

[Ian Hickson]

On Wed, 9 Sep 2009, Olli Pettay wrote:
> On 6/25/09 11:44 AM, Olli Pettay wrote:
> > 
> > currently "6.11.9 History traversal" doesn't seem to handle nested 
> > hashchange events too well. If there is a fragment id change to A, 
> > hashchange is dispatched, then if the listener changes the fragment to 
> > B, there is a new hashchange and after that the page will scroll to B. 
> > But the fragment change to A hasn't finished yet, so the page will 
> > then scroll to A.
> > 
> > Either one should be able prevent the default action of hashchange 
> > (scrolling), or hashchange should be dispatched after scrolling. I 
> > think I'd prefer the latter. That would keep things simple and prevent 
> > all sort of strange cases like the example above if preventDefault 
> > isn't called.
> 
> So the synchronous hashchange causes this problem again; per the draft 
> the event is dispatched first and the scrolling happens after that.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] behavior

[Boris Zbarsky]

Michael A. Puls II wrote:
I'm trying to remember. Did you also say that FF makes some use of 
display: none for fallback content


It does not, but it does make use of lack of CSS boxes...

and that if FF was fixed so 
display:none didn't affect plug-in instantiation, both plug-ins in the 
following would load at the same time?







If the plugin instantiation were done entirely via the DOM, then yes, 
unless something prevented that from happening.



Also, is it considered a bug just for , or  too?


I'd think both.

-Boris

Re: [whatwg] Web Address and its escape

[Ian Hickson]

On Wed, 9 Sep 2009, NARUSE, Yui wrote:
> 
> First is about 4.10.16.4 URL-encoded form data.
> http://www.whatwg.org/specs/web-apps/current-work/#application/x-www-form-urlencoded-encoding-algorithm
> 
> In this algorithm at 6.2.1,
> "SP, *, -, ., 0 .. 9, A .. Z, _, a .. z" is not escaped.
> But many other specs which use application/x-www-form-urlencoded refers
> URI's unreserved. And it in RFC3986 is
>unreserved= ALPHA / DIGIT / "-" / "." / "_" / "~"
> Why ~ is escaped and * is not escaped?

No idea, but that's what browsers do.


> Second is also URL-encoded form data 6.2.1.
> This says:
> > the string a U+0025 PERCENT SIGN character (%) followed by two
> > characters in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE
> > (9) and U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z
> But hexadecimal is 0-9 A-F,
> so to "U+0046 LATIN CAPITAL LETTER F" seems right.

Oops, thanks. Fixed.


> Third is about Web addresses in HTML 5. (this spec is also this ML?)
> http://www.w3.org/html/wg/href/draft
> 
> In 2 Parsing Web addresses at 2. Percent-encode all non-URI characters in w,
> percent-encoding many characters includeing U+0025 percent sign.
> But by this spec, if a Web address w is already escaped URL,
> this process double-escape those characters.
> 
> For example, w is http://www.example.org/D%C3%BCrst,
> on step 2, w comes to be http://www.example.org/D%25C3%25BCrst.
> And on step 5, w is broken.

Please send this feedback to Larry Masinter .

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] behavior

[Michael A. Puls II]

On Mon, 14 Sep 2009 02:10:22 -0400, Ian Hickson  wrote:


On Thu, 3 Sep 2009, Michael A. Puls II wrote:

On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson  wrote:
> On Thu, 27 Aug 2009, Michael A. Puls II wrote:
> >
> > Here's an example that uses a more modern plug-in that shows what
> > browsers do.
> >
> > window.onload = function() {
> > var obj = document.createElement("object");
> > obj.type = "application/x-shockwave-flash";
> > obj.data = "http://adobe.com/shockwave/welcome/flash.swf";;
> > obj.width = "320";
> > obj.height = "240";
> > //document.body.appendChild(obj);
> > //obj.style.display = "none";
> > setTimeout(function() {
> > alert(obj.SetVariable);
> > }, 1000);
> > };
> >
> > In other words, for a plug-in to be initialized (and scriptable if  
it's

> > capable):
> >
> > 1. Its element must be attached to the document.
>
> I'm told this is considered a bug.

O.K., so once that's fixed in browsers, if I do:

var obj = document.createElement("object");
obj.type = "application/x-shockwave-flash";
obj.data = "file.swf"
obj.appendParam("quality", "low");

, will that load as soon as I set @type (according to HTML5) and result  
in
@data and the param not being honored because the plug-in already  
initialized?

Hm, good point.
Fixed.


Thanks

--
Michael

Re: [whatwg] behavior

[Michael A. Puls II]

On Mon, 14 Sep 2009 08:42:10 -0400, Boris Zbarsky  wrote:

Ah.  I must have been unclear.  We (Gecko) consider it a bug that a  
display:none  in a document doesn't instantiate the plug-in.


I'm trying to remember. Did you also say that FF makes some use of  
display: none for fallback content and that if FF was fixed so  
display:none didn't affect plug-in instantiation, both plug-ins in the  
following would load at the same time?






(as opposed to the nested one only firing up after the parent's fallback  
mode is triggered)


Also, is it considered a bug just for , or  too?

Thanks

--
Michael

Re: [whatwg] Inter-window communication beyond window.postMessage()

[Jeremy Orlow]

On Mon, Sep 14, 2009 at 3:06 PM, Ian Hickson  wrote:

> On Mon, 14 Sep 2009, Sidney San Martín wrote:
> >
> > The cross-document messaging API solves a lot of problems and is overall
> > an Awesome Thing, but requiring a reference to the target window is
> > hugely limiting. When a a window wants to talk to another window and
> > didn't create it, there are basically three options:
> >
> > 1. window.open with a window name argument, which is a hack because the
> target
> > window has to reload.
> > 2. Comet, which is a horrible hack because a trip to the server is
> required.
> > 3. LocalStorage and storage events, which wasn't designed for anything
> > remotely like this.
>
> 4. Open a SharedWorker and send a MessagePort to the other window.
>
>
> > Unless there's a reason to prevent free communication between windows,
> > there must be a better solution. I can think of a couple of
> > possibilities. The most obvious one would be an API similar to
> > postMessage that allows broadcasting of messages to all windows, windows
> > by name, and windows by domain. Another one (which I haven't developed
> > very far) would be to stick with window.postMessage but provide an API
> > to ask for windows. So, I could say, "Can I please have a reference to
> > the window named 'x'", or, "...to windows at 'example.com'", or, "...to
> > any window who'll give me one". Each window would obviously have to opt
> > into this.
> >
> > What do you all think?
>
> How do you know there's a Window to get a hold of if you don't have a hold
> of it already?
>
> The main reason for Window.postMessage() is communication with iframes
> (gadgets), not with other top-level browsing contexts. What's the use case
> for the latter?
>

I assume the use case for this is similar with the use case for storage
events which essentially is a broadcast mechanism that's specific to just
DOM storage.  So if, for example, you wanted to tell your other windows
"hey!  I changed the cookie" then you could do it with a message.  This
seems much better than, for example polling.

This could also be useful if you wanted to say "hey, I just navigated to
gmail.com.  Do any of you already have the inbox and chat contacts loaded
up?".  I suppose there's not much advantage to doing it like this over
shared workers since either way you're passing messages, but I also don't
see any major downsides to allowing broadcasts.

Re: [whatwg] Fakepath revisited

[Michael A. Puls II]

On Mon, 14 Sep 2009 10:04:30 -0400, Benjamin Smedberg  
 wrote:


Two bugs reports which we *know* we triggered when we removed the full  
path:

https://bugzilla.mozilla.org/show_bug.cgi?id=436116 (BlackBoard)
https://bugzilla.mozilla.org/show_bug.cgi?id=417715 (eBay)
In both these cases changes in the website fixed the problem.


Here are two that used to choke when they didn't get the full path. The  
first page is gone now. The second no longer seems to have the problem,  
but you can check the source to see some of the checks they make on the  
value to make sure.





--
Michael

Re: [whatwg] Inter-window communication beyond window.postMessage()

[Ian Hickson]

On Mon, 14 Sep 2009, Sidney San Martín wrote:
>
> The cross-document messaging API solves a lot of problems and is overall 
> an Awesome Thing, but requiring a reference to the target window is 
> hugely limiting. When a a window wants to talk to another window and 
> didn't create it, there are basically three options:
> 
> 1. window.open with a window name argument, which is a hack because the target
> window has to reload.
> 2. Comet, which is a horrible hack because a trip to the server is required.
> 3. LocalStorage and storage events, which wasn't designed for anything
> remotely like this.

4. Open a SharedWorker and send a MessagePort to the other window.


> Unless there's a reason to prevent free communication between windows, 
> there must be a better solution. I can think of a couple of 
> possibilities. The most obvious one would be an API similar to 
> postMessage that allows broadcasting of messages to all windows, windows 
> by name, and windows by domain. Another one (which I haven't developed 
> very far) would be to stick with window.postMessage but provide an API 
> to ask for windows. So, I could say, "Can I please have a reference to 
> the window named 'x'", or, "...to windows at 'example.com'", or, "...to 
> any window who'll give me one". Each window would obviously have to opt 
> into this.
> 
> What do you all think?

How do you know there's a Window to get a hold of if you don't have a hold 
of it already?

The main reason for Window.postMessage() is communication with iframes 
(gadgets), not with other top-level browsing contexts. What's the use case 
for the latter?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Fakepath revisited

[Aryeh Gregor]

On Mon, Sep 14, 2009 at 3:17 PM, Alex Henrie  wrote:
> Then for however long we use HTML, we will always remember that we
> have to work around fakepath because someone decided that
> compatibility with a handful of badly designed pages in 2009 was more
> important than having good design in 2090.

Yes.  It's a pain, but that's life.  Bad design decisions by
implementors early in the web's life -- inventing new features without
adequate planning and care to get a quick leg up on the competition --
have condemned it to be a mess forever.

Unreasonable legacy baggage is hardly unique to the web, of course.
We're currently communicating in a format that only allows 7-bit
transmission over the wire and has no concept of authentication.  One
of the biggest contributing factors to the ubiquity of malware today
is arguably the fact that the desktop system that won out happened to
have been originally designed for use on non-networked single-user
machines instead of networked multi-user machines.  And so on.

In an ideal world, we'd throw out HTML and replace it with something
sane.  We'd also throw out e-mail and replace it with something sane,
and throw out all legacy Windows APIs and replace them with something
better suited to today's world.  And so on.  Unfortunately, we do not
live in an ideal world.  Anyone who tries throwing out those things
will just be ignored, because . . . their brilliant new product
doesn't work with everything that already exists.  Instead we have to
hack on ugly nonsense so that the existing stuff continues to work,
however stupid or wrong it may be in retrospect -- like Vista's
elaborate efforts to trick legacy programs into thinking they're
running as root and can write to C:\Program Files\.  Or like base64
and SPF in e-mail.  Or like C:\fakepath in HTML5.

It would be nice if we didn't have to do this kind of thing.  But we do.

Re: [whatwg] Fakepath revisited

[Alex Henrie]

On Mon, Sep 7, 2009 at 12:56 PM, Aryeh Gregor wrote:
> On Mon, Sep 7, 2009 at 2:41 PM, Alex Henrie  wrote:
>> CSS2 demanded incompatibility with IE6 and IE7's previous
>> implementations.  IE8 resolved these problems and IE8 users haven't
>> taken to the streets of Redmond with pitchforks yet.
>
> IE6 and 7 weren't even compatible with CSS1 in many ways.  On the
> other hand, all other browsers overwhelmingly were.  It would have
> been impossible to do anything that didn't either break IE, or break
> everyone else, *dramatically* (as in "everyone has to rewrite all
> their pages" dramatically).  Since the behavior of everyone else was
> already specced, and IE's wasn't, and IE was the one that implemented
> the spec incorrectly to start with, the decision there was to stick
> with the already-specced stuff, and IE changed to accommodate it.
>
> I don't know why you think there wasn't massive backlash against
> Microsoft for their incompatible changes, either.  IE7 adoption was
> very slow, and one reason I've often seen given is lack of
> compatibility with intranet sites.  You might want to read this post
> by Chris Wilson:
>
> http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html

That's a really interesting post. As you know, after that was written
the IE team came to a compromise where IE would be standard by default
but provide a compatibility view to work with broken pages. I'm not
saying that every browser should implement a compatibility view, but
IE does seem to be the browser that's affected the most by this and
fakepath would fit very well with its compatibility view's goals.

On Mon, Sep 14, 2009 at 5:39 AM, Eduard Pascual  wrote:
> Considering that
> "pre-HTML5" browsers (like IE 6 and 7 or FF2) are going to stay there
> for a while, approaches like substr(12) or any other means of just
> trimming "C:\fakepath\" just won't work. Last indexof("\\") would
> break on any browser that doesn't include path at all (that's what
> fakepath is addressing, after all)

Actually, lastIndexOf can work quite well, as long as there are no
backslashes in the file name. Both
"upload.txt".substr("upload.txt".lastIndexOf("\\")+1) and
"C:\\fakepath\\upload.txt".substr("C:\\fakepath\\upload.txt".lastIndexOf("\\")+1)
return "upload.txt" because lastIndexOf returns -1 if nothing was
found. The problem appears to be web pages adding additional "checks"
that don't always hold up.

On Sun, Sep 13, 2009 at 8:01 PM, Robert O'Callahan  wrote:
> On Mon, Sep 14, 2009 at 1:12 PM, Ian Hickson  wrote:
>>
>> Here are some bug reports that I believe are caused by this issue:
>>
>>
>> http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routers&message.id=135649
>>
>> http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking
>>
>> http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978&p=2822806&postcount=3269
>>
>> Based on this my guess is just that people haven't filed this bug because
>> they haven't thought of it as a browser bug (notice how nobody in those
>> threads even mentions the browser).
>
> You may be right, although the first thread mentions browsers. I don't know
> if that's enough to explain why I can only find two Mozilla bugs related to
> this.
> https://bugzilla.mozilla.org/show_bug.cgi?id=446167
> https://bugzilla.mozilla.org/show_bug.cgi?id=505348

Thanks for the data. So, the list of known affected devices is:

Linksys WRT110
Netgear WGR614v9
D-Link DSL-2640B

On Sun, Sep 13, 2009 at 3:50 PM, Ian Hickson  wrote:
> There are basically only two arguments:
>
> Aesthetics: Having the fake path is ugly and poor language design.
>
>  Compatibility: Having it increases compatibility with deployed content.
>
> In HTML5's development, compatibility is a stronger argument than
> aesthetics. Therefore the path stays.

Then for however long we use HTML, we will always remember that we
have to work around fakepath because someone decided that
compatibility with a handful of badly designed pages in 2009 was more
important than having good design in 2090.

> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Indeed.

-Alex

Re: [whatwg] Inter-window communication beyond window.postMessage()

[Drew Wilson]

Agreed - I've always felt like having to have a reference to a window would
be an obstacle.
I feel obliged to point out that cross-domain SharedWorkers might be another
option for two completely unrelated windows to interact, although the
suggestions I've heard for APIs for x-domain access seem to center around
CORS, which may or may not be sufficient for this type of case.
-atw

On Mon, Sep 14, 2009 at 7:36 AM, Sidney San Martín  wrote:

> The cross-document messaging API solves a lot of problems and is overall an
> Awesome Thing, but requiring a reference to the target window is hugely
> limiting. When a a window wants to talk to another window and didn't create
> it, there are basically three options:
>
> 1. window.open with a window name argument, which is a hack because the
> target window has to reload.
> 2. Comet, which is a horrible hack because a trip to the server is
> required.
> 3. LocalStorage and storage events, which wasn't designed for anything
> remotely like this.
>
> Unless there's a reason to prevent free communication between windows,
> there must be a better solution. I can think of a couple of possibilities.
> The most obvious one would be an API similar to postMessage that allows
> broadcasting of messages to all windows, windows by name, and windows by
> domain. Another one (which I haven't developed very far) would be to stick
> with window.postMessage but provide an API to ask for windows. So, I could
> say, "Can I please have a reference to the window named 'x'", or, "...to
> windows at 'example.com'", or, "...to any window who'll give me one". Each
> window would obviously have to opt into this.
>
> What do you all think?
>

Re: [whatwg] size content attribute on

[Anne van Kesteren]

On Mon, 14 Sep 2009 17:26:24 +0200, Aryeh Gregor  
 wrote:

On Mon, Sep 14, 2009 at 7:29 AM, Ian Hickson  wrote:

Use the min, max, and step attributes to specify the range, then the UA
can automatically determine the size.


I guess.  I'm sure there are some cases where you'd have an idea of
likely values but don't want to actually prohibit values outside the
range, but I can't think of a very good example offhand.


step="any"


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] size content attribute on

[Aryeh Gregor]

On Mon, Sep 14, 2009 at 7:29 AM, Ian Hickson  wrote:
> Use the min, max, and step attributes to specify the range, then the UA
> can automatically determine the size.

I guess.  I'm sure there are some cases where you'd have an idea of
likely values but don't want to actually prohibit values outside the
range, but I can't think of a very good example offhand.

> That's an interesting idea. In practice, though, I think people will have
> much more elaborate fallback than just text -- using script -- so that the
> size="" attribute isn't that important for this purpose. When no script is
> available, the default size is fine, IMHO. I'd rather make the conformance
> criteria be forward-looking here.

It's unlikely anyone will have script fallback for number, and script
fallback for things like time isn't a given.  But I see your point
here.  For now, authors can use CSS to control the width if they like.

[whatwg] Inter-window communication beyond window.postMessage()

[Sidney San Martín]

The cross-document messaging API solves a lot of problems and is  
overall an Awesome Thing, but requiring a reference to the target  
window is hugely limiting. When a a window wants to talk to another  
window and didn't create it, there are basically three options:


1. window.open with a window name argument, which is a hack because  
the target window has to reload.
2. Comet, which is a horrible hack because a trip to the server is  
required.
3. LocalStorage and storage events, which wasn't designed for anything  
remotely like this.


Unless there's a reason to prevent free communication between windows,  
there must be a better solution. I can think of a couple of  
possibilities. The most obvious one would be an API similar to  
postMessage that allows broadcasting of messages to all windows,  
windows by name, and windows by domain. Another one (which I haven't  
developed very far) would be to stick with window.postMessage but  
provide an API to ask for windows. So, I could say, "Can I please have  
a reference to the window named 'x'", or, "...to windows at  
'example.com'", or, "...to any window who'll give me one". Each window  
would obviously have to opt into this.


What do you all think?

Re: [whatwg] Fakepath revisited

[Benjamin Smedberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 9/13/09 5:58 PM, Maciej Stachowiak wrote:

>> In this case, I'd like to see a list of specific routers, sites etc
>> that triggered the implementation of fakepath in Opera and IE. I'd
>> like to crosscheck with our Bugzilla to understand why we haven't felt
>> the need to do this in Firefox.
> 
> For Safari/WebKit, we haven't seen specific bug reports that are clearly
> identifiable as this issue. But I'm willing to believe it is real. We

Two bugs reports which we *know* we triggered when we removed the full path:

https://bugzilla.mozilla.org/show_bug.cgi?id=436116 (BlackBoard)
https://bugzilla.mozilla.org/show_bug.cgi?id=417715 (eBay)

In both these cases changes in the website fixed the problem.

- --BDS
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKrk1uSSwGp5sTYNkRAo7VAKCE9m6VsOun/ul9Evj99ZaSq13XbwCeMIt/
jGLXrMHxEtoYfjqHruPqPwo=
=j5fi
-END PGP SIGNATURE-

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Boris Zbarsky]

Marius Gundersen wrote:
The composite paths that you indicated sounds cool, but sounds like 
something I asked about previously, namely having an explicit method for 
redrawing the canvas when the user is done.


I should note that you never responded to the comments Robert and I made 
in that thread


-Boris

Re: [whatwg] behavior

[Boris Zbarsky]

Ian Hickson wrote:

On Sun, 6 Sep 2009, Boris Zbarsky wrote:

Ian Hickson wrote:

1. Its element must be attached to the document.

I'm told this is considered a bug.

Told by whom, if I might ask?


I thought by you, but apparently I misunderstood the point you had been 
making! I've changed HTML5 to not instantiate plugins when their element 
is not in the document, and to uninstantiate any that are removed from the 
document.


Ah.  I must have been unclear.  We (Gecko) consider it a bug that a 
display:none  in a document doesn't instantiate the plug-in.  I 
don't think we have an opinion yet on s that are not in 
documents at all; I suspect making those instantiate would be 
suboptimal, but that's really just a gut feeling with no data to back it up.


I didn't realise that the list of types the UA supported and the list of 
types plugins supported could overlap.


Fixed.


Indeed.  Thanks!

As far as text/plain goes, the current spec text means that if I have a 
PostScript file that includes some "binary" bytes in the first 512 bytes 
and my web server sends text/plain for it and the  has a type 
attribute with the value "text/plain" then the data will be treated as 
application/postscript.  That doesn't seem desirable to me.  Is it 
intentional?


Yes. This is the same as happens if you navigate straight to such a file, 
as far as I can tell. Why would we not want that?


One difference is that in this case in addition to the text/plain 
content-type header (which we know is untrustworthy) there is also an 
out-of-band @type attribute saying text/plain, which presumably 
represents the author's wishes.


Since the whole point of text/plain sniffing is a workaround around a 
known issue where content is reliably mis-marked as text/plain, and 
since in this case there is a source of MIME information that's more 
reliable than that, it's not clear to me why we want to continue sniffing.


Of course if there is no @type there is no problem; I'm specifically 
concerned about the @type="text/plain" case here.


My concern about text/plain data being sniffed as text/html by your 
current algorithm (even with the changes you've made) seems to remain 
unaddressed.  That's a critical issue, no?


-Boris

Re: [whatwg] Spec comments, section 4.11

[Ian Hickson]

On Mon, 7 Sep 2009, Aryeh Gregor wrote:
>
> In "The command element":
> 
> 'the checkbox" maps to the Checkbox'
> 
> Missing 'keyword "' or such before 'checkbox'.

Fixed.


> In "The menu element":
> 
> "Tool bar" looks weird to me.  Isn't "toolbar" more common?

"Tool bar" appears to be the historically correct term, "toolbar" seems to 
be a new spelling.


> In "Introduction" (subsection of "The menu element"):
> 
> Is it intentional that the "save" button has an id, and none of the others do?

Probably originally. Removed it though. :-)


> Also, no offense to whoever made that image, but maybe someone could 
> volunteer to whip up something that looks a little more attractive? We 
> have some designers who post here, I think.

Volunteers welcome!


> In "Commands":
> 
> "This attribute will be shadowed by the icon attribute on command elements."
> 
> What does "shadowed" mean here?

It means the same as it always means in computer science:

   http://en.wikipedia.org/wiki/Variable_shadowing


> Should it be a link to something? The same goes for the other attributes 
> with similar sentences.  Also, in two cases it says "xxx IDL attribute", 
> and twice it omits the word IDL -- is that intentional?

Fixed.


> In "The div element":
> 
> "she plays her new physique to the neighbors regularly, in an attempt to 
> get pets."
> 
> It's an example and a rather whimsical one at that, but I don't know 
> what "plays her new physique" means

She lost her leg (when she came back from her 3-week absence it was 
broken, and despite 3 hours of surgery trying to save it, it had to be 
amputated), and now she goes out and limps on purpose near our neighbours 
to get them to pet her. It works, too. She really plays that pity card to 
its full possible potential.


> and would think you mean "to get petted" or such.

I was using "pets" in the plural noun form.


> (And I'm an American, FWIW.  :P)

I'm British. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Fakepath revisited

[Eduard Pascual]

On Mon, Sep 14, 2009 at 3:12 AM, Ian Hickson  wrote:
> Here are some bug reports that I believe are caused by this issue:
>
>   
> http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routers&message.id=135649
>   http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-tweaking
>   
> http://www.rx8club.com/showpost.php?s=42aad353530dfa4add91a1f2a67b2978&p=2822806&postcount=3269
This is factual data, thank you.

>   http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx
This, on contrast, is not. It's an interesting read, and a good
rationale, but it doesn't show any real-world example of what is
causing the issue. From that page (or from all Microsoft's posts,
mails, etc I have seen around the topic), the only "proof" they give
about the problem actually exists was their own word. I won't say
whether Microsoft's word on something should be trusted (there are
enough "MS evangelists" and "MS haters" out there to guarantee
perpetual disagreement on this), but just wanted to point out that
such word is not the same as factual data.

> I would love more data.
Although I'd also love it, I don't really need it. The few links you
posted, quoted above, are enough to show that this is a real issue.
That's all I was asking. Thanks again.

Please, let me clarify that my examples of filenames containing
backslashes were purely theoretical. I have no factual data to back
them, and I don't really need it. Without actual examples on the need
of fakepath, they were at the same position as the arguments standing
in favor of fakepath. Their only goal was to encourage bringing
specific data about the need for fakepath, and it has been achieved.

Now, maybe stepping on a side topic, I'd like to bring back a separate
request: I think, if fakepath is to be included on the spec, that
content authors shouldn't be left at their own risks. Considering that
"pre-HTML5" browsers (like IE 6 and 7 or FF2) are going to stay there
for a while, approaches like substr(12) or any other means of just
trimming "C:\fakepath\" just won't work. Last indexof("\\") would
break on any browser that doesn't include path at all (that's what
fakepath is addressing, after all), as well as any browser that runs
on Unix-like systems and provides full path (not sure if there is any
current browser on this category).
Is there any way we content authors can reliably retrieve a filename
from scripts, other than special-casing several versions of each
browser in existence?
More specifically, would .files[0] work on those "pre-HTML5" browsers?
If it does, this is a non-issue. However, if it doesn't, I'd like to
suggest adding an algorythm on the spec to deal with this task. Just
like the spec offers algorythms for browsers to deal with
non-compliant existing content, on cases like this it would be equally
valuable to have algorythms for content to deal with non-compliant
existing browsers.

I am Ok with working around content's brokenness when fixing the
content is not an option; but that shouldn't be done at the expense of
good content and careful authors.

Regards,
Eduard Pascual

Re: [whatwg] Global Script proposal.

[Ian Hickson]

On Mon, 7 Sep 2009, Dimitri Glazkov wrote:
> On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson wrote:
> >> Another case is an application that uses navigation from page to page 
> >> using menu or some site navigation mechanism. Global Script Context 
> >> could keep the application state so it doesn't have to be 
> >> round-tripped via server in a cookie or URL.
> >
> > You can keep the state using sessionStorage or localStorage, or you 
> > can use pushState() instead of actual navigation.
> 
> First off, sessionStorage and localStorage are not anywhere close to 
> being useful if you're dealing with the actual DOM objects. The JS code 
> that would freeze-dry them and bring back to life will make the whole 
> exercise cost-prohibitive.

Indeed. I don't see why you would want to be keeping nodes alive while 
navigating to entirely new documents though.


> But more to the point, I think globalScript is a good replacement for 
> the pushState additions to the History spec. I've been reading up on the 
> spec an the comments made about pushState and I am becoming somewhat 
> convinced that pushState is confusing, hard to get right, and full of 
> fail. You should simply look at the motivation behind building JS-based 
> history state managers -- it all becomes fairly clear.
> 
> The best analogy I can muster is this: pushHistory is like creating 
> Rhoad's-like kinetic machines for moving furniture around the house in 
> an effort to keep the tenant standing still. Whereas globalScript 
> proposes to just let the poor slob to walk to the chest to get the damn 
> socks.
> 
> My big issue with pushHistory is that it messes with the nature of the 
> Web: a URL is a resource you request from the server. Not something you 
> arrive to via clever sleight of hand in a user agent. So, you've managed 
> to pushState your way to a.com/some/path/10/clicks/from/the/home/page. 
> Now the user bookmarks it. What are you going to do know? Intuitively, 
> it feels like we should be improving the user agent to eliminate the 
> need for mucking with history, not providing more tools to encourage it.

The only criticism of substance in the above -- that pushState() lets you 
change the URL of the current page when you change the page dynamically -- 
is pretty much the entire point of the feature, and I don't understand why 
it's bad. I certainly don't want to require that every pan on Google Maps 
require a new page load.


On Tue, 8 Sep 2009, Anne van Kesteren wrote:
>
> If JavaScript can be somehow kept-alive while navigating to a new page 
> within a single domain, be in control of what is displayed and without 
> security issues and all that'd be rather cool and also solve the issue.

This seems substantially less preferable, performance-wise, than having a 
single Document and script, using pushState().

The pushState() model is basically fixing the AJAX model to work right; it 
seems like a good thing to me.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] HTML 5 buttons and constraint validation

[Ian Hickson]

On Sun, 6 Sep 2009, Alex Vincent wrote:
>
> There's a possible disconnect between  and 
> .  The former is barred from constraint validation, but the 
> latter is not.  (Section 4.10).  Is this intentional?

On Mon, 7 Sep 2009, Michelangelo De Simone wrote:
> 
> I guess it's a mistake; actual implementation of willValidate flag on 
> WebKit assumes that both of them (button and type=button) are barred 
> from validation.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] size content attribute on

[Ian Hickson]

On Sun, 6 Sep 2009, Aryeh Gregor wrote:
>
> The current spec prohibits input elements in the Number state from 
> having the size attribute:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#number-state
> 
> I don't see the reason for this.  It seems at least as likely that the 
> author would like to provide a hint for the length of a number field as, 
> say, a URL field.  Users are likely to only want to submit one- or 
> two-digit numbers in some cases, and decimal numbers with very high 
> precision in other cases.  It would be reasonable to have size=3 for an 
> "age" field, for instance, but a much larger size for a field in a 
> scientific application.  Of course, if the UA provides an input 
> mechanism that doesn't resemble a text box, it might not be relevant to 
> that particular UA, but a text-boxy thing is a logical way to implement 
> type=number, and in fact that's how Opera does it.

Use the min, max, and step attributes to specify the range, then the UA 
can automatically determine the size.


> Also note that even when UAs are expected to implement special input
> mechanisms where specifying size doesn't make sense, it could still be
> useful to specify a size to get more graceful fallback in older
> browsers.  The default  size in most browsers is likely quite a
> lot larger than necessary to specify a time, for instance.  It's worth
> considering allowing size for all the new input types for that reason.

That's an interesting idea. In practice, though, I think people will have 
much more elaborate fallback than just text -- using script -- so that the 
size="" attribute isn't that important for this purpose. When no script is 
available, the default size is fine, IMHO. I'd rather make the conformance 
criteria be forward-looking here.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] More prohibited characters for unquoted attributes are needed

[Ian Hickson]

On Sun, 6 Sep 2009, Aryeh Gregor wrote:
>
> See some research here:
> 
> http://code.google.com/p/html5lib/issues/detail?id=93
> 
> It seems like in addition to whitespace and "'=<> , the characters 
> U+ through U+0020 should be banned from unquoted attribute values, 
> as well as U+0060 (backtick `), for the sake of compatibility.

On Mon, 7 Sep 2009, Geoffrey Sneddon wrote:
> 
> Apparently Hixie had previously said he didn't want to change this as it 
> will become a non-issue over time. I think it does matter due to the 
> security issues it presents in existing UAs. Conforming markup (using 
> elements/attributes allowed in HTML 4.01) should not cause JS to execute 
> in one browser but not in another.

The right fix here is to have the browsers all implement the same parser 
algorithm.

Validators are welcome to warn about this case, though.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Spec comments, sections 4.9-4.10

[Ian Hickson]

On Sun, 6 Sep 2009, Aryeh Gregor wrote:
> >> In 4.10.4:
> >>
> >> It's a little confusing that no visual distinction is made between
> >> content attributes and DOM attributes here.  I thought it was an error
> >> that checked occurred twice, for instance.  (Or is it an error? Things
> >> like max and min only occur once even though they have both content and
> >> DOM attributes.)
> >
> > Do you mean in the table?
> 
> Yes.

I removed the row for "checked", since it was redundant, and added 
annotations for the other IDL attributes.


> > I'm not really sure what you mean here.
> >
> >  - There's the element's "value" content attribute.
> >  - There's the element's "value" DOM attribute.
> >  - There's the "value" mode that the "value" DOM attribute can be in.
> >  - There's the element's "defaultValue" DOM attribute (which reflects the
> >    element's "value" content attribute).
> >  - There's the element's actual value.
> >  - There's the value exposed to the user.
> >
> > Are you asking that the fifth of these (the value concept) should be
> > renamed to something else?
> 
> I'm not really sure, I just know I got confused by which "value" was
> being referred to in various cases.  I'm not sure I can suggest any
> better wording, because I think I still don't understand what "value"
> is being referred to in a lot of cases.

Which of the above is unclear?


> >> Likewise, sentences like "Unless otherwise specified, the user agent 
> >> should not allow the user to modify the element's value or 
> >> checkedness." are very perplexing.  It would make more sense at 
> >> first sight if it said ". . . the element's default value or default 
> >> checkedness."
> >
> > What's the element's default value or default checkedness?
> 
> I guess it's the same as the value content attribute, actually.  Or the 
> presence/absence of the checked content attribute.

Ah. I think I'd rather stick to the explicit terms instead of adding more!


> > It means that the internal states named "value" and "checkedness" 
> > can't be changed by the user unless otherwise stated. These aren't 
> > default anythings, and can have little to no bearing on what is 
> > exposed through the DOM or markup.
> 
> So this is overridden for a lot of things by saying "the user agent 
> should allow the user to change X", then, and you really mean the actual 
> current value that will be submitted with the form.

Right.


> I didn't get that at all from reading it; I thought it referred to the 
> value/checked content attributes or something, because saying that the 
> current/submittable value couldn't be changed unless otherwise stated 
> seemed very unlikely to me. The general rule is it *can* be changed, in 
> practice, with some exceptions, so this way of stating it seems 
> backwards (and thus confusing given all the meanings of "value" flying 
> around).

Nothing is to be read between the lines -- unless it says that something 
can be changed, the default assumption is that it can't be changed. (There 
are a finite number of things that can be changed, and an infinite number 
that cannot, so it doesn't make sense to do it the other way around.)


> >> In 4.10.4.1.2:
> >>
> >> What's the purpose of type=search?  Is it envisioned that this be 
> >> used as an inline substitute for OpenSearch, for instance? Or is it 
> >> mainly intended to allow separate styling (e.g., to match platform 
> >> conventions)?  I can't find any practical normative difference, so 
> >> it would be useful if there were an informative note making it clear 
> >> what some differences might be in practice.
> >
> > The difference is stylistic. Compare the two in Safari.
> 
> I think more informative notes about the purpose of things like this 
> would make the spec a lot easier to comprehend.

Added a note about this.


> >> In 4.10.4.1.7:
> >>
> >> "If the element is mutable, the user agent should allow the user to 
> >> change the global date and time represented by its value, as obtained 
> >> by parsing a global date and time from it. User agents must not allow 
> >> the user to set the value to a string that is not a valid global date 
> >> and time string expressed in UTC, though user agents may allow the 
> >> user to set and view the time in another time zone and silently 
> >> translate the time to and from the UTC time zone in the value. If the 
> >> user agent provides a user interface for selecting a global date and 
> >> time, then the value must be set to a valid global date and time 
> >> string expressed in UTC representing the user's selection. User 
> >> agents should allow the user to set the value to the empty string."
> >>
> >> This paragraph looks repetitive to me.  I think the third sentence 
> >> can just be dropped, unless I'm missing something -- does it add 
> >> anything?
> >
> > This paragraph is setting out precisely what the requirements are for 
> > user agents. The four sentences each cover a slightly different aspect 
> > of the re

Re: [whatwg] Fakepath revisited

[Simon Pieters]

On Mon, 14 Sep 2009 03:12:39 +0200, Ian Hickson  wrote:


Here are some bug reports that I believe are caused by this issue:

   
http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routers&message.id=135649


Note this message in particular:

"I've fought this on a new WRT110 for a week, tried the Code.bin idea and  
other ways to shorten the path, but only switching back from Firefox to  
IE7 solved this particular problem. Thanks a lot!"


--
Simon Pieters
Opera Software

Re: [whatwg] Any chance for Double Buffering in the ?

[Ian Hickson]

On Sat, 5 Sep 2009, Marius Gundersen wrote:
>
> I've been playing around with the canvas element, making a 3D engine. It 
> works, but is incredibly slow. Part of the reason is probably that the 
> browser renders the canvas everytime I draw something to it. In a 3D 
> engine, as well as a game engine, the entire canvas is erased and 
> redrawn several times a second, and only at the end of each frame does 
> it need to be rendered to the screen.
> 
> This could be solved with a double buffer, and an explicit redraw() 
> function called at the end of each frame. for example:
> 
> function render(){
>   ctx.clearRect(0, 0, width, height);
>   drawSpaceShip(ctx);
>   for(var i=0; i drawSpaceInvader(spaceInvaders[i], ctx);
>   }
>   ctx.repaint();
> }
> 
> Of course this is not always desirable. The context2D could therefore 
> have a flag which turns on and off double buffering. Set to true, the 
> canvas is only redrawn when the repaint function is called, set to 
> false, it will repaint every time the user calls a function that draws 
> to the canvas (drawImage, fillRect, stroke... etc).
> 
> So, to sum up, this is what should be added to the context2D object:
> 
> attribute boolean doubleBuffer; //(default false)
> void repaint(); //repaints the entire canvas. Only used if doubleBuffer is
> true

On Sat, 5 Sep 2009, Robert O'Callahan wrote:
> 
> I assume you have a setTimeout handler (or similar) which renders a 
> complete frame before returning. If so, then in Gecko and I think also 
> in Webkit the canvas will not be drawn to the screen while your script 
> is running, only between frames. So I suspect your performance problem 
> has some other cause.

Based on roc's comments, I haven't added the feature here.

It should be noted that long-term, the right solution for 3D is a 3D API, 
not a library on top of the 2D API.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Robert O'Callahan]

On Mon, Sep 14, 2009 at 7:43 PM, Ian Hickson  wrote:

> I agree that sometimes antialiasing leads to seams, though; the solution
> to that isn't to disable antialiasing, though (that would just replace one
> problem with another), the solution is to provide new features that allow
> you to create composite paths that are stroked or filled in one operation
> (with one single antialiasing step) instead of requiring multiple distinct
> operations (each with their own antialiasing).
>

That often isn't possible because the information required is not available.
For example, if you were implementing a Postscript interpreter on top of
canvas, you couldn't do this.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

Re: [whatwg] HTML 5 drag and drop feedback

[Ian Hickson]

On Thu, 3 Sep 2009, Francisco Tolmasky wrote:
> On Aug 30, 2009, at 7:46 PM, Ian Hickson wrote:
> > 
> > The big thing to realise about this API is that it isn't young -- it's 
> > what IE has shipped for about 10 years, and what Safari has had for a 
> > bit less than that.
> > 
> > We should definitely extend the API going forward, but I'd rather wait 
> > until the browsers implement this set of features reliably before 
> > adding more features.
> 
> I can certainly see the logic behind this, and admittedly my second 
> request (explicitly starting drags) may be particularly difficult to add 
> without changing the spec too much. I will continue to think if there is 
> some trickery that can be done with this.
> 
> However, I think the addition of the deferred setData methods could be 
> added today in a way that is completely backwards compatible with 
> current implementations and would still be of great benefit. 
> Specifically, my request for deferring the calling of toString on 
> non-string objects as such:
> 
> event.dataTransfer.setData("something", { toString: function() { return
> expensiveFunctionCall(); } });
> 
> This would allow me to submit patches to Firefox and WebKit that would 
> solve the current performance issues which are literally blocking my 
> ability to switch from "fake" drag and drop to "native" drag and drop. 
> At the same time, this should still work today in all browsers that 
> implement setData because the object is coerced into a string 
> immediately for you, thus not requiring immediate action on their part 
> to change anything.

Yes, that is a neat solution. However, it is still the case that at this 
time we should not add new features, otherwise we might get too far ahead 
of the implementations, and the quality of implementations will go down.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Ian Hickson]

On Mon, 14 Sep 2009, Marius Gundersen wrote:
> >
> > What part of that e-mail suggested that it had anything to do with 
> > browsers not implementing it?
>
> This part indicates that it is not implemented because some browsers 
> might ignore it:
> 
>> causing browsers that support these features to render certain sites 
>> significantly worse or slower (or both) than browsers who ignore these 
>> flags and instead apply heuristics to determine the optimal rendering 
>> modes.

Ah, yes, I suppose that does mean that browsers wouldn't implement it, 
since they'd be at a disadvantage if they did.


> The composite paths that you indicated sounds cool, but sounds like 
> something I asked about previously, namely having an explicit method for 
> redrawing the canvas when the user is done.

That's similar, though not quite the same, yes.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Marius Gundersen]

This part indicates that it is not implemented because some browsers might
ignore it:

causing browsers that support these features to render
certain sites significantly worse or slower (or both) than browsers who
ignore these flags and instead apply heuristics to determine the optimal
rendering modes.

The composite paths that you indicated sounds cool, but sounds like
something I asked about previously, namely having an explicit method for
redrawing the canvas when the user is done.

Marius Gundersen

On Mon, Sep 14, 2009 at 5:43 PM, Ian Hickson  wrote:

> On Mon, 14 Sep 2009, Marius Gundersen wrote:
> > >
> > > This has been considered before:
> > >
> > >
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011263.html
> >
> > so it was decided against because some browsers might not implement it?
>
> No, not at all. What part of that e-mail suggested that it had anything to
> do with browsers not implementing it?
>
>
> > In some cases turning off anti aliasing isn't just about speed or
> > beauty, in some cases it can introduce things that should not be there.
> > For example, notice the white line running diagonally across the face of
> > the crate here:
> > http://www.mariusgundersen.net/projects/Canvas3D/step6.html
>
> The right way to do 3D rendering is not to use a 2D canvas but to use a 3D
> canvas, such as is being developed (in secret, for some reason) by the
> Khronos group.
>
> I agree that sometimes antialiasing leads to seams, though; the solution
> to that isn't to disable antialiasing, though (that would just replace one
> problem with another), the solution is to provide new features that allow
> you to create composite paths that are stroked or filled in one operation
> (with one single antialiasing step) instead of requiring multiple distinct
> operations (each with their own antialiasing).
>
> Such new features will likely be considered for a future version.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] HTML extension for system idle detection.

[David Bennett]

On Sun, Sep 13, 2009 at 9:51 AM,  wrote:

>
> Sure it can. The user is effectively idle, in that they are not using
> your web application .
>

Not really, it is possible to notify people that someone in a new tab has
sent a message and that it requires attention.  The whole reason for this
api is that this statement is not always true.


> In short, what I'm saying is that I'm objecting to a procedure for
> system idle, the concept is broken and it won't work, and i'll be
> forced to break it the day after it's integrated into Gecko and then
> people will wonder why it doesn't work.
>

I am not really sure you made this particular argument.  I also don't see
why, in your particular case, you couldn't make it so that all background
tasks are 'idle'.

The concept of system idle is very important for doing rich client based im
clients, and for other rich client based things like games and other things
where it is important to know that the user is potentially available.

Thanks,
David.

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Ian Hickson]

On Mon, 14 Sep 2009, Marius Gundersen wrote:
> >
> > This has been considered before:
> >
> >   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011263.html
>
> so it was decided against because some browsers might not implement it? 

No, not at all. What part of that e-mail suggested that it had anything to 
do with browsers not implementing it?


> In some cases turning off anti aliasing isn't just about speed or 
> beauty, in some cases it can introduce things that should not be there. 
> For example, notice the white line running diagonally across the face of 
> the crate here: 
> http://www.mariusgundersen.net/projects/Canvas3D/step6.html

The right way to do 3D rendering is not to use a 2D canvas but to use a 3D 
canvas, such as is being developed (in secret, for some reason) by the 
Khronos group.

I agree that sometimes antialiasing leads to seams, though; the solution 
to that isn't to disable antialiasing, though (that would just replace one 
problem with another), the solution is to provide new features that allow 
you to create composite paths that are stroked or filled in one operation 
(with one single antialiasing step) instead of requiring multiple distinct 
operations (each with their own antialiasing).

Such new features will likely be considered for a future version.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web Storage: apparent contradiction in spec

[Ian Hickson]

On Thu, 3 Sep 2009, Tab Atkins Jr. wrote:
> >
> > Flash's privacy problem can be removed by uninstalling Flash. They're 
> > not a license to add more privacy problems to the platform.
> 
> And more-than-a-cache-Storage can be explicitly turned off or have its 
> quota dropped to zero.  If that's important, the browsers will make it 
> easy.  And more importantly, they'll make it *consistent* (within the 
> browser), rather than the user having to figure out how to do it within 
> Flash, then possibly within the next technology that hacks around this 
> lack in browser technology, and the next one...
>
> > But I'm not speccing something that so blatently allows users to be 
> > tracked without their consent -- and worse -- despite their attempts 
> > to stop it.
> 
> It doesn't 'allow users to be tracked without their consent' any more 
> than cookies by themselves do.

It's the second part that's the problem.


> If this is important, browsers will expose the ability to blow away all 
> of a site's storages at once.

Right, that's what the spec encourages.


> You're seem to be assuming that either permanent Storage is *really* 
> permanent, or that browsers will never expose a way to delete that data 
> to the user (which amounts to the same).

Then I'm not expressing myself way. My concern is just that users will not 
realise that clearing away cookies doesn't stop sites from tracking them 
as it used to.


> Would an approach like the  be okay, where the user has 
> to explicitly take an action to enable permanent Storage for a site the 
> first time?

There are plenty of use cases where there's nothing to explicitly save, so 
no, I don't think that would work.


> That makes simple navigation exactly as safe as it is today, where 
> cookies can leak privacy but they can be wiped. You have to actively opt 
> in to reducing your privacy.  I *want* to be able to reduce my privacy 
> for sites that I trust.

Nothing is stopping you, is it?


On Thu, 3 Sep 2009, Peter Kasting wrote:
> On Thu, Sep 3, 2009 at 5:17 PM, Ian Hickson  wrote:
> > On Thu, 3 Sep 2009, Peter Kasting wrote:
> > >
> > > Something like this would be more clear: "If users attempt to 
> > > protect their privacy by clearing cookies without also clearing 
> > > persistent storage data, sites can defeat those attempts by using 
> > > the two features as redundant backup for each other.  User agents 
> > > should present the interfaces for clearing these in a way that helps 
> > > users to understand this possibility and enables them to delete data 
> > > in both simultaneously."
> > >
> > > IMO this achieves what you're trying for while leaving the actual UI 
> > > design as open as possible.
> >
> > Do you mean this as a repalcement or in addition to what's in the spec 
> > now?
> 
> Replacement.

Ok, done.


> > For the Cookie Resurrection section or the User Tracking section?
> 
> Cookie resurrection section.  Although because the comments in both 
> sections are so similar, I'm not sure I see value in having two 
> sections.  Just having one, which has this text, seems fine.

Merged them together.

Cheers,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Turn off Anti-Aliasing in Canvas

[Marius Gundersen]

so it was decided against because some browsers might not implement it?
isn't the point of a specification that all browsers implement it :p

In some cases turning off anti aliasing isn't just about speed or beauty, in
some cases it can introduce things that should not be there. For example,
notice the white line running diagonally across the face of the crate here:
http://www.mariusgundersen.net/projects/Canvas3D/step6.html

Marius Gundersen

On Mon, Sep 14, 2009 at 5:03 PM, Ian Hickson  wrote:

> On Mon, 14 Sep 2009, Marius Gundersen wrote:
> >
> > A way to speed up drawing to the canvas would be to turn off
> > anti-aliasing. Currently there is no way to do this. Is that something
> > that will be added in the future?
>
> This has been considered before:
>
>   http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011263.html
>
> Cheers,
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>